Utf bom что такое

Utf bom что такое

Войти

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Что такое ВОМ и кодировка файлов UTF-8 без BOM

Многие владельцы сайтов, в частности работающих на блоговом движке WordPress, редактируют PHP-файлы в блокноте, который прилагается к ОС Windows.

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

Однако блокнот Windows при сохранении в кодировке UTF-8 добавляет в PHP-файлы невидимые символы, называемые BOM (кстати говоря, невидимые они именно в блокноте Винды), которые в результате приводят к тому, что либо на сайте отображается какая-то PHP-ошибка, либо “съезжает” дизайн.

После этого сохраните файл и загрузите его на свой сайт через FTP.

Если вы не знаете, какой из файлов сохранен в неправильной UTF-8 кодировке, то воспользуйтесь специальным скриптом, который найдет все файлы с BOM, которые необходимо пересохранить вышеописанным способом.

Все, на этом задачу с кодировкой можно считать решенной.

Понравилась статья. Простенько и со вкусом. Буду пользоваться и другим рекомендую.
Только не забывайте, что если вы уже видите крикозябли в виде черных квадратиков, нужно в начале выбрать пункт «Преобразовать в UTF-8 без ВОМ». Вот так:

Источник

В чем разница между UTF-8 и UTF-8 без спецификации?

Спецификация UTF-8 представляет собой последовательность байтов в начале текстового потока (EF BB BF), которая позволяет читателю более надежно угадывать файл как кодированный в UTF-8.

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

2.6 Схемы кодирования

Другие отличные ответы уже ответили, что:

Например, данные [EF BB BF 41 42 43] могут быть:

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

Кодировки должны быть известны, а не предсказаны.

Существует как минимум три проблемы с размещением спецификации в кодированных файлах UTF-8.

И, как уже упоминали другие, недостаточно или необходимо иметь спецификацию, чтобы обнаружить, что что-то является UTF-8:

Это старый вопрос с множеством хороших ответов, но нужно добавить одну вещь.

Все ответы очень общие. Я хотел бы добавить примеры использования спецификации, которые на самом деле вызывают реальные проблемы, но многие люди об этом не знают.

BOM ломает скрипты

Символы Shebang представлены теми же двумя байтами в расширенных кодировках ASCII, включая UTF-8, который обычно используется для сценариев и других текстовых файлов в современных Unix-подобных системах. Однако файлы UTF-8 могут начинаться с дополнительной метки порядка байтов (BOM); если функция «exec» определенно обнаруживает байты 0x23 и 0x21, то наличие спецификации (0xEF 0xBB 0xBF) до того, как Shebang предотвратит выполнение интерпретатора сценария. Некоторые власти рекомендуют не использовать метку порядка байтов в сценариях POSIX (Unix-like), [14] по этой причине и для более широкой функциональной совместимости и философских соображений. Кроме того, метка порядка байтов в UTF-8 не требуется, так как у этого кодирования нет проблем с порядком байтов; он служит только для идентификации кодировки как UTF-8. [выделение добавлено]

Спецификация запрещена в JSON

Реализации НЕ ДОЛЖНЫ добавлять метку порядка байтов в начало текста JSON.

Спецификация избыточна в JSON

Он не только незаконен в JSON, но и не нужен для определить кодировку символов, поскольку существуют более надежные способы однозначного определения как кодировки символов, так и порядка байтов, используемого в любом потоке JSON (подробности см. в этот ответ ).

BOM ломает парсеры JSON

Определяем кодировку и порядковый номер JSON, исследуя первые 4 байта для байта NUL:

Теперь, если файл начинается с спецификации, он будет выглядеть так:

Обратите внимание, что:

В зависимости от реализации все они могут быть неверно интерпретированы как UTF-8, а затем неверно истолкованы или отклонены как недействительные UTF-8, или не распознаны вообще.

Кроме того, если реализация проверяет действительный JSON, как я рекомендую, он отклонит даже ввод, который действительно закодирован как UTF-8, потому что он не начинается с символа ASCII

Чем отличаются UTF-8 и UTF-8 без спецификации?

Краткий ответ: в UTF-8 спецификация кодируется как байты EF BB BF в начале файла.

Первоначально предполагалось, что nicode будет кодироваться в UTF-16/UCS-2. Спецификация была разработана для этой формы кодирования. Когда у вас есть 2-байтовые единицы кода, необходимо указать, в каком порядке находятся эти два байта, и общее соглашение для этого заключается в том, чтобы включить символ U + FEFF в качестве «метки порядка байтов» в начале данных. Символ U + FFFE постоянно не назначен, поэтому его присутствие можно использовать для обнаружения неправильного порядка байтов.

UTF-8 имеет один и тот же порядок байтов независимо от порядкового номера платформы, поэтому знак порядка байтов не требуется. Однако это может произойти (как последовательность байтов EF BB FF ) в данных, которые были преобразованы в UTF-8 из UTF-16, или как «подпись», чтобы указать, что данные являются UTF-8.

