回答:
彼らは別のキャラクターです。\r
はキャリッジリターンで、\n
ラインフィードです。
「古い」プリンタで\r
は、印刷ヘッドを行の先頭に戻し\n
、紙を1行進めました。したがって、次の行で印刷を開始するには両方が必要でした。
明らかにそれは今やいくらか重要ではありませんが、コンソールによって\r
は、行の先頭に移動して既存のテキストを上書きできる場合があります。
さらに重要なことに、Unix \n
は行区切り文字として使用する傾向があります。Windows \r\n
は行区切り文字として使用する傾向があり、Mac(OS 9まで)は行区切り文字として使用するために使用さ\r
れていました。(Mac OS XはUnix-yなので、\n
代わりに\r
使用します。ただし、代わりにを使用する互換性の状況が存在する場合があります。)
詳細については、ウィキペディアの改行記事を参照してください。
編集:これは言語依存です。たとえば、C#とJavaでは、\n
常に Unicode U + 000Aを意味し、ラインフィードとして定義されます。CおよびC ++では、意味はプラットフォーム固有であるため、水はやや濁っています。詳細についてはコメントを参照してください。
\n
が保証されています(セクション2.4.4.4)。もちろん、OPがプラットフォームを指定しているとよいでしょう。また、このレベルの詳細は、違いを尋ねるだけの人にとってはわかりにくいと思います。
CおよびC ++では、\n
は概念で\r
あり、文字であり、\r\n
(ほとんどの場合)移植性のバグです。
古いテレタイプについて考えてみてください。印字ヘッドは行と列に配置されています。印刷可能な文字をテレタイプに送信すると、現在の位置に文字が印刷され、ヘッドが次の列に移動します。(これは概念的にはタイプライターと同じですが、タイプライターは通常、プリントヘッドに対して用紙を移動します。)
現在の行を終了して次の行から始めたい場合は、2つの別々の手順を実行する必要がありました。
ASCIIは、これらのアクションを2つの異なる制御文字としてエンコードします。
\x0D
(CR)印字ヘッドを行の先頭に戻します。(UnicodeはこれをとしてエンコードしU+000D CARRIAGE RETURN
ます。)\x0A
(LF)印字ヘッドを次の行に移動します。(UnicodeはこれをとしてエンコードしU+000A LINE FEED
ます。)テレタイプと初期のテクノロジープリンターの時代には、これらが2つの別々の操作であるという事実を実際に利用していました。LFを付けずにCRを送信すると、すでに印刷した行の上に印刷できます。これにより、アクセント、太字、下線などの効果が可能になりました。一部のシステムでは、ハードコピーにパスワードが表示されないようにするために、数回オーバープリントされました。初期のシリアルCRT端末では、CRは画面上のテキストを更新するためにカーソル位置を制御する方法の1つでした。
しかし、ほとんどの場合、実際には次の行に行きたいだけです。一部のシステムでは、制御文字のペアを要求するのではなく、どちらか一方のみを許可しました。例えば:
U+0085 NEXT LINE
ですが、実際のEBCDIC値は0x15
です。異なるシステムが異なる方法を選択したのはなぜですか?普遍的な基準がなかったからです。キーボードがおそらく「Enter」と言っているところで、古いキーボードは「Return」と言っていましたが、これはキャリッジリターンの略でした。実際、シリアル端末でReturnキーを押すと、実際にはCR文字が送信されます。テキストエディタを作成している場合、ターミナルから入力した文字をそのまま使用するのは魅力的です。おそらくそれが、古いMacがCRだけを使用した理由です。
これで標準ができたので、改行を表す方法は他にもあります。世の中で非常にまれですが、Unicodeには次のような新しい文字があります。
U+2028 LINE SEPARATOR
U+2029 PARAGRAPH SEPARATOR
Unicodeが登場する前から、プログラマーは、基礎となる文字セットを気にすることなく、最も有用な制御コードのいくつかを表す簡単な方法を求めていました。Cには、制御コードを表すためのいくつかのエスケープシーケンスがあります。
\a
(アラート用)テレタイプのベルを鳴らすか、端末のビープ音を鳴らす\f
(改ページ用)次ページの先頭に移動\t
(タブの場合)印刷ヘッドを次の水平タブ位置に移動します(このリストは意図的に不完全です。)
このマッピングはコンパイル時に行われます-コンパイラは\a
、ベルを鳴らすために使用されるすべての魔法の値を確認して配置します。
これらのニーモニックのほとんどは、ASCII制御コードと直接相関していることに注意してください。たとえば、\a
にマップします0x07 BEL
ます。ホスト文字セットにASCII以外のもの(EBCDICなど)を使用するシステム用にコンパイラを作成できます。特定のニーモニックを持つ制御コードのほとんどは、他の文字セットの制御コードにマップできます。
フザー!携帯性!
よくほとんど。Cではprintf("\aHello, World!");
、ベル(またはビープ)を鳴らしてメッセージを出力するように書くことができます。しかし、次の行に何かを印刷したい場合でも、ホストプラットフォームが出力の次の行に移動するために何が必要かを知る必要があります。CR LF?CR?LF?NL?他に何か?移植性のためにそんなに。
Cには、バイナリとテキストの2つのI / Oモードがあります。バイナリモードでは、送信されるデータはすべてそのまま送信されます。しかし、テキストモードでは、ホストプラットフォームが新しい行に必要なもの(またはその逆)に特殊文字を変換するランタイム変換があります。
すばらしいので、特別なキャラクターは何ですか?
それも実装に依存しますが、実装に依存しない方法で指定できます\n
。通常、「改行文字」と呼ばれます。
これは微妙ですが重要なポイントです。 コンパイル時に実装定義の文字値に\n
マップされます(テキストモードの場合)は、実行時に、基盤となるプラットフォームが移動するために必要な実際の文字(または文字シーケンス)に再度マップされます。次の行へ。
\n
2つのマッピングが関係しているため、他のすべてのバックスラッシュリテラルとは異なります。この2段階のマッピングは、とは\n
大幅に異なり\r
ます。これは、コンパイル時のCR(または、基になる文字セットが最も似ている制御コード)へのコンパイル時のマッピングです。
これは多くのCおよびC ++プログラマーをつまずかせます。それらの100をポーリングする場合、少なくとも99 \n
はラインフィードを意味します。これは完全に真実ではありません。ほとんど(おそらくすべて)のCおよびC ++の実装では、LFをの魔法の中間値として使用しますが\n
、これは実装の詳細です。コンパイラが別の値を使用することは現実的です。実際、ホストの文字セットがASCIIのスーパーセットでない場合(たとえば、EBCDICの場合)は、\n
ほぼ確実にLFにはなりません。
したがって、CおよびC ++では:
\r
文字通りキャリッジリターンです。\n
実行時にホストプラットフォームの改行セマンティクスとの間で(テキストモードで)変換される魔法の値です。\r\n
ほとんどの場合、移植性のバグです。テキストモードでは、これはCRに変換され、その後にプラットフォームの改行シーケンスが続きます-おそらく意図したものではありません。バイナリモードでは、これはCRに変換され、その後にLF ではない可能性がある魔法の値が続きます。\x0A
ASCII LFを示す最もポータブルな方法ですが、それはバイナリモードでのみ行いたいものです。ほとんどのテキストモード実装は、それをのように扱います\n
。\r\n
実際に、行を個別のリスト要素に適切に分割できる唯一の方法です。これが変なHTMLアーティファクトなのか、それともPythonがrequest
オブジェクトから文字列を取り込む方法に関係しているのか疑問に思います。
"\ n" =>改行または改行(セマンティクス)
Unixベースのシステムでは、「\ n」だけを使用してテキスト行を終了します。
つまり、\ rにはASCII値13(CR)があり、\ nにはASCII値10(LF)があります。Macは行区切り文字としてCRを使用します(少なくとも以前はそうでしたが、現代のMacではわかりません)。* nixはLFを使用し、Windowsは両方(CRLF)を使用します。
\ rはキャリッジリターンです。\ nは改行(改行)です...それぞれの意味はOSによって異なります。Cの「\ n」と「\ r \ n」の違いの詳細については、この記事をお読みください。
'\n'
ます。