CR LF、LF、CRの改行タイプの違いは？

CR LF（Windows）、LF（Unix）、CR（Macintosh）の改行タイプの違いを（可能な場合は例を挙げて）知りたい。

実際には、どのバイトがファイルに格納されているかについてです。CRキャリッジリターン（タイプライターの時代）のバイトコードであり、LF同様にラインフィードのバイトコードです。行末マーカーとして配置されるバイトを参照するだけです。

いつものように、ウィキペディアでもっと多くの情報を。

CRとLFは制御文字であり、それぞれコード化され0x0Dています0x0A（10進数13）と（10進数10）。

テキストファイルの改行をマークするために使用されます。ご指摘のとおり、WindowsはCR LFシーケンスの2文字を使用します。UnixはLFのみを使用し、古いMacOS（OSX以前のMacIntosh）はCRを使用していました。

外典的な歴史的展望：

Peterが示したように、CR = キャリッジリターンとLF = ラインフィードの 2つの式は、古いタイプライター/ TTYにルーツがあります。LFは紙を上に移動し（ただし、水平位置は同じまま）、CRは「キャリッジ」を元に戻し、次に入力した文字が紙の左端（同じ行上）になるようにしました。CR + LFは両方を実行していました。つまり、新しい行を入力する準備をしています。時間の経過とともにコードの物理的セマンティクスが適用できなくなり、メモリとフロッピーディスクの容量が限られているため、一部のOS設計者は1つの文字のみを使用することを決定しましたが、お互いにうまく通信できませんでした。 -）

最近のほとんどのテキストエディタとテキスト指向のアプリケーションは、ファイルの行末の規則を自動的に検出し、それに応じて表示できるオプション/設定などを提供しています。

これは私が見つけた良い要約です：

復帰（CR）文字（0x0D、\r）は、カーソルを次の行に進めずに行の先頭に移動します。この文字は、CommodoreおよびEarly Macintoshオペレーティングシステム（OS-9以前）で改行文字として使用されます。

改行（LF）文字（0x0A、\n）は、カーソルを行の先頭に戻らずに次の行に移動します。この文字は、UNIXベースのシステム（Linux、Mac OSXなど）で改行文字として使用されます

行末（EOL）シーケンス（0x0D 0x0A、\r\n）は、実際にはCR文字とLF文字の組み合わせである2つのASCII文字です。カーソルを次の行とその行の先頭の両方に移動します。この文字は、Microsoft Windows、Symbian OSなど、他のほとんどの非UNIXオペレーティングシステムで改行文字として使用されます。

ソース

これだけを述べる答えはないので、簡潔に要約します。

キャリッジリターン（MAC pre-OSX）

• CR
• \ r
• ASCIIコード13

改行（Linux、MAC OSX）

• LF
• \ n
• ASCIIコード10

キャリッジリターンとラインフィード（Windows）

• CRLF
• \ r \ n
• ASCIIコード13、次にASCIIコード10

奇妙な形式のASCIIコードが表示された場合、それらは通常、基数8（8進数）または基数16（16進数）の異なる基数/基数の13と10です。

http://www.bluesock.org/~willg/dev/ascii.html

Jeff Atwoodがこれについて最近ブログに投稿しました：Great Newline Schism

ここにウィキペディアの本質があります：

シーケンスCR + LFは、テレタイプマシン（通常はASR33）をコンソールデバイスとして採用していた多くの初期のコンピューターシステムで一般的に使用されていました。これらのシステムでは、こうしたハードウェアの詳細をアプリケーションから隠すデバイスドライバーの概念がまだ十分に開発されていないため、テキストは通常​​、これらのプリンターと互換性を持つように定期的に構成されていました。アプリケーションはテレタイプマシンと直接通信し、その慣例に従う必要がありました。2つの機能の分離により、印字ヘッドが1文字の時間で右端から次の行の先頭に戻ることができなかったという事実が隠されました。そのため、シーケンスは常に最初にCRで送信されました。実際、多くの場合、プリントヘッドに左マージンに移動する時間を与えるために、余分な文字（無関係なCRまたはNUL、無視されます）を送信する必要がありました。テレタイプがより高いボーレートのコンピューター端末に置き換えられた後でも、多くのオペレーティングシステムは、ディスプレイをスクロールするために複数の文字時間を必要とする安価な端末との互換性のために、これらのフィル文字の自動送信をサポートしていました。

CR-ASCIIコード13

LF-ASCIIコード10。

理論的には、CRはカーソルを最初の位置（左側）に戻します。LFは、カーソルを1行下に移動して1行送ります。これは、昔はプリンタやテキストモードモニタを制御していた方法です。これらの文字は通常、テキストファイルの行の終わりを示すために使用されます。オペレーティングシステムが異なれば、使用される規則も異なります。ご指摘のとおり、WindowsではCR / LFの組み合わせを使用していますが、OSX以前のMacではCRのみを使用しています。

ASCIIまたは互換性のある文字セットに基づくシステムは、LF（改行、0x0A、10進数で10）またはCR（キャリッジリターン、0x0D、10進数で13）を個別に使用するか、CRの後にLF（CR + LF、0x0D 0x0A）を続けます。これらの文字はプリンターコマンドに基づいています。改行は1行の用紙がプリンターから送り出されることを示し、キャリッジリターンはプリンターのキャリッジが現在の行の先頭に戻ることを示しました。

詳細はこちらです。

「レコードセパレータ」または「行ターミネータ」の悲しい状態は、コンピューティングの暗黒時代の遺産です。

ここで、表現したいものはなんらかの方法で構造化されたデータであり、行、ファイル、プロトコル、メッセージ、マークアップなどを定義するさまざまな抽象化に準拠していることは当然です。

しかし、むかしむかし、これは正確には当てはまりませんでした。アプリケーションの組み込み制御文字とデバイス固有の処理。CRとLFの両方を必要とする頭の悪いシステムは、単にレコードセパレータや行ターミネータを抽象化していませんでした。テレタイプまたはビデオディスプレイを列1に戻すにはCRが必要で、次の行に進むにはLF（今日、NL、同じコード）が必要でした。生データをデバイスにダンプする以外の何かをするという考えは、あまりにも複雑だったと思います。

UnixとMacは実際には行末の抽象化を指定していますが、想像してみてください。悲しいことに、彼らは別のものを指定しました。（Unix、エヘムが最初に来ました。）そして当然、彼らはすでにSOPに「近い」制御コードを使用していました。

今日のほとんどすべてのオペレーティングソフトウェアは、Unix、Mac、またはMSオペレーティングソフトウェアの子孫であるため、混乱の終焉に悩まされています。

NLはEBCDIC NL = x'15 'から派生し、CRLF x'odoa asciiと論理的に比較されます。これは、データをメインフレームからミッドレンジに物理的に移動するときに明らかになります。口語的に（難解な人々だけがebcdicを使用するため）NLはCRまたはLFまたはCRLFと同等と見なされています