改行コード変換ツール

改行コードとは？

改行コードとは、テキストファイル内で「行の終わり」を示すために使われる特殊な制御文字のことです。一見すると単なる改行に見えますが、その正体はOSによって異なる1〜2バイトのバイナリデータです。Windowsでは CR + LF（2バイト）、macOS・Linuxでは LF（1バイト）、Classic Mac OSでは CR（1バイト）と、歴史的経緯から複数の流派が併存しています。同じ「改行」に見えても、ファイル内部のバイト列はまったく異なるのです。

歴史的経緯 — タイプライターから始まった2文字の伝統

CR（Carriage Return / 復帰）と LF（Line Feed / 改行）の語源は、機械式タイプライターと初期のテレタイプ端末にあります。タイプライターでは、行末で「キャリッジ（紙を載せた台）を左端まで戻す動作（CR）」と「紙を1行分送る動作（LF）」を別々に行う必要がありました。物理的にこの2動作を完了するには時間がかかったため、初期の電気機械式端末ではタイミング保護も兼ねて両方の制御コードを送る慣習が生まれました。

1970年代、UNIXの開発者たちは「改行ごとに2バイト消費するのは無駄だ」と判断し、LFのみで改行を表現する方式を採用しました。これがUNIX文化の哲学である「シンプルさ」の体現です。一方Microsoft DOS（後のWindows）はCP/Mの影響を受け、テレタイプ互換性を重視してCRLF（2バイト）を踏襲しました。AppleのClassic Mac OSは独自路線を歩み、CRのみで改行を表していました。Mac OS X（2001年）以降、AppleはUNIX系カーネルを採用したことでLFへ移行し、現在のmacOSはLINUXと同じLFを使っています。

改行コードの違いが引き起こすトラブル

ファイルが「1行」として表示される

UNIXで作成したLF改行のファイルを、Windowsの古いメモ帳（Windows 10 Build 17661以前）で開くと、改行が認識されずに文章が1行にベタッと続いて表示されることがありました。逆に、Windowsで作成したCRLFファイルを古いMac OSアプリで開くと、行末にゴミ文字（^M）が表示される現象が起きます。現代のエディタ（VS Code、Sublime Text、Notepad++など）はほとんど自動判別しますが、レガシーシステムや組込み機器ではいまだに問題になります。

Git diffがノイズだらけになる

Windows開発者とMac/Linux開発者が混在するチームでは、リポジトリにコミットされたファイルの改行コードが統一されていないと、Git差分が「中身は変わっていないのに全行変更扱い」になる悲劇が頻発します。レビュー不能、マージ不能の地獄です。これを防ぐために、リポジトリのルートに .gitattributes を置いて改行コードを統一するのがベストプラクティスです。

シェルスクリプトやプログラムが壊れる

WindowsでCRLF改行のまま保存されたシェルスクリプト（.sh）をLinuxで実行すると、シバン行 #!/bin/bash\r の末尾CRが解釈されず「bad interpreter: No such file or directory」というエラーになります。Pythonスクリプトでも、CSVパーサが改行コードを正しく扱えず、データの末尾に余計なCR文字が混入することがあります。Dockerイメージのビルドが謎のエラーで失敗する原因の半分は、実は改行コードです。

.gitattributes による統一設定

Gitリポジトリで改行コードを安全に統一するには、以下のような .gitattributes をリポジトリのルートに置きます。

# 自動判別してリポジトリ内ではLFに統一
* text=auto eol=lf
# Windowsバッチファイルだけは強制CRLF
*.bat text eol=crlf
*.cmd text eol=crlf
# シェルスクリプトは強制LF
*.sh text eol=lf
# バイナリは触らない
*.png binary

これにより、各開発者の作業ディレクトリではOSネイティブの改行コードが使われつつ、リポジトリ内には常にLFで保存される、という理想的な運用が実現します。

どの改行コードを選ぶべきか — 用途別ガイド

Web開発・サーバー運用 → LF

Linux/Unix系サーバー、Docker、Kubernetes、CI/CDパイプラインで動かすコードはすべてLFに統一しましょう。シェルスクリプト、Dockerfile、設定ファイル（YAML/JSON/TOML）、HTML/CSS/JS、Python/Ruby/Go/Rustのソースコードはすべてこれが標準です。

Windows専用ツール・バッチファイル → CRLF

Windows のバッチファイル（.bat / .cmd）はCRLFでないと正しく動作しないことがあります。Windowsの古いソフトウェアが読み取るログファイル、INI ファイル、Windowsで配布する README.txt なども、ユーザーがメモ帳で開いて読むことを想定してCRLFが安全です。

Classic Mac互換が必要なレガシー連携 → CR

現代の通常用途では使われませんが、古いMac向けのファイルフォーマット（一部のClarisWorks、AppleScript旧形式など）と互換性を保つ必要がある場合のみCRを選択します。新規開発では選ぶ必要はまずありません。

このツールでできること

このツールは、貼り付けたテキストの現在の改行コードを自動検出し、CRLF / LF / CR / 改行削除 のいずれかへワンクリックで変換します。リアルタイム変換に対応し、入力中に即座に結果が反映されます。「改行を可視化」オプションをONにすれば、通常見えない \r や \n を ⏎↵ のような視覚マーカーで表示でき、混在した改行コードを一目で発見できます。文字数・行数・バイト数も常時表示するため、変換前後でファイルサイズがどう変わるかも確認できます。