✓この記事でわかること
- 1CRLF・LF・CRの違いと、利用先に合わせた選び方
- 2改行コードが混在したファイルで起きる表示・処理上の問題
- 3文字コードやBOMと切り分け、変換前後を確認する手順
同じ文章なのに、アプリによって行の区切り方が違う、Gitの差分が行単位で増える、CSVを渡した相手の環境で読み込み結果が変わる。こうした問題では、文字そのものではなく「改行コード」が合っていない可能性があります。見た目だけで判断せず、ファイルの中身を診断してから変換するのが安全です。
結論：まず改行コードを数え、利用先に合わせて変換する
迷ったときは、入力ファイルの改行コードがCRLF、LF、CRのどれか、または混在しているかを確認します。Webや開発用ファイルではLF、Windows向けのテキストやExcel向けCSVではCRLFが使われることが多い一方、相手先の指定がある場合はその指定を優先します。変換後は、行数、改行の種類、文字化けの有無をプレビューで確認してから保存します。
1. CRLF・LF・CRは何が違うのか
改行は画面上では同じ1行の区切りに見えますが、ファイル内部では異なる制御文字の並びで表されます。CRLFはCRとLFの2文字、LFはLFの1文字、CRはCRの1文字です。現在の環境ではLFとCRLFを目にすることが多く、CRは古い形式や一部の特殊なファイルで残っています。
| 形式 | 主な利用場面 | 注意点 |
|---|---|---|
| CRLF | Windows向けのテキスト、Excel向けCSVなど | 受け渡し先がWindows前提なら候補 |
| LF | Unix系、macOS、Web、ソースコードなど | 開発環境やWeb向けで扱いやすい |
| CR | 古い形式や一部の特殊なデータ | 変換前に利用先の指定を確認 |
「Windowsだから必ずCRLF」「macOSだから必ずLF」と決めつけるのではなく、実際の受け渡し先やプロジェクトのルールを確認します。特にCSVは、改行コードだけでなく文字コードやBOMの指定も別に存在するため、1つの設定だけで問題が解決するとは限りません。
2. 改行コードが混在すると起きること
ファイルの途中でCRLFとLFが混ざっていても、一般的なエディタでは普通に読める場合があります。そのため、見た目だけでは混在に気づきにくいのが特徴です。しかし、行単位で処理するツール、差分表示、CSVの取り込み、スクリプトの解析では、行数や区切りの扱いが想定とずれることがあります。
混在を放置した場合
- 差分に不要な変更が大量に表示される
- 一部の行だけ空行や連結行に見える
- 別の環境で行数や読み込み結果が変わる
変換前に確認すること
- CRLF・LF・CRの件数と混在状態
- ファイルの行数と末尾改行の有無
- 利用先が指定する改行コード
ただし、混在しているから必ず壊れているとは限りません。受け渡し先が混在を許容している場合もあるため、変換の目的を明確にします。不要な一括変換で差分を増やさないためにも、診断結果を確認してから処理することが重要です。
3. ファイルを診断してから変換する手順
変換は、いきなり保存形式を決めるのではなく、入力の状態、利用先、出力後の検証を順番に確認します。次の流れなら、文字化けと改行崩れを別々に切り分けやすくなります。
入力ファイルを読み込む
TXT、CSV、TSV、JSON、MD、HTML、CSS、JS、LOGなど、実際に渡すファイルを選びます。
診断結果と改行件数を見る
CRLF・LF・CRの件数、行数、置換文字、制御文字を確認し、混在していればそのまま変換しない理由を考えます。
利用先に合う出力を選ぶ
Webや開発用ならLF、Excel向けCSVならUTF-8 BOM付きCRLFなど、受け取る側の条件に合わせます。
プレビューと再診断を確認する
行数、改行件数、文字化けの疑い、BOMの有無が意図した設定になっているかを確認して保存します。
4. AI・PowerShellの編集経路と、文字コード・BOMを分けて考える
文字コードは文字をバイト列へ変換するルール、改行コードは行の区切りを表すルールです。文字コードが正しくても改行が混在することがあり、改行を統一しても文字コードが違えば文字化けします。両方を一度に変更する場合は、変換後にそれぞれを確認します。
AI・バイブコーディングで確認したいこと
AIにコードの作成や修正を依頼する機会が増えても、文字コードや改行コードを決めるのはAIの回答文だけではありません。エディタでの保存、ターミナルからの書き込み、Gitのチェックアウト、パッチの適用といった途中の処理で、ファイルの形式が変わることがあります。AIのせいだと決めつける前に、変更前後のファイルと差分を確認します。
AI修正後の確認順
- Git差分で、意図した行だけが変更されたかを見る
- 全行が変更された場合は、改行コードの変換を疑う
- 日本語が含まれる場合は、文字化けとBOMを診断する
リポジトリ側の確認
.gitattributesのtext/eol指定core.autocrlfの設定とOSごとのチェックアウト結果- エディタの保存時エンコーディングと改行設定
Gitの改行変換については、Git公式のgitattributesドキュメントにある text、eol、core.autocrlf の説明も確認できます。プロジェクトのルールがある場合は、個人のエディタ設定よりリポジトリの方針を優先します。
AIで生成したコードを貼り付けた直後に保存・変換を重ねると、どの段階で変わったのか分かりにくくなります。まず元ファイルをコピーして診断し、AIの変更、改行の統一、文字コードの変換を別々に行うと原因を追いやすくなります。
PowerShellで保存したファイルを確認する
PowerShellはバージョンやコマンドレットによって、ファイル出力時の既定エンコーディングが異なります。特にWindows PowerShell 5.1とPowerShell 7以降では、UTF-8やBOMの扱いが同じではありません。詳しい既定値はMicrosoftの文字コードに関する公式説明で確認できます。
- Windows PowerShell 5.1では、
>やOut-FileがUTF-16LEになる場合がある - Windows PowerShell 5.1の
-Encoding UTF8は、UTF-8 BOM付きとして扱われる - PowerShell 7以降は、既定のテキスト出力がUTF-8 BOMなしになっている
- 読み込みに失敗したファイルを、文字コードを指定せず再保存しない
まず $PSVersionTable.PSVersion でPowerShellのバージョンを確認し、出力コマンドの -Encoding を省略しないようにします。ただし、変換前に読み込み自体が文字化けしていると、正しい文字列へ戻せないまま保存される可能性があります。保存前後のファイルをツールで診断し、文字コード、BOM、改行コード、行数をそれぞれ確認してください。
自動判定をそのまま信じない場面
- ASCII文字だけのファイルで、UTF-8とShift_JIS系を区別できない
- 読み込み結果に置換文字があり、入力文字コードが違う可能性がある
- BOMの有無を受け渡し先が指定している
- 現行版はUTF-8出力が中心で、Shift_JIS出力を確定する機能ではない
BOMはファイル先頭の識別用バイト列であり、改行コードそのものではありません。Excel向けCSVなどではBOMが必要な場合がありますが、Webや開発用ファイルでは不要な場合もあります。用途別プリセットを使う場合も、保存先の条件と出力後の表示を確認してください。
まとめ
改行コードの問題は、見た目が同じでもファイル内部の区切りが異なることから起きます。まずCRLF・LF・CRの件数と混在状態を診断し、受け渡し先の条件に合わせて変換します。文字コードやBOMとは別の項目として確認し、変換後の行数、プレビュー、文字化け疑い、BOMを再確認してから利用しましょう。