Почему я должен использовать метку порядка байтов подписи Unicode?

Question

Они устарели? Они кажутся худшей идеей - внедрить в содержимое файла что-то, что никто не может увидеть, но влияет на функциональность файла. Я не понимаю, зачем мне это нужно.

Answer 1

В некоторых случаях они необходимы, да, потому что есть реализации с прямым порядком байтов и с прямым порядком байтов UTF-16.

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

Это то, что делает спецификация.

А тебе нужен? Только если вы 1) используете кодировку UTF, в которой проблема с порядком байтов является проблемой (это имеет значение для UTF-16, но UTF8 всегда выглядит одинаково независимо от порядка байтов), и , к которым будет предоставлен доступ к файлу внешние приложения.

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

Answer 2

Некоторые выдержки из UTF и BOM FAQ от Консорциума Unicode могут быть полезны.

В: Что такое спецификация?

A: Метка порядка байтов (BOM) состоит из кода символа U + FEFF в начале потока данных , где его можно использовать в качестве подписи, определяющей порядок байтов и форма кодирования, в основном из неотмеченных текстовых файлов. В некоторых протоколах более высокого уровня использование спецификации может быть обязательным (или запрещенным) в потоке данных Unicode, определенном в этом протоколе. (Выделение мое.)

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

В: Где полезна спецификация?

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

Итак, вам нужна спецификация, когда ваша программа способна обрабатывать несколько кодировок Unicode. Как еще ваша программа узнает, какую кодировку использовать при интерпретации ввода?

В: При использовании спецификации только в 16-битном тексте Unicode?

A: Нет, спецификацию можно использовать в качестве подписи независимо от того, как преобразуется текст Unicode: UTF-16, UTF-8, UTF-7 и т. Д. Точные байты, составляющие спецификацию будет любым символом Юникода U + FEFF, преобразованным в этот формат преобразования. В этой форме спецификация служит для указания того, что это файл Unicode и в каком формате он находится.

Вероятно, это тот случай, когда спецификация используется чаще всего сегодня. Он отличает текст в кодировке UTF-8 от любых других кодировок; на самом деле он не помечает порядок байтов, поскольку UTF-8 имеет только один порядок.

Если вы разрабатываете свой собственный протокол или формат данных, вам не нужно использовать спецификацию. Еще один вопрос из FAQ касается:

В: Как пометить данные, которые не интерпретируют U + FEFF как спецификацию?

A: Используйте тег UTF-16BE для обозначения текста UTF-16 с прямым порядком байтов и UTF-16LE для обозначения текста UTF-16 с прямым порядком байтов. Если вы используете спецификацию, отметьте текст как UTF-16.

В нем упоминается концепция тегирования формата ваших данных. Это означает указание формата вне диапазона из самих данных. Прекрасно, если такая возможность доступна для вас, но часто это не так, особенно когда старые системы переоборудуются под Unicode.

Answer 3

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

Однако UTF-8 не требует спецификации.

Ознакомьтесь с статьей Википедии .

Answer 4

«Спецификация» - это пережиток с первых дней существования Юникода, когда предполагалось, что использование Юникода будет означать использование 16-битных символов. Это совершенно бессмысленно в кодировке, подобной UTF-8, которая имеет только один порядок байтов. Выбор U + FEFF также неоптимален для UTF-32, потому что он не может различить все возможные порядки байтов среднего порядка (для этого потребуется спецификация, закодированная с 4 различными байтами).

Единственная причина, по которой вы используете одну, - это отправка данных UTF-16 или UTF-32 между платформами с разными порядками байтов, но (1) большинство людей все равно используют UTF-8 и (2) MIME charset Параметр обеспечивает лучший механизм.

Answer 5

Когда вы пометили это UTF-8, я скажу, что вам не нужна спецификация. Метки порядка байтов полезны только для UTF-16 и UTF-32, поскольку они информируют компьютер, находится ли файл в Big Endian или Little Endian . Некоторые текстовые редакторы могут использовать метку порядка байтов, чтобы решить, какую кодировку использует документ, но это не является частью стандарта Unicode.

Answer 6

Поскольку спецификации UTF16 и UTF32 сообщают, имеет ли содержимое формат Big-Endian или Little-Endian, а также то, что содержимое является Unicode, спецификация UTF-8 классифицирует файл как кодированный utf-8. Без спецификации UTF-8, как узнать, является ли это файл ANSI или файл в кодировке UTF-8? Конечно, спецификация UTF-8 не говорит о порядке байтов, потому что utf-8 - это всегда поток байтов, но он сообщает, является ли содержимое кодировкой UTF-8 Unicode или ANSI. Конечно, вы можете сканировать допустимые последовательности utf-8, но, на мой взгляд, проще проверить первые три байта файла.

Answer 7

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

Answer 8

UTF16 и UTF32 могут быть записаны как в формате Big-Endian, так и в формате Little-Endian. Вы можете попытаться эвристически определить порядок байтов, проанализировав результат обработки файла в любом порядке байтов, но чтобы избавить вас от всех этих проблем, спецификация может сообщить вам сразу.

UTF-8 на самом деле не нуждается в спецификации, так как вы декодируете ее побайтно.