Unicode BOM para UTF-16LE vs UTF32-LE

Question

Parece que há uma ambiguidade entre as marcas de ordem de bytes usadas para UTF16-LE e UTF-32LE. Em particular, considere um arquivo que contém os 8 bytes a seguir:

FF FE 00 00 00 00 00 00

Como posso saber se este arquivo contém:

1. O Bom UTF16-LE (FF Fe) seguido por 3 caracteres nulos; ou
2. O UTF32-LE BOM (FF FE 00 00) seguido por um caractere nulo?

Os BOMs Unicode são descritos aqui: http://unicode.org/faq/utf_bom.html#bom4 Mas não há discussão sobre essa ambiguidade. Estou esquecendo de algo?

Answer 1

Como o nome sugere, o nascimento só diz o Ordem de byte, não a codificação. Você precisa saber qual é a codificação primeiro, então você pode usar o nascido para determinar se os bytes menos ou mais significativos são os primeiros para sequências multibytes.

Um efeito colateral afortunado da BOM é que você também pode usá-lo para adivinhar a codificação, se não souber, mas não é para isso que foi projetado e não substitui o envio de informações adequadas à codificação.

Answer 2

É inequívoco. FF FE é para UTF-16LE, e FF FE 00 00 indica UTF-32LE. Não há razão para pensar que FF FE 00 00 é possivelmente UTF-16LE porque os UTFs foram projetados para texto, e os usuários não devem estar usando caracteres nul em seu texto. Afinal, quando foi a última vez que você abriu um editor hexadecimente e inseriu alguns bytes de 00 em um documento de texto? ^_^

Answer 3

Eu experimentei o mesmo problema que Edward. Eu concordo com Dustin, geralmente não usa caracteres nulos em arquivos de texto.

No entanto, criei um arquivo que contém todos os caracteres Unicode. Primeiro, usei a codificação UTF-32LE, depois uma codificação UTF-32BE, um UTF-16LE e uma codificação UTF-16BE, bem como uma codificação UTF-8.

Ao tentar reencodificar os arquivos para o UTF-8, eu queria comparar o resultado com o arquivo UTF-8 já existente. Como o primeiro caractere nos meus arquivos após o BOM é o NULL-Character, não pude detectar com sucesso o arquivo com o UTF-16LE BOM, ele apareceu como Bom UTF-32LE, porque os bytes pareciam exatamente como Edward descreveu. O primeiro caractere após o BOM FFFE é 0000, mas a detecção da BOM encontrou um BOM FFFE0000 e, portanto, detectou o UTF-32LE em vez de UTF-16LE, pelo qual meu primeiro caractere 0000 foi roubado e tomado como parte do nascimento.

Portanto, nunca se deve usar um caractere nulo como o primeiro caractere de um arquivo codificado com o UTF-16 Little Endian, porque fará o UTF-16LE e o UTF-32LE Bom Ambígua.

Para resolver meu problema, trocarei o primeiro e o segundo personagem. :-)