改行コードとは？目に見えない制御文字の正体

テキストファイル（.txtや.csv、プログラムのソースコードなど）は、人間の目には文字と空白と改行の組み合わせに見えます。しかしコンピュータにとっては、すべて「文字コードと呼ばれる数値の並び」に過ぎません。

私たちがキーボードの「Enterキー」を押して行を変えたとき、画面上には何も文字が表示されませんが、ファイルの中には「ここで改行する」という指示を出す特殊な文字が保存されます。

このように、画面に文字を表示するのではなく、機器や画面の動作を制御するために用意された特殊な文字のことを「制御文字（不可視文字）」と呼びます。改行コードは、まさにこの制御文字の代表例です。

そして、Windowsで標準的に使われているのが、この2つの制御文字を連続して並べた「CR+LF（\r\n）」です。

「CR」と「LF」の違いと由来：タイプライターから続く歴史

「改行したいだけなのに、なぜCRとLFという2つの動作を組み合わせる必要があるのか？」と不思議に思う方も多いでしょう。
その理由は、コンピュータが普及するはるか昔、機械式タイプライターやテレタイプ端末（遠隔印字機）が活躍していた時代の構造にあります。

CR（Carriage Return / キャリッジ・リターン）とは

CRは「復帰」と訳されます。タイプライターにおいて、紙を挟んで左右に動く台座部分（キャリッジ）を、行の先頭である「一番左端」までガシャンと戻す動作を指します。
つまり、CRを実行しただけでは、印字位置が左端に戻るだけで、同じ行の先頭に重ね書きされてしまいます。

LF（Line Feed / ライン・フィード）とは

LFは「行送り」と訳されます。タイプライターのローラーを回転させ、用紙を「1行分だけ上（次の行）」へ進める動作を指します。
LFだけを実行すると、横位置（カーソル位置）はそのままで、真下の行へ移動することになります。

なぜ改行に2つの命令が必要だったのか？

タイプライターで新しい行から文章を書き始めるには、「用紙を1行分送り（LF）」、さらに「印字位置を行の先頭に戻す（CR）」という2つの物理的な動作がどちらも必須でした。

初期の電子通信（テレタイプ端末）でも、印字ヘッドを物理的に左端まで戻すのにはほんの少し時間がかかりました。そのため、「CR（戻れ）」と「LF（送れ）」という別々の信号を順番に送る仕組みが設計されたのです。

この歴史的な仕組みをそのままコンピュータのテキスト処理に引き継いだのが、MS-DOSであり、現在のWindowsです。Windowsでは改行を表現するために今でも「CR」と「LF」の2文字（CR+LF）を記録しています。

改行コードの動作原理とOS別規格の全体像

OSによって異なる改行コードの規格

コンピュータの歴史が進むにつれ、「テキストファイルの中でわざわざ改行に2文字分も使うのはデータ容量の無駄ではないか？」と考える技術者たちが現れました。
その結果、OS（オペレーティングシステム）ごとに異なる改行方式が採用されることになり、現在に至る規格の分断が生まれました。

Windows：CR+LF

Windows（MS-DOS系）は互換性を重視し、タイプライター由来の「CR+LF」を採用し続けています。メモ帳などでテキストを作成して普通に保存すると、通常はCR+LFで記録されます。

Linux・macOS：LF

Unix系OSの開発者たちは、「画面やプリンタを動かすのはソフトウェアの役目であり、データファイル自体は1文字（LF）で改行を表せば十分」と割り切って設計しました。1バイトでもメモリやストレージを節約したかった時代の合理的な判断です。
その後、Macも2001年のMac OS X（現macOS）でUnixベースに刷新されたため、改行コードはLFへと統一されました。
現在、世界中のWebサーバーやクラウド環境の多くがLinuxで動いているため、Web業界やプログラミングの世界では「LF」がデファクトスタンダード（事実上の標準）となっています。

クラシックMac：CR

かつての古いMacintosh（OS 9まで）では、なぜかCR単体が改行コードとして採用されていました。現在ではクラシック環境のファイルを扱う場面以外で見かけることはほとんどありません。

