utf 8 алгоритм кодирования

Utf 8 алгоритм кодирования

В отличие от UTF-16, UTF-8 является самосинхронизирующейся кодировкой (англ.): при потере одного байта последующие байты будут раскодированы корректно.

Проще говоря, в формате UTF-8 символы латинского алфавита, знаки препинания и управляющие символы ASCII записываются кодами US-ASCII, a все остальные символы кодируются при помощи нескольких байтов со старшим битом 1. Это приводит к двум эффектам.

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

Однако это сводится на нет необходимостью поддержки суррогатных пар, о которых часто забывают при использовании UTF-16, реализуя лишь поддержку символов UCS-2. [2]

Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9. [4] Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D.

Содержание

Принцип кодирования

Текстовое описание

В UTF-8 можно кодировать значения кодов символов от 0 до 7FFFFFFF₁₆ включительно (все комбинации 32-битных без установленного старшего бита).

Каждый символ кодируется переменным количеством последовательных 8-битных байт (октетов). Количество же может варьироваться от 1 до 6 байт включительно и определяется самым первым байтом.

Все ASCII-символы (от 0 до 127 (00000000₂ — 01111111₂ или 00₁₆ — 7F₁₆) включительно) записываются как есть одним байтом со сброшенным старшим битом.

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

У байт не ASCII-символов старший бит всегда установлен в 1. При этом второй с конца бит всегда сброшен у не первых байт (у первых, соответственно, установлен). Поэтому если чтение производится с произвольного байта, то по второму биту можно определять промежуточные байты.

И у не первых байт остальные 6 младших бит содержат фрагмент кода символа (об этом ниже).

Количество байт, которое отводится под символ, всегда равно количеству идущих подряд старших бит со значением 1 в первом байте. Эти биты всегда завершаются битом со значением 0. Оставшиеся младшие биты первого байта составляют код символа. Отсюда обуславливается ограничение в 6 байт на символ — если выше, то в первом байте уже не хватит места под биты данных. Поэтому последовательности бит 11111110₂ (FE₁₆) и 11111111₂ (FF₁₆) общепринято считаются не используемыми в UTF-8.

До этого описывалась структура, а теперь про расположение данных.

Как видно из описания выше, каждый байт имеет определённое количество младших бит под данные — переменное у первого и по 6 в последующих. 32-битный код символа последовательно размещается в этих контейнерах. Старшие биты оказываются в первых байтах, а младшие — в последних. Поэтому младшие 6 бит последнего байта всегда содержат биты 0..5 кода символа. Аналогично, предпоследний байт содержат биты 6..11, третий с конца — 12..17, четвёртый — 18..23, пятый — 24..29. Первый байт же содержит оставшиеся старшие биты значения.

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

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

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

Кодировка UTF-8 не является однозначной, так как в ней учитывается размер бит значения без учёта позиции последнего установленного бита. Поэтому возможно написание «грубого» кодировщика, который не отбрасывает лидирующие нули. Например, ASCII-символ «1» (код 00110001₂ (31₁₆)), может быть представлен следующими двухбайтовыми и трёхбайтовыми последовательностями: 11000000₂ 10110001₂ (C0₁₆ B1₁₆) и 11100000₂ 10000000₂ 10110001₂ (E0₁₆ 80₁₆ B1₁₆). Отсюда выходят следующие бессмыленные битовые комбинации первых байт: 11000000₂ (C0₁₆), 11100000₂ (E0₁₆), 11110000₂ (F0₁₆), 11111000₂ (F8₁₆), 11111100₂ (FC₁₆), а также последующие за ними комбинации промежуточных байт 10000000₂ (80₁₆).

Графическое представление

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

Максимальный потенциал

До этого рассматривалось кодирование в UTF-8 лишь 32-битных целых без отрицательных значений. Следует отметить, что в стандарте Unicode используются символы лишь до кода 001FFFFF₁₆ включительно. Поэтому даже 32-битных значений может вполне хватить, но этот раздел был включён для полноты изложения в случае использования UTF-8 для кодирования несимвольных данных.

В первом байте количество установленных старших бит определяет количество байт на символ. Оставшиеся младшие биты хранят старшие биты значения кода символа. Мы можем сделать допущение о том, что первый байт не обязан содержать данные. При этом допускаем, что все биты за пределами байта равны нулю. Тогда данные будут содержать только 6 бит в последующих байтах. Получается 36 бит для семибайтового символа и 42 бита — для восьмибайтового.

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

BOM (сигнатура)

