Unicode BOM для UTF-16LE против UTF32-LE - PullRequest
Новая
       82

Unicode BOM для UTF-16LE против UTF32-LE

8 голосов
/ 18 декабря 2009

Кажется, что существует некоторая неопределенность между метками порядка байтов, используемыми для UTF16-LE и UTF-32LE. В частности, рассмотрим файл, который содержит следующие 8 байтов: 

FF FE 00 00 00 00 00 00

Как узнать, содержит ли этот файл:

  1. Спецификация UTF16-LE (FF FE), за которой следуют 3 нулевых символа; или
  2. Спецификация UTF32-LE (FF FE 00 00), за которой следует один нулевой символ?

Спецификации Unicode описаны здесь: http://unicode.org/faq/utf_bom.html#bom4, но здесь нет обсуждения этой двусмысленности. Я что-то упустил?

Ответы [ 3 ]

11 голосов
/ 18 декабря 2009

Как следует из названия, спецификация указывает только порядок байтов , а не кодировку.Сначала вы должны знать, что такое кодировка, а затем использовать спецификацию, чтобы определить, являются ли младшие или наиболее значимые байты первыми для многобайтовых последовательностей.

Удачным побочным эффектом спецификации является то, чтоиногда используйте ее, чтобы угадать кодировку, если вы ее не знаете, но это не то, для чего она была разработана, и она не заменит отправку правильной информации о кодировке.

9 голосов
/ 18 декабря 2009

Это однозначно. FF FE для UTF-16LE, а FF FE 00 00 обозначает UTF-32LE. Нет оснований полагать, что FF FE 00 00, возможно, является UTF-16LE, потому что UTF были разработаны для текста, и пользователи не должны использовать символы NUL в своем тексте. В конце концов, когда вы в последний раз открывали шестнадцатеричный редактор и вставляли несколько байтов 00 в текстовый документ? ^ _ ^

1 голос
/ 25 июля 2012

Я столкнулся с той же проблемой, что и Эдвард. Я согласен с Дастином, обычно в текстовых файлах нельзя использовать нулевые символы.

Однако я создал файл, который содержит все символы Юникода. Сначала я использовал кодировку utf-32le, затем кодировку utf-32be, кодировку utf-16le и utf-16be, а также кодировку utf-8.

При попытке перекодировать файлы в utf-8, я хотел сравнить результат с уже существующим файлом utf-8. Поскольку первый символ в моих файлах после BOM - это нулевой символ, я не смог успешно определить файл с помощью utf-16le BOM, он обнаружился как utf-32le BOM, потому что байты выглядели точно так, как описал Эдвард. Первый символ после FOM FOME - 0000, но обнаружение BOM обнаружило BOM FFFE0000 и, таким образом, обнаружило utf-32le вместо utf-16le, в результате чего мой первый 0000-символ был украден и взят как часть спецификации.

Таким образом, никогда не следует использовать нулевой символ в качестве первого символа файла, закодированного с прямым порядком байтов utf-16, потому что это сделает спецификации UTF-16le и utf-32le неоднозначными.

Чтобы решить мою проблему, я поменяю местами первый и второй символ. : -)

...