ファイルにどのバイトが格納されているかということだけです。 CRは（タイプライターの時代からの）キャリッジリターン用のバイトコードであり、同様にラインフィード用のLFです。行末マーカーとして配置されているバイトを参照するだけです。
いつものように、 wikipedia でもっと多くの情報を入手してください。
CRとLFは制御文字で、それぞれ0x0D（10進数の13）と0x0A（10進数の10）でコーディングされています。
それらはテキストファイルの改行をマークするために使われます。あなたが示したように、Windowsは2つの文字をCR LFシーケンスとして使います。 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オペレーティングシステムで改行文字として使用されます。
これだけを記載した答えはないので、簡潔に要約します。
キャリッジリターン （MACプレ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の数字です。
Jeff Atwoodがこれに関する最近のブログ投稿をしています： The Great Newline Schism
これは Wikipedia からの本質です。
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行の用紙がプリンタから送り出されることを示し、キャリッジリターンは、プリンタキャリッジが現在の行の先頭に戻ることを示します。
これが details です。
「レコード区切り文字」または「行終了記号」の悲しい状態は、コンピューティングの暗い時代の遺産です。
今、私たちが表現したいものはなんらかの形で構造化されたデータであり、行、ファイル、プロトコル、メッセージ、マークアップなどを定義するさまざまな抽象化に準拠していることは当然のことです。
しかし昔々これは正確ではありませんでした。アプリケーション組み込み制御文字および装置固有の処理。 CRとLFの両方を必要とした頭脳死のシステムは、レコードの区切り文字や行の終端文字を抽象化するものではありませんでした。テレタイプまたはビデオ表示を1列目に戻すにはCRが必要で、次の行に進むにはLF（今日はNL、同じコード）が必要でした。生データをデバイスにダンプする以外のことをするという考えは複雑すぎたと思います。
UnixとMacは実際に 抽象 を行末に指定しました、と想像してください。残念ながら、彼らは違うものを指定しました。そして、当然のことながら、彼らはすでにS.O.Pに "近い"制御コードを使用していました。
今日の私たちのオペレーティングソフトウェアのほとんどすべてがUnix、Mac、またはMSオペレーティングソフトウェアの子孫であるので、私たちは行末の混乱で立ち往生しています。
論理的にCRLF x'odoa asciiと比較するEBCDIC NL = x'15 'から派生したNL ...これは、データを物理的にメインフレームからミッドレンジに移動するときに明らかになります。口語的に（難解な人々だけがebcdicを使っているので）NLはCRかLFあるいはCRLFのどちらかと同一視されています