改行

多くの通信プロトコルには、何らかの改行規則が定められています。特に、インターネット技術タスクフォース（IETF）が発行するプロトコルでは、一般的にASCIIのCRLFシーケンスが使用されます。

古いプロトコルの中には、改行の後にチェックサムまたはパリティ文字が続くものがある。

Unicode標準では、準拠するアプリケーションが行末文字として認識すべき文字がいくつか定義されています。^{[ 9 ]}

すべての行末文字を単一の文字（ LFなど）に変換するなどの方法に比べると複雑すぎるように思えるかもしれませんが、Unicodeはテキストファイルを既存のエンコーディングからUnicodeに変換し、また元に戻す際にすべての情報を保持するように設計されているため（往復整合性）、Unicodeは他のエンコーディングによって行われる改行についても同様の区別をする必要があります。たとえば、EBCDICにはNL、CR、LFの文字があるため、これら3つすべてがUnicodeにも存在する必要があります。

ほとんどの改行文字と改行シーケンスはASCIIのC0制御範囲（つまり、Unicodeコードポイントが0x1Fまで）にあります。この範囲外の3つの改行文字（NEL、LS、PS）は、ソフトウェアによって改行として認識されないことがよくあります。例：

• JSON はCRとLF を空白文字として認識しますが、他の改行文字は認識しません。^{[ 10 ]} C0 制御文字は文字列内にエスケープされずに現れることはできませんが、他の改行文字はエスケープされずに現れることができます。^{[ 11 ]}
• ECMAScript はCR、LF、LS、PS のみを改行文字として認識します。 ^{[ 12 ]}従来、文字列リテラルではエスケープされていない改行文字は許可されていませんでしたが、^{[ 13 ]} JSON との互換性のために、 ES2019でエスケープされていないLSとPS が文字列で許可されるように変更されました。^{[ 12 ] [ 14 ]}
• YAML 1.1 では 3 つすべてを改行として認識していましたが、YAML 1.2 ではJSONとの互換性を保つために改行として認識しなくなりました。^{[ 15 ]}
• Microsoft WindowsのデフォルトのテキストエディタであるWindows メモ帳は、 NEL、LS、PSのいずれも改行として扱いません。
• GNOMEデスクトップ環境のデフォルトのテキストエディタであるgeditは、 LSとPSを改行として扱いますが、 NELは扱いません。

Unicodeには、文書の読者に対してユーザーに見える文字を表示することを目的としたグリフがいくつか含まれており、そのため、それ自体は改行として認識されません。

• U+23CE ⏎リターンシンボル
• U+240A ␊ラインフィードの記号
• U+240D ␍キャリッジリターン記号
• U+2424 ␤改行記号

HTMLでは、改行は空白であり、一般的にはスペースと区別なく扱われます。^{[ 16 ]段落はHTML}要素の別々のインスタンス^を使用して作成され、段落の物理的な分離はレンダリング エンジンによって制御されます。^{[ 17 ]}<p>

改行は、HTML 要素を使用して明示的に作成できます。スクリーン リーダーがページを解釈できるようにするために、HTML ドキュメントでは、段落にこの要素を使用しないことを推奨しています。代わりに、MDN Web Docsなどの情報源では、詩にこの要素を使用することを推奨しています。^{[ 18 ]}<br>

移植性の高いプログラムを作成しやすくするために、プログラミング言語は、さまざまな環境で使用されるさまざまな種類の改行シーケンスを扱うための抽象化機能を提供している。

C言語はエスケープシーケンス\n（改行）と（キャリッジリターン）を提供します。ただし、これらはASCIIのLFおよびCR\r制御文字と同等である必要はありません。C規格は、次の2つの特性のみを保証します。

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

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

C言語の標準ライブラリ関数fgets ()は、バイナリモードでは使用を避けるのが最善です。Unixの改行規則に従って書き込まれていないファイルは、正しく読み込まれないからです。また、テキストモードでも、システムのネイティブな改行シーケンスに従って書き込まれていないファイル（例えば、Unixシステムで作成され、Windowsシステムにコピーされたファイルなど）は、同様に正しく読み込まれません。