Многие программы Windows (включая Блокнот) добавляют байты EF₁₆, BB₁₆, BF₁₆ в начале любого документа, сохраняемого как UTF-8. Это метка порядка байтов (англ. Byte Order Mark, BOM), также её часто называют сигнатурой (соответственно, UTF-8 и UTF-8 with Signature). По наличию сигнатуры программы могут автоматически определить, является ли файл закодированным в UTF-8, однако файлы с такой сигнатурой могут некорректно обрабатываться старыми программами, в частности xml-анализаторами. Такие редакторы, как Notepad++, Notepad2 и Kate, позволяют явно указывать, следует ли добавлять сигнатуру при сохранении UTF-файлов.

Например: В файле записана одна латинская буква «a».

Если считывающая программа не поддерживает BOM, то эти три байта успешно раскодируются в один Unicode-символ FEFF₁₆. Это не разрывающий слова пробел нулевой ширины и поэтому он может не отобразиться. Этот же символ используется в BOM для кодировок UTF-16 и UTF-32.

Источник

Практическое руководство по Unicode’изации

Мы, наконец, это сделали! Долгое время позорное наследие CP1251 раздражало разработчиков, наводило на мысли о том, что, как же так? Эпоха Unicode уже давно наступила, а мы все еще используем однобайтовую кодировку и расставляем в разных местах костыли для совместимости с внешними системами. Но причина тому была достаточно рациональная: перевести на Unicode большой проект, в который развился Мой Мир, очень трудоемко. Мы оценивали это в полгода и не были готовы тратить столько ресурсов на фичу, которая не принесет русскоязычной аудитории существенной пользы.

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

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

Перекодирование баз данных

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

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

MySQL

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

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

Во-вторых, выяснилось, что выполнить для всех таблиц alter table `my_table` convert to character set utf8; не рационально и, более того, невозможно. Не рационально потому, что индекс для UTF-8-поля всегда занимает 3 * length_in_characters байт, даже если поле содержит только ASCII-символы. А таких полей у нас оказалось немало, в том числе индексных, особенно таких, которые содержали hex-строки. Невозможно по причине того, что максимальная длина ключа индекса в MySQL 767 байт, и индексы (особенно многоколоночные) перестают помещаться. Помимо этого обнаружилось, что в текстовых полях кое-где по недосмотру хранятся бинарные данные и наоборот, и надо внимательно проверять каждое поле.

После того, как мы собрали с наших баз данных информацию об имеющихся там таблицах, появилось понимание, что львиная доля их, скорее всего, не используется. Так оно в результате и оказалось, мы удалили из баз примерно половину всех имевшихся в них таблиц. Для того чтобы найти неиспользуемые таблицы мы применили следующую технику: при помощи tcpdump собрали все запросы к нашим базам за сутки, затем пересекли список таблиц из этого дампа с текущей схемой баз и на всякий случай поискали неиспользуемые таблицы по коду (заодно подчистили код). Tcpdump применили потому, что он, в отличие от записи всех запросов в лог средствами MySQL, не требует перезапуска базы и не оказывает влияния на скорость обработки запросов. Разумеется, сразу удалять таблицы было страшно, поэтому сначала просто переименовали таблицы со специальным суффиксом, выждали несколько недель и потом удалили (кстати, не зря перестраховались, парочку лишних малоиспользуемых зацепили по недосмотру, пришлось вернуть).

C и UTF-8

В нашем коде на C, к счастью, оказалось не так много строк, как в перле, поэтому пошли по классическому пути: вынесли все кириллические строки в отдельный файл. Это позволило ограничить потенциальные конфликты при мерджах в рамках одного файла, а также упростило последующую локализацию. В процессе конвертации репо в UTF-8 обнаружили забавное — русскоязычные комментарии в коде были во всех 4 кириллических кодировках: cp1251, cp866, koi8-r и iso8859-5. Пришлось при конвертации использовать автоопределение кодировки каждой конкретной строки.

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

Шаблоны, javascript и UTF-8

С шаблонами, к счастью, все оказалось достаточно просто. На production они раскладываются rpm-пакетами, поэтому логичным решением было впилить перекодирование в процесс сборки rpm. Мы добавили еще один пакет с шаблонами в UTF-8, которые устанавливались в соседнюю директорию, а код (и перловый и сишный) после этого просто выбирал шаблон из соответствующей директории.

С javascript же из коробки не получилось. Большинство браузеров при загрузке javascript учитывают его Content-Type, но все же есть отдельные старые экземпляры, которые этого не делают, а ориентируются на кодировку страницы. Поэтому поставили костыль: при сборке пакета с javascript мы заменяли все не-ASCII-символы на их escape-последовательности в виде номеров code point’ов. При таком подходе размер js увеличивается, но зато любой браузер загружает его корректно.

Что в итоге