Без. Как ответил Мартин Кот, стандарт Unicode не рекомендует его. Это вызывает проблемы с программным обеспечением, не поддерживающим спецификацию.

Если файл CSV сохранен без спецификации, Excel считает, что это ANSI, и выдает бессмысленный текст. После добавления «EF BB BF» спереди (например, путем повторного сохранения его с помощью Блокнота с UTF-8; или Блокнота ++ с UTF-8 с спецификацией) Excel открывает его в порядке.

В RFC 3629 рекомендуется добавлять символ спецификации к текстовым файлам Unicode: «UTF-8, формат преобразования ISO 10646», ноябрь 2003 г., http://tools.ietf.org/html/rfc3629 (эта последняя информация найдена по адресу: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

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

Вопрос: Чем отличаются UTF-8 и UTF-8 без спецификации? Что лучше?

О значении спецификации и UTF-8:

Аргумент для НЕ с использованием спецификации:

Аргумент ДЛЯ с использованием спецификации:

Аргумент в пользу использования спецификации заключается в том, что без нее требуется эвристический анализ, чтобы определить, какую кодировку символов использует файл. Исторически такой анализ, чтобы различать различные 8-битные кодировки, сложен, подвержен ошибкам, а иногда и медленен. Для облегчения этой задачи доступно несколько библиотек, таких как Mozilla Universal Charset Detector и Международные компоненты для Unicode.

Программисты ошибочно полагают, что обнаружение UTF-8 одинаково сложно (это не потому, что подавляющее большинство байтовых последовательностей являются недействительными UTF-8, тогда как кодировки, которые эти библиотеки пытаются различить, разрешают все возможные байтовые последовательности). Поэтому не все программы, поддерживающие Unicode, выполняют такой анализ и вместо этого полагаются на спецификацию.

На что лучше, С или БЕЗ спецификация:

IETF рекомендует, если в протоколе либо (a) всегда используется UTF-8, либо (b) есть какой-то другой способ указать, какая кодировка используется, тогда он «ДОЛЖЕН запретить использование U». + FEFF в качестве подписи. «

Мой вывод:

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

Источник

Utf bom что такое

Reg.ru: домены и хостинг

Крупнейший регистратор и хостинг-провайдер в России.

Более 2 миллионов доменных имен на обслуживании.

Продвижение, почта для домена, решения для бизнеса.

Более 700 тыс. клиентов по всему миру уже сделали свой выбор.

Бесплатный Курс «Практика HTML5 и CSS3»

Освойте бесплатно пошаговый видеокурс

по основам адаптивной верстки

на HTML5 и CSS3 с полного нуля.

Фреймворк Bootstrap: быстрая адаптивная вёрстка

Пошаговый видеокурс по основам адаптивной верстки в фреймворке Bootstrap.

Научитесь верстать просто, быстро и качественно, используя мощный и практичный инструмент.

Верстайте на заказ и получайте деньги.

Что нужно знать для создания PHP-сайтов?

Ответ здесь. Только самое важное и полезное для начинающего веб-разработчика.

Узнайте, как создавать качественные сайты на PHP всего за 2 часа и 27 минут!

Создайте свой сайт за 3 часа и 30 минут.

После просмотра данного видеокурса у Вас на компьютере будет готовый к использованию сайт, который Вы сделали сами.

Вам останется лишь наполнить его нужной информацией и изменить дизайн (по желанию).

Изучите основы HTML и CSS менее чем за 4 часа.

После просмотра данного видеокурса Вы перестанете с ужасом смотреть на HTML-код и будете понимать, как он работает.

Вы сможете создать свои первые HTML-страницы и придать им нужный вид с помощью CSS.

Бесплатный курс «Сайт на WordPress»

Хотите освоить CMS WordPress?

Получите уроки по дизайну и верстке сайта на WordPress.

Научитесь работать с темами и нарезать макет.

Бесплатный видеокурс по рисованию дизайна сайта, его верстке и установке на CMS WordPress!

Хотите изучить JavaScript, но не знаете, как подступиться?

После прохождения видеокурса Вы освоите базовые моменты работы с JavaScript.

Развеются мифы о сложности работы с этим языком, и Вы будете готовы изучать JavaScript на более серьезном уровне.

*Наведите курсор мыши для приостановки прокрутки.

Кодировки: полезная информация и краткая ретроспектива

Данную статью я решил написать как небольшой обзор, касающийся вопроса кодировок.

Мы разберемся, что такое вообще кодировка и немного коснемся истории того, как они появились в принципе.

Мы поговорим о некоторых их особенностях а также рассмотрим моменты, позволяющие нам работать с кодировками более осознанно и избегать появления на сайте так называемых кракозябров, т.е. нечитаемых символов.

Что такое кодировка?

Т.е. каждый символ, который мы вводим с клавиатуры, либо видим на экране монитора, закодирован определенной последовательностью битов (нулей и единиц). 8 бит, как вы, наверное, знаете, равны 1 байту информации, но об этом чуть позже.

