改行

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

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

改行(行末、行末( EOL )、​​次の行( NEL ) または改行と呼ばれることが多い)は、ASCIIEBCDICUnicodeなどの文字エンコーディング仕様における制御文字または一連の制御文字です。この文字、または文字列で、テキスト行の終わりと新しい行の開始を示すために使用されます。[1]

歴史

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

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

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

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

Multicsオペレーティング システムは1964 年に開発を開始し、改行としてLFのみを使用しました。Multics はデバイス ドライバーを使用して、この文字をプリンターが必要とする任意のシーケンス (追加の埋め込み文字を含む) に変換し、プログラミングには 1 バイトの方が便利でした。CRは、ある行を別の行にオーバープリントして太字下線、および取り消し線の効果を作成する便利な機能を提供するため、より明白な選択肢であるCRは使用されませんでした。おそらくもっと重要なことは、最終的なISO/IEC 646標準の草案に、行終端記号としてLFを単独で使用することが既に組み込まれていることです。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 進値 10進値 エスケープ シーケンス
UnixおよびUnix ライクなシステム ( LinuxmacOSFreeBSDAIXXenixなど)、MulticsBeOSAmigaRISC OSなど[3] アスキー LF 0A 10 \n
Microsoft WindowsDOS ( MS-DOSPC DOSなど)、Atari TOSDEC TOPS-10RT-11CP/MMP/MOS/2Symbian OSPalm OSAmstrad CPC、および他のほとんどの初期の非 Unix および非 IBM オペレーティング システム CRLF 0D 0A 13 10 \r\n
Commodore 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]およびRISC OSスプールされたテキスト出力[5] LF CR 0A 0D 10 13 \n\r
Atari 8 ビットマシン ATASCII 9B 155
z/OS ( OS/390 ) およびIBM i ( OS/400 ) を含むIBMメインフレーム システム EBCDIC NL 15 21 \025
ZX80およびZX81 ( Sinclair Research Ltdのホーム コンピューター) 特定の非 ASCII 文字セットを使用した 改行 76 118
  • EBCDICシステム (主にz/OS ( OS/390 ) やIBM i ( OS/400 )などのIBMメインフレーム システム)は、改行と改行の機能を組み合わせた文字としてNL (New Line, 0x15 ) [6]を使用します。同等の Unicode 文字 ( ) はNEL (Next Line) と呼ばれます。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規格は、準拠するアプリケーションが改行文字として認識すべき多くの文字を定義しています: [ 7]

 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 制御セットの制御文字であるUnicode NEL0x85にマップされます。[8]そのため、ECMA 48 [9]によって定義され、 ISO/IEC 2022 (ECMA 35 と同等) に準拠したエンコーディングによって認識されます。[10] C1 コントロール セットは、 ISO-8859-1とも互換性があります。[引用が必要]Unicode 標準で採用されているアプローチにより、ラウンドトリップ変換で情報を保持しながら、アプリケーションが可能なすべての種類の行末記号を認識できるようになります。

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

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

プログラミング言語で

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

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

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

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

C ライブラリ関数fgets ()はバイナリ モードでは避けるのが最善です。これは、Unix 改行規則で記述されていないファイルは読み違えるためです。また、テキスト モードでは、システム固有の改行シーケンスで記述されていないファイル (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+000DおよびU +000A を表すことが保証されています。

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

例:

   文字列 eol  = システム. lineSeparator (); 
   文字列 lineColor  =  "色: 赤"  +  eol ;

Python では、読み取り用にファイルを開くとき、モジュールをインポートするとき、およびファイルを実行するときに、"Universal Newline Support" が許可されます。[21]

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

C#での例:

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

異なる改行形式に関する問題

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

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

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

逆に、Windows コンピューターから生成されたファイルを Unix ライクなシステムで表示すると、余分な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内

 :ファイル形式を設定 = dos
 : wq

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

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

異なる改行規則間でファイルを変換する特別な目的のプログラムには、unix2dosdos2unixmac2unixunix2macmac2dosdos2mac、およびflipが含まれます。[26] trコマンドは事実上すべてUnix ライクなシステムで利用でき、単一の文字に対して任意の置換操作を実行するために使用できます。DOS/Windows テキスト ファイルは、ASCII CR文字を すべて削除するだけで 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 (拡張 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, 10 進数 141) は、印刷位置を 1 行戻す (用紙を逆送りする、または表示カーソルを 1 行上に移動する) ために使用されるので、他の文字が既存のテキストの上に印刷される可能性があります。これは、太字にしたり、下線、取り消し線、分音符号などの他の文字を追加したりするために行うことができます。

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

も参照

参考文献

  1. ^ 「改行とは何ですか?」. www.computerhope.com 2021年5月10日閲覧
  2. ^ クアルライン、スティーブ (2001). Vi の改良 - Vim (PDF)サムズ。p。120.ISBN _  9780735710016.
  3. ^ "ASCII チャート" .
  4. ^ ブレイ、アンドリュー C.; ディケンズ、エイドリアンC。ホームズ、マーク A. (1983)。BBC マイクロコンピューターの上級ユーザー ガイド(PDF)pp. 103, 104. ISBN  978-0946827008. 2019年1月30日閲覧
  5. ^ 「RISC OS 3 プログラマーズ リファレンス マニュアル」. 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. ^ 「ISO 6429 の C1 制御文字セット」(PDF) . ITSC​​J。情報処理学会。1983 年 10 月 1 日2022年3月3日閲覧
  9. ^ コード化文字セットの制御関数(PDF) (レポート)。ECMA インターナショナル。1991 年 6 月。
  10. ^ 文字コードの構造と拡張技術(PDF) (レポート) (第 6 版). ECMA インターナショナル。1994 年 12 月。
  11. ^ 「ECMAScript 2019 言語仕様」 . ECMA インターナショナル。2019 年 6 月. 11.3 ライン ターミネータ.
  12. ^ 「ECMAScript 2019 言語仕様」 . ECMA インターナショナル。2019 年 6 月。11.2ホワイトスペース
  13. ^ ブレイ、ティム (2014 年 3 月). 「JavaScript Object Notation (JSON) データ交換フォーマット」 . 7. ストリングス. RFC 7159 .  {{cite journal}}:引用ジャーナルが必要です|journal=( help )
  14. ^ "JSON のサブシューム (別名 JSON ⊂ ECMAScript)" . GitHub . 2018 年 5 月 22 日。
  15. ^ 「ECMAScript 2019 言語仕様」 . ECMA インターナショナル。2019 年 6 月。11.8.4 文字列リテラル
  16. ^ 「ECMAScript 2018 言語仕様」 . ECMA インターナショナル。2018 年 6 月。11.8.4 文字列リテラル
  17. ^ "YAML Ain't Markup Language (YAML) バージョン 1.2" . yaml.org5.4. 改行文字
  18. ^ "binmode - perldoc.perl.org" . perldoc.perl.org .
  19. ^ "PHP: 文字列 - マニュアル" . www.php.net
  20. ^ 「字句解析 – Python v3.0.1 ドキュメント」 . docs.python.org .
  21. ^ 「Python 2.3 の新機能」 .
  22. ^ "PHP: 定義済み定数 - マニュアル" . www.php.net
  23. ^ "cr.yp.to" .
  24. ^ レズニック、ピート (2001 年 4 月). 「RFC 2822 - インターネット メッセージ フォーマット」 . インターネット エンジニアリング タスク フォース
  25. ^ 「ファイル転送」 . 疑わしい場合は、バイナリ モードで転送してください。
  26. ^ 「UNIX、Macintosh、MS-DOS 間の ASCII テキスト変換」 . 2009 年 2 月 9 日にオリジナルからアーカイブされました。
  27. ^ 「C1 コントロールと Latin-1 サプリメント」(PDF) . unicode.org 2016年 2 月 13 日閲覧

外部リンク