日本語圏で人気のテキストエディタ「秀丸エディタ」には、改行コードをCR/LF/CR+LFの中から明示的に選んで保存できるメニューが昔から用意されている——それだけ、Windows中心の日本の開発現場では改行コードの取り違えが実務上の悩みの種として長く意識されてきたということでもある。
この違いはどこから来たのか
UnixとmacOSは1つの文字を使います — LF（ラインフィード、\n）。Windowsは古いテレタイプ端末から2文字のペアを受け継ぎました — CRLF（キャリッジリターン + ラインフィード、\r\n）: 1つはキャリッジを行の先頭に戻し、もう1つはそれを1行下に移動させます — タイプライターの文字通りの模倣です。
今でも重要な理由
- Git。 CRLF改行のファイルが、他のファイルがLFを使うリポジトリに入ると、1行しか編集していなくてもgitが「ファイル全体が変更された」と表示することがあります — 技術的にはすべての行の改行が変わったためです。
- Shebang行。 CRLF改行で保存されたUnixシェルスクリプトは、Linuxサーバー上で実行に失敗することがあります。インタプリタが最初の行に余分な
\r文字を見てしまうためです。 - コード内の文字列比較。 CRLFファイルから読み込まれた行は、見た目のテキストが同じでも、期待されるLF文字列と比較したときにマッチしないことがあります。
どう対処されるか
Gitにはcheckout/commit時に改行コードを自動変換する設定（core.autocrlf）がありますが、各開発者のローカル設定に頼るのは不安定です。リポジトリに.gitattributesをコミットしてファイル種別ごとの改行スタイルを固定するほうが、エディタやOSに依存せず確実です。
手動変換が必要な理由
- 誤った改行スタイルでリポジトリに入ったファイルを修正する。
- Windowsエディタで編集されたスクリプトをLinuxサーバーへのデプロイ前に整える。
- 見た目が同一の2つのファイル間でテキスト比較に差異が出る理由を診断する。
1つのファイル内に混在する改行
複数のエディタや異なるOSで編集されたファイルには、CRLFとLFの両方が同時に含まれていることがあります — 一部の行は一方のスタイル、残りの行はもう一方のスタイルです。これは最も厄介なケースです。「LFへの変換」は、すでにLFだった行に対しては一見何も変わらないように見えますが、目に見えて「怪しい」行だけでなく、ファイル全体に変換を適用することが重要です。そうしないと問題が見えないまま残ってしまいます。