hexでの改行文字 — LF、CR、CRLF

改行はオペレーティングシステム間で異なる表現をされ、この違いはバグの持続的な原因です。16進数では、3つの標準改行規則は: LF（0A）、CR（0D）、CRLF（0D 0A）です。これらのhex値を理解することは、テキストファイルの問題のデバッグ、ネットワークプロトコルの解析、クロスプラットフォーム互換性の確保に不可欠です。

3つの改行スタイル:

スタイル	Hex	エスケープ	使用元
LF（ラインフィード）	0A	\n	Unix、Linux、macOS（OS X以降）、現代の標準
CR（キャリッジリターン）	0D	\r	クラシックMac OS（OS X以前、現在ほとんど見られない）
CRLF	0D 0A	\r\n	Windows、HTTP、SMTP、FTP、ほとんどのインターネットプロトコル

CRとLFの起源:

これらの文字は機械式テレタイプに由来します。キャリッジリターン（CR、0D）は物理的に印字ヘッドを行の先頭に戻しました。ラインフィード（LF、0A）は用紙を1行進めました。両方の操作を実行することで（CRの後にLF）新しい行が始まり、これがWindowsとネットワークプロトコルが2文字シーケンスを使用する理由です。

hexダンプでの改行の発見:

テキストファイルをhexエディタで開くと、改行は即座に可視化されます:

• Unixファイル: ...48 65 6C 6C 6F 0A 57 6F 72 6C 64...（"Hello\nWorld"）
• Windowsファイル: ...48 65 6C 6C 6F 0D 0A 57 6F 72 6C 64...（"Hello\r\nWorld"）
• 混在改行: 0Aと0D 0Aの両方のパターンが出現（問題の兆候）

改行によって引き起こされる一般的な問題:

• Gitのdiffがファイル全体が変更されたと表示 — 改行変換が原因であることが多い
• Linuxでシェルスクリプトが失敗 — Windowsで編集されたスクリプトは\r\n改行を持ち、シェルが\rをコマンドの一部として解釈する
• CSV解析エラー — 一部のパーサーは一方のスタイルを期待するが他方を受け取る
• HTTPプロトコル違反 — HTTPヘッダーはRFC仕様に従い\r\nで終わる必要がある

ネットワークプロトコルとCRLF:

HTTP、SMTP、FTP、ほとんどのインターネットプロトコルは行セパレータとしてCRLF（0D 0A）を義務付けています。HTTPレスポンスヘッダーブロックはダブルCRLF（0D 0A 0D 0A）で終わります。これはヘッダーとボディを分離する\r\n\r\nシーケンスです。ネットワークキャプチャをhexで分析する際、この4バイトパターンを探してヘッダー/ボディの境界を見つけます。