改行コードの違いで発生するよくあるトラブル

OS間でテキストファイルを受け渡したとき、改行コードの違いに気づかないと様々な不具合が発生します。代表的なトラブル事例を見ていきましょう。

テキストが1行に繋がる、または空行が増える

かつての古いWindowsの「メモ帳」で、MacやLinuxで作成されたテキストファイル（改行がLFのみ）を開くと、改行が一切認識されず、文章全体が横に1行で繋がって表示される現象が有名でした。
（※現在のWindows 10/11のメモ帳はLFも自動認識するように改良されていますが、一部の古い業務アプリやテキストビューワーでは依然として発生します。）

逆に、Windowsで作成したCR+LFのテキストをLinuxの簡易ツールで表示すると、CRの部分が余計な空行として処理されたり、行末に「^M」という見慣れない記号が表示されたりすることがあります。

Linuxサーバーでシェルスクリプトが動かない（\rエラー）

プログラミングやサーバー運用で非常によくあるトラブルが、Windows上で作成・編集したシェルスクリプト（.shファイル）をLinuxサーバーにアップロードして実行したときに発生するエラーです。

$ ./deploy.sh
bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory
: command not found: line 2: 

Linuxは「LF」だけを改行とみなすため、CR+LFの末尾にある「CR（\r）」を改行ではなく「コマンドの一部」として解釈してしまいます。その結果、「そんなコマンドは存在しない」とエラーになってスクリプトが停止してしまうのです。

Gitでの警告メッセージ（LF will be replaced by CRLF）

ソースコードのバージョン管理ツール「Git」を使っていると、ファイルをコミット（登録）しようとした際に以下のような警告が表示されることがあります。

warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory

これは、Gitがチーム開発での混乱を防ぐために「リポジトリ内はLFで管理し、Windows環境に取り出すときは自動でCRLFに変換する」という自動変換機能（core.autocrlf）を働かせていることを通知する警告です。

CSVデータやシステム連携での取り込みエラー

業務システムの基幹データベースやECサイトへの商品一括登録など、CSVファイルをシステムにインポートする場面でも改行コードの不一致はトラブルの温床になります。
「システムの受け入れ仕様はLFのみなのに、Excelから書き出したCSVがCR+LFだったため、全件読み込みエラーになった」という事例は日常茶飯事です。

改行コードの確認と変換方法

改行コードに起因するトラブルを防ぐには、ファイルを開いたときに現在の改行コードを確認し、必要に応じて変換する習慣をつけることが大切です。

VS Code（Visual Studio Code）で確認・変換する

エンジニアやWeb制作の現場で最も普及しているエディタ「VS Code」では、ウィンドウの右下にあるステータスバーを見るだけで、現在開いているファイルの改行コードが一目で分かります。

これだけの操作で、ファイル全体の改行コードを瞬時に統一して保存し直すことができます。

サクラエディタなどのテキストエディタで確認・変換する

Windows向けの老舗テキストエディタ「サクラエディタ」でも、ステータスバーに「CRLF」などの表記が表示されています。
メニューの「ファイル」→「名前を付けて保存」を開き、保存ダイアログ下部にある「改行コード」のドロップダウン（CRLF / LF / CR）を変更して保存することで変換が可能です。

どの改行コードを使うべきか？（基本の判断基準）

迷ったときは、以下の基準で判断するとトラブルを最小限に抑えられます。

まとめ：改行コードを理解して無駄なエラーを未然に防ごう

改行コード「CR+LF」は、一見すると専門的で細かな仕様に見えますが、その背景にはタイプライターの時代から続く機械制御の歴史と、OSの進化の歩みがあります。

普段何気なく押しているEnterキーの裏側で、「WindowsはCR+LF（2文字）」「LinuxやMacはLF（1文字）」という違いがあることを知っておくだけで、ファイルの文字化け、スクリプトの謎のエラー、Gitの警告などに遭遇した際も冷静に原因を特定できるようになります。

異なる環境へファイルを渡すときやシステム連携を行うときは、ぜひエディタのステータスバーをチェックして、適切な改行コードが設定されているか確認してみてください。