Gitで git diff を見たら1行も変えていないのに全行が差分として表示された、あるいはWindowsで作ったスクリプトを Macで動かしたら行末に ^Mが出てエラーになった——こうした「あるある」の正体が、CRLFとLFという改行コードの違いです。 この記事では、CRLFとLFの違いから、変換が必要になる典型ケース、ブラウザツール・VSCode・コマンドラインでの 変換手順までを実務目線で解説します。
CRLFとLFの違い
改行コードは「ここで行が変わる」ことを表す制御文字です。ところがこの表現方法がOSによって異なり、 主に CRLF と LF の2種類が使われています。 CR（Carriage Return、復帰）とLF（Line Feed、改行）はもともとタイプライターの動作に由来し、 CRが「行頭に戻る」、LFが「次の行へ送る」操作を表していました。
| 改行コード | バイト表現（16進） | 標準とするOS・環境 | 由来 |
|---|---|---|---|
| CRLF | 0D 0A（2バイト） | Windows・MS-DOS・一部のネットワーク規格 | タイプライターの「復帰＋改行」をそのまま継承 |
| LF | 0A（1バイト） | macOS・Linux・Unix・Web全般 | Unixが改行をLF1文字に簡略化 |
| CR | 0D（1バイト） | Mac OS 9以前（クラシックMac） | 現在はほぼ使われない |
現在は LFが事実上の標準です。macOS（Mac OS X以降）はUnix系なのでLFを採用しており、 HTTP・JSON・各種プログラミング言語のソースもLFが前提です。Windowsだけが歴史的経緯でCRLFを使い続けているため、 WindowsとMac/Linuxをまたいでファイルをやり取りすると改行コードの差が顕在化します。
変換が必要になる典型ケース
改行コードの違いは普段は気づきませんが、次のような場面でトラブルとして表面化します。
1. Gitの差分が全行になる・コンフリクトする
WindowsとMacのメンバーが同じリポジトリで作業すると、改行コードがCRLFとLFで食い違い、 中身は同じなのに「全行が変更された」と表示されます。レビューが困難になり、無意味なコンフリクトも増えます。 後述の .gitattributes で改行コードを固定するのが根本対策です。
2. シェルスクリプトが「^M」でエラーになる
WindowsでCRLF保存したシェルスクリプトをMac/Linuxで実行すると、各行末に残ったCRが原因でbad interpreter やcommand not found が発生します。 スクリプトをLFに変換すれば解決します。
3. ExcelのCSVで行が崩れる
セル内改行や改行コードの不一致があると、CSVを開いたときに1行が複数行に分かれたり、 逆に複数行が1行にまとまったりします。改行コードを揃えると行崩れを防げます。
4. サーバー送信・API連携でデータが壊れる
HTTPヘッダやメール（SMTP）は規格上CRLFを要求しますが、本文データはLF前提のことが多く、 混在すると意図しない空行や解析エラーが起きます。連携先の仕様に改行コードを合わせる必要があります。
ブラウザツールで改行コードを変換する（最も手軽）
インストール不要で一番手軽なのが、ぱんだツールズのブラウザツールを使う方法です。 ファイルはサーバーに送信されず、すべてブラウザ内で処理が完結するため、機密ファイルでも安心です。
- 改行コード変換ツールを開く：改行コード変換ツールにテキストファイルをドロップするか、変換したいテキストを貼り付けます。
- 変換先の改行コードを選ぶ：LF（Mac/Linux）・CRLF（Windows）・CR から目的の形式を選択します。
- 変換結果を取得する：変換後のテキストをコピーするか、ファイルとしてダウンロードします。
ヒント
改行コードと一緒に文字コードも気になる場合は、先に文字コード確認ツールで現在の文字コードを判定し、必要ならテキスト文字コード変換ツールでUTF-8などに揃えておくと、文字化けと改行ズレをまとめて解消できます。
VSCodeで改行コードを変換する
VSCode（Visual Studio Code）なら、エディタ画面のなかで改行コードをワンクリックで切り替えられます。 無料でWindows・macOS・Linuxに対応しています。
- 変換したいファイルをVSCodeで開く
- 画面右下のステータスバーにある EOLインジケータ（「CRLF」または「LF」と表示されている部分）をクリック
- 表示されたメニューから「LF」または「CRLF」を選ぶ
- ファイルを上書き保存する（保存して初めて変換が反映される）
プロジェクト全体で改行コードを統一したい場合は、設定（settings.json）に"files.eol": "\n"を追加すると、新規ファイルがLFで作られるようになります。
コマンドラインで改行コードを変換する
ターミナルでまとめて変換したい場合は、次のコマンドが定番です。状況に応じて使い分けてください。 以下はいずれもCRLFをLFに変換する例です。
dos2unix（最も確実）
改行コード変換専用のコマンドで、迷ったらこれが安全です。
# CRLF → LF（Windows形式 → Mac/Linux形式）
dos2unix input.txt
# LF → CRLF（Mac/Linux形式 → Windows形式）
unix2dos input.txtsed
多くの環境に標準で入っています。行末のCR（\r）を削除します。
# CRLF → LF（行末のCRを削除）
sed -i 's/\r$//' input.txttr
CR文字そのものを削除します。シンプルですがファイル中のすべてのCRを消す点に注意してください。
# CRLF → LF（CRをすべて削除）
tr -d '\r' < input.txt > output.txtnkf（文字コードも同時に変換）
日本語の文字コード変換でおなじみのnkfは、改行コードの変換にも対応しています。-Lu でLF、-Lw でCRLFを指定します。
# CRLF → LF かつ UTF-8 へ変換して上書き
nkf -w -Lu --overwrite input.txt.gitattributesで自動変換する（開発者向け）
チーム開発では、各自のエディタ設定や core.autocrlfに頼るより、リポジトリのルートに .gitattributesを置いて改行コードを固定するのが確実です。これにより、OSやエディタが違っても リポジトリ内の改行コードが揃い、無意味な差分やコンフリクトを防げます。
# すべてのテキストを自動判定し、リポジトリ内はLFに統一
* text=auto eol=lf
# Windows用のバッチ・PowerShellスクリプトはCRLFを維持
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
# バイナリファイルは改行変換しない
*.png binary
*.jpg binary
*.pdf binary.gitattributes を追加・変更した後は、 既存ファイルへ反映させるために git add --renormalize .を実行してコミットします。バイナリファイルに binaryを明示しておくと、画像やPDFが改行変換で壊れる事故を防げます。
まとめ
- CRLF（0D 0A・Windows）とLF（0A・Mac/Linux/Web）はバイト数が違う別の改行コード
- 現代の標準はLF。WindowsとMac/LinuxをまたぐとGitの差分・「^M」・行崩れの原因になる
- 最も手軽な変換は改行コード変換ツール（インストール不要・サーバー送信なし）
- VSCodeなら右下のEOLインジケータをクリックしてLF/CRLFを切り替え、保存で反映
- コマンドラインでは dos2unix・sed・tr・nkf が定番。nkfは文字コードも同時に変換できる
- チーム開発では
.gitattributesで改行コードを固定し、バイナリは変換対象から除外する - 文字コードが気になるときは文字コード確認ツールで判定できる