CRLF と LF の違いとは？改行の違いを解説
CRLF と LF は一般的な 2 つの行末スタイルです。Windows は行末を carriage-return と line-feed で終え、Unix は line-feed のみを使います。
CRLF 対 LF は、ほとんどの改行問題の裏にある具体的で実践的な争いです。Windows のツールはデフォルトで CRLF を使い、Linux と macOS は LF を使い、CI は通常 Linux 上で動作します。ファイルが正規化されずにその境界を越えると、スクリプトは失敗し diff はノイズになります。これは改行の話の日常版であり、実際に何をすべきかに焦点を当てています。
CRLF と LF とは何か
LF は単一の line-feed バイトです。CRLF は carriage-return バイトに続いて line-feed バイトが来ます。どちらも行を終えますが、LF が 1 バイトで済むところを CRLF は 2 バイト使います。CRLF の余分な carriage return が、CRLF ファイルが LF を期待するツールで処理されるときの厄介者です。
Windows と Unix の分断
この分断は歴史的なものです。CRLF はテレタイプの時代に由来し Windows に残った一方、Unix は LF に簡素化しました。今日ではほとんどの CI runner、コンテナ、サーバーは Linux であり LF を期待するため、Windows で作成された CRLF ファイルが摩擦の一般的な原因になります。
なぜ CI を壊すのか
CRLF で保存された shell スクリプトは shebang 行の末尾に不可視の carriage return を持つため、runner は末尾に CR の付いたインタープリタのパスを実行しようとし、紛らわしい「no such file」エラーで失敗します。文字列比較や設定のパースも、隠れたバイトのせいで静かに一致しなくなります。
gitattributes で解決する
恒久的な修正は git に行末を正規化させることです。.gitattributes ファイルはテキストファイルを LF としてチェックインすると宣言するため、エディタや OS に関わらず runner は常に LF を見ます。これは各コントリビューターにエディタの設定を頼むよりも信頼できます。
# Force LF for scripts so CI never sees CRLF
* text=auto eol=lf
*.sh text eol=lf素早い診断
スクリプトが Windows のローカルでは動くのに Linux runner で即座に死ぬ場合は、CRLF を疑ってください。file や、制御文字を可視化した cat のようなツールが carriage return を明らかにします。LF への変換（dos2unix や git の正規化による）で通常は即座に直ります。
重要なポイント
- LF は 1 バイト、CRLF は carriage-return と line-feed です。Windows は CRLF、Unix は LF を使います。
- CI は Linux 上で動作するため、CRLF のスクリプトは紛らわしい shebang やファイルが見つからないエラーで失敗します。
- テキストファイルに LF を強制する .gitattributes のルールが、クロスプラットフォームな CI のための信頼できる修正です。