改行コード（CRLF / LF / CR）とは？混在が起こす不具合と直し方
改行の表し方はOSによって異なり、Windowsでは復帰と改行を並べたCRLF、macOSやLinuxでは改行だけのLFが使われます。画面上はまったく同じに見えるため、食い違いは差分や実行時のエラーという形で遅れて表に出ます。Line Ending Inspectorはファイルをバイト列のまま読み、どの改行コードが何件あるか、混在していないかを表示します。
なぜ貼り付けでは調べられないのか
HTMLのテキスト入力欄は、仕様として改行をLFに正規化します。つまりCRLFのファイルをコピーして入力欄に貼り付けた時点で、復帰（U+000D）は失われ、残るのは改行（U+000A）だけです。この状態をいくら調べても「CRは入っていない」としか出ません。改行コードを確認したい場合は、入力欄を経由せずファイルそのものをバイト列として読む必要があります。このツールがドロップでの読み込みだけに対応しているのはそのためです。
混在がいちばんやっかい
1つのファイルの中でCRLFとLFが混ざっている状態は、全体がどちらかに統一されている状態よりも厄介です。エディタは最初に見つけた改行コードをそのファイルの形式として表示することが多く、残りの行が別形式でも気づけません。差分の一部の行だけが理由なく変更として出る、行単位の処理が特定の行でだけ失敗する、といった再現性の低い不具合につながります。少数派の行番号が分かれば、どの編集でそれが入り込んだかを履歴から追えます。
シェルスクリプトが動かない典型例
実行権限もパスも正しいのにスクリプトが動かず、インタプリタが見つからないという趣旨のエラーで止まる場合、1行目の末尾に復帰文字が残っていることが多いです。1行目に書いたインタプリタの指定が、復帰文字まで含めたコマンド名として解釈されるため、その名前のコマンドは存在しないと判断されます。エラーメッセージには見えない文字が含まれているので、画面を見ているだけでは原因にたどり着けません。改行コードを確認するのが最短です。
BOMと最終行の改行も同時に見る
ファイルの先頭に付くBOMも、改行コードと同じく目に見えないまま不具合を起こします。UTF-8のBOMが付いたまま読み込まれると、先頭の値に余分な文字が混ざり、設定ファイルの最初のキーが認識されない、といった形で表に出ます。最終行の改行の有無も確認できます。最後に改行がないファイルは、Gitの差分で最終行が特別な表示になり、別の人が改行を足すだけで差分が2行分出ます。いずれも、見えないがゆえに時間を溶かす種類の問題です。
再発を止めるのはリポジトリ側の設定
手元で変換しても、各自の環境の既定値が違えば同じことが繰り返されます。Gitの個人設定でも変換はできますが、新しく参加した人の環境には効きません。リポジトリに .gitattributes を置き、テキストファイルの扱いを宣言しておくと、設定ファイル自体がリポジトリに入るため全員に同じ規則が適用されます。改行コードが固定されていないと動かないシェルスクリプトなどは、個別に改行だけの形へ固定しておくと安全です。