Внешний вид самих символов определяется файлами шрифтов, которые установлены на вашем компьютере. Поэтому процесс вывода на экран текста можно описать как постоянное сопоставление последовательностей нулей и единиц каким-то конкретным символам, входящим в состав шрифта.

Прародителем всех современных кодировок можно считать ASCII.

Эта аббревиатура расшифровывается как American Standard Code for Information Interchange (американская стандартная кодировочная таблица для печатных символов и некоторых специальных кодов).

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

Позже она была расширена (изначально она не использовала все 8 бит), поэтому появилась возможность использовать уже не 128, а 256 (2 в 8 степени) различных символов, которые можно закодировать в одном байте информации.

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

Следующим шагом в развитии кодировок можно считать появление так называемых ANSI-кодировок.

По сути это были те же расширенные версии ASCII, однако из них были удалены различные псевдографические элементы и добавлены символы типографики, для которых ранее не хватало «свободных мест».

Примером такой ANSI-кодировки является всем известная Windows-1251. Помимо типографических символов, в эту кодировку также были включены буквы алфавитов языков, близких к русскому (украинский, белорусский, сербский, македонский и болгарский).

В контексте веб-разработки, мы можем столкнуться с кракозябрами, когда, к примеру, русский текст по ошибке сохраняется не в той кодировке, которая используется на сервере.

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

Одним словом, нужно было создать универсальную кодировку, которая решила бы проблему кракозябров раз и навсегда.

Юникод — универсальная кодировка текста (UTF-32, UTF-16 и UTF-8)

Сам стандарт был предложен в 1991 году некоммерческой организацией «Консорциум Юникода» (Unicode Consortium, Unicode Inc.), и первым результатом его работы стало создание кодировки UTF-32.

Кстати, сама аббревиатура UTF расшифровывается как Unicode Transformation Format (Формат Преобразования Юникод).

В этой кодировке для кодирования одного символа предполагалось использовать аж 32 бита, т.е. 4 байта информации. Если сравнивать это число с однобайтовыми кодировками, то мы придем к простому выводу: для кодирования 1 символа в этой универсальной кодировке нужно в 4 раза больше битов, что «утяжеляет» файл в 4 раза.

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

Как очевидно из названия, в этой кодировке один символ кодируют уже не 32 бита, а только 16 (т.е. 2 байта). Очевидно, это делает любой символ вдвое «легче», чем в UTF-32, однако и вдвое «тяжелее» любого символа, закодированного с помощью однобайтовой кодировки.

Количество символов, доступное для кодирования в UTF-16 равно, как минимум, 2 в 16 степени, т.е. 65536 символов. Вроде бы все неплохо, к тому же окончательная величина кодового пространства в UTF-16 была расширена до более, чем 1 миллиона символов.

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

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

Дело в том, что UTF-8 обеспечивает наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Для кодирования одного символа в UTF-8 реально используется от 1 до 4 байт (гипотетически можно и до 6 байт).

В UTF-8 все латинские символы кодируются 8 битами, как и в кодировке ASCII. Иными словами, базовая часть кодировки ASCII (128 символов) перешла в UTF-8, что позволяет «тратить» на их представление всего 1 байт, сохраняя при этом универсальность кодировки, ради которой все и затевалось.

Итак, если первые 128 символов кодируются 1 байтом, то все остальные символы кодируются уже 2 байтами и более. В частности, каждый символ кириллицы кодируется именно 2 байтами.

Таким образом, мы получили универсальную кодировку, позволяющую охватить все возможные символы, которые требуется отобразить, не «утяжеляя» без необходимости файлы.

Если вы работали с текстовыми редакторами (редакторами кода), например Notepad++, phpDesigner, rapid PHP и т.д., то, вероятно, обращали внимание на то, что при задании кодировки, в которой будет создана страница, можно выбрать, как правило, 3 варианта:

— ANSI
— UTF-8
— UTF-8 без BOM

Итак, что же такое BOM и почему нам это не нужно?

BOM расшифровывается как Byte Order Mark. Это специальный Unicode-символ, используемый для индикации порядка байтов текстового файла. По спецификации его использование не является обязательным, однако если BOM используется, то он должен быть установлен в начале текстового файла.

Не будем вдаваться в детали работы BOM. Для нас главный вывод следующий: использование этого служебного символа вместе с UTF-8 мешает программам считывать кодировку нормальным образом, в результате чего возникают ошибки в работе скриптов.

Поэтому, при работе с UTF-8 используйте именно вариант «UTF-8 без BOM». Также лучше не используйте редакторы, в которых в принципе нельзя указать кодировку (скажем, Блокнот из стандартных программ в Windows).

Кодировка текущего файла, открытого в редакторе кода, как правило, указывается в нижней части окна.

Обратите внимание, что запись «ANSI as UTF-8» в редакторе Notepad++ означает то же самое, что и «UTF-8 без BOM». Это одно и то же.