もう一つのよくある問題は、\nインターネットプロトコルを使用して通信する際に、行末にASCII CR + LFを使用することが義務付けられている場合です。テキストモードのストリームに書き込むと、Windowsシステムでは正しく動作しますが、 UnixではLFしか生成されず、より特殊なシステムでは全く異なる結果になります。バイナリモードでの使用は、若干改善されます。\n\r\n

C++、Perl、^{[ 19 ]}、Haskellなどの多くの言語は、\nCと同じ解釈を提供します。C++には、マニピュレータstd::endlを使用して改行を出力（およびストリームバッファをフラッシュ）できる代替の入出力（I/O）モデルがあります。

Java、PHP、^{[ 20 ]}、Python ^{[ 21 ]}\r\nは、(ASCII CR + LFの場合) シーケンスを提供します。C とは対照的に、これらはそれぞれU+000DとU+000Aの値を表すことが保証されています。

Javaクラス ライブラリの入出力(I/O) メソッドは、入力または出力時にこれらの改行シーケンスをプラットフォーム依存の改行シーケンスに透過的に変換しません。代わりに、ネイティブの改行シーケンスを自動的に追加する完全な行を書き込む関数と、行末文字としてCR、LF、またはCR + LFを受け入れる行を読み取る関数 ( BufferedReader.readLine()を参照) を提供します。System.lineSeparator ()メソッドを使用して、基となる行区切り文字を取得できます。これは、書式指定子を使用する場合にも自動的に挿入されます。%nSystem.out::printf

例：

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

Pythonにはデフォルトで有効になっている「ユニバーサル改行サポート」機能があり、ファイルの読み取り、モジュールのインポート、ファイルの実行時に、よく使われる3つの改行規則（ \n、、）をPythonの標準規則に変換します。この機能は\r、ファイルを開くときに関数の引数を使用して制御できます。 ^{[ 22 ] [ 23 ]}\r\n\nnewlineopen()

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

C#の例:

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

改行規則の違いにより、異なる種類のシステム間で転送されたテキストファイルが正しく表示されない場合があります。

Unix系OSや従来のMac OSでよく使われるプログラムで作成されたファイル内のテキストは、 MS-DOSやMicrosoft Windowsでよく使われるほとんどのプログラムでは、1行の長いテキストとして表示されます。これは、これらのプログラムが1行line feedまたは1行のcarriage returnテキストを改行として表示しないためです。

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

さらに、テキストエディタ以外のプログラムでは、例えば設定ファイルなど、外国語の改行規則を使用してエンコードされたファイルを有効なファイルとして認識しない場合があります。

問題は、一部のプログラムが外国語の改行を正しく処理する一方で、そうでないプログラムもあるため、見つけにくい場合があります。たとえば、ソースファイルがコンソールやエディタで正しく表示されていても、コンパイラが分かりにくい構文エラーで失敗することがあります。最新のテキストエディタは一般的に、あらゆる種類のCR + LF改行を認識し、ユーザーが異なる規格間で変換できるようにしています。Webブラウザも通常、異なる種類の改行を使用するテキストファイルやWebサイトを表示できます。

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

ほとんどのテキストベースのインターネットプロトコル（HTTP、SMTP、FTP、IRCなど多数）は、プロトコルレベルでASCII CR + LF（、0x0D 0x0A ）の使用を義務付けていますが、寛容なアプリケーションは単独のLF（、0x0A）も認識することを推奨しています。規定された標準にもかかわらず、多くのアプリケーションは、キャリッジリターンエスケープと改行エスケープシーケンスの正しい組み合わせ（CR + LF）の代わりに、誤ってC言語の改行エスケープシーケンス（LF）を使用しています（上記の「プログラミング言語の改行」のセクションを参照）。このような誤ったエスケープシーケンスの偶発的な使用は、推奨されている寛容な解釈ではなく、標準のより厳格な解釈に従うシステムと通信しようとしたときに問題を引き起こします。そのような寛容でないシステムの1つがqmailメール転送エージェントで、必要なCR + LFの代わりにLFのみを送信するシステムからのメッセージの受け入れを積極的に拒否します。^{[ 25 ]}\r\n\n\n\r\n