В итоге, по прошествии шести месяцев пасьянс сошелся. Админы как раз закончили перекодировать пару сотен баз, разработчики допилили код, процесс тестирования тоже завершился. Мы постепенно переключили ручки на панели управления Миром: сначала в UTF-8 перевели все аккаунты наших коллег, затем одного процента пользователей, после чего стали по 10 серверов переключать backend-сервера и, в конце, frontend’ы. Визуально ничего не менялось, ни страницы проекта, ни графики нагрузки, что не могла не радовать. Единственное внешние изменение, по которому было понятно, что полгода прошли недаром, — это изменение в Content-Type строчки charset=windows-1251 на charset=UTF-8.

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

Источник

Использование UTF-8 в HTTP заголовках

Как известно, HTTP 1.1 — это текстовой протокол передачи данных. HTTP сообщения закодированы, используя ISO-8859-1 (которую условно можно считать расширенной версией ASCII, содержащей умляуты, диакритику и другие символы, используемые в западноевропейских языках). При этом в теле сообщений можно использовать другую кодировку, которая должна быть обозначена в заголовке «Content-Type». Но что делать, если нам необходимо задать non-ASCII символы не в теле сообщения, а в самих заголовках? Наверное, самый распространенный кейс — это проставление имени файла в «Content-Disposition» заголовке. Это, казалось бы, довольно распространенная задача, но ее реализация не так очевидна.

TL;DR: Используйте кодировку, описанную в RFC 6266, для «Content-Disposition» и преобразуйте текст в латиницу (транслит) в остальных случаях.

Небольшая вводная в кодировки

В статье упоминаются и используются кодировки US-ASCII (часто именуемую просто ASCII), ISO-8859-1 и UTF-8. Это небольшая вводная в эти кодировки. Раздел предназначен для разработчиков, которые редко или совсем не работают с кодировками и успели подзабыть их. Если вы к ним не относитесь, то смело пропускайте раздел.

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

7 бит достаточно, чтобы представить любой ASCII символ. Слово «test» будет представлено в HEX представлении, как 0x74 0x65 0x73 0x74. Первый бит у всех символов всегда 0, поскольку символов в кодировке 128, а байт предоставляет 2^8 = 256 вариантов.

ISO-8859-1 — кодировка, предназначенная для западноевропейских языков. Содержит французскую диакритику, немецкие умляуты и т.д.

Кодировка содержит 256 символов и, таким образом, может быть представлена одним байтом. Первая половина (128 символов) полностью совпадает с ASCII. Таким образом, если первый бит = 0, то это обычный ASCII символ. Если 1, то это символ, специфичный для ISO-8859-1.

UTF-8 — одна из самых известных кодировок наравне с ASCII. Способна кодировать 1.112.064 символов. Размер каждого символа варьируется от 1-го до 4-х байт (раньше допускались значения до 6 байт).

Программа, работающая с этой кодировкой, определяет по первым битам, как много байтов входит в символ. Если октет начинается с 0, то символ представлен одним байтом. 110 — два байта, 1110 — три байта, 11110 — 4 байта.

Как и в случае с ISO-8859-1, первые 128 символов полностью соответствуют ASCII. Поэтому тексты, использующие только ASCII символы, будут абсолютно идентичны в бинарном представлении, вне зависимости от того, использовалась ли для кодирования US-ASCII, ISO-8859-1 или UTF-8.

Использование UTF-8 в теле сообщения

Прежде чем перейти к заголовкам, давайте быстро взглянем, как использовать UTF-8 в теле сообщений. Для этого используется заголовок «Content-Type».

Если «Content-Type» не задан, то браузер должен обрабатывать сообщения, как будто они написаны в ISO-8859-1. Браузер не должен пытаться отгадать кодировку и, тем более, игнорировать «Content-Type». Но, что реально отобразится в ситуации, когда «Content-Type» не передан, зависит от реализации браузера. Например, Firefox сделает согласно спецификации и прочитает сообщение, будто оно было закодировано в ISO-8859-1. Google Chrome, напротив, будет использовать кодировку операционной системы, которая для многих российских пользователей равна Windows-1251. В любом случае, если сообщение было в UTF-8, то оно будет отображено некорректно.

Проставляем UTF-8 сообщение в значение заголовка

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

Что будет, если просто взять и записать UTF-8 значение в значение заголовка? Мы видели, что такой трюк с телом сообщения приведет к тому, что значение будет просто прочитано в ISO-8859-1. Логично было бы предположить, что то же самое произойдет с заголовком. Но это не так. Фактически, во многих, если не в большинстве, случаях такое решение будет работать. Сюда включаются старые айфончики, IE11, Firefox, Google Chrome. Единственным из находящихся у меня под рукой браузеров, когда я писал эту статью, который не захотел работать с таким заголовком, является Edge.