В программе phpDesigner нельзя сразу точно сказать, используется BOM, или нет. Для этого нужно кликнуть правой кнопкой мыши по надписи «UTF-8», после чего во всплывающем окне можно увидеть, используется ли BOM (опция Save with BOM).

В редакторе rapid PHP кодировка UTF-8 без BOM обозначается как «UTF-8*».

Как вы понимаете, в разных редакторах все выглядит немного по-разному, однако главную идею вы поняли.

После того, как документ сохранен в UTF-8 без BOM, нужно также убедиться, что верная кодировка указана в специальном метатэге в секции head вашего html-документа:

Соблюдение этих простых правил уже позволит вам избежать многих пробелем с кодировками.

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

Если вам интересна эта тема с более прикладной точки зрения, то рекомендую вам изучить мой видеоурок Полный UTF-8: чеклист для начинающих.

P.S. Присмотритесь к премиум-урокам по различным аспектам сайтостроения, а также к бесплатному курсу по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить различные технологии веб-разработки.

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!

Источник

UTF-8, UTF-16, UTF-32 & BOM

General questions, relating to UTF or Encoding Forms

UTF-8 FAQ

UTF-16 FAQ

UTF-32 FAQ

Byte Order Mark (BOM) FAQ

General questions, relating to UTF or Encoding Form

Q: Is Unicode a 16-bit encoding?

A: No. The first version of Unicode was a 16-bit encoding, from 1991 to 1995, but starting with Unicode 2.0 (July, 1996), it has not been a 16-bit encoding. The Unicode Standard encodes characters in the range U+0000..U+10FFFF, which amounts to a 21-bit code space. Depending on the encoding form you choose (UTF-8, UTF-16, or UTF-32), each character will then be represented either as a sequence of one to four 8-bit bytes, one or two 16-bit code units, or a single 32-bit code unit.

Q: Can Unicode text be represented in more than one way?

A: Yes, there are several possible representations of Unicode data, including UTF-8, UTF-16 and UTF-32. In addition, there are compression transformations such as the one described in the UTS #6: A Standard Compression Scheme for Unicode (SCSU).

A: A Unicode transformation format (UTF) is an algorithmic mapping from every Unicode code point (except surrogate code points) to a unique byte sequence. The ISO/IEC 10646 standard uses the term “UCS transformation format” for UTF; the two terms are merely synonyms for the same concept.

Each UTF is reversible, thus every UTF supports lossless round tripping: mapping from any Unicode coded character sequence S to a sequence of bytes and back will produce S again. To ensure round tripping, a UTF mapping must map all code points (except surrogate code points) to unique byte sequences. This includes reserved (unassigned) code points and the 66 noncharacters (including U+FFFE and U+FFFF).

The SCSU compression method, even though it is reversible, is not a UTF because the same string can map to very many different byte sequences, depending on the particular SCSU compressor. [AF]

Q: Where can I get more information on encoding forms?

A: For the formal definition of UTFs see Section 3.9, Unicode Encoding Forms in The Unicode Standard. For more information on encoding forms see UTR #17: Unicode Character Encoding Model. [AF]

Q: How do I write a UTF converter?

A: The freely available open source project International Components for Unicode (ICU) has UTF conversion built into it. The latest version may be downloaded from the ICU Project web site. [AF]

Q: Are there any byte sequences that are not generated by a UTF? How should I interpret them?

A: None of the UTFs can generate every arbitrary byte sequence. For example, in UTF-8 every byte of the form 110xxxxx₂ must be followed with a byte of the form 10xxxxxx₂. A sequence such as is illegal, and must never be generated. When faced with this illegal byte sequence while transforming or interpreting, a UTF-8 conformant process must treat the first byte 110xxxxx₂ as an illegal termination error: for example, either signaling an error, filtering the byte out, or representing the byte with a marker such as FFFD (REPLACEMENT CHARACTER). In the latter two cases, it will continue processing at the second byte 0xxxxxxx₂.

A conformant process must not interpret illegal or ill-formed byte sequences as characters, however, it may take error recovery actions. No conformant process may use irregular byte sequences to encode out-of-band information.

Q: Which of the UTFs do I need to support?

A: UTF-8 is most common on the web. UTF-16 is used by Java and Windows. UTF-8 and UTF-32 are used by Linux and various Unix systems. The conversions between all of them are algorithmically based, fast and lossless. This makes it easy to support data input or output in multiple formats, while using a particular UTF for internal storage or processing. [AF]

Q: What are some of the differences between the UTFs?

A: The following table summarizes some of the properties of each of the UTFs.

In the table indicates that the byte order is determined by a byte order mark, if present at the beginning of the data stream, otherwise it is big-endian. [AF]

Q: Why do some of the UTFs have a BE or LE in their label, such as UTF-16LE?

