キャリッジリターン（CR）とラインフィード（LF）の概念は密接に関連しており、個別にまたは一緒に検討することができます。タイプライターやプリンターの物理メディアでは、ページに新しい行を作成するために、「下」と「横」の2つの動きの軸が必要です。マシン（タイプライターまたはプリンター）の設計ではそれらを個別に考慮する必要がありますが、ソフトウェアの抽象的なロジックでは、それらを1つのイベントとして組み合わせることができます。これが、文字エンコードの改行を CR と LF を1つに組み合わせて定義できる理由です。 （一般に CR + LF または CRLF と呼ばれます）。

一部文字セットは、個別の改行文字コードを提供します。たとえば、EBCDICは、CRおよびLFコードに加えてNL文字コードを提供します。 Unicodeは、ASCII CRおよびLF制御コードを提供することに加えて、「次行」（NEL）制御コード、および「行区切り」および「段落区切り」マーカーの制御コードも提供します。

• EBCDICシステム（主にz / OS（OS / 390）およびi5 / OS（OS / 400）を含むIBMメインフレームシステム）は、改行とキャリッジの機能を組み合わせた文字としてNL（改行、0x15）を使用します戻ります。同等のUnicode文字（ 0x85 ）はNEL（次の行）と呼ばれます。 EBCDICにもCRおよびLFと呼ばれる制御文字がありますが、LF（0x25）の数値はASCII（0x0A）で使用されるものとは異なります。さらに、一部のEBCDICバリアントもNLを使用しますが、文字に異なる数値コードを割り当てます。ただし、これらのオペレーティングシステムは、テキストファイルを1行に1つのレコードとして格納するレコードベースのファイルシステムを使用します。ほとんどのファイル形式では、実際には行末記号は格納されません。
• CDC 6000シリーズのオペレーティングシステムは、改行を60ビットワードの末尾にある2つ以上のゼロ値の6ビット文字として定義しました。一部の構成では、ゼロ値の文字をコロン文字として定義しているため、位置によっては複数のコロンが改行として解釈される可能性があります。
• RSX-11およびOpenVMSも、レコードベースのファイルシステムを使用します。 、テキストファイルを1行に1つのレコードとして保存します。ほとんどのファイル形式では、行ターミネータは実際には格納されませんが、レコード管理サービス機能は、アプリケーションによって取得されるときに、各行にターミネータを透過的に追加できます。レコード自体に同じ行末記号文字を含めることができます。これは、アプリケーションに応じて、機能または迷惑と見なされる可能性があります。 RMSは、レコードを格納するだけでなく、ファイルのさまざまなビットにレコードセパレータに関するメタデータを格納して、問題をさらに複雑にします（ファイルには固定長のレコード、カウントが前に付いたレコード、または特定の文字で終了したレコードが含まれる可能性があるため） ）。ビットは一般的ではなかったため、CRLFまたはLF、さらにはCRが行末記号であると指定できましたが、他のコードを置き換えることはできませんでした。
• 固定行長は一部の初期のメインフレームオペレーティングで使用されていました。システム。このようなシステムでは、たとえば、72文字または80文字ごとに暗黙の行末が想定されていました。改行文字は格納されませんでした。ファイルが外部からインポートされた場合、行の長さより短い行はスペースで埋める必要があり、行の長さより長い行は切り捨てる必要がありました。これはパンチカードの使用を模倣しており、各行は別々のカードに保存されていました。通常、各カードには80列あり、多くの場合、列番号は73〜80列です。これらのシステムの多くは、次のレコードの先頭にキャリッジ制御文字を追加しました。これは、次のレコードが前のレコードで開始された行の続きであるか、新しい行であるか、または前の行をオーバープリントする必要があるかどうかを示している可能性があります（CRと同様）。多くの場合、これは＃などの通常の印刷文字であるため、行の最初の文字として使用できませんでした。一部の初期のラインプリンターは、送信されたレコードでこれらの文字を直接解釈しました。

UnicodeEdit

Unicode標準では、準拠アプリケーションが改行子として認識する必要のある文字数が定義されています。