Такое поведение не зафиксировано в спецификациях. Возможно, разработчики браузеров решили облегчить жизнь разработчиков и автоматически определять, что в заголовках сообщение закодировано в UTF-8. В общем-то, это не является такой сложной задачей. Смотрим на первый бит: если 0, то ASCII, если 1 — то, возможно, UTF-8.

Нет ли в этом случае пересечения с ISO-8859-1? На самом деле, практически нет. Возьмем для примера UTF-8 символ из 2-х октетов (русские буквы представлены двумя октетами). Символ в бинарном представили будет иметь вид: 110xxxxx 10xxxxxx. В HEX представлении: [0xC0-0x6F] [0x80-0xBF]. В ISO-8859-1 этими символами едва ли можно закодировать что-то, несущее смысловую нагрузку. Поэтому риск того, что браузер неправильно расшифрует сообщение, очень мал.

Однако, при попытке использовать этот способ можно столкнуться с техническими проблемами: ваш веб-сервер или фреймворк может просто не разрешить записывать UTF-8 символы в значение заголовка. Например, Apache Tomcat вместо всех UTF-8 символов проставляет 0x3F (вопросительный знак). Разумеется, это ограничение можно обойти, но, если само приложение бьет по рукам и не дает что-то сделать, то, возможно, вам и не нужно это делать.

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

Транслит

Я думаю, что использовать транслит — eto bolee horoshee reshenie. Многие крупные популярные русские ресурсы не брезгуют использовать транслит в названиях файлов. Это гарантированное решение, которое не сломается с выпуском новых браузеров и которое не надо тестировать отдельно на каждой платформе. Хотя, разумеется, надо подумать, как преобразовывать весь спектр возможных символов, что может быть не совсем тривиально. Например, если приложение рассчитано на российскую аудиторию, то в имя файла могут попасть татарские буквы ә и ң, которые надо как-то обработать, а не просто заменять на «?».

RFC 2047

Как я уже упомянул, томкат не позволил мне проставить UTF-8 в заголовке сообщения. Отражена ли эта особенность поведения в Java docs для сервлетов? Да, отражена:

Упоминается RFC 2047. Я пробовал кодировать сообщения, используя этот формат, — браузер меня не понял. Этот метод кодировки не работает в HTTP. Хотя работал раньше. Вот, например, тикет на удаление поддержки этой кодировки из Firefox.

RFC 6266

В тикете, ссылка на который содержится в предыдущем разделе, есть упоминания, что даже после прекращения поддержки RFC 2047, все еще есть способ передавать UTF-8 значения в названии скачиваемых файлов: RFC 6266. На мой взгляд, это самое правильно решение на сегодняшний день. Многие популярные интернет ресурсы используют его. Мы в CUBA Platform также используем именно этот RFC для генерации «Content-Disposition».

RFC 6266 — это спецификация, описывающая использование “Content-Disposition” заголовка. Сам способ кодировки подробно описан в другой спецификации — RFC 8187.

Параметр “filename” содержит название файла в ASCII, “filename*” — в любой необходимой кодировке. При наличии обоих атрибутов “filename” игнорируется во всех современных браузерах (включая IE11 и старые версии Safari). Совсем старые браузеры, напротив, игнорируют “filename*”.

При использовании данного способа кодирования в параметре сначала указывается кодировка, после » идет закодированное значение. Видимые символы из ASCII кодирования не требуют. Остальные символы просто пишутся в hex представлении, со стоящим «%» перед каждым октетом.

Что делать с другими заголовками?

Кодирование, описанное в RFC 8187, не является универсальным. Да, можно поместить в заголовок параметр с * префиксом, и это, возможно, будет даже работать для некоторых браузеров, но спецификация предписывает не делать так.

В каждом случае, где в заголовках поддерживается UTF-8, на настоящий момент есть явное упоминание об этом в релевантном RFC. Помимо «Content-Disposition» данная кодировка используется, например, в Web Linking и Digest Access Authentication.

Следует учесть, что стандарты в этой области постоянно меняются. Использование описанной выше кодировки в HTTP было предложено лишь в 2010. Использование данной кодировки именно в «Content-Disposition» было зафиксировано в стандарте в 2011. Несмотря на то, что эти стандарты находятся лишь на стадии «Proposed Standard», они поддержаны повсеместно. Вариант, что в будущем нас ожидают новые стандарты, которые позволят более унифицировано работать с различными кодировками в заголовках, не исключен. Поэтому остается только следить за новостями в мире стандартов HTTP и уровня их поддержки на стороне браузеров.

Источник