A: UTF-16 and UTF-32 use code units that are two and four bytes long respectively. For these UTFs, there are three sub-flavors: BE, LE and unmarked. The BE form uses big-endian byte serialization (most significant byte first), the LE form uses little-endian byte serialization (least significant byte first) and the unmarked form uses big-endian byte serialization by default, but may include a byte order mark at the beginning to indicate the actual byte serialization used. [AF]

Q: Is there a standard method to package a Unicode character so it fits an 8-Bit ASCII stream?

A: There are three or four options for making Unicode fit into an 8-bit format.

a) Use UTF-8. This preserves ASCII, but not Latin-1, because the characters >127 are different from Latin-1. UTF-8 uses the bytes in the ASCII only for ASCII characters. Therefore, it works well in any environment where ASCII characters have a significance as syntax characters, e.g. file name syntaxes, markup languages, etc., but where the all other characters may use arbitrary bytes.
Example: “Latin Small Letter s with Acute” (015B) would be encoded as two bytes: C5 9B.

b) Use Java or C style escapes, of the form \uXXXXX or \xXXXXX. This format is not standard for text files, but well defined in the framework of the languages in question, primarily for source files.
Example: The Polish word “wyjście” with character “Latin Small Letter s with Acute” (015B) in the middle (ś is one character) would look like: “wyj\u015Bcie».

c) Use the &#xXXXX; or &#DDDDD; numeric character escapes as in HTML or XML. Again, these are not standard for plain text files, but well defined within the framework of these markup languages.
Example: “wyjście” would look like “ wyjście «

d) Use SCSU. This format compresses Unicode into 8-bit format, preserving most of ASCII, but using some of the control codes as commands for the decoder. However, while ASCII text will look like ASCII text after being encoded in SCSU, other characters may occasionally be encoded with the same byte values, making SCSU unsuitable for 8-bit channels that blindly interpret any of the bytes as ASCII characters.
Example: “ wyjÛcie” where indicates the byte 0x12 and “Û” corresponds to byte 0xDB. [AF]

Q: Which of these approaches is the best?

A: That depends on the circumstances: Of these four approaches, d) uses the least space, but cannot be used transparently in most 8-bit environments. a) is the most widely supported in plain text files and b) and c) use the most space, but are widely supported for program source files in Java and C, or within HTML and XML files respectively. [AF]

Q: Which of these formats is the most standard?

A: All four require that the receiver can understand that format, but a) is considered one of the three equivalent Unicode Encoding Forms and therefore standard. The use of b), or c) out of their given context would definitely be considered non-standard, but could be a good solution for internal data transmission. The use of SCSU is itself a standard (for compressed data streams) but few general purpose receivers support SCSU, so it is again most useful in internal data transmission. [AF]

UTF-8 FAQ

Q: What is the definition of UTF-8?

A: UTF-8 is the byte-oriented encoding form of Unicode. For details of its definition, see Section 2.5, Encoding Forms and Section 3.9, Unicode Encoding Forms ” in The Unicode Standard. See, in particular, Table 3-6 UTF-8 Bit Distribution and Table 3-7 Well-formed UTF-8 Byte Sequences, which give succinct summaries of the encoding form. Make sure you refer to the latest version of the Unicode Standard, as the Unicode Technical Committee has tightened the definition of UTF-8 over time to more strictly enforce unique sequences and to prohibit encoding of certain invalid characters. There is an Internet RFC 3629 about UTF-8. UTF-8 is also defined in Annex D of ISO/IEC 10646. See also the question above, How do I write a UTF converter?

Q: Is the UTF-8 encoding scheme the same irrespective of whether the underlying processor is little endian or big endian?

A: Yes. Since UTF-8 is interpreted as a sequence of bytes, there is no endian problem as there is for encoding forms that use 16-bit or 32-bit code units. Where a BOM is used with UTF-8, it is only used as an encoding signature to distinguish UTF-8 from other encodings — it has nothing to do with byte order. [AF]

Q: Is the UTF-8 encoding scheme the same irrespective of whether the underlying system uses ASCII or EBCDIC encoding?

A: There is only one definition of UTF-8. It is precisely the same, whether the data were converted from ASCII or EBCDIC based character sets. However, byte sequences from standard UTF-8 won’t interoperate well in an EBCDIC system, because of the different arrangements of control codes between ASCII and EBCDIC. UTR #16: UTF-EBCDIC defines is a specialized UTF that will interoperate in EBCDIC systems. [AF]

Q: How do I convert a UTF-16 surrogate pair such as to UTF-8? As one 4-byte sequence or as two separate 3-byte sequences?

A: The definition of UTF-8 requires that supplementary characters (those using surrogate pairs in UTF-16) be encoded with a single 4-byte sequence. However, there is a widespread practice of generating pairs of 3-byte sequences in older software, especially software which pre-dates the introduction of UTF-16 or that is interoperating with UTF-16 environments under particular constraints. Such an encoding is not conformant to UTF-8 as defined. See UTR #26: Compatability Encoding Scheme for UTF-16: 8-bit (CESU) for a formal description of such a non-UTF-8 data format. When using CESU-8, great care must be taken that data is not accidentally treated as if it was UTF-8, due to the similarity of the formats. [AF]

