改行

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

「Hello」と「world」の間に改行が挿入されました

改行(しばしば行末行末EOL)、次の行NEL)、または改行と呼ばれる)は、文字エンコード仕様(ASCIIEBCDICなど)の制御文字または制御文字のシーケンスであり、テキスト行の終わりと新しい行の始まり。[1]

歴史

1800年代半ば、テレプリンターやテレタイプマシンが登場するずっと前に、モールス信号のオペレーターまたは電信士は、モールス信号の略称を発明して使用し、正式に書かれたテキストメッセージに空白のテキスト形式をエンコードしていました。特に、通常の文字間間隔なしで送信された文字通りのテキストモールス信号「B」と「T」の文字の連結によって表されるモールス信号BT(mnemonic b reak t ext)は、モールス信号で改行をエンコードして示すために使用されますまたは正式なテキストメッセージの 新しいセクション。

その後、現代のテレプリンターの時代に、標準化された文字セット制御コードが開発され、空白テキストのフォーマットを支援しました。ASCIIは、国際標準化機構(ISO)と米国規格協会(ASA)によって同時に開発されました。後者は、米国規格協会(ANSI)の前身の組織です。1963年から1968年の期間中、ISOドラフト標準は改行としてCR + LFまたはLFのみの使用をサポートしていましたが、ASAドラフトはCR + LFのみをサポートしていました。

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

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

Multicsオペレーティングシステムは1964年に開発を開始し、その改行としてLFのみを使用していました。Multicsは、デバイスドライバーを使用して、この文字をプリンターが必要とする任意のシーケンス(追加のパディング文字を含む)に変換し、プログラミングには1バイトの方が便利でした。CRは、太字アンダースコア取り消し線の効果を作成するために1つの行を別の行にオーバープリントする便利な機能を提供したため、より明白な選択のように思われるもの( CR)は使用されませんでした。おそらくもっと重要なことは、ラインターミネータとしてのLFのみの使用は、最終的なISO / IEC646規格のドラフトにすでに組み込まれていることです。UnixはMulticsの慣習に従い、その後、UnixライクなシステムはUnixに従いました。これにより、WindowsとUnixライクなオペレーティングシステムの間に競合が発生し、あるオペレーティングシステムで作成されたファイルを別のオペレーティングシステム(たとえば、メモ帳などのWindowsテキストエディタで記述されたUNIXシェルスクリプト)で適切にフォーマットまたは解釈できなくなりました。

表現

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

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

1つまたは2つの制御文字を使用した改行のソフトウェアアプリケーションとオペレーティングシステムの表現
オペレーティング・システム 文字コード 略語 16 進値 dec エスケープシーケンス
UnixおよびUnixライクなシステム(LinuxmacOSFreeBSDAIXXenixなど)、MulticsBeOSAmigaRISC OS、その他[3] ASCII LF 0A 10 \ n
Microsoft WindowsDOSMS-DOSPC DOSなど)、Atari TOSDEC TOPS-10RT-11CP / MMP / MOS / 2Symbian OSPalm OSAmstrad CPC、他のほとんどの初期の非Unixおよび非IBMオペレーティングシステム CR LF 0D 0A 13 10 \ r \ n
コモドール8ビットマシン(C64C128)、Acorn BBCZX SpectrumTRS-80Apple IIシリーズOberonクラシックMac OS、MIT Lisp MachineOS-9 CR 0D 13 \ r
QNX pre-POSIX実装(バージョン<4) RS 1E 30 \ 036
Acorn BBC [4]およびRISCOSスプールテキスト出力[5] LF CR 0A 0D 10 13 \ n \ r
Atari8ビットマシン ATASCII 9B 155
z / OSOS / 390)およびIBM iOS / 400) を含むIBMメインフレームシステム EBCDIC NL 15 21 \ 025
ZX80およびZX81 ( Sinclair Research Ltdの家庭用コンピューター 特定の非ASCII文字セットを使用しました NEWLINE NEWLINE 76 118
  • EBCDICシステム(主にz / OSOS / 390)およびIBM iOS / 400)を含むIBMメインフレームシステム)は、改行とキャリッジリターンの機能を組み合わせた文字としてNL(改行、0x15[6]を使用します。同等のUnicode文字()はNEL(次の行)と呼ばれます。EBCDICにもCRおよびLFと呼ばれる制御文字がありますが、 LFの数値0x25 )はASCIIで使用される数値( 0x0A)とは異なります。さらに、一部のEBCDICバリアントもNLを使用します0x85ただし、文字に別の数値コードを割り当てます。ただし、これらのオペレーティングシステムは、テキストファイルを1行に1つのレコードとして保存するレコードベースのファイルシステムを使用します。ほとんどのファイル形式では、ラインターミネータは実際には保存されません。
  • CDC 6000シリーズのオペレーティングシステムは、改行を60ビットワードの末尾にある2つ以上のゼロ値の6ビット文字として定義しました。一部の構成では、ゼロ値の文字をコロン文字として定義しているため、位置によっては複数のコロンが改行として解釈される可能性があります。
  • RSX-11OpenVMSは、テキストファイルを1行に1つのレコードとして保存するレコードベースのファイルシステムも使用します。ほとんどのファイル形式では、ラインターミネータは実際には保存されませんが、レコード管理サービスは保存されますファシリティは、アプリケーションによって取得されるときに、各行にターミネータを透過的に追加できます。レコード自体に同じ行末文字が含まれている可能性があります。これは、アプリケーションに応じて、機能または迷惑と見なされる可能性があります。RMSはレコードを保存するだけでなく、ファイルのさまざまなビットにレコードセパレータに関するメタデータを保存して、問題をさらに複雑にします(ファイルには固定長のレコード、カウントが前に付いたレコード、または特定の文字で終了したレコードが含まれる可能性があるため) )。ビットはジェネリックではなかったため、CR LFまたはLF、さらにはCRがラインターミネータであることを指定できましたが、他のコードを置き換えることはできませんでした。
  • 一部の初期のメインフレームオペレーティングシステムでは、固定回線長が使用されていました。このようなシステムでは、たとえば、72文字または80文字ごとに暗黙の行末が想定されていました。改行文字は格納されませんでした。ファイルが外部からインポートされた場合、行の長さより短い行はスペースで埋める必要があり、行の長さより長い行は切り捨てる必要がありました。これはパンチカードの使用を模倣しており、各行は別々のカードに保存されていました。通常、各カードには80列あり、多くの場合、列番号は73〜80列です。これらのシステムの多くは、の先頭にキャリッジ制御文字を追加しました記録; これは、次のレコードが前のレコードで開始された行の続きであるか、新しい行であるか、または前の行をオーバープリントする必要があるかを示している可能性があります(CRと同様)。多くの場合、これは通常の印刷文字であるため、行の最初の文字として使用することはできませんでした。一部の初期のラインプリンターは、送信されたレコードでこれらの文字を直接解釈していました。#