電子メールの標準インターネットメッセージフォーマット^{[ 26 ]}では、「CRとLFはCRLFとしてのみ一緒に出現しなければならず、本文中に単独で出現してはならない」と規定されています。SMTP実装間で、裸のLFおよび/または裸のCR文字の扱い方が異なるため、「SMTPスマグリング」と呼ばれるSMTPスプーフィング攻撃が発生しています。^{[ 27 ]}

ファイル転送プロトコルは、 「ASCII モード」で転送する場合、異なる改行表現を持つシステム間で転送されるファイルの改行を自動的に変換できます。しかし、バイナリ ファイルをこのモードで転送すると、通常は深刻な問題が発生します。このコンテキストでは行末の意味を持たない、通常のバイト シーケンスの一部である改行バイト シーケンスが出現すると、相手側のシステムが使用する改行表現に変換され、事実上ファイルが破損します。FTP クライアントは、バイナリ モードまたは ASCII モードを自動的に選択するために、多くの場合、何らかのヒューリスティック(たとえば、ファイル名拡張子の検査) を使用しますが、最終的には、ファイルが正しいモードで転送されていることを確認するのはユーザーの責任です。正しいモードについて疑問がある場合は、バイナリ モードを使用する必要があります。そうすれば、FTP によってファイルが変更されることはありませんが、正しく表示されない可能性があります。^{[ 28 ]}

テキストエディタは、異なる改行形式間でテキストファイルを変換するためによく使用されます。最新のエディタのほとんどは、少なくとも異なるASCII CR / LF規則を使用してファイルを読み書きできます。

例えば、エディタのVimは、Windowsのメモ帳テキストエディタと互換性のあるファイルを作成できます。Vim内では

ファイル形式をdosに設定し ます : wq

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

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

異なる改行規則間でファイルを変換するための専用プログラムには、unix2dosとdos2unix、mac2unixとunix2mac、mac2dosとdos2mac、およびflip があります。^{[ 29 ]} trコマンドは、ほぼすべてのUnix ライクなシステムで使用でき、単一文字に対して任意の置換操作を実行できます。DOS/Windows テキストファイルは、すべての ASCII CR文字を削除するだけで Unix 形式に変換できます。

$ tr -d '\r' <入力ファイル>出力ファイル

または、テキストにCR改行しかない場合は、すべてのCR改行をLFに変換して

$ tr '\r' '\n' <入力ファイル>出力ファイル

同様のタスクは、awk、sed、またはプラットフォームにPerlインタープリタがある場合はPerlを使用して実行されることもあります。

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile # UNIX から DOS へ (GNU 拡張機能のない Linux および BSD ベースの OS に CR を追加) $ awk '{gsub("\r",""); print;}' inputfile > outputfile # DOS から UNIX へ (GNU 拡張機能を持たない Linux および BSD ベースの OS では CR を削除) $ sed -e 's/$/\r/' inputfile > outputfile # UNIX から DOS へ (GNU 拡張機能を使用する Linux ベースの OS では CR を追加) $ sed -e 's/\r$//' inputfile > outputfile # DOS から UNIX へ (GNU 拡張機能を使用する Linux ベースの OS では CR を削除) $ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile # DOS に変換$ perl -pe 's/\r?\n|\r/\n/g' inputfile > outputfile # UNIX に変換$ perl -pe 's/\r?\n|\r/\r/g' inputfile > outputfile # 古い Mac に変換

fileコマンドは、行末の種類を識別できます。

$ file myfile.txt myfile.txt: CRLF 行末文字を含む ASCII 英語テキスト

Unixのegrep（拡張grep）コマンドは、UnixまたはDOSファイルのファイル名を表示するために使用できます（UnixおよびDOS形式のファイルのみを対象とし、従来のMac OS形式のファイルは対象外です）。

$ egrep -L '\r\n' myfile.txt # UNIX スタイルのファイル (LF で終了) を表示$ egrep -l '\r\n' myfile.txt # DOS スタイルのファイル (CRLF で終了) を表示

その他のツールを使用すると、ユーザーは改行文字を視覚化できます。

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