Q: How do I convert an unpaired UTF-16 surrogate to UTF-8?

A different issue arises if an unpaired surrogate is encountered when converting ill-formed UTF-16 data. By representing such an unpaired surrogate on its own as a 3-byte sequence, the resulting UTF-8 data stream would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires that encoding form conversion always results in a valid data stream. Therefore a converter must treat this as an error. [AF]

UTF-16 FAQ

A: UTF-16 uses a single 16-bit code unit to encode the most common 63K characters, and a pair of 16-bit code units, called surrogates, to encode the 1M less commonly used characters in Unicode.

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16. [AF]

Q: What are surrogates?

A: Surrogates are code points from two special ranges of Unicode values, reserved for use as the leading, and trailing values of paired code units in UTF-16. Leading, also called high, surrogates are from D800₁₆ to DBFF₁₆, and trailing, or low, surrogates are from DC00₁₆ to DFFF₁₆. They are called surrogates, since they do not represent characters directly, but only as a pair.

Q: What’s the algorithm to convert from UTF-16 to character codes?

A: The Unicode Standard used to contain a short algorithm, now there is just a bit distribution table. Here are three short code snippets that translate the information from the bit distribution table into C code that will convert to and from UTF-16.

Using the following type definitions

the first snippet calculates the high (or leading) surrogate from a character code C.

where X, U and W correspond to the labels used in Table 3-5 UTF-16 Bit Distribution. The next snippet does the same for the low surrogate.

Finally, the reverse, where hi and lo are the high and low surrogate, and C the resulting character

A caller would need to ensure that C, hi, and lo are in the appropriate ranges. [AF]

Q: Isn’t there a simpler way to do this?

A: There is a much simpler computation that does not try to follow the bit distribution table.

Q: Why are some people opposed to UTF-16?

A: People familiar with variable width East Asian character sets such as Shift-JIS ( SJIS) are understandably nervous about UTF-16, which sometimes requires two code units to represent a single character. They are well acquainted with the problems that variable-width codes have caused. However, there are some important differences between the mechanisms used in SJIS and UTF-16:

In SJIS, there is overlap between the leading and trailing code unit values, and between the trailing and single code unit values. This causes a number of problems:

It causes false matches. For example, searching for an “a” may match against the trailing code unit of a Japanese character.

It prevents efficient random access. To know whether you are on a character boundary, you have to search backwards to find a known boundary.

It makes the text extremely fragile. If a unit is dropped from a leading-trailing code unit pair, many following characters can be corrupted.

In UTF-16, the code point ranges for high and low surrogates, as well as for single units are all completely disjoint. None of these problems occur:

There are no false matches.

The location of the character boundary can be directly determined from each code unit value.

A dropped surrogate will corrupt only a single character.

The vast majority of SJIS characters require 2 units, but characters using single units occur commonly and often have special importance, for example in file names.

With UTF-16, relatively few characters require 2 units. The vast majority of characters in common use are single code units. Even in East Asian text, the incidence of surrogate pairs should be well less than 1% of all text storage on average. (Certain documents, of course, may have a higher incidence of surrogate pairs, just as phthisique is an fairly infrequent word in English, but may occur quite often in a particular scholarly text.) [AF]

Q: Will UTF-16 ever be extended to more than a million characters?

A: No. Both Unicode and ISO 10646 have policies in place that formally limit future code assignment to the integer range that can be expressed with current UTF-16 (0 to 1,114,111). Even if other encoding forms (i.e. other UTFs) can represent larger integers, these policies mean that all encoding forms will always represent the same set of characters. Over a million possible codes is far more than enough for the goal of Unicode of encoding characters, not glyphs. Unicode is not designed to encode arbitrary data. If you wanted, for example, to give each “instance of a character on paper throughout history” its own code, you might need trillions or quadrillions of such codes; noble as this effort might be, you would not use Unicode for such an encoding. [AF]

Q: Are there any 16-bit values that are invalid?

A: Unpaired surrogates are invalid in UTFs. These include any value in the range D800₁₆ to DBFF₁₆ not followed by a value in the range DC00₁₆ to DFFF₁₆, or any value in the range DC00₁₆ to DFFF₁₆ not preceded by a value in the range D800₁₆ to DBFF₁₆. [AF]

Q: What about noncharacters? Are they invalid?

A: Not at all. Noncharacters are valid in UTFs and must be properly converted. For more details on the definition and use of noncharacters, as well as their correct representation in each UTF, see the Noncharacters FAQ.

Q: Because most supplementary characters are uncommon, does that mean I can ignore them?

A: Most supplementary characters (expressed with surrogate pairs in UTF-16) are not too common. However, that does not mean that supplementary characters should be neglected. Among them are a number of individual characters that are very popular, as well as many sets important to East Asian procurement specifications. Among the notable supplementary characters are:

many popular emoji and emoticons

symbols used for interoperating with Wingdings and Webdings

