CR LF (Windows)、LF (Unix)、および CR (Macintosh) の改行タイプの違い (可能であれば例を挙げて) を知りたいです。
9 に答える
CR と LF は、それぞれ(10 進数0x0D
で 13) と0x0A
(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
) は、実際には 2 つの ASCII 文字であり、CR と LF 文字の組み合わせです。カーソルを次の行とその行の先頭の両方に移動します。この文字は、Microsoft Windows、Symbian OS など、他のほとんどの非 Unix オペレーティング システムで改行文字として使用されます。
実際には、どのバイトがファイルに格納されるかだけです。CR
は、(タイプライターの時代からの) キャリッジ リターンのバイトコードであり、LF
同様にライン フィードのバイトコードです。行末マーカーとして配置されたバイトを参照するだけです。
いつものように、ウィキペディアでより多くの情報を入手してください。
Jeff Atwood は、これに関する最近のブログ記事を持っています: The Great Newline Schism
ウィキペディアからの本質は次のとおりです。
シーケンス CR+LF は、テレタイプ マシン (通常は ASR33) をコンソール デバイスとして採用した多くの初期のコンピューター システムで一般的に使用されていました。これは、このシーケンスがプリンターを新しい行の先頭に配置するために必要だったためです。これらのシステムでは、アプリケーションからそのようなハードウェアの詳細を隠すデバイスドライバーの概念がまだ十分に開発されていなかったため、テキストはこれらのプリンターと互換性があるように日常的に構成されていました。アプリケーションは、テレタイプ マシンと直接対話し、その規則に従う必要がありました。2 つの機能の分離により、印字ヘッドが右端から次の行の先頭に 1 文字の時間で戻ることができないという事実が隠されました。これが、シーケンスが常に最初に CR で送信された理由です。実際、プリント ヘッドが左マージンに移動する時間を確保するために、余分な文字 (無視される余分な CR または NUL) を送信する必要があることがよくありました。テレタイプがより高いボーレートを持つコンピューター端末に置き換えられた後でも、多くのオペレーティング システムは、ディスプレイをスクロールするのに複数の文字時間を必要とする安価な端末との互換性のために、これらのフィル文字の自動送信をサポートしていました。
CR - アスキーコード 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 オペレーティング ソフトウェアの子孫であるため、行末の混乱に悩まされています。