Windowsでは改行マーカーは_CR+LF
_である必要がありますが、UnixではLF
のみです。
それで、Console.Write("line1\nline2");
のようなものを使用すると、なぜそれが「正しく」機能し、2行表示されるのですか?私はこの_\n
_が機能しないことを期待しており、_\r\n
_の組み合わせのみが機能します。
'\n'
は改行文字です。従来は、プリンターが用紙を1行に巻き上げていました。 '\r'
はキャリッジリターン文字で、従来はプリンターヘッドが用紙の左端に移動していました。
この方法で文字を解釈するプリンターおよびコンソールでは、line1\nline2
の出力は次のようになります。
line1
line2
多くのコンソール(およびエディター)は '\ n'を解釈して、新しい行を開始するおよびカーソルをその新しい行の先頭に置きますライン。それはあなたがここで見るものです。
特定の定数をハードコーディングするのではなく、 Environment.NewLine を使用する必要があります。
これは、基盤となるWindowsコンソールの標準的な動作にすぎません。 0x0A
をコンソールに出力する場合、ネイティブCアプリはまったく同じことを行います。
もちろん、新しい行には Environment.NewLine
を使用する必要があります。 Environment.NewLine
は、Windowsでは\r\n
に、UNIXのようなシステムでは\n
に解決されます。
私の経験では、WriteLine()を使用してコンソールに出力すると、\ nエスケープ文字を受け入れます。 StreamWriterを使用しているときにWriteLine()を呼び出すと、\ r\nと入力して新しい行に移動します。コンソールは、キャリッジリターンなしで\ nエスケープ文字を受け入れるようにプログラムされていると思います。
ファイルエンコーディング!= Console
解釈。
つまり、CR
+ LF
の「Windows標準」はファイルに存在しますが、LF
または\n
は、コンソールウィンドウで適切なキャリッジリターンと改行の解釈をもたらしました。
\ nは改行文字です。 * nixとWindowsシステムの両方で、2行を作成する必要があります。\rはキャリッジリターンで、筆記具を行頭に移動します。
最近のほとんどのコンソール/エディターは、\ nを\ r\nと解釈するのに十分な復元力を備えています