Кодировка символов и Юникод (для разработчиков)
Перевод статьи «What Every Developer Must Know About Encoding and Unicode».
Photo by Tomas Martinez on UnsplashЕсли вы пишете международное приложение, в котором будут использоваться разные языки, вы должны разбираться в кодировке символов. Впрочем, эту статью стоит почитать, даже если вам просто любопытно, как слова выводятся на экран.
Я расскажу краткую историю кодировки символов (и о том, сколь мало она была стандартизирована), а затем чуть подробнее остановлюсь на том, чем мы пользуемся в настоящее время.
Введение в кодирование символов
Компьютер понимает только двоичный код. То есть только нули и единицы. Каждая из этих цифр — один бит. Восемь таких цифр (нулей и/или единиц) — один байт.
В конечном итоге все в компьютере сводится к двоичному коду: языки программирования, движения мыши, ввод текста и все слова на экране.
Но если весь текст, который вы читаете, тоже был в форме нулей и единиц, то как же произошло его превращение в понятные человеку слова? Чтобы в этом разобраться, давайте вернемся к истокам.
Краткая история кодировки
На заре интернета в нем все было исключительно на английском. Нам не приходилось беспокоиться о символах, которых в английском языке просто нет. Для сопоставления всех нужных символов с числовыми кодами использовалась таблица ASCII (American standard code for information interchange).
Получаемый компьютером двоичный код:
01001000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100
при помощи ASCII переводился в «Hello world».
Одного байта (8 бит) вполне хватало, чтобы уникально закодировать любой символ английского языка, а также некоторое количество управляющих символов. Часть этих управляющих символов использовалась для телетайпов, которые были довольно распространены в то время. Сейчас, впрочем, не используются ни телетайпы, ни эти символы.
Что из себя представляют управляющие символы? Например, управляющий символ с кодом 7 (111 в двоичной системе) служит для подачи компьютером звукового сигнала.
Символ с кодом 8 (1000 в двоичной системе) перемещает позицию печати на один символ назад (например, для наложения одного символа на другой или для стирания предшествующего символа). Символ с кодом 12 (1100 в двоичной системе) отвечает за очистку экрана терминала.
В то время компьютеры использовали 8 бит для одного байта (хотя так было не всегда), так что проблем не было. Это позволяло закодировать все управляющие символы, все цифры и буквы английского алфавита, да еще и свободные коды оставались! Дело в том, что 1 байт может принимать 256 (0 — 255) разных значений. То есть потенциально можно было закодировать 255 символов, а в ASCII их было всего 127. Так что 128 кодов оставались неиспользованными.
Давайте посмотрим на саму таблицу ASCII. Все символы алфавита в верхнем и нижнем регистре, а также цифры получили двоичные коды. Первые 32 символа таблицы — управляющие, они не имеют графического отображения.
Как видите, символы кончаются кодом 127. У нас осталось свободное место в таблице.
Проблемы с ASCII
При помощи кодов 128-255 можно было бы закодировать еще какие-нибудь символы. Люди задумались, какими именно символами лучше заполнить таблицу. Но у всех были разные идеи на этот счет.
Американский институт национальных стандартов (American national standards institute, ANSI) разметил, за какие символы должны отвечать коды 0-127 (т. е., те, которые уже были размечены ASCII). Но остальные коды остались открытыми.
Примечание: не путайте ANSI (институт) и ASCII (таблица).
Назначение кодов 0-127 никто не оспаривал. Проблема была в том, что делать с оставшимися.
В первых компьютерах IBM коды ASCII 128-255 представляли следующие символы:
Но в других компьютерах было по-другому. И буквально каждый производитель стремился по-своему применить свободные коды из конца таблицы ASCII.
Эти разные варианты концовок таблицы ASCII назывались кодовыми страницами.
Что такое кодовые страницы ASCII?
Пройдя по ссылке, вы найдете коллекцию из более чем 465 различных кодовых страниц! Как видите, даже для одного языка существовали разные кодовые страницы.
Например, для греческого и китайского есть по нескольку кодовых страниц.
Но как же, черт побери, все это стандартизировать? Как работать с несколькими языками? А с одним языком, но разными кодовыми страницами? А с не-английским языком?
В китайском языке больше 100 тысяч различных символов. Даже если бы мы договорились отдать под символы китайского языка все оставшиеся коды, их бы все равно не хватило.
Выглядело все это довольно плохо. Для этой проблемы даже придумали отдельный термин: mojibake (на японском это слово означает «трансформация символа»).
Это неправильно декодированный текст, в котором символы систематически заменяются другими, причем часто — даже из других систем письменности.
Пример mojibakeС ума сойти…
Вот именно! У нас не было ни единого шанса надежно обмениваться данными.
Интернет — всего лишь огромная сеть компьютеров по всему миру. Представьте, что было бы, если бы каждая страна самостоятельно определяла стандарты кодировки.
Тогда компьютеры в Греции нормально выводили бы только греческий язык, а в США — только английский.
ASCII не подходила для использования в реальном мире. Чтобы интернет был всемирным, нам нужно было что-то менять. Ну, или вечно работать с сотнями кодовых страниц.
���Если только вам������, конечно, не ���нравится ��� расшифровывать такие абзацы.�֎֏0590��׀ׁׂ׃ׅׄ׆ׇ
И тут пришел Юникод
Юникод (Unicode) иногда называют UCS — универсальным набором символов (Universal Coded Character Set), и даже ISO/IEC 10646. Но Юникод — наиболее распространенное название.
Юникод состоит из множества кодовых пунктов (code points, по сути — шестнадцатеричные числа), связанных с символами. Коллекция кодовых пунктов называется набором символов. Вот этот набор — и есть Юникод.
Люди проделали огромную работу, назначив коды всем символам всех языков, а мы можем просто пользоваться результатами их труда. Отображение кодов выглядит так:
"Hello World" U+0048 : LATIN CAPITAL LETTER H U+0065 : LATIN SMALL LETTER E U+006C : LATIN SMALL LETTER L U+006C : LATIN SMALL LETTER L U+006F : LATIN SMALL LETTER O U+0020 : SPACE [SP] U+0057 : LATIN CAPITAL LETTER W U+006F : LATIN SMALL LETTER O U+0072 : LATIN SMALL LETTER R U+006C : LATIN SMALL LETTER L U+0064 : LATIN SMALL LETTER D
U+ указывает на то, что это стандарт Unicode, а номер — число, в которое переведен двоичный код для данного символа.
Вот ссылка на ресурс, где вы можете впечатать в форму любой символ и получить его кодировку в Юникод. Или же можете просмотреть все 143859 символов здесь. В таблице можно увидеть, из какой части света происходит каждый символ!
Просто для ясности подобью итоги. В настоящее время у нас есть большой словарь кодовых пунктов с отображением на символы. Это очень большое множество символов. Н
Наконец, переходим к последнему ингредиенту.
Unicode Transform Format (UTF)
UTF («Формат преобразования Юникода») — это способ представления Юникод. Кодировки UTF определены стандартом Юникод и позволяют закодировать любой нужный нам кодовый пункт Юникод.
Есть несколько разных видов UTF-стандартов. Они отличаются количеством байтов, используемых для кодирования одного кодового пункта. В UTF-8 используется один байт на кодовый пункт, в UTF-16 — 2 байта, в UTF-32 — 4 байта.
Поскольку кодировок так много, как понять, какую использовать? Есть такая вещь как маркер последовательности байтов (англ. Byte order mark, BOM) Это двубайтный маркер в начале файла, который говорит о том, какая кодировка используется в этом файле.
UTF-8 — самая распространенная кодировка в интернете. В HTML5 она определена как предпочтительная для новых документов. Поэтому я уделю ей особое внимание.
Даже по диаграмме 2012 года видно, что UTF-8 становится самой распространенной кодировкой.Диаграмма от W3 показывает, насколько интенсивно используется UTF-8 на сайтахЧто такое кодировка UTF-8 и как она работает?
UTF-8 кодирует кодовые пункты Юникод 0-127 в одном байте (т. е. так же, как в ASCII). Это значит, что если вы для своей программы использовали кодировку ASCII, а ваши пользователи используют UTF-8, они не заметят никакой разницы. Все будет нормально работать.
Просто обратите внимание, насколько это классно. Нам нужно было начать внедрять и повсеместно использовать UTF-8 и при этом сохранить обратную совместимость с ASCII.
Это удалось сделать, UTF-8 ничего не ломает.
В названии кодировки заложено указание на количество бит (8 бит = 1 байт), которые используются для одного кодового пункта. Но есть символы Юникод, для хранения которых требуется по нескольку байтов (раньше было до 6, теперь — до 4, в зависимости от символа). Именно это имеется в виду, когда говорят, что UTF-8 — кодировка переменной длины (см. UTF-32, — прим. ред.).
Тут все зависит от языка. Символ английского алфавита — 1 байт. Европейская латиница, иврит, арабские символы представляются 2 байтами. Для китайских, японских, корейских символов и символов других азиатских языков используются 3 байта.
Чтобы символ мог занимать больше одного байта, есть битовая комбинация, идентифицирующая знак продолжения. Она сообщает о том, что этот символ продолжается в нескольких последующих байтах. Таким образом, для английского языка вы по-прежнему будете использовать по одному байту на символ, но сможете составить и документ, содержащий символы на других языках.
Радостно сознавать, что теперь у нас полное согласие по части того, как кодировать шумерскую клинопись, а также смайлики!
Если описать весь процесс в общих чертах, то:
- сначала вы читаете BOM, чтобы узнать кодировку,
- затем расшифровываете файл в кодовые пункты Юникод,
- затем представляете символы из набора Юникод в символы, которые отрисовываются на экране.
Еще немного о UTF
Помните, что кодировка это ключ. Если я пошлю совершенно неправильную кодировку, вы не сможете ничего прочесть. Имейте это в виду, отсылая или получая данные. Зачастую в постоянно используемых нами инструментах это абстрагировано, но программист должен понимать, что происходит под капотом.
Как мы указываем кодировку? Поскольку HTML написан на английском и практически все кодировки прекрасно справляются с английскими символами, мы можем указать кодировку прямо сверху, в разделе <head>.
<html lang="en"> <head> <meta charset="utf-8"> </head>
Это важно сделать в самом начале <head>, потому что если будет использована не та кодировка, парсинг HTML может начаться заново.
Мы также можем получить кодировку из заголовка Content-Type в HTTP-запросе или ответе.
В спецификации HTML5 есть любопытный способ угадать кодировку, если HTML-документ не содержит соответствующего тега, — BOM sniffing («вынюхивание BOM»). В этом случае кодировка определяется по маркеру последовательности байтов, который мы упоминали ранее.
Это все?
Работа над Юникодом продолжается. Как в любом стандарте, мы можем что-то добавлять, удалять, вносить предложения. Никакая спецификация никогда не считается окончательно завершенной.
Обычно бывает 1-2 релиза Юникода в год, найти их можно здесь.
Недавно мне попалась статья об очень интересном баге: Twitter неверно рендерил русские символы Юникода.
Если вы дочитали до сюда, — снимаю шляпу. Я знаю, информации много.
Советую также выполнить «домашнее задание».
Посмотрите, как могут ломаться сайты из-за неправильной кодировки. Я использовал вот это расширение Google Chrome для смены кодировки и пробовал читать разные страницы.
Текст был совершенно непонятен. Попробуйте прочесть эту статью, например. Зайдите на Википедию. Посмотрите на Mojibake своими глазами.
Это поможет вам проникнуться важностью кодировок.
Заключение
Название этой статьи — дань уважения статье Джоела Спольски, которая познакомила меня с кодировкой и многими концепциями, о которых я и не подозревал. Именно после прочтения этой статьи я углубился в тему кодировки. Также я очень многое почерпнул из этого источника.
Изучая информацию и пытаясь упростить свою статью, я узнал о Майкле Эверсоне. С 1993 года он предложил больше 200 изменений в Юникод и добавил в стандарт тысячи символов. В 2003 году он был одним из ведущих контрибьюторов предложений в Юникод. Своим современным видом Юникод (а значит, и вообще интернет) во многом обязан именно Майклу Эверсону.
Надеюсь, у меня получилось сделать хороший обзор того, зачем нам нужны кодировки, какие проблемы они решают и что случается, если с кодировкой происходит сбой.
о чём должен знать каждый разработчик / Хабр
Если вы пишете международное приложение, использующее несколько языков, то вам нужно кое-что знать о кодировке. Она отвечает за то, как текст отображается на экране. Я вкратце расскажу об истории кодировки и о её стандартизации, а затем мы поговорим о её использовании. Затронем немного и теорию информатики.
Введение в кодировку
Компьютеры понимают лишь двоичные числа — нули и единицы, это их язык. Больше ничего. Одно число называется байтом, каждый байт состоит из восьми битов. То есть восемь нулей и единиц составляют один байт. Внутри компьютеров всё сводится к двоичности — языки программирования, движений мыши, нажатия клавиш и все слова на экране. Но если статья, которую вы читаете, раньше была набором нулей и единиц, то как двоичные числа превратились в текст? Давайте разберёмся.Краткая история кодировки
На заре своего развития интернет был исключительно англоязычным. Его авторам и пользователям не нужно было заботиться о символах других языков, и все нужды полностью покрывала кодировка American Standard Code for Information Interchange (ASCII).
ASCII — это таблица сопоставления бинарных обозначений знакам алфавита. Когда компьютер получает такую запись:
01001000 01100101 01101100 01101100 01101111 00100000 01110111 01101111 01110010 01101100 01100100то с помощью ASCII он преобразует её во фразу «Hello world».
Один байт (восемь бит) был достаточно велик, чтобы вместить в себя любую англоязычную букву, как и управляющие символы, часть из которых использовалась телепринтерами, так что в те годы они были полезны (сегодня уже не особо). К управляющим символам относился, например 7 (0111 в двоичном представлении), который заставлял компьютер издавать сигнал; 8 (1000 в двоичном представлении) — выводил последний напечатанный символ; или 12 (1100 в двоичном представлении) — стирал весь написанный на видеотерминале текст.
В те времена компьютеры считали 8 бит за один байт (так было не всегда), так что проблем не возникало. Мы могли хранить все управляющие символы, все числа и англоязычные буквы, и даже ещё оставалось место, поскольку один байт может кодировать 255 символов, а для ASCII нужно только 127.
Вот как выглядит таблица ASCII. Двоичными числами кодируются все строчные и прописные буквы от A до Z и числа от 0 до 9. Первые 32 позиции отведены для непечатаемых управляющих символов.
Проблемы с ASCII
Позиции со 128 по 255 были пустыми. Общественность задумалась, чем их заполнить. Но у всех были разные идеи. Американский национальный институт стандартов (American National Standards Institute, ANSI) формулирует стандарты для разных отраслей. Там утвердили позиции ASCII с 0 по 127. Их никто не оспаривал. Проблема была с остальными позициями.Вот чем были заполнены позиции 128-255 в первых компьютерах IBM:
Какие-то загогулины, фоновые иконки, математические операторы и символы с диакретическим знаком вроде é. Но разработчики других компьютерных архитектур не поддержали инициативу. Всем хотелось внедрить свою собственную кодировку во второй половине ASCII.Все эти различные концовки назвали кодовыми страницами.
Что такое кодовые страницы ASCII?
Здесь собрана коллекция из более чем 465 разных кодовых страниц! Существовали разные страницы даже в рамках какого-то одного языка, например, для греческого и китайского. Как можно было стандартизировать этот бардак? Или хотя бы заставить его работать между разными языками? Или между разными кодовыми страницами для одного языка? В языках, отличающихся от английского? У китайцев больше 100 000 иероглифов. ASCII даже не может всех их вместить, даже если бы решили отдать все пустые позиции под китайские символы.Эта проблема даже получила название Mojibake (бнопня, кракозябры). Так говорят про искажённый текст, который получается при использовании некорректной кодировки. В переводе с японского mojibake означает «преобразование символов».
Пример бнопни (кракозябров).Безумие какое-то…
Именно! Не было ни единого шанса надёжно преобразовывать данные. Интернет — это лишь монструозное соединение компьютеров по всему миру.
Представьте, что все страны решили использовать собственные стандарты. Например, греческие компьютеры принимают только греческий язык, а английские отправляют только английский. Это как кричать в пустой пещере, тебя никто не услышит.ASCII уже не удовлетворял жизненным требованиям. Для всемирного интернета нужно было создать что-то другое, либо пришлось бы иметь дело с сотнями кодовых страниц.
��� Если только ������ вы не хотели ��� бы ��� читать подобные параграфы. �֎֏0590��׀ׁׂ׃ׅׄ׆ׇ
Так появился Unicode
Unicode расшифровывают как Universal Coded Character Set (UCS), и у него есть официальное обозначение ISO/IEC 10646. Но обычно все используют название Unicode.Этот стандарт помог решить проблемы, возникавшие из-за кодировки и кодовых страниц. Он содержит множество кодовых пунктов (кодовых точек), присвоенных символам из языков и культур со всего мира. То есть Unicode — это набор символов.
С его помощью можно сопоставить некую абстракцию с буквой, на которую мы хотим ссылаться. И так сделано для каждого символа, даже египетских иероглифов.
Кто-то проделал огромную работу, сопоставляя каждый символ во всех языках с уникальными кодами. Вот как это выглядит:
«Hello World» U+0048 : латинская прописная H U+0065 : латинская строчная E U+006C : латинская строчная L U+006C : латинская строчная L U+006F : латинская строчная O U+0020 : пробел U+0057 : латинская прописная W U+006F : латинская строчная O U+0072 : латинская строчная R U+006C : латинская строчная L U+0064 : латинская строчная DПрефикс U+ говорит о том, что это стандарт Unicode, а число — это результат преобразования двоичных чисел. Стандарт использует шестнадцатеричную нотацию, которая является упрощённым представлением двоичных чисел. Здесь вы можете ввести в поле что угодно и посмотреть, как это будет преобразовано в Unicode. А здесь можно полюбоваться на все 143 859 кодовых пунктов.
Уточню на всякий случай: речь идёт о большом словаре кодовых пунктов, присвоенных всевозможным символам.
Осталось добавить последний ингредиент.
Unicode Transform Protocol (UTF)
UTF — протокол кодирования кодовых пунктов в Unicode. Он прописан в стандарте и позволяет кодировать любой кодовый пункт. Однако существуют разные типы UTF. Они различаются количеством байтов, используемых для кодировки одного пункта. В UTF-8 используется один байт на пункт, в UTF-16 — два байта, в UTF-32 — четыре байта.Но если у нас есть три разные кодировки, то как узнать, какая из них применяется в конкретном файле? Для этого используют маркер последовательности байтов (Byte Order Mark, BOM), который ещё называют сигнатурой кодировки (Encoding Signature). BOM — это двухбайтный маркер в начале файл, который говорит о том, какая именно кодировка тут применена.
В интернете чаще всего используют UTF-8, она также прописана как предпочтительная в стандарте HTML5, так что уделю ей больше всего внимания.
Что такое UTF-8 и как она работает?
UTF-8 кодирует с помощью одного байта каждый кодовый пункт Unicode с 0 по 127 (как в ASCII). То есть если вы писали программу с использованием ASCII, а ваши пользователи применяют UTF-8, они не заметят ничего необычного. Всё будет работать как задумано. Обратите внимание, как это важно. Нам нужно было сохранить обратную совместимость с ASCII в ходе массового внедрения UTF-8. И эта кодировка ничего не ломает.Как следует из названия, кодовый пункт состоит из 8 битов (один байт). В Unicode есть символы, которые занимают несколько байтов (вплоть до 6). Это называют переменной длиной. В разных языках удельное количество байтов разное. В английском — 1, европейские языки (с латинским алфавитом), иврит и арабский представлены с помощью двух байтов на кодовый пункт.
Если нужно, чтобы символ занимал больше одного байта, то применяется битовая комбинация, обозначающая переход — он говорит о том, что символ продолжается в нескольких следующих байтах.
И теперь мы, как по волшебству, пришли к соглашению, как закодировать шумерскую клинопись (Хабр её не отображает), а также значки emoji!
Подытожив сказанное: сначала читаем BOM, чтобы определить версию кодировки, затем преобразуем файл в кодовые пункты Unicode, а потом выводим на экран символы из набора Unicode.
Напоследок про UTF
Коды являются ключами. Если я отправлю ошибочную кодировку, вы не сможете ничего прочесть. Не забывайте об этом при отправке и получении данных. В наших повседневных инструментах это часто абстрагировано, но нам, программистам, важно понимать, что происходит под капотом.Как нам задавать кодировку? Поскольку HTML пишется на английском, и почти все кодировки прекрасно работают с английским, мы можем указать кодировку в начале раздела <hеad>.
<html lang="en"> <head> <meta charset="utf-8"> </head>Важно сделать это в самом начале
<hеad>, поскольку парсинг HTML может начаться заново, если в данный момент используется неправильная кодировка. Также узнать версию кодировки можно из заголовка Content-Type HTTP-запроса/ответа.Если HTML-документ не содержит упоминания кодировки, спецификация HTML5 предлагает такое интересное решение, как BOM-сниффинг. С его помощью мы по маркеру порядка байтов (BOM) можем определить используемую кодировку.
Это всё?
Unicode ещё не завершён. Как и в случае с любым стандартом, мы что-то добавляем, убираем, предлагаем новое. Никакие спецификации нельзя назвать «завершёнными». Обычно в год бывает 1-2 релиза, найти их описание можно здесь.Недавно я прочитал об очень интересном баге, связанном с некорректным отображением в Twitter русских Unicode-символов.
Если вы дочитали до конца, то вы молодцы. Предлагаю сделать домашнюю работу.
Посмотрите, как могут ломаться сайты при использовании неправильной кодировки. Я воспользовался этим расширением для Google Chrome, поменял кодировку и попытался открывать разные страницы. Информация была совершенно нечитаемой. Попробуйте сами, как выглядит бнопня. Это поможет понять, насколько важна кодировка.
Заключение
При написании этой статьи я узнал о Майкле Эверсоне. С 1993 года он предложил больше 200 изменений в Unicode, добавил в стандарт тысячи символов. По состоянию на 2003 год он считался самым продуктивным участником. Он один очень сильно повлиял на облик Unicode. Майкл — один из тех, кто сделал интернет таким, каким мы его сегодня знаем. Очень впечатляет.Надеюсь, мне удалось показать вам, для чего нужны кодировки, какие проблемы они решают, и что происходит при их сбоях.
Распространенные проблемы Unicode и UTF-8
Unicode — это набор символов (список букв, цифр, знаков препинания и других письменных знаков), который охватывает почти все системы письма, используемые в настоящее время во всем мире , , а также многие исторические системы важных академических интерес.
Он охватывает не только латинский алфавит от A до Z с международными акцентами (такими как é и á) и местные символы (например, знак фунта стерлингов или символ евро), но также охватывает нелатинские алфавиты, такие как греческий, иврит, арабский и китайский языки. . Каждому символу присвоен номер.
Первые 128 символов Unicode идентичны старому стандарту набора символов ASCII, который также идентичен первой половине наборов символов ISO Western (ISO 8859-1) и ISO Celtic (ISO 8859-14). Это означает, что при условии, что буквы латинского алфавита без диакритических знаков используются только когда-либо, а местные символы, такие как знак фунта стерлингов, избегаются, тогда символы в ASCII, ISO Western, ISO Celtic и Unicode будут иметь одинаковый номер. Например, буква A в верхнем регистре содержит число 65, а буква z в нижнем регистре — число 122.
Валлийский символ ŵ (w-circumflex) включен в Unicode и ISO Celtic, но не включен в ASCII или ISO Western. Аналогичным, но принципиально противоположным образом скандинавский символ ð (eth) включен в Unicode и ISO Western, но не в ASCII или ISO Celtic.
Чтобы усложнить ситуацию, этим двум символам присвоен один и тот же номер в соответствующих наборах символов ISO. Использование Unicode решает эту проблему несовместимости набора символов ISO, поскольку этим двум символам в Unicode присвоены разные номера.
Unicode играет жизненно важную роль в обеспечении того, чтобы HESA мог поддерживать правильное представление знаков, используемых на всей территории Соединенного Королевства.
До недавнего времени большинство компьютерных систем в Великобритании были настроены на использование набора символов ISO Western. В регионах, говорящих на валлийском языке, и, в меньшей степени, в регионах, говорящих на шотландском и ирландском гэльском языках, компьютерные системы могли быть альтернативно настроены для использования набора символов ISO Celtic. Использование Unicode избавляет от необходимости делать этот выбор между двумя противоположными наборами символов ISO, поскольку Unicode поддерживает все наборы символов одновременно.
UTF-8 — это стандарт для представления чисел Unicode в компьютерных файлах.
Символы с номером Unicode от 0 до 127 представляются точно так же, как и в ASCII, с использованием одного 8-битного байта. Сюда входят все буквы латинского алфавита без ударения. При условии, что символы с диакритическими знаками и местные символы, такие как знак фунта стерлингов, не используются, файлы в форматах ASCII, ISO Western, ISO Celtic и Unicode будут напрямую взаимозаменяемы (хотя первые три байта файла могут быть специальным заголовком UTF-8; как обсуждается ниже).
Для символов со значением Unicode выше 127, которые включают знак фунта стерлингов и буквы с ударением, такие как é, они кодируются с использованием двух или более байтов. Это означает, что файлы с этими символами не будут совместимы с наборами символов ASCII, ISO Western или ISO Celtic. Большинство компьютерных операционных систем в большинстве случаев легко преобразуются между UTF-8 и любым набором символов ISO, на использование которого настроен компьютер. Однако из этого правила есть исключение, которое особенно актуально для Соединенного Королевства.
Поскольку появление букв с диакритическими знаками и национальных символов, по крайней мере, в тех видах данных, которые интересуют HESA, может быть небольшим или даже отсутствовать вообще (обычно ограничивается именами собственными или финансовыми значениями), может быть трудно сказать файл UTF-8 из файла ASCII. Поэтому рекомендуется добавлять к файлу UTF-8 в качестве префикса три специальных байта, которые называются заголовком Byte Order Mark (заголовок BOM). При просмотре в формате ISO Western эти байты выглядят как  . При просмотре в Unicode эти символы обычно не отображаются. Если вы видите эти странные символы в начале файла, это явный признак того, что ваша компьютерная система может быть неправильно настроена для использования Unicode.
Система сбора данных HESA всегда выводит файлы UTF-8 с заголовками BOM. Настоятельно рекомендуется, чтобы учреждения использовали заголовки спецификации UTF-8 в своих XML-файлах. Для некоторых коллекций XML заголовки BOM могут быть обязательными; пожалуйста, проверьте соответствующее руководство по кодированию.
Если данные отправляются в HESA с использованием ISO Western или ISO Celtic, то, в зависимости от коллекции, данные могут быть отклонены или могут быть автоматически преобразованы в Unicode с UTF-8 (опять же, см. соответствующее руководство по кодированию) . Это означает, что теоретически возможно отправлять однобайтовые закодированные файлы, но получать обратно многобайтовые файлы. HESA никогда не изменит отправляемые данные, но может изменить метод, используемый для их кодирования.
Файлы XML также могут иметь высокоуровневый атрибут encoding=»UTF-8″. Это обязательно для всех коллекций XML. Пожалуйста, ознакомьтесь с соответствующим руководством по кодированию.
Важно отметить, что простое добавление фразы encoding=»UTF-8″ не приводит к автоматическому преобразованию файла в файл UTF-8; этот атрибут является индикатором пояса и скобок, поэтому системы, читающие эти файлы, знают, что ожидают UTF-8 (даже если это ожидание впоследствии окажется неверным). Поэтому рекомендуется, чтобы системы были настроены на использование Unicode с UTF-8 и не полагались на этот атрибут кодировки XML.
Инструмент отладки символов UTF-8
i18nqa.com -> utf8-debug
Вот таблица проблем с кодировкой, которая помогает отлаживать распространенные проблемы с кодировкой символов UTF-8. Посмотрите эти 3 типичных сценария проблем, с которыми может помочь диаграмма.
- Проблема кодирования 1: обработка байтов UTF-8 как Windows-1252 или ISO-8859-1
- Проблема кодирования 2: неправильное двойное неправильное преобразование
- Проблема кодирования 3: ISO-8859-1 против Windows-1252
В следующей таблице показаны символы в Windows-1252 от 128 до 255 (шестнадцатеричные от 80 до FF). Кодовая точка Unicode для каждого
указан символ и шестнадцатеричные значения для каждого из байтов в кодировке UTF-8 для тех же символов.
Эти байты UTF-8 также отображаются, как если бы они были символами Windows-1252.
Вы можете использовать эту диаграмму для отладки
проблемы, в которых встречаются эти последовательности латинских символов, где ожидался только один символ.