改行

改行（改行とも呼ばれる）は、ASCII、EBCDIC、Unicodeなどの文字エンコード仕様における制御文字または制御文字のシーケンスです。この文字または文字列は、テキストの行の終わりと新しい行の始まりを示すために使用されます。^[1]

1800 年代半ば、テレタイプ機やテレプリンタが登場するずっと前に、モールス信号のオペレーターや電信技師は、正式なテキスト メッセージ内の空白のテキスト フォーマットをエンコードするためにモールス信号のプロサインを発明し、使用しました。特に、通常の文字間スペースなしで送信される、文字どおりのテキスト モールス信号の「B」と「T」の連結で表されるモールス信号のプロサインBT (ニーモニック ブレーク テキスト) は、モールス信号で、正式なテキスト メッセージ内の新しい行または新しいセクションをエンコードして示すために使用されます。

その後、近代的なテレプリンタの時代になると、空白テキストのフォーマットを支援するために標準化された文字セット制御コードが開発されました。ASCII は、国際標準化機構(ISO) と米国規格協会 (ASA) によって同時に開発されました。ASA は、米国規格協会(ANSI)の前身組織です。1963 年から 1968 年にかけて、ISO 草案標準では、改行として .mw-parser-output .monospaced{font-family:monospace,monospace}CR+LF または LF のみの使用がサポートされていましたが、ASA 草案ではCR + LFのみがサポートされていました。

CR + LFシーケンスは、テレタイプマシン (通常はテレタイプ モデル 33 ASR) をコンソール デバイスとして採用した初期のコンピュータ システムの多くで一般的に使用されていました。このシーケンスは、これらのプリンタを新しい行の先頭に配置するために必要だったためです。改行を 2 つの機能に分離すると、プリント ヘッドが次の文字を印刷するのに間に合うように右端から次の行の先頭に戻ることができないという事実が隠蔽されます。CR の後に印刷された文字は、プリント ヘッドがキャリッジを最初の位置に戻している間に、ページの中央に汚れとして印刷されることがよくありました。「解決策は、改行を 2 つの文字にすることでした。キャリッジを列 1 に移動するにはCR、用紙を上に移動するにはLF です。」 ^[2]実際、余分なパディング文字(余分な CR または NUL) を送信する必要がよくありました。これらは無視されますが、プリント ヘッドが左マージンに移動する時間を与えます。初期のビデオ ディスプレイの多くでは、ディスプレイをスクロールするのに複数の文字時間も必要でした。

このようなシステムでは、デバイス ドライバーがハードウェアの詳細をアプリケーションから隠すという概念がまだ十分に開発されていなかったため、アプリケーションはテレタイプ マシンと直接通信し、その規則に従う必要がありました。そのため、テキストはテレタイプ マシンのニーズを満たすように日常的に作成されていました。DEC のミニコンピュータ システムのほとんどはこの規則を使用していました。CP /Mも、ミニコンピュータが使用するのと同じ端末で印刷するためにこの規則を使用しました。そこから、MS-DOS (1981)は互換性を保つためにCP/MのCR + LFを採用し、この規則は Microsoft の後のWindowsオペレーティング システムに継承されました。

Multicsオペレーティング システムの開発は 1964 年に始まり、改行文字としてLFのみを使用していました。Multics では、デバイスドライバーを使用してこの文字をプリンターが必要とするシーケンス (追加のパディング文字を含む) に変換し、1 バイトの方がプログラミングに便利でした。より明白な選択と思われるCR は使用されませんでした。CR には、太字、下線、取り消し線の効果を作成するために 1 つの行を別の行で重ね印刷する便利な機能があったためです。おそらくより重要なのは、LFのみを行末文字として使用することが、最終的なISO/IEC 646標準の草案にすでに組み込まれていたことです^。UnixはMultics の慣例に従い、その後Unix ライクなシステムが Unix に従いました。これにより、Windows と Unix ライクなオペレーティング システムの間に競合が発生し、あるオペレーティング システムで作成されたファイルは、 別のオペレーティングシステムでは適切にフォーマット^{または解釈されない}

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

一部の文字セットでは、別個の改行文字コードが提供されています。たとえば、EBCDICでは、 CR コードとLFコードに加えて、 NL文字コードが提供されています。Unicodeでは、 ASCII CRおよびLF制御コードに加えて、「次の行」( NEL ) 制御コードや、「行区切り」マーカーと「段落区切り」マーカーの制御コードも提供されています。Unicode には、制御ピクチャ ブロックに、ライン フィード ␊、キャリッジ リターン ␍、その他の C0 制御コード (および汎用改行 ␤) を視覚的に表す印刷可能な文字も含まれています。

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