Unicode

Unicode標準では、準拠アプリケーションが行末記号として認識すべき文字の数が定義されています。[7]

 LFラインフィード、 U + 000A   
 VT垂直タブ U + 000B   
 FFフォームフィード U + 000C   
 CRキャリッジリターン U + 000D   
 CR + LFCRU + 000D)の後にLFU + 000A )
 NEL次の行、 U + 0085  
 LSラインセパレーター、 U + 2028   
 PS段落区切り文字、 U + 2029   

これは、すべての行末記号を単一の文字( LFなど)に変換するなどのアプローチと比較すると、非常に複雑に見える場合があります。ただし、Unicodeは、テキストファイルを既存のエンコーディングからUnicodeに、またはその逆に変換するときにすべての情報を保持するように設計されています。したがって、Unicodeには既存のエンコーディングに含まれる文字を含める必要があります。

例:NLEBCDICの一部であり、コード0x15を使用します。通常、C1制御セットの制御文字であるUnicode NEL0x85にマップされます。[8]このように、ECMA 48 [9]によって定義され、 ISO / IEC 2022(ECMA 35と同等)に準拠したエンコーディングによって認識されます。[10] C1コントロールセットはISO-8859-1とも互換性があります。[要出典]Unicode標準で採用されているアプローチにより、アプリケーションがすべての可能なタイプのラインターミネータを認識できるようにしながら、ラウンドトリップ変換で情報を保持できます。

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

Unicodeの特殊文字U + 2424SYMBOL FOR NEWLINE)、U + 23CERETURN SYMBOL) 、 U​​ + 240D (SYMBOL FOR CARRIAGE RETURN)、およびU + 240ASYMBOL FOR LINE FEED)は意図されたグリフであることに注意してください。ドキュメントの読者にユーザーに表示される文字を表示するため。したがって、改行として認識されません。

プログラミング言語で

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

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

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

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

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

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

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

JavaPHP[19]およびPython [20]は、 「\ r \ n」シーケンスを提供します(ASCII CR + LFの場合)。Cとは対照的に、これらはそれぞれU + 000DU + 000Aの値を表すことが保証されています。

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

例:

   文字列 eol  =  System lineSeparator (); 
   String  lineColor  =  "Color:Red"  +  eol ;

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

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

C#の例

   文字列 eol  = 環境NewLine ; 
   string  lineColor  =  "色:赤"  +  eol ;
   
   string  eol2  =  "\ n" ; 
   string  lineColor2  =  "色:青"  +  eol2 ;

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

geditで作成され、 16進エディターで表示されるテキストファイルテキストオブジェクトの他に、16進値が0AのEOLマーカーのみがあります。

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

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

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

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

一部のプログラムは外国の改行を適切に処理しますが、他のプログラムは処理しないため、問題を特定するのは難しい場合があります。たとえば、コンソールまたはエディタに表示されたときにソースファイルが正しく表示されていても、コンパイラが不明瞭な構文エラーで失敗する場合があります最新のテキストエディタは通常、CR + LF改行のすべてのフレーバーを認識し、ユーザーが異なる標準間で変換できるようにします。Webブラウザは通常、さまざまな種類の改行を使用するテキストファイルやWebサイトを表示することもできます。

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

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