LF：改行、U + 000A VT：垂直タブ、U + 000B FF：フォームフィード、U + 000C CR：キャリッジリターン、U + 000D CR + LF：CR（U + 000D）、続いてLF（U + 000A）NEL：次の行、U + 0085 LS：改行区切り文字、U + 2028 PS：段落記号区切り記号、U + 2029

これは、すべての改行記号を単一の文字（LFなど）に変換するなどのアプローチと比較すると、非常に複雑に見える場合があります。ただし、Unicodeは、テキストファイルを既存のエンコーディングからUnicodeに、またはその逆に変換するときにすべての情報を保持するように設計されています。したがって、Unicodeには既存のエンコーディングに含まれる文字を含める必要があります。NLはコード0x15でEBCDICに含まれ、多くの場合、C1制御セットの制御文字であるNELにマップされます。そのため、ECMA 48で定義され、ISO / IEC 2022（ECMA 35と同等）に準拠したエンコーディングで認識されます。 C1コントロールセットはISO-8859-1とも互換性があります。 Unicode標準で採用されているアプローチにより、ラウンドトリップ変換で情報を保持しながら、アプリケーションがすべての可能なタイプのラインターミネータを認識できるようになります。

0x7F（NEL、LS）より大きい改行コードを認識して使用するPS）はあまり行われていません。これらはUTF-8では複数バイトであり、NELのコードはWindows-1252では省略記号（…）文字として使用されています。例：

• ECMAScriptはLSとPSを改行として受け入れますが、改行ではなくU + 0085（NEL）空白を考慮します。
• Windows 10は、デフォルトのテキストエディタであるメモ帳でNEL、LS、またはPSを改行として扱いません。
• gedit、GNOMEデスクトップ環境のデフォルトのテキストエディタ、LSとPSを改行として扱いますが、NELは扱いません。
• JSONは文字列内のLSとPS文字を許可しますが、ES2019より前のECMAScriptはそれらを改行として扱い、したがって構文が不正です。
• JSONとの互換性を保つために、バージョン1.2以降、YAMLはそれらを特別なものとして認識しなくなりました。

Unicode文字U + 2424（SYMBOL FOR NEWLINE、␤）、U + 23CE（RETURN SYMBOL、⏎）、U + 240D（SYMBOL FORキャリッジリターン、␍）およびU + 240A（ラインフィードの記号、␊）はユーザーに表示される文字をドキュメントの読者に提示することを目的としているため、改行として認識されません。

エスケープシーケンス編集

エスケープシーケンスは、文字の組み合わせであり、テキストなしを表します。 （テキストとして）表示される代わりに、プログラムによって傍受され、特別な機能が実行されることになっています。エスケープシーケンスは、特殊文字の処理（設定、検索、置換など）にも使用されます。

プログラミング言語の場合編集

ポータブルプログラムの作成を容易にするために、プログラミング言語は、さまざまな環境で使用されるさまざまなタイプの改行シーケンスを処理するための抽象化を提供します。

Cプログラミング言語は、エスケープシーケンス「\ n」（改行）と「\ r」（キャリッジリターン）を提供します。ただし、これらはASCIILFおよびCR制御文字と同等である必要はありません。 C標準では、次の2つのみが保証されます。

1. これらのエスケープシーケンスはそれぞれ、単一のchar値に格納できる一意の実装定義の数値にマップされます。
2. 書き込み時テキストモードのファイル、デバイスノード、またはソケット/ fifoに、「\ n」は、システムで使用されるネイティブの改行シーケンスに透過的に変換されます。これは、1文字より長くなる場合があります。テキストモードで読み取る場合、ネイティブの改行シーケンスは「\ n」に変換されます。バイナリモードでは、変換は実行されず、「\ n」によって生成された内部表現が直接出力されます。

Cが発生したUnixプラットフォームでは、ネイティブの改行シーケンスはASCII LF（ 0x0A）なので、「\ n」は単にその値として定義されています。内部表現と外部表現が同一であるため、テキストモードで実行される変換はノーオペレーションであり、Unixにはテキストモードまたはバイナリモードの概念がありません。これにより、Unixシステムでソフトウェアを開発した多くのプログラマーは、この違いを完全に無視し、異なるプラットフォームに移植できないコードになりました。

