異なるプラットフォームで異なる路線の終端が存在する歴史的理由

Question

DOS/Windows と Mac は、なぜ行末に ではなく と を使用することにしたのでしょうか?それは単に Unix とは「違う」ことを目指した結果だったのでしょうか？

そして今、Mac OS X は Unix (-like) なので、Apple は から に切り替えたのでしょうか?

Answer 1

DOSはCP / MからCR-LFの行末（アスキー文字を明示的にするだけで\ r \ nと呼んでいます）を継承しました。 CP / Mは、CP / MデザイナーのGary Kildallに影響を与えたさまざまなDECオペレーティングシステムから継承しました。

CR

Unixの人たちはそれをデバイスドライバーで処理し、必要に応じて、必要なデバイスへの出力でLFをCR-LFに変換しました。

ご想像のとおり、Mac OS XはLFを使用するようになりました。

Answer 2

@Mark Harrison に本当に感謝しています...

Unix は「プログラマが指定したテキストを出力しているだけ」だが、DOS は壊れている、と言う人は明らかに間違っています。また、DOS が EOF 文字を見つけたときに EOF にフラグを立てるのは愚かであるという主張もあり、その EOF 文字が正確に何のためのものなのかという疑問が生じます。

テキスト ファイルの行末には唯一の正しい規則はなく、プラットフォーム固有の規則があるだけです。結局のところ、CR-LF でさえ、これまでに使用された行末規則は CR と LF だけではなく、ASCII が唯一の文字セットでもありませんでした。問題は、このプラットフォーム依存の詳細が抽象化されていない C 標準ライブラリとランタイムです。他の第 3 世代言語 (Pascal や Basic など) でも、少なくともある程度は対応できました。このため、C コンパイラが他のプラットフォーム用に作成されたときは、既存のソース コードや書籍との互換性を実現するためにランタイム ライブラリのハックが必要でした。

実際、ユーザーは通常、CR LF 行末を必要とする ASCII 端末を使用していたため、もともとコンソール I/O に文字列変換が必要だったのは Unix と Multics でした。ただし、この変換はデバイス ドライバーで行われました。その目的は、保存されるテキスト ファイルについては 1 つの規則を採用し、それに固執する方がよいと考え、デバイス固有の情報を抽象化することでした。

C テキスト I/O ハックは原理的には CygWin が現在行っていることと似ており、Linux ランタイムをハッキングして Windows 上で期待できるのと同じように動作します。何かをハッキングして Unix に似たものに変えようとしたという実際の歴史があります。しかし、Linux を Windows に変える Wine もあります。奇妙なことに、Windows に対する行末の間違った批判を以下の記事で読むことができます。 CygWin FAQ (Internet Archive リンクは 2013 年に追加されました - このページはもう存在しません)。彼らは基本的に自分たちが批判していることを、もっと壮大なスケールでやっているので、おそらくそれは彼らのユーモアのセンスなのかもしれません ;-)

C++ 標準ライブラリ (実装されているプラ​​ットフォームに関係なく) は、行末を抽象化する iostream を使用してこの問題を回避します。 アウトプットに関しては、それが私には合っています。入力の場合はさらに制御が必要なので、文字ごとに解釈するか、スキャナー ジェネレーターを使用します。

[編集 上記の取り消し線が付いた主張は真実ではなく、決して真実ではなかったことが判明しました。の std::endl 文字通りに訳すと、 \n そしてフラッシュ。の \n 全く同じです \n C では「改行」と呼ばれがちですが、実際には ASCII 改行文字であり、必要に応じてランタイムによって変換されます。面白いことに、誤った仮定が深く根付いてしまい、疑問を持たなくなることがあります。基本的に、互換性の理由から、C++ には C が行ったことと同じことを (最上位にレイヤーを追加する以外に) 行う選択肢はありませんでした。それは常に明らかであるべきでした。]

私の見解からの最大の責任は C にありますが、他のプラットフォームへの移行を予測できなかったプロジェクトは C だけではありません。ビル・ゲイツを非難するのはまったくの馬鹿げた話だ。彼がやったのは、当時人気のあった CP/M のバリエーションを購入して磨き上げただけだ。実際、これは単なる歴史です。ほとんどのテキスト ファイルで 128 ～ 255 の文字コードが何を指すのかがわからないのと同じ理由です。3 つの行末規則すべてに簡単に対処できることを考えると、一部の開発者が依然として「私のプラットフォームの規則が唯一の真の方法であり、好むと好まざるにかかわらず、それを強制するつもりです」という態度を主張しているのは奇妙です。

また、将来のテキスト ファイルでは、Unicode 行区切りコードポイント U+2028 がこれらすべての規則に置き換わりますか?;-)

Answer 3

ウィキペディアには行末に関するかなり長い記事があります。 「履歴」セクションは質問の少なくとも一部に回答します。 http://en.wikipedia.org/wiki/Newline#履歴

Answer 4

CRLFがほとんどインターネット標準であることに注目するのは興味深いことです。つまり、回線指向のほとんどすべての標準インターネットプロトコルはCRLFを使用します。 SMTP、POP、IMAP、NNTPなど。電子メールの本文は、CRLFで終了する行で構成されます。