numerous small sets of CJK characters important for procurement, including personal and place names

variation selectors used for all ideographic variation sequences

numerous minority scripts important for some user communities

some highly salient historic scripts, such as Egyptian hieroglyphics

Ken Lunde has an interesting presentation file on this topic, with a Top Ten list: Why Support Beyond-BMP Code Points?

Q: How should I handle supplementary characters in my code?

A: Compared with BMP characters as a whole, the supplementary characters occur less commonly in text. This remains true now, even though many thousands of supplementary characters have been added to the standard, and a few individual characters, such as popular emoji, have become quite common. The relative frequency of BMP characters, and of the ASCII subset within the BMP, can be taken into account when optimizing implementations for best performance: execution speed, memory usage, and data storage.

Such strategies are particularly useful for UTF-16 implementations, where BMP characters require one 16-bit code unit to process or store, whereas supplementary characters require two.

Strategies that optimize for the BMP are less useful for UTF-8 implementations, but if the distribution of data warrants it, an optimization for the ASCII subset may make sense, as that subset only requires a single byte for processing and storage in UTF-8.

Q: What is the difference between UCS-2 and UTF-16?

A: UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1, before surrogate code points and UTF-16 were added to Version 2.0 of the standard. This term should now be avoided.

UCS-2 does not describe a data format distinct from UTF-16, because both use exactly the same 16-bit code unit representations. However, UCS-2 does not interpret surrogate code points, and thus cannot be used to conformantly represent supplementary characters.

Sometimes in the past an implementation has been labeled «UCS-2» to indicate that it does not support supplementary characters and doesn’t interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters. [AF]

UTF-32 FAQ

A: Any Unicode character can be represented as a single 32-bit unit in UTF-32. This single 4 code unit corresponds to the Unicode scalar value, which is the abstract number associated with a Unicode character. UTF-32 is a subset of the encoding mechanism called UCS-4 in ISO 10646. For more information, see Section 3.9, Unicode Encoding Forms in The Unicode Standard. [AF]

Q: Should I use UTF-32 (or UCS-4) for storing Unicode strings in memory?

A: This depends. If you frequently need to access APIs that require string parameters to be in UTF-32, it may be more convenient to work with UTF-32 strings all the time. However, the downside of UTF-32 is that it forces you to use 32-bits for each character, when only 21 bits are ever needed. The number of significant bits needed for the average character in common texts is much lower, making the ratio effectively that much worse. In many situations that does not matter, and the convenience of having a fixed number of code units per character can be the deciding factor.

Increasing the storage for the same number of characters does have its cost in applications dealing with large volume of text data: it can mean exhausting cache limits sooner; it can result in noticeably increased read/write times or in reaching bandwidth limits; and it requires more space for storage. What a number of implementations do is to represent strings with UTF-16, but individual character values with UTF-32.

The chief selling point for Unicode is providing a representation for all the world’s characters, eliminating the need for juggling multiple character sets and avoiding the associated data corruption problems. These features were enough to swing industry to the side of using Unicode (UTF-16). While a UTF-32 representation does make the programming model somewhat simpler, the increased average storage size has real drawbacks, making a complete transition to UTF-32 less compelling. [AF]

Q: How about using UTF-32 interfaces in my APIs?

A: Except in some environments that store text as UTF-32 in memory, most Unicode APIs are using UTF-16. With UTF-16 APIs the low level indexing is at the storage or code unit level, with higher-level mechanisms for graphemes or words specifying their boundaries in terms of the code units. This provides efficiency at the low levels, and the required functionality at the high levels.

If its ever necessary to locate the n th character, indexing by character can be implemented as a high level operation. However, while converting from such a UTF-16 code unit index to a character index or vice versa is fairly straightforward, it does involve a scan through the 16-bit units up to the index point. In a test run, for example, accessing UTF-16 storage as characters, instead of code units resulted in a 10× degradation. While there are some interesting optimizations that can be performed, it will always be slower on average. Therefore locating other boundaries, such as grapheme, word, line or sentence boundaries proceeds directly from the code unit index, not indirectly via an intermediate character code index.

Q: Doesn’t it cause a problem to have only UTF-16 string APIs, instead of UTF-32 char APIs?

A: Almost all international functions (upper-, lower-, titlecasing, case folding, drawing, measuring, collation, transliteration, grapheme-, word-, linebreaks, etc.) should take string parameters in the API, not single code-points (UTF-32). Single code-point APIs almost always produce the wrong results except for very simple languages, either because you need more context to get the right answer, or because you need to generate a sequence of characters to return the right answer, or both.

Storing a single code point in a struct or class instead of a string, would exclude support for graphemes, such as “ch” for Slovak, where a single code point may not be sufficient, but a character sequence is needed to express what is required. In other words, most API parameters and fields of composite data types should not be defined as a character, but as a string. And if they are strings, it does not matter what the internal representation of the string is.

