改行コードの \r と \n。それぞれ何の略？

解説

\r は Carriage Return（CR・復帰）、\n は Line Feed（LF・改行）の略です。選択肢Aの「Return / Newline」は惜しいですが、正式には Carriage Return です。Reset・Next・Row・Null はいずれも無関係な単語で、正式な略称ではありません。CR・LFはタイプライターの動きそのものこの名前は物理的なタイプライターの動作に由来しています。タイプライターで文字を打つと、紙を載せたキャリッジ（carriage）という部品が1文字ぶんずつ左にずれていきます。行末まで来たら、2つの操作が必要でした。Carriage Return：キャリッジを右端（行頭）まで戻す → 横方向のリセットLine Feed：紙を1行ぶん上に送る → 縦方向に次の行へ移動つまり「行頭に戻す」と「次の行に進む」は、もともと別々の物理動作だったわけです。これがそのままコンピュータの制御文字として残りました。OSごとに改行コードが違う理由この歴史的経緯から、OSによって改行コードの扱いが分かれました。Windows：\r\n（CR+LF）— タイプライターと同じ2文字セットmacOS / Linux：\n（LFのみ）古いMac（OS 9以前）：\r（CRのみ）現在のWeb開発ではほぼ \n だけを意識すれば済みますが、Windowsで作成されたCSVファイルを読み込んだり、git diff で意図しない差分が出たりするときに \r\n が原因であることは珍しくありません。実務で困るパターンたとえば、Windowsで作成されたテキストファイルを split('\n') で行分割すると、各行の末尾に \r が残ります。目に見えない文字なのでデバッグしにくく、文字列比較が一致しない原因になりがちです。対策としては .replace(/\r\n/g, '\n') で正規化する、あるいは .split(/\r?\n/) のように両方に対応する正規表現を使うのが定番です。エディタの設定やGitの core.autocrlf 設定でチーム内の改行コードを統一しておくと、こうしたトラブルを未然に防げます。.editorconfig ファイルで end_of_line = lf を指定するのも広く使われている方法です。