UTF16-LE と UTF-32LE で使用されるバイト オーダー マークにはあいまいさがあるようです。特に、次の 8 バイトを含むファイルを考えてみましょう。
FF FE 00 00 00 00 00 00
このファイルに次のものが含まれているかどうかを確認するにはどうすればよいですか。
Unicode BOM はhttp://unicode.org/faq/utf_bom.html#bom4で説明されていますが、このあいまいさについての議論はありません。何か不足していますか？
名前が示すように、BOMはエンコーディングではなく、バイト オーダーのみを示します。最初にエンコーディングが何であるかを知る必要があります。次に、BOM を使用して、マルチバイト シーケンスの最下位バイトまたは最上位バイトのどちらが最初であるかを判断できます。
BOM の幸いな副作用は、それがわからない場合にエンコーディングを推測するために使用できることですが、それは設計された目的ではなく、適切なエンコーディング情報を送信する代わりにはなりません。
それは明白です。 FF FEは UTF-16LE 用で、FF FE 00 00UTF-32LE を示します。FF FE 00 00UTF はテキスト用に設計されており、ユーザーはテキストに NUL 文字を使用してはならないため、おそらく UTF-16LE であると考える理由はありません。結局のところ、最後に 16 進エディターを開いてテキスト ドキュメントに数バイトの 00 を挿入したのはいつですか? ^_^
私はエドワードと同じ問題を経験しました。私はダスティンに同意します。通常、テキストファイルではヌル文字を使用しません。
ただし、すべてのユニコード文字を含むファイルを作成しました。最初に utf-32le エンコーディングを使用し、次に utf-32be エンコーディング、utf-16le および utf-16be エンコーディング、さらに utf-8 エンコーディングを使用しました。
ファイルを utf-8 に再エンコードしようとしたときに、結果を既存の utf-8 ファイルと比較したかったのです。私のファイルの BOM の後の最初の文字はヌル文字であるため、utf-16le BOM を含むファイルを正常に検出できませんでした。Edward が説明したとおりにバイトが表示されたため、utf-32le BOM として表示されました。BOM FFFE の後の最初の文字は 0000 ですが、BOM 検出で BOM FFFE0000 が検出されたため、utf-16le ではなく utf-32le が検出されたため、最初の 0000 文字が盗まれ、BOM の一部として取得されました。
したがって、utf-16 リトル エンディアンでエンコードされたファイルの最初の文字としてヌル文字を使用しないでください。これは、utf-16le と utf-32le の BOM があいまいになるためです。
私の問題を解決するために、最初の文字と 2 番目の文字を交換します。:-)