Given that any industrial-strength text and internationalization support API has to be able to handle sequences of characters, it makes little difference whether the string is internally represented by a sequence of UTF-16 code units, or by a sequence of code-points ( = UTF-32 code units). Both UTF-16 and UTF-8 are designed to make working with substrings easy, by the fact that the sequence of code units for a given code point is unique. [AF]

Q: Are there exceptions to the rule of exclusively using string parameters in APIs?

A: The main exception are very low-level operations such as getting character properties (e.g. General Category or Canonical Class in the UCD). For those it is handy to have interfaces that convert quickly to and from UTF-16 and UTF-32, and that allow you to iterate through strings returning UTF-32 values (even though the internal format is UTF-16).

Q: How do I convert a UTF-16 surrogate pair such as to UTF-32? As one 4-byte sequence or as two 4-byte sequences?

A: The definition of UTF-32 requires that supplementary characters (those using surrogate pairs in UTF-16) be encoded with a single 4-byte sequence.

Q: How do I convert an unpaired UTF-16 surrogate to UTF-32?

A: If an unpaired surrogate is encountered when converting ill-formed UTF-16 data, any conformant converter must treat this as an error. By representing such an unpaired surrogate on its own, the resulting UTF-32 data stream would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires that encoding form conversion always results in valid data stream. [AF]

Byte Order Mark (BOM) FAQ

A: A byte order mark (BOM) consists of the character code U+FEFF at the beginning of a data stream, where it can be used as a signature defining the byte order and encoding form, primarily of unmarked plaintext files. Under some higher level protocols, use of a BOM may be mandatory (or prohibited) in the Unicode data stream defined in that protocol. [AF]

Q: Where is a BOM useful?

A: A BOM is useful at the beginning of files that are typed as text, but for which it is not known whether they are in big or little endian format—it can also serve as a hint indicating that the file is in Unicode, as opposed to in a legacy encoding and furthermore, it act as a signature for the specific encoding form used. [AF]

Q: What does ‘endian’ mean?

A: Data types longer than a byte can be stored in computer memory with the most significant byte (MSB) first or last. The former is called big-endian, the latter little-endian. When data is exchanged, bytes that appear in the «correct» order on the sending system may appear to be out of order on the receiving system. In that situation, a BOM would look like 0xFFFE which is a noncharacter, allowing the receiving system to apply byte reversal before processing the data. UTF-8 is byte oriented and therefore does not have that issue. Nevertheless, an initial BOM might be useful to identify the datastream as UTF-8. [AF]

Q: When a BOM is used, is it only in 16-bit Unicode text?

A: No, a BOM can be used as a signature no matter how the Unicode text is transformed: UTF-16, UTF-8, or UTF-32. The exact bytes comprising the BOM will be whatever the Unicode character U+FEFF is converted into by that transformation format. In that form, the BOM serves to indicate both that it is a Unicode file, and which of the formats it is in. Examples:

Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?

A: Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is only used as a signature — an indication that an otherwise unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently in 8-bit environments, the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning, such as the use of «#!» of at the beginning of Unix shell scripts. [AF]

Q: What should I do with U+FEFF in the middle of a file?

A: In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF should normally not occur. For backwards compatibility it should be treated as ZERO WIDTH NON-BREAKING SPACE (ZWNBSP), and is then part of the content of the file or string. The use of U+2060 WORD JOINER is strongly preferred over ZWNBSP for expressing word joining semantics since it cannot be confused with a BOM. When designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In that case, any U+FEFF occurring in the middle of a file can be treated as an unsupported character. [AF]

Q: I am using a protocol that has BOM at the start of text. How do I represent an initial ZWNBSP?

A: Use U+2060 WORD JOINER instead.

Q: How do I tag data that does not interpret U+FEFF as a BOM?

A: Use the tag UTF-16BE to indicate big-endian UTF-16 text, and UTF-16LE to indicate little-endian UTF-16 text. If you do use a BOM, tag the text as simply UTF-16. [MD]

Q: Why wouldn’t I always use a protocol that requires a BOM?

A: Where the data has an associated type, such as a field in a database, a BOM is unnecessary. In particular, if a text data stream is marked as UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary nor permitted. Any U+FEFF would be interpreted as a ZWNBSP.

Do not tag every string in a database or set of fields with a BOM, since it wastes space and complicates string concatenation. Moreover, it also means two data fields may have precisely the same content, but not be binary-equal (where one is prefaced by a BOM).

Q: How I should deal with BOMs?

A: Here are some guidelines to follow:

Some protocols allow optional BOMs in the case of untagged text. In those cases,

Where a text data stream is known to be plain text, but of unknown encoding, BOM can be used as a signature. If there is no BOM, the encoding could be anything.

Where a text data stream is known to be plain Unicode text (but not which endian), then BOM can be used as a signature. If there is no BOM, the text should be interpreted as big-endian.

Some byte oriented protocols expect ASCII characters at the beginning of a file. If UTF-8 is used with these protocols, use of the BOM as encoding form signature should be avoided.

Источник