多くの通信プロトコルには、何らかの改行規則があります。特に、インターネット技術タスクフォース(IETF) によって公開されたプロトコルでは、通常、ASCII CRLF シーケンスが使用されます。

一部の古いプロトコルでは、新しい行の後にチェックサムまたはパリティ文字が続く場合があります。

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

 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 はEBCDICの一部で、コード0x15を使用します。通常は Unicode NEL ( 0x85 ) にマッピングされます。これはC1 制御セットの制御文字です。^[10]そのため、ECMA 48 で定義され、^[11] ISO/IEC 2022 (ECMA 35 に相当)に準拠したエンコードで認識されます。 ^{[12] C1 制御セットは}ISO-8859-1とも互換性があります。^[要出典] Unicode 標準で採用されているアプローチにより、往復変換で情報を保持しながら、アプリケーションがあらゆる種類の行末文字を認識できるようになります。

0x7Fより大きい改行コード( NEL、LS、PS ) を認識して使用することはあまりありません。これらはUTF-8では複数バイトであり、 NELのコードはWindows-1252では省略記号( ) 文字として使用されています。たとえば、次のように なります。…

• ECMAScriptはLSとPSを改行として受け入れますが^{[13] 、} U+0085（NEL）は空白文字として扱います。 ^[14]
• JSON ^{[15]では文字列内で}LS文字とPS文字を使用できますが、 ES2019 ^{[16] [17]}より前のECMAScriptではこれらを改行文字として扱うため、不正な構文となります。^[18]
• YAML ^[19]はJSONとの互換性を保つためにバージョン1.2以降では改行として認識されなくなりました。
• Microsoft Windowsのデフォルトのテキスト エディターであるWindows メモ帳は、 NEL、LS、PSのいずれも改行として扱いません。
• GNOMEデスクトップ環境のデフォルトのテキスト エディターであるgedit は、 LSとPS を改行として扱いますが、 NEL は扱いません。

Unicode 特殊文字U+2424 (改行記号、)、U+23CE (復帰記号、)、U+240D (復帰改行記号、)、およびU+240A (改行記号、) は、文書の読者にユーザーに見える文字を提示するためのグリフであるため、それ自体は改行として認識されません。 ␤⏎␍␊

移植可能なプログラムの作成を容易にするために、プログラミング言語では、さまざまな環境で使用されるさまざまな種類の改行シーケンスを処理するための抽象化がいくつか提供されています。

C言語では、エスケープ シーケンス '\n' (改行) と'\r' (復帰)が提供されています。ただし、これらは ASCII のLFおよびCR制御文字と同等である必要はありません。C 標準では、次の 2 つの特性のみが保証されています。

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

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

Cライブラリ関数fgets () は、 Unix の改行規則に従って記述されていないファイルは誤って読み取られるため、バイナリ モードでは使用を避けることをお勧めします。また、テキスト モードでは、システムのネイティブの改行シーケンスに従って記述されていないファイル (Unix システムで作成され、その後 Windows システムにコピーされたファイルなど) も誤って読み取られます。

もう 1 つのよくある問題は、行末にASCII CR + LFの使用を義務付けるインターネット プロトコルを使用して通信するときに'\n'を使用することです。テキスト モード ストリームに'\n'を書き込むと、Windows システムでは正常に機能しますが、Unix ではLFのみが生成され、より特殊なシステムではまったく異なるものが生成されます。バイナリ モードで"\r\n"を使用すると、少し改善されます。

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

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

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

例：

   文字列eol = System.lineSeparator ();文字列lineColor = "色: 赤" + eol ;   
        

Pythonでは、ファイルを読み込み用に開くとき、モジュールをインポートするとき、およびファイルを実行するときに「ユニバーサル改行サポート」が許可されます。^[23]

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

C#の例:

   文字列eol = Environment . NewLine ;文字列lineColor = "色: 赤" + eol ;文字列eol2 = "\n" ;文字列lineColor2 = "色: 青" + eol2 ;   
        
   
      
        

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

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

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

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