Cライブラリ関数fgets（）は、バイナリモードでは避けるのが最善です。 Unixの改行規則で書かれていないファイルは誤読されるためです。また、テキストモードでは、システムのネイティブ改行シーケンスで書き込まれていないファイル（Unixシステムで作成されてからWindowsシステムにコピーされたファイルなど）も誤読されます。

別の一般的な問題は、終了行にASCII CR + LFの使用を義務付けるインターネットプロトコルを使用して通信するときに「\ n」を使用することです。テキストモードストリームに「\ n」を書き込むと、Windowsシステムでは正しく機能しますが、でLFのみが生成されます。 Unix、およびよりエキゾチックなシステムではまったく異なるもの。バイナリモードで「\ r \ n」を使用する方がわずかに優れています。

Java I / Oライブラリは、これらをプラットフォームに依存する改行シーケンスに透過的に変換しません。入力または出力。代わりに、ネイティブの改行シーケンスを自動的に追加する完全な行を書き込むための関数と、CR、LF、またはCR + LFのいずれかを行末記号として受け入れる行を読み取るための関数を提供します（BufferedReader.readLine（）を参照）。 ）。System.lineSeparator（）メソッドを使用して、基になる行区切り記号を取得できます。

例：

 String eol = System.lineSeparator(); String lineColor = "Color: Red" + eol;

Pythonは、読み取り用にファイルを開くときに「ユニバーサル改行サポート」を許可します。モジュールのインポート、およびファイルの実行時。

一部の言語では、プログラムの実行中に改行を容易にするために、特別な変数、定数、およびサブルーチンが作成されています。 PHPやPerlなどの一部の言語では、「\ n」や「\ r」を含むすべてのエスケープシーケンスのエスケープ置換を実行するには、二重引用符が必要です。 PHPでは、移植性の問題を回避するために、PHP_EOL定数を使用して改行シーケンスを発行する必要があります。

C＃の例：

 string eol = Environment.NewLine; string lineColor = "Color: Red" + eol; string eol2 = "\n"; string lineColor2 = "Color: Blue" + eol2;

さまざまな改行形式の問題編集

制御文字は、テキストファイルで使用される対応する文字エンコードテーブルで明確に定義されていますが、 、まだ問題があります。改行を設定および表示するためのさまざまな規則があります。

単一の改行を示すために、Unixプログラムは改行を使用します。 、ASCIIでの16進値は 0a ですが、MS-DOSおよびMicrosoftWindowsに共通のほとんどのプログラムはキャリッジリターン + 改行。ASCIIの16進値は 0d 0a 。 ASCIIでは、キャリッジリターンは別個の制御文字です。

改行規則が異なると、異なるタイプのシステム間で転送されたテキストファイルが正しく表示されません。

作成されたファイル内のテキストUnixライクまたはクラシックMacOSで一般的なプログラムでは、MS-DOSおよびMicrosoft Windowsで一般的なほとんどのプログラムでは、単一のが表示されないため、単一の長い行として表示されます。改行または単一の改行を改行として

逆に、Windowsコンピュータから発信されたファイルを表示する場合Unixライクなシステムでは、余分なCRは、2番目の改行として、^ Mとして、または< cr >として表示される場合があります。各行の終わりに。

さらに、テキストエディタ以外のプログラムはファイルを受け入れない場合があります。一部の構成ファイルは、外部改行規則を使用して有効なファイルとしてエンコードされています。

一部のプログラムは外部改行を適切に処理し、他のプログラムは処理しないため、問題を特定するのが難しい場合があります。たとえば、コンソールまたはエディターに表示されたときにソースファイルが正しく表示されていても、コンパイラーがあいまいな構文エラーで失敗する場合があります。 Unixライクなシステムでは、コマンドcat -v myfile.txtがファイルをstdout（通常はターミナル）に送信し、^ Mを表示します。これは、デバッグに役立ちます。最新のテキストエディタは通常、CR + LF改行のすべてのフレーバーを認識し、ユーザーが異なる標準間で変換できるようにします。 Webブラウザは通常、さまざまな種類の改行を使用するテキストファイルやWebサイトを表示することもできます。

