web-dev-qa-db-ja.com

テキストエディタがこのファイルをUTF-8と考えるのはなぜですか？

2つのテキストファイルがあり、内容を正確に保存するために、Pastebinではなくダウンロードリンクを提供しています。

これらのテキストファイルは両方とも、スペース、キャリッジリターン、改行、および文字Xのみで構成され、ASCIIエンコードされている必要があります。これら2つのファイルの唯一の違いは、2番目のファイルの先頭と末尾の空白行が削除され、各行の先頭と末尾のスペースが削除されました。

最初のファイルは問題を引き起こしていません。何らかの理由で、私のテキストエディタはsecondファイルをUTF-8として検出しています：

  • メモ帳をテキストファイルをダブルクリックして開くと、破損したテキストが表示されます。

enter image description here

  • メモ帳は、[ファイル]→[開く]を使用する場合、明示的に[ANSI]を選択している限り、正常に機能します。

enter image description here

  • Notepad ++は、ファイルを正常に表示しますが、「UTF-8（BOMなし）」としてエンコードされていると考えています。

enter image description here

  • Notepad ++では、「ANSIに変換」を選択してファイルを保存しても、保存されたファイルは元のファイルとバイト単位で同一であり、両方のエディターがUTF-8として検出します。

  • どちらのエディターも最初のファイルに問題はなく、それをASCII（またはANSI））として正しく認識します。

16進エディタで2番目のテキストファイルを見ました。確かに、それはBOMで始まりません。ファイルの最初の数バイトは20 20 20 20 20 20 20 20、スペースで始まるので、そうあるべきです：

enter image description here

私の質問は、なぜ、NotepadとNotepad ++の両方が2番目のファイルをUTF-8として検出するのですか？ファイルにBOMヘッダーがない場合、なぜこれが発生するのでしょうか。また、これを引き起こしている最初のファイルと比較して、2番目のファイルの特徴は何ですか。何が起こっているのか理解できません。

windows-7text-editorsunicode
6
Jason C

これらのファイルは両方とも有効ですASCII and UTF-8は、コードポイント<0x7Fのみを含むためです（言い換えると、1バイトの値が127より大きいことはありません）。

私の推測では、メモ帳++とメモ帳のヒューリスティックは異なります[複数のエンコーディングが有効な場合]：

N ++は単にUTF-8を好みます。

メモ帳（Winユーティリティ）は、ファイルの長さをUTF-16（主に2バイトのネイティブWindowsエンコーディング）として扱うよりも偶数（72 320バイトの2番目のファイルとして）を調べているようです。 [常にではありませんが、おそらく常に2バイトであった以前のUCS-2から引き継がれました]）そしてそれが奇数（最初のファイルとして-78 045バイト）の場合はASCII（シングルバイト）。

最初のファイルの最後に単一のスペース（または他の有効なASCII文字）を追加して長さを均等にすることでテストできます-メモ帳で開くと、Unicodeであると見なされ、「ガベージ」が表示されます

btw：両方のファイルが私のPCのNotepad ++でutf-8として認識されます

5
wmz