電子メールの標準のインターネットメッセージ形式[24]には、「CRとLFはCRLFとして一緒にのみ発生する必要があり、本文に個別に表示されてはなりません」と記載されています。

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

改行形式間の変換

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

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

 :set  fileformat = dos
 :wq

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

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

異なる改行規則間でファイルを変換するための特別な目的のプログラムには、unix2dosとdos2unixmac2unixunix2macmac2dosdos2mac、およびflipが含まれます。[26] trコマンドは 、事実上すべてのUnixライクなシステムで使用可能であり、単一の文字に対して任意の置換操作を実行するために使用できます。DOS / Windowsテキストファイルは、すべてのASCIICR文字を 削除するだけでUnix形式に変換できます。

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

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

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

プラットフォームにPerlインタープリターがある場合は 、 awksed、または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(CRの追加) GNU拡張機能を使用するLinuxベースのOSの場合)
$ sed -e 's / \ r $ // ' inputfile>              
'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:ASCII英語テキスト、CRLFラインターミネータ付き

Unix egrep(extended 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、[27] ISO / IEC 6429 8D、decimal 141)を使用して、印刷位置を1行戻します(用紙を逆送りするか、表示カーソルを1行上に移動します)。他の文字が既存のテキストの上に印刷される可能性があること。これは、それらを太字にするため、または下線、ストライクスルー、または発音区別符号などの他の文字を追加するために行うことができます。

同様に、PLDU + 008B PARTIAL LINE FORWARD、10進数の139)およびPLUU + 008C PARTIAL LINE BACKWARD、10進数の140)を使用して、テキストの印刷位置を垂直線間隔の一部(通常は半分)だけ前後に移動できます。 )。これらは、下付き文字(前進してから反転)と上付き文字(反転してから前進)に組み合わせて使用​​でき、発音区別符号の印刷にも役立つ場合があります。

も参照してください

参考文献

  1. ^ 「改行とは何ですか?」www.computerhope.com 2021年5月10日取得
  2. ^ Qualline、Steve(2001)。Viの改善-Vim(PDF)サムズ。p。120. ISBN  9780735710016
  3. ^ 「ASCIIチャート」
  4. ^ ブレイ、アンドリューC。; ディケンズ、エイドリアンC。; ホームズ、マークA.(1983)。BBCマイクロコンピューターの上級ユーザーガイド(PDF)pp。103、104。ISBN _  978-09468270082019年1月30日取得
  5. ^ 「RISCOS3プログラマーズリファレンスマニュアル」2018年7月18日取得
  6. ^ IBM System / 360 Reference Data Card、Publication GX20-1703、IBM Data Processing Division、White Plains、NY
  7. ^ 「UAX#14:Unicode改行アルゴリズム」www.unicode.org
  8. ^ 「ISO6429のC1制御文字セット」(PDF)ITSC​​J。IPSJ。1983年10月1日。
  9. ^ コード化された文字セットの制御機能(PDF)(レポート)。ECMAインターナショナル。1991年6月。
  10. ^ 文字コードの構造と拡張技術(PDF)(レポート)(第6版)。ECMAインターナショナル。1994年12月。
  11. ^ 「ECMAScript2019言語仕様」ECMAインターナショナル。2019年6月。11.3ラインターミネーター
  12. ^ 「ECMAScript2019言語仕様」ECMAインターナショナル。2019年6月。11.2ホワイトスペース
  13. ^ ブレイ、ティム(2014年3月)。「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」7.文字列RFC7159_  {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  14. ^ 「JSON(別名JSON⊂ECMAScript)を含める」GitHub2018年5月22日。
  15. ^ 「ECMAScript2019言語仕様」ECMAインターナショナル。2019年6月。11.8.4文字列リテラル
  16. ^ 「ECMAScript2018言語仕様」ECMAインターナショナル。2018年6月。11.8.4文字列リテラル
  17. ^ 「YAMLはマークアップ言語(YAML)バージョン1.2ではありません」yaml.org5.4。改行文字
  18. ^ "binmode --perldoc.perl.org"perldoc.perl.org
  19. ^ 「PHP:文字列-手動」www.php.net
  20. ^ 「字句解析– Pythonv3.0.1ドキュメント」docs.python.org
  21. ^ 「Python2.3の新機能」
  22. ^ 「PHP:事前定義された定数-手動」www.php.net
  23. ^ "cr.yp.to"
  24. ^ Resnick、Pete(2001年4月)。「RFC2822-インターネットメッセージフォーマット」インターネットエンジニアリングタスクフォース
  25. ^ 「ファイル転送」疑わしい場合は、バイナリモードで転送してください。
  26. ^ 「UNIX、Macintosh、MS-DOS間のASCIIテキスト変換」2009年2月9日にオリジナルからアーカイブされました。
  27. ^ 「C1コントロールとラテン1サプリメント」(PDF)unicode.org 2016年2月13日取得

外部リンク