Windows の「Unicode」は UTF-16LE で、各文字は 2 または 4 バイトです。 Linux は UTF-8 を使用し、各文字は 1 ～ 4 バイトです。
「すべてのソフトウェア開発者が絶対に、積極的に Unicode と文字セットについて知っておく必要がある絶対最小値 (言い訳はありません!)」
改行
Windows は CRLF (\r\n) を使用します 、 0D 0A ) Unix は単に LF (\n) を使用しますが、行末は 、 0A ).
文字エンコード
最新の (つまり、2004 年以降) Unix ライクなシステムのほとんどは、UTF-8 をデフォルトの文字エンコーディングにしています。
ただし、Windows には UTF-8 のネイティブ サポートがありません。内部では UTF-16 で動作し、char を想定しています。 ベースの文字列はレガシー コード ページにあります。幸いなことに、メモ帳は UTF-8 ファイルを読み取ることができます。残念ながら、「ANSI」エンコーディングはまだ デフォルトです。
問題のある特殊文字
U+001A 代役
Windows は (まれに) Ctrl を使用します +Z ファイルの終わり文字として。たとえば、type の場合 コマンド プロンプトでファイルを呼び出すと、最初の 1A で切り捨てられます バイト。
Unix では、Ctrl +Z 特別なことではありません。
U+FEFF ZERO with NO-BREAK SPACE (Byte-Order Mark)
Windows では、UTF-8 ファイルは「バイト オーダー マーク」EF BB BF で始まることがよくあります。 ANSI ファイルと区別します。
Linux では、BOM はシェル スクリプトのシバン行などを壊すため、お勧めできません。さらに、とにかく UTF-8 がデフォルトのエンコーディングである場合、UTF-8 署名を使用しても意味がありません。
<ブロック引用>
私が聞いた違いの 1 つは、\r\n (Windows) と改行 (Linux) の \n の使用です。
はい。ほとんどの UNIX テキスト エディタはこれを自動的に処理しますが、Windows プログラマのエディタはこれを処理できますが、一般的なテキスト エディタ (ベース メモ帳) は処理しません。
Windows では、一部のコンテキストでは END OF FILE として EOF (Ctrl-Z) も必要なようですが、UNIX ではおそらく見られないでしょう。
MacOS X は現在 UNIX であるため、UNIX の行末を使用していることを思い出してください。ただし、OS X (MacOS 9 以下) より前では、独自の末尾がありました (\r)
編集:他の形式の CR および LF:
- \n は ASCII 0x0A、改行 (LF)
- \r は ASCII 0x0D、キャリッジ リターン (CR) です