Unicode BOM per UTF-16 vs UTF-32-LE

Question

Sembra che ci sia un'ambiguità tra il Byte Order Marks utilizzato per UTF16-LE e UTF-32LE. In particolare, si consideri un file che contiene l'8 byte seguente:

FF FE 00 00 00 00 00 00

Come faccio a sapere se questo file contiene:

1. L'UTF16-LE BOM (FF FE) seguito da 3 caratteri nulli; o
2. L'UTF-32-LE BOM (FF FE 00 00) seguito da un carattere null?

Unicode distinte componenti sono descritti qui: http://unicode.org/faq/utf_bom.html # bom4 ma non c'è nessuna discussione di questa ambiguità. Mi sto perdendo qualcosa?

Answer 1

Come suggerisce il nome, la distinta dice solo il ordine dei byte , non è la codifica. Dovete sapere che cosa la codifica è prima, quindi è possibile utilizzare la distinta base per determinare se i byte meno o più significative sono di prima per le sequenze più byte.

Un fortunato effetto collaterale della distinta base è che si può anche a volte usarlo per indovinare la codifica se non lo sai, ma che non è quello che è stato progettato per e non è un sostituto per l'invio di una corretta informazione di codifica .

Answer 2

E 'inequivocabile. FF FE è per UTF-16, e FF FE 00 00 denota UTF-32LE. Non v'è alcun motivo di pensare che FF FE 00 00 è forse UTF-16, perché i UTFs sono stati progettati per il testo, e gli utenti non dovrebbe usare caratteri NUL nel loro testo. Dopo tutto, quando è stata l'ultima volta che è stato aperto un editor esadecimale e inserito un paio di byte di 00 in un documento di testo? ^ _ ^

Answer 3

ho sperimentato lo stesso problema come Edward. Sono d'accordo con Dustin, di solito non si userà nulli caratteri in file di testo.

Tuttavia ho creato un file che contiene tutti i caratteri Unicode. Ho prima utilizzata la codifica utf-32le, quindi una codifica utf-32be, un UTF-16 e una codifica UTF-16BE nonché una codifica utf-8.

Quando si cerca di ri-codificare i file in UTF-8, ho voluto confrontare il risultato al file utf-8 già esistenti. Perché il primo carattere nei miei file dopo il BOM è il nulla-personaggio, non ho potuto rilevare correttamente il file con UTF-16 BOM, si presentò come UTF-32le BOM, perché i byte apparivano esattamente come Edward ha descritto. Il primo carattere dopo la distinta FFFE è 0000, ma la rilevazione distinta base ha trovato una distinta FFFE0000 e così, rilevato utf-32le invece di UTF-16 per cui il mio primo 0000 caratteri è stato rubato e portato come parte della distinta base.

Quindi, non si dovrebbe mai usare un null-carattere come primo carattere di un file codificato con UTF-16 little endian, perché renderà l'UTF-16 e UTF-32le BOM ambiguo.

Per risolvere il mio problema, io scambiare il primo ed il secondo carattere. : -)