プログラムがさまざまな改行規則をサポートしている場合でも、これらの機能は十分にラベル付け、説明、または文書化されていないことがよくあります。通常、さまざまな改行規則を列挙するメニューまたはコンボボックスは、選択によって改行が再解釈されるか、一時的に変換されるか、永続的に変換されるかを示すことなく、ユーザーに表示されます。一部のプログラムは、開く、コピー、貼り付け、または保存時に暗黙的に変換されます。多くの場合、一貫性がありません。

ほとんどのテキストインターネットプロトコル（HTTP、SMTP、FTP、IRC、その他多数を含む）では、ASCII CR +の使用が義務付けられています。プロトコルレベルではLF（ “\ r \ n”、0x0D 0x0A）ですが、耐性のあるアプリケーションは単独のLF（ “\ n”、0x0A）も認識することをお勧めします。規定された標準にもかかわらず、多くのアプリケーションは、キャリッジリターンエスケープと改行エスケープシーケンス “\ r \ n”（CR + LF）の正しい組み合わせではなく、C改行エスケープシーケンス “\ n”（LF）を誤って使用します（上記のプログラミング言語）。間違ったエスケープシーケンスを誤って使用すると、推奨される許容解釈ではなく、標準のより厳密な解釈に準拠しているシステムと通信しようとしたときに問題が発生します。そのような不寛容なシステムの1つは、必要なCR + LFの代わりに裸のLFを送信するシステムからのメッセージの受け入れを積極的に拒否するqmailメール転送エージェントです。

電子メールの標準インターネットメッセージ形式：CRとLFは必須ですCRLFとして一緒にのみ発生します。本体に個別に表示してはなりません。

ファイル転送プロトコルは、転送が「ASCIIモード」で行われる場合、異なる改行表現を持つシステム間で転送されるファイルの改行を自動的に変換できます。ただし、このモードでバイナリファイルを転送すると、通常、悲惨な結果が生じます。このコンテキストでは改行セマンティクスはありませんが、通常のバイトシーケンスの一部である改行バイトシーケンスが発生すると、改行表現に変換されます。他のシステムが使用し、ファイルを事実上破壊します。 FTPクライアントは、多くの場合、いくつかのヒューリスティック（たとえば、ファイル名拡張子の検査）を使用して、バイナリモードまたはASCIIモードを自動的に選択しますが、最終的には、ファイルが正しいモードで転送されることを確認するのはユーザーの責任です。正しいモードに疑問がある場合は、バイナリモードを使用する必要があります。これにより、ファイルはFTPによって変更されませんが、正しく表示されない場合があります。

改行形式間の変換編集

テキストエディタは、テキストファイルを異なる改行形式間で変換するためによく使用されます。最近のほとんどのエディターは、少なくとも異なるASCII CR / LF規則を使用してファイルを読み書きできます。たとえば、エディターVimは、ファイルをWindowsメモ帳テキストエディターと互換性のあるものにすることができます。 vim内

 :set fileformat=dos :wq

エディターは、大きなファイルの変換や多くのファイルの一括変換には適さない場合があります。より大きなファイル（Windows NT / 2000 / XPの場合）の場合、次のコマンドがよく使用されます。

D:\>TYPE unix_file | FIND /V "" > dos_file

変換する専用プログラム異なる改行規則間のファイルには、unix2dosとdos2unix、mac2unixとunix2mac、mac2dosとdos2mac、flipが含まれます.trコマンドは、事実上すべてのUnixライクなシステムで使用でき、単一の文字に対して任意の置換操作を実行するために使用できます。 DOS / Windowsテキストファイルは、

$ tr -d "\r" < inputfile > outputfile

を使用してすべてのASCIICR文字を削除するか、テキストにCR改行しかない場合は、次の方法でUnix形式に変換できます。

$ tr "\r" "\n" < inputfile > outputfile

プラットフォームにPerlインタープリターがある場合、awk、sed、またはPerlで同じタスクが実行されることがあります。

$ tr "\r" "\n" < inputfile > outputfile

p>

fileコマンドは、行末のタイプを識別できます。

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

Unix egrep（拡張grep）コマンドUnixまたはDOSファイルのファイル名を印刷するために使用できます（UnixおよびDOSスタイルのファイルのみ、Mac OSは想定していません）：

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

他のツールを使用すると、ユーザーはEOL文字を視覚化できます：

$ od -a myfile.txt$ cat -e myfile.txt$ hexdump -c myfile.txt