プログラムによっては、外部の改行文字を適切に処理できるものとできないものがあることから、この問題を見つけるのは難しい場合があります。たとえば、コンソールやエディターでソースファイルを表示すると正しく見えるにもかかわらず、コンパイラが不明瞭な構文エラーで失敗することがあります。最近のテキスト エディターは、一般に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 つがqmailメール転送エージェントです。qmail は、必要なCR + LFの代わりに裸のLF を送信するシステムからのメッセージの受信を積極的に拒否します。^[25]

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

ファイル転送プロトコルは、転送が「ASCII モード」で行われる場合、異なる改行表現を持つシステム間で転送されるファイルの改行を自動的に変換できます。ただし、このモードでバイナリ ファイルを転送すると、通常は悲惨な結果になります。改行バイト シーケンス (このコンテキストでは行末文字の意味を持ちませんが、通常のバイト シーケンスの一部にすぎません) が発生すると、他のシステムが使用する改行表現に変換され、ファイルが破損します。FTP クライアントは、バイナリ モードまたは ASCII モードを自動的に選択するために、いくつかのヒューリスティック(たとえば、ファイル名拡張子の検査) を使用することがよくありますが、最終的には、ファイルが正しいモードで転送されるようにするのはユーザー次第です。正しいモードについて疑問がある場合は、バイナリ モードを使用する必要があります。そうすれば、FTP によってファイルが変更されることはありません (ただし、正しく表示されない可能性があります)。^[28]

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

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

 :ファイルフォーマットをdosに設定する 
 :わーい

エディタは、大きなファイルの変換や多数のファイルの一括変換には適さない場合があります。大きなファイルの場合 (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コマンドは行末の種類を識別できます。

$ファイル myfile.txt
 myfile.txt: ASCII 英語テキスト、CRLF 行末文字付き

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 で終了)   
    

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

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

改行を捉える 2 つの方法は、どちらも自己矛盾がなく、改行が行を区切るものか、行を終了するものかのいずれかです。改行が区切り文字と見なされる場合、ファイルの最終行の後には改行はありません。一部のプログラムでは、ファイルの最終行が改行で終了していないと、その行の処理で問題が発生します。一方、改行が区切り文字として使用されることを期待するプログラムは、最後の改行を新しい (空の) 行の開始として解釈します。逆に、改行が終了文字と見なされる場合、最後の行を含むすべてのテキスト行は、改行で終了するものと想定されます。テキスト ファイルの最後の文字シーケンスが改行でない場合、ファイルの最終行は不適切または不完全なテキスト行であると見なされるか、ファイルが不適切に切り捨てられていると見なされる可能性があります。

ワードラップ機能を実装したソフトウェアを使用して人間が読むことを主な目的とするテキストでは、改行文字は通常、段落間や垂直リスト内など、次の単語が同じ行に収まるかどうかに関係なく改行が必要な場合のみ保存する必要があります。したがって、ワードプロセッサとほとんどのテキストエディタのロジックでは、改行は段落区切りとして使用され、「ハードリターン」と呼ばれます。これは、ワードラップを実装するために動的に作成され、表示インスタンスごとに変更可能な「ソフトリターン」とは対照的です。多くのアプリケーションでは、単一の段落内で強制的に改行するための「手動改行」と呼ばれる別の制御文字が存在します。ハードリターンの制御文字のグリフは通常、ピルクロー(¶) であり、手動改行の制御文字のグリフは通常、キャリッジリターン矢印 (↵) です。

RI（U +008D REVERSE LINE FEED、^[30] ISO/IEC 6429 8D、10進数141）は、印刷位置を1行戻す（用紙を逆送りするか、表示カーソルを1行上に移動することによって）ために使用され、他の文字を既存のテキストの上に印刷できるようにします。これは、文字を太字にしたり、下線、取り消し線、または分音記号などの他の文字を追加したりするために行われます。

同様に、PLD ( U +008B PARTIAL LINE FORWARD、10 進数 139) およびPLU ( U +008C PARTIAL LINE BACKWARD、10 進数 140) を使用すると、テキストの印刷位置を垂直行間隔の一部 (通常は半分) だけ進めたり戻したりできます。これらは、下付き文字 (進めてから戻す) や上付き文字 (逆にしてから進める) に組み合わせて使用​​でき、分音記号の印刷にも役立ちます。

• ファイルの終わり
• Enterキー
• ページ区切り

• Unicode リファレンス。Unicode 4.0 標準の第 5 章の段落 5.8 を参照してください (PDF)
• 「[NEL] 改行文字」。
• 行末パズル
• Wayback Machineでの改行の理解(2006 年 8 月 20 日アーカイブ)
• 「終焉の物語」