改行

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

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

改行(頻繁に呼び出さ行末行の終わりEOL)、次の行NEL)または改行は)ある制御文字に制御文字または一連の文字エンコーディングの指定(例えば、ASCIIEBCDIC意味するために使用されます)年末テキストの行と新しいものの始まり、[1]例えば、ラインフィードLF)でのUnix一部のテキストエディタは、キーを押すときにこの特殊文字を設定します。 Enter

テキストファイルを表示(または印刷)する場合、この制御文字または文字のシーケンスにより、テキストエディタはそれに続く文字を新しい行に表示します。

歴史

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

その後、現代のテレプリンターの時代に、標準化された文字セット制御コードが開発され、空白テキストのフォーマットを支援しました。 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は、ある行を別の行にオーバープリントして太字取り消し線の効果を作成する便利な機能を提供したため、より明白な選択のように思われるもの(CR)は使用されませんでした。おそらくもっと重要なことは、ラインターミネータとしてLFのみの使用は、最終的なISO / IEC646規格のドラフトにすでに組み込まれていることです。UnixMulticsの慣習に従い、その後、UnixライクなシステムがUnixに従いました。これにより、WindowsとUnixライクなオペレーティングシステムの間に競合が発生し、あるオペレーティングシステムで作成されたファイルを別のオペレーティングシステム(メモ帳などのWindowsテキストエディタで記述されUNIXシェルスクリプトなど)で適切にフォーマットまたは解釈できなくなりました

表現

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

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

1つまたは2つの制御文字を使用した改行のソフトウェアアプリケーションとオペレーティングシステムの表現
オペレーティング・システム 文字コード 略語 16進値 dec エスケープシーケンス
UnixおよびUnixライクなシステム(LinuxmacOSFreeBSDAIXXenixなど)、MulticsBeOSAmigaRISCOSなど[3] ASCII LF 0A 10 \NS
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 \NS
QNX pre-POSIX実装(バージョン<4) RS 1E 30 \ 036
どんぐりBBC [4]RISC OSは、スプールテキスト出力[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およびZX81Sinclair Research Ltdの家庭用コンピューター 特定の非ASCII文字セットを使用しました NEWLINE NEWLINE 76 118
  • EBCDICシステム(主にz / OSOS / 390)およびIBM iOS / 400を含むIBMメインフレームシステム)は、改行とキャリッジリターンの機能を組み合わせた文字としてNL改行0x15[6]を使用します。同等のUnicode文字()はNEL(次の行)と呼ばれます。 EBCDICにもCRおよびLFと呼ばれる制御文字がありますが、LF0x25)の数値は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 + 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 + 240DSYMBOL FOR CARRIAGE RETURN)、およびU + 240ASYMBOL FOR LINE FEED)は意図されたグリフであることに注意してください。ドキュメントの読者にユーザーに表示される文字を表示するため。したがって、改行として認識されません。

エスケープシーケンス

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

エスケープシーケンス
特殊文字 エスケープシーケンス によって使われた ...
line feed \NS PerlVim、..。 Vim::%s/}/}\r\t/g=ファイル全体で各「}」文字を「}改行タブ」に置き換えます
carriage return \NS
tabulator \NS

プログラミング言語で

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

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

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

Cが発生したUnixプラットフォームでは、ネイティブの改行シーケンスはASCII LF0x0A)であるため、「\ n」は単にその値として定義されています。内部表現と外部表現が同一であるため、テキストモードで実行される変換はノーオペレーションであり、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 + 000DU + 000Aの値を表すことが保証されています

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

例:

   文字列 eol  = システムlineSeparator (); 
   String  lineColor  =  "Color:Red"  +  eol ;

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

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

C#の

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

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

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

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

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

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

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

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

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

一部のプログラムは外国語の改行を適切に処理しますが、他のプログラムは処理しないため、問題を見つけるのは難しい場合があります。たとえばコンソールまたはエディターに表示されたときにソースファイルが正しく表示されていてもコンパイラーがあいまいな構文エラーで失敗する場合がありますUnixライクなシステムでは、コマンドcat -v myfile.txtがファイルをstdout(通常はターミナル)に送信し、^ Mを表示します。これは、デバッグに役立ちます。最新のテキストエディタは通常、CR + LF改行のすべてのフレーバーを認識し、ユーザーが異なる標準間で変換できるようにします。ウェブブラウザー 通常、さまざまな種類の改行を使用するテキストファイルや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ライクなシステムおよび単一文字上の任意の置換操作を実行するために使用することができます。A DOS / Windowsのテキストファイルは、単純にすべてのASCII除去することにより、UNIX形式に変換することができたCRで文字を

$ 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>              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(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
 $ 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)サムズ。NS。120. ISBN  9780735710016
  3. ^ 「ASCIIチャート」
  4. ^ ブレイ、アンドリューC。; ディケンズ、エイドリアンC。; ホームズ、マークA. BBCマイクロコンピューターの上級ユーザーガイド(PDF)頁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. ^ 「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」2014年3月。7。文字列RFC 7159 
  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. ^ 「RFC2822-インターネットメッセージフォーマット」インターネットエンジニアリングタスクフォース
  25. ^ 「ファイル転送」疑わしい場合は、バイナリモードで転送してください。
  26. ^ 「UNIX、Macintosh、MS-DOS間のASCIIテキスト変換」2009年2月9日にオリジナルからアーカイブされまし
  27. ^ 「C1コントロールとラテン1サプリメント」(PDF)unicode.org 取得した13年2月2016

外部リンク