復帰と改行の順序
キャリッジリターンと改行の正しい順序にすることが重要ですか？テキストエディタの場合、表示される順序は重要ですか？
たとえば
\r\n
この
\n\r
ジェフはすでにとても素敵なことを書いているようです ブログ投稿 件名に。
両方の制御文字が使用される場合の従来の順序は、キャリッジリターン、ラインフィードです。
この理由は、古いASR-33 Teletypeに遡ります。
ASR-33にキャリッジリターンが発行されると、プリントヘッドが右マージンの近くにある場合、左マージンに戻るのに10分の1秒かかり、さらに左がマージンがヒットします。
注文が改行であり、キャリッジリターンの場合、最初に印刷される文字はキャリッジリターンの10分の1秒後に発生する可能性があり、したがってページの途中で（スミアとして）印刷される可能性があります。ただし、キャリッジリターンの後にラインフィードが来る場合、ラインフィードにかかる時間により、プリントヘッドがトリップを完了するための余分な時間が提供されます。
一部のシステム（たとえば、古いXerox Sigma 7 OSを考えている）は、ラインフィードを実行してからキャリッジリターンを実行しますが、データストリームにNULL文字などを挿入して、プリントヘッドが処理できるようにします。
そして、もちろん、より高速なデバイス（初期の30 CPSテレプリンターなど）に到達すると、問題は悪化し、より複雑な戦略が必要になります。
（ユーザー入力の場合、ユーザーがReturnキーを押すとキャリッジリターンが提供され、ラインフィードはコンピューターが提供する必要があるという点もあります。このため、通常の印刷を行うのが「スタイル」であることがよくありました。 lines begin Line Feedおよびend Carriage Return。ユーザー入力のプロンプトは、改行のみで構成され、ユーザー入力はCarriage Returnで終了しました。一貫して使用すると、このスキームはうまく機能しましたが、もちろん常にそうなるとは限りませんでした。）
一般的な3つの改行形式があります。
- DOS\Windowsワールドの\ r\n
- OSX以前のMacの世界では\ r
- UnixおよびUnixライクな世界の場合は\ n
\ n\rは私が知っているどこでも標準ではないので、エディターがUnix形式のテキストファイルを持っていると考え、おそらく奇妙な\ r文字をテキストとして表示します。
歴史的に、\ rはキャリッジリターン（CR、ASCII code 13）に変換されます。これは、古い学校のタイプライターを指します。この場合、キャリッジを左に押し戻し、カーソルを先頭に戻します。\nはラインフィード（LF、ASCIIコード10）に変換され、文字をページの下に1文字移動します。潜在的に興味深いが、一般的には問題ではありません。現在のプラットフォームのラインフィード形式。
（申し訳ありませんが、これはこの問題に関する検索結果の主な結果です）
Notepad ++では重要です。改行で始まる場合\nその後、キャリッジリターン\r、ラインフィードは次の行になります。したがって、順序は次のとおりです。CR LF
キャリッジリターン、ラインフィードリサーチポットのフォローアップとして。
NotePadを使用すると、文字CR + LFが見つかったときに行末が検出されます。これは、CP/M、MS-DOS、およびWin32で使用される一般的な形式です。 ソース
Unixは、LFを検出すると行末を検出します。
AppleはCRを検出すると、行末を検出します。
Uni-Codeの観点からすると、 次の行（NEL） 状況をさらに複雑にするためです。
Cプログラミング言語では、改行文字を指定したときにキャリッジリターン+ラインフィードが書き込まれるのはなぜですか？例えば
printf（ "hello World\ n"）。
Cプログラミング言語およびUnixオペレーティングシステムは、stdioライブラリが変換することを意図して、改行文字として改行文字を再定義しました。 改行文字 そのプラットフォームの次の行の先頭に実際に移動するために必要なものすべて、たとえば、Win32の復帰+改行.
したがって、C/C++およびWindowsまたはLinuxで改行文字（実際にはLF文字）を記述すると、スタジオライブラリは、出力に必要な出力形式を決定しますそのプラットフォームの行末。
これは、Cプログラムでバイナリファイルまたはテキストファイルを作成すると明らかです。バイナリファイルを書き込むことを指定すると、スタジオライブラリはそのプラットフォームの出力形式を変更しません。そのため、データをファイルに書き込むときに改行文字に遭遇すると、プラットフォーム依存の文字が改行に挿入されません。
結局のところ、結論に至りましたが。
たとえば、キャリッジリターン+ラインフィードのWin32ルールに従って、以下を純粋なバイナリファイルとしてファイルに書き込みます。
MyText \ n MyText \ n MyText
そして、あなたはそれがあなたのテキストエディタでこのようにレンダリングすると仮定します。
MyText MyText MyText
ほとんどのエディターは、代わりにこのようにレンダリングします。
MyText MyText MyText
混乱のほとんどは、2つの異なる意味で\ n改行文字を使用するC標準によるものです。まず、オペレーティングシステムの新しい行形式に変換するSTIOライブラリの新しい行インジケーターとして（win32ではCR + LF、LinuxではLF、AppleではCR）。 16進値の改行。
10回の改訂とWin3.1,95,98、XPでのさまざまなアプローチの試行後、CRとLFを独立して使用できるアプリケーションが見つからなかったという結論に達しました。ほとんどのテキストエディターは、単一のCRまたはLFにヒットすると正方形を表示します。ほとんどのスマートテキストエディターは、適切なプラットフォームのCR + LF/LF/CRを見つけるかどうかに応じてファイル形式を変更します。
すべてではないにしても、ほとんどのエディターは、ユーザーに新しい行をレンダリングすることだけに関心があり、さまざまなファイル形式を切り替えます。ライターがレクサーと文字列トークナイザーをいつでもすぐに使用し、いつ新しい行を検出するかを心配している場合。下位レベルでファイル形式（CR + LF Win32、LF Linux、CR Apple）を検出して行番号をインクリメントするのが最適です。または、これを考慮するReadLine機能を使用します。
控えめに言っても、なぜキャリッジリターン+ラインフィードがテキストエディターに新しい行をレンダリングするよう指示するための標準としてIBMとWin32に採用されたのか、とてつもないことです。実際にはその冗長性。 Carriage Return + Line Feedが提示または提案する実際の名前に対して独立してレンダリングまたは使用する単一のアプリケーションを見つけることができませんでした。
だからあなたの大学の学生が世界を驚かせるために新しいテキストエディタを書いているなら。ファイル形式を自動的に検出し、CR + LFに与えられる実際の技術的意味を心配する必要はありません。
多数の改行コンバーターがあります。
例えば。 これ 。彼らはあなたのためにほとんどの仕事をします。