Спецификация Unicode для UTF-16LE против UTF32-LE

Question

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

FF FE 00 00 00 00 00 00

Как я могу определить, содержит ли этот файл:

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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