Переход на Unicode

Зачем переходить на Unicode?

Есть несколько причин для принятия Unicode:

Чтобы обработать текст необходимо его понимать, поэтому процесс обработки зависит от кодировки символов. Unicode обеспечивает прочную основу для обработки текста со всего мира, тогда как другие кодирования требуют отдельных реализаций для каждой кодировки и каждая из них поддерживает только ограниченный набор языков. Соответственно использование Unicode также облегчает распределение программным обеспечением для обработки текста по всему миру.
Некоторые программы поддерживают связь и сотрудничество между пользователями, проживающими в разных частях света и используют различные языка. Unicode - стандарт, который всем в мире, предоставляет связь без ограничений, накладываемых языком, которым общается пользователь или регионом, в котором живут пользователи.
Поскольку многие языки не поддерживаются, кодировками символов отличными от Unicode, то иногда пользователи представляют созданный ими контент (такой как form data) в кодировках, отличных от поддерживаемых (например, путем изменения кодировки браузера). Это препятствует программе правильно обрабатывать текст, например, при его поиске в базе данных, или при выборе рекламы для размещения за ним.
Многие веб-сайты или программные ошибки связаные с кодировками символов, так как разные сайты или локализации одного и того же сайта используют различные кодировки символов, и кодировка текстовых данных во многих местах неправильная.

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

Планирование перехода

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

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

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

Для начала, вы должны хорошо понимать как кодировка символов используются в вашем программном обеспечении. Определить компоненты программы и вместилища данных: передняя часть, задняя часть, вместилище, APIs(прикладные программные интерфейсы), веб интерфейсы, и т.д., и выяснить их использование в кодировках:

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

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

Данные из вне могут вообще не определить кодировку. Это очень распространенная проблема для электронной почты, веб-страниц, или каналов данных.
Данные из вне могут не правильно определить кодировку. Это также общая проблема для электронной почты и веб-страниц.
Веб-приложения могли присвоить кодировку для формы подачи, но пользователи действительно изменили кодировку в браузере. Пользователи часто это делают, когда кодирование, которое используется веб-приложением не поддерживает язык пользователя, например, приложение поддерживает только ISO 8859-1, а пользователь хочет использовать нелатинские скриптовые языки, такие как Греческий, Русский, Хинди, Китайский, и так далее.
Кодирование было известно в определенный момент, но затем эта информация потерялась. Это обычная ситуация с log files (файлы журнала) - веб-приложение возможно, не знало (или хотя би правильно предпологало) кодировку, которая используется для HTTP запроса, но сам запрос и, следовательно, запись журнала не содержат эту информацию.
Данные пропускали через интерфейс в одной кодировке, где интерфейс на самом деле требует другую кодировку. Примером может служить хранение информации о пользователе закодированной с помощью UTF-8 в базе данных ISO 8859-1.

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

Mozilla
ICU

Проверка устоев

Реализация программного обеспечения часто зависит от другого программного обеспечения:

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

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

Выбрать кодировку для внутреннего использования

Unicode предлагает три формы кодирования: UTF-8, UTF-16, та UTF-32. Обычно для перемещения по сети или для сохранения в файлах UTF-8 работает лучше потому, что оно совместимо с ASCII, тогда как похожие на ASCII байты, которые содержатся в UTF-16 и UTF-32 тексте - это проблема для некоторых сетевых устройств или инструментов обработки файлов. Для обработки в памяти, все три формы кодирования могут быть полезными, и лучший выбор часто зависит от программных платформ и библиотек, которые вы используете: Java, JavaScript, ICU, и большинство Windows APIs (прикладные программные интерфейсы) базируются на основе UTF-16, в то время как Unix системы, как правило, предпочитают UTF-8. Размер хранящихся данных редко становится фактором при принятии решения между UTF-8 и UTF-16, поскольку оба могут иметь лучший размер профиля, в зависимости от сочетания разметки и Европейских или Азиатских языков. UTF-32 является неэффективным для хранения и, следовательно, редко используется с этой целью, но оно очень удобно для обработки, и некоторые библиотеки, такие как Java и ICU, обеспечили строку доступа и обработки API (прикладные программные интерфейсы) с точки зрения UTF-32 code points (точка кода). Преобразования между тремя формами кодирования быстрое и безопасное, так что использование различных форм кодирования в различных компонентах больших программных систем вполне реальное и распространенное.

С уверенностью можно сказать, что сохранение текста, кодирование которого не известно есть исключением из единого правила Unicode. Такой текст часто нужно интерпретировать используя технологию распознавания кодировки символов. И обнаружения кодирования символов не надежный процесс. Таким образом, вы должны вблизи держать оригинальные байты (наряду с выявленным кодированием символов), так чтобы текст можно было повторно преобразовать, когда человек изменит кодировку.

Выбрать кодировку для внешних интерфейсов

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

Электронная почта: Вы должны принимать входящие письма в любой кодировке, использующей вашей электронной почтой. Для исходящей почты, вам, возможно, придется учесть, что многие старые приложения электронной почты не поддерживают UTF-8. В настоящее время, исходящая почта должна быть преобразована в устаревшее кодирование, которое может отобразить весь ее контент; UTF-8 надо использовать только тогда, когда нельзя найти такое устаревшее кодирование. Кодирование исходящей почты должно быть указано. Какие выходные кодирования использовать зависит от потребностей вашей программы.
URIs и POST данные: Они используются в нескольких различных контекстах: форма подачи, веб-сервисы, или URL-адреса, введенные непосредственно в веб-браузере. Для формы подачи, HTML форма должна быть разработана с возможностью обнаружения кодирования, даже если пользователь изменит его в браузере. (Вы можете использовать JavaScript или специальные значения полей, чтобы определить, изменил ли пользователь кодирование: возможно, вы должны мягко напоминать пользователю не делать этого?)
Веб службы: Веб службы (Особенно Веб службы основанные на REST (передача состояния подачи)) должны определять использование UTF-8 и отвергать запросы, которые не действительны для UTF-8. Для сторонних веб сервисов, используйте UTF-8, если, эта функция поддерживается веб сервисом и убедитесь в правильной идентификации используемой кодировки. Для URIs (Унифицированный Идентификатор Ресурсов) кодирование вводится непосредственно в веб браузере (например, маркетинговые URIs), другие кодирования возможно нуждаются в поддержке.
HTML: При подаче страниц на настольные браузеры, используйте кодировку UTF-8; его поддержка сейчас является почти универсальной. Мобильные браузеры не всегда поддерживают UTF-8, так что вы можете использовать устаревшие кодировки в зависимости от целевого устройства. Кодирование, которое используется должно быть назначено с использованием HTTP: заголовок Content-Type, HTML meta тэг, либо (предпочтительнее) оба. Если вы не можете контролировать конфигурации вашего сервера, на уровне файлов или запросов или не можете настроить его для подачи UTF-8 в качестве кодировки, тогда убедитесь, что он вообще не отправляет кодировку: клиентские приложения обращают внимание на эту кодировку перед тем как что-то назначить в meta тэг. Правильный HTML meta тэг:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

Как установить HTTP Content-Type заголовок зависит от вашей среды выполнения. Например, в PHP, вы должны использовать:

<?php header("Content-type: text/html; charset=UTF-8"); ?>.

Смотрите подробную информацию на странице установка content-type.

Если вы взяли контент за пределами вашего сайта (например, веб-паук поисковой системы или внешний HTML), то вам придется иметь дело с любым кодированием. В некоторых случая это означает принятие и обработку используемого кодирования. Если вы включите тот материал в свои собственные страницы, то вы должны будете сделать кодирования соответствующим вашей странице (или положить его в тег iframe, где он может использовать свое оригинальное кодирование).
XML:Исходные XML всегда должны быть закодированы в UTF-8; XML спецификация нуждается, чтобы каждый XML анализатор понимал это. Для источников данных XML, кажите использование UTF-8. В других случаях, XML файлы закодированные в других кодировках должны быть приняты до тех пор, пока они действительны. Обратите внимание, HTTP Content-Type text/XML по умолчанию US-ASCII (по этому поводу, как правило, отдается предпочтение application/xml+*) и вам все равно нужно указать charset (набор символов), если вы используете text/xml Content-Type.
JSON: Исходные данные JSON всегда должны быть закодированы в UTF-8, и желательно в ASCII с экранированными символами \u для всех отличных от ASCII символов. Для входных данных, может быть также рассмотрена поддержка UTF-16 и UTF-32. Спецификация JSON не позволяет любых других кодировок.
Сериализованая PHP: Этот формат данных, следует избегать, поскольку он не позволяет спецификацию кодировки, которая используется, и поэтому, вероятно, может привести к повреждению данных отличного от ASCII текста. JSON является хорошей альтернативой. Если вы совершенно не можете избежать сериализованой PHP, то укажите кодирование UTF-8 и используйте его.
Другие каналы данных: Там где вы можете влиять на кодирование входных каналов данных, оно должно быть UTF-8, или по крайней мере хорошо определенным. Там могут быть случаи, когда вы хотите использовать каналы данных, которые вы не можете контролировать, в таком случае вам придется использовать все, что вы получите.

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

Создание плана

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

Укажите кодировку, которая используется в существующих APIs (прикладные программные интерфейсы). Поскольку все больше компонентов собираются использовать Unicode кодировки, то важно знать, какие компоненты этого еще не сделали для того, чтобы избежать повреждения данных.
Ввести основанные на Unicode версии внешних интерфейсов от которых зависит другое программное обеспечение. Это должно быть первым шагом для того, чтобы разрешить переход зависимого программного обеспечения. На этом этапе каждый внешний интерфейс (API (Прикладной программный интерфейс), веб сервис, поток данных), который базируется на основе устаревших кодировок дублируется с параллельным основанным на Unicode интерфейсом. Для многих интерфейсов, первоначальный вариант нового интерфейса просто превращает входной текст с Unicode в устаревшее кодирование, которое до сих пор используются, вызывает старый интерфейс, и превращает исходный текст из устаревшего кодирование в Unicode. В некоторых случаях, новый интерфейс будет достаточно отличается от старого: Например, где старый интерфейс состоит из прямого доступа к общим данным, новый интерфейс должен быть API (так, инкапсуляция данных является хорошей идеей). Использование устаревших кодировок в базовой реализации означает, что поддерживается только подмножество набора символов Unicode - это ограничение должно быть задокументировано, а затем удалено с помощью следующих шагов.
Поощряйте владельцев других продуктов, которые имеют доступ к вашим базам данных перейти на новый API (Прикладной программный интерфейс). Вам будет лучше чтобы это началось как можно раньше потому, что вы не сможете превратить вашу базу данных в Unicode пока другие имеют доступ к ней используя устаревшие кодировки.
Введите уровень абстракции в частные базы данных продукта, основанного на Unicode. Подобно к шагу выше, это позволяет превращение реализации вашего продукта, и позволяет идти вперед без ожидания превращения баз данных.
Преобразование реализации вашего продукта на Unicode. Частью этого шага, может быть изменение вашего зовнишнишнього интерфейса таким образом, что теперь версии основаные на Unicode будут работать непосредственно с реализацией, в то время как версии, основанные на устаревших кодировках будут превращаться в Unicode и с Unicode. Для больших сайтов или программы, этот шаг может начаться с основанных на Unicode внутренних интерфейсов между подсистемами, подобное тому, что вы сделали для внешних интерфейсов выше, так чтобы подсистемы можно было конвертировать самостоятельно.
Превращение ваших баз данных и/или хранилищ данных в Unicode. Если базы данных были доступны другим продуктам, возможно вам придется ждать, пока те продукты перейдут на APIs, которые были представлены в первом шаге. Раздел Передача данных содержит больше информации об этом шаге.
Удалите интерфейсы, основанные на устаревших кодировках. Это будет заключительный этап вашего перехода, и, в зависимости от того, кто полагается на эти интерфейсы, возможно, придется ждать долго.

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

Проектирование для Unicode

Спецификации кодирования символов

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

Кодирование символов можно задать разными способами:

В спецификации формата: спецификация для формата данных может указать кодировку или напрямую, или указать простой детерминированный механизм для определения кодировки символов смотря на начало последовательности байтов. Примерами являются спецификация Java String class, которая определяет UTF-16, и спецификация JSON, которая приписывает использование Unicode кодировок и как их различать.
В рамках последовательности байтов: Спецификация для формата данных может предусматривать механизм для указания кодировки как части последовательности байтов. XML спецификация делает это в элегантный способ используя назначение кодирования, HTML спецификация делает это в менее элегантный способ используя meta тэг. Для форматов данных, которые позволяют такую спецификацию, данные могут содержать спецификацию кодировки, если только последовательность байтов в кодировке - UTF-8 и спецификация обеспечивает правильное выявление UTF-8 (как для XML). для HTML файлов meta тэг указывает content type и кодирование должно быть первой подкатегорией элемента head , и перед ним не должны стоять символы отличающиеся от ASCII.
В данных, которые являются внешними по отношению к последовательности байтов: Во многих случаях, вместилище последовательности байтов обеспечивает спецификацию кодирования. Несколько примеров будут включать в себя HTTP или MIME, где поле Content-Type заголовок может указать кодировку и базы данных, где кодирования указано как часть схемы или конфигурации базы данных. Опять же, где такие возможности существуют, текстовые данные должны использовать их. В некоторых случаях, таких как отправка HTML через HTTP внешняя спецификация кодирования может дублировать то, что является частью последовательности байтов - это хорошо, так как веб браузеры предпочитают заголовку HTTP, в то время как meta тэг - единственная спецификация, которая сохраняется при сохранении файла на диск.
В спецификациях интерфейса: Спецификации интерфейсов, которые принимают или возвращают последовательности байтов без всяких спецификаций кодировки могут (и должны) указывать используемое кодирование. Спецификация может быть абсолютной или относительной по отношению к среде установки. Например, некоторые библиотеки предоставляют функции, которые принимают или возвращают строки в UTF-8, в то время как другие принимают или возвращают строки закодированными в некоторые устаревшие кодировки.
В контексте: кодировку можно вывести из контекста в котором встречается последовательность байтов. Например, браузеры обычно отправляют данные формы в кодировке символов, которую использует страница, содержащая эту форму. Это очень слабая форма спецификации так как последовательность байтов часто передается с контекста, например, в log файлы, где кодирование уже нельзя изменить. Кроме того, пользователи иногда меняют кодировки браузера так, что кодироване данных формы, которое возвращается не будет соответствовать кодировке страницы, созданной веб-приложением. Использование UTF-8 является одним из способов свести к минимуму ущерб от этой слабой формы спецификации кодирования так как устраняет необходимость пользователям изменять кодировку браузера и поэтому для UTF-8 обнаружение кодировки работает лучше чем для большинства других кодировок.
За внешним соглашением: Когда ничего из вышеперечисленного не применяется, такое как текстовые файлы, то надо сделать внешнее соглашение о кодировании. Такое соглашение могло бы, например, быть частью лицензионного соглашения для ленты контента. Первые четыре механизма лучше, чем два последних и им следует отдавать предпочтение везде, где это возможно. Лучше использовать любой из них, чем вообще не указывать кодировку.

Названия кодировок символов

Существует стандарт для названий кодировок в интернете, RFC 2978, и связанный реестр IANA charset. Однако фактическое использование часто отличается. Многие кодировок приходят в различных вариантах или имеют сестринские кодирования, которые поддерживают расширенные наборы символов, и различное программное обеспечение, часто использует разные названия для одного и того же кодирования или то же название для разных кодировок. Например, название ISO-8859-1 часто используется для описания данных, которые в действительности используют кодировку windows-1252. Это последнее кодирование (Microsoft Windows code page 1252) очень похоже на кодировку ISO 8859-1, но назначает графические символы до диапазона байтов между 0x80 и 0x9F. Многие веб-приложений (таких как браузеры, поисковые системы, и т.д.) относятся к контенту который отмеченный, как ISO 8859-1, как к такому, что использует кодирование windows-1252 потому, что для всех практических целей, windows-1252 является "расширением" ISO 8859-1. Другие приложения, такие как преобразователи кодирования (например iconv или ICU) достаточно буквальные и вы должны указать правильное название кодировки, чтобы получить правильные результаты.

Определение кодировки символов

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

Интерпретировать любые доступные спецификации кодирования. Если спецификация доступна и ей можно доверять, то все готово.
Если спецификация кодирования символов доступна, но ей полностью нельзя доверять, то проверьте ее. Проверка доступна для кодировок, которые накладывают ограничения на действительные последовательности байтов, такие как UTF-8, EUC-KR, ISO 2022-JP. Если текст превращен в другую кодировку для внутренней отделки, проверка часто является просто побочным эффектом преобразования, но если преобразование не требуется, то необходимо сделать проверку. Если последовательность байтов недопустима для указанного кодирования вам необходимо отказаться от входной информации и связаться с провайдером, чтобы он предоставил правильную входную информацию (в случае XML, отказ необходим согласно спецификации). Тем не менее, в случаях, когда у вас нет контроля над данными, переходите к следующему шагу.
Если спецификация кодирования символов не доступна, или не удалось провести проверку используйте выявление кодировки для определения вероятного кодирования.
Если кодирование было определено путем выявления (а не по спецификации и проверке), то держите неподалеку оригинальную последовательность байтов, для того чтобы позже можно было снова превратить его на другое кодирование символов. Обеспечьте механизм пользовательского интерфейса, который позволяет пользователям переопределить заданное или обнаруженое кодирование и повторить преобразования. Сохраните вместе с последовательностью байтов кодировки символов, которое чаще всего используются для последовательности байтов, особенно, если это было выбором пользователя, это поможет избежать ненужной переработки всех вышеупомянутых шагов.

Выбор и назначение кодировки символов

При отправке текста, выбор кодировки символов должен базироваться на основе формата данных и получателя. Раздел Принятие Решения об Использовании Кодировки Символов для Внешних Интерфейсов обсуждает использование кодирования на основе форматов данных. В большинстве случаев рекомендуется Unicode кодирование. Однако, есть два основных исключения:

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

Независимо от того, какое кодирование используется, кодировку однозначно надо указывать, используя один из механизмов, описанных в разделе Спецификации Кодировок Символов.

Преобразование кодировки символов

Перекодировка нужна всегда, когда текст ожидается в одной кодировке символов в одном месте и в другой кодировке символов в следующем месте. ICU и iconv - часто используемые библиотеки для преобразования кодировки символов, однако, некоторые платформы, такие как Java и Perl, предоставляют свои библиотеки преобразования.

При использовании библиотек, важно использовать правильные названия кодировки для конкретной библиотеки. Для более подробной информации смотрите раздел Названия Кодировок Символов.

Есть некоторые конкретные вопросы преобразования, которые могут повлиять на определенные продукты:

Альтернативные отображения некоторых символов: в некоторых Восточно-азиатских кодировках, некоторые символов имеют несколько толкований. Например, значение 0x5C в Shift-JIS может быть истолковано в именах файлов как "\", но в финансовых данных как "¥". При отображении Unicode, должно быть принято решение отражать или U+005C "\" или U+00A5 "¥". Общий подход - отображать U+005C, работающий в файловой системе и который много Японских шрифтов будут отображать как "¥". Однако, если поведение вашей программы зависит от отображения (например, она анализирует значение валюты), вы имеете принять необходимые меры, чтобы контролировать результат. В случае примера, вы могли бы перед превращением отобразить 0x5C как код валюты "JPY" и затем, после преобразования "JPY" как U+00A5.
Символы частного использования: Несколько кодировок, включая Unicode и большинство кодировок Восточной Азии, имеют диапазоны code point (точка кода), которые зарезервированы для частного использования или просто не определены. Они часто используются для символов конкретного или частного использования — emoji установленая Японскими операторами мобильной связи является примером. Стандартные преобразователи символов не знают как отобразить такие символы. Для приложений, где поддержка символов частного использования является критической, чтобы обеспечить правильное отображение вам лучше использовать обычные преобразователи символов или использовать обходные пути, такие как numeric character references (числовые ссылки).
Версии кодировок символов и отображений: Много кодировок символов менялись с течением времени, и поэтому сопоставьте их. Примером может служить отображение с HKSCS в Unicode: Ранние версии HKSCS имели отображать числовые символы в области частного использования Unicode, ибо Unicode не поддерживал их, но позже эти символы добавили в набор символов Unicode, и отображение с HKSCS были изменены, чтобы отобразить новые добавленые символы. Вообще, вы должны убедиться, что вы используете последние версии преобразователей символов.

Нормализация

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

Unicode не предписывает, когда использовать конкретную форму Unicode нормализации. Тем не менее, целый ряд процессов, работает лучше, если текст нормирован, в отдельных процессах, которые содержат в себе сравнения текста, таких как сортировка, поиск и обработка regular expression (регулярное выражение). Некоторые библиотеки выполняя эти процессы предлагают нормализацию в качестве части процесса, в противном случае, прежде чем использовать эти процессы вы должны убедиться, что текст нормирован. Как правило, нормализационная форма C (NFC) рекомендована для веб-приложений. Тем не менее, некоторые процессы, такие как интернационализированные доменные имена, используют другие нормализационное формы.

Некоторые языки требуют нормализации перед обработкой, поскольку различные методы ввода могут генерировать различные последовательности codepoints (точка кода) Unicode. Вьетнамская язык является ярким примером, где вьетнамская раскладка клавиатуры начиная с Windows 2000 и выше производит последовательности символов, которые отличаются от, тех что производят большинство Вьетнамского программного обеспечения для ввода данных. Аналогичные вопросы возникают в ряде Африканских языков, первая, которая приходит в голову - Йоруба.

Вопросы о размере текста

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

Источник Кодирования	Языки	UTF-8	UTF-16
ASCII	Английский, Малайский, ...	0%	100%
ISO-8859-1	Западноевропейские	10%	100%
ISO-8859-7, обычный текст	Греческий	90%	100%
ISO-8859-7, 50% разметка	Греческий	45%	100%
TIS-620, обычный текст	Тайский	190%	100%
TIS-620, 50% разметка	Тайский	95%	100%
EUC-KR, обычный текст	Корейский	50%	5%
EUC-KR, 50% разметка	Корейский	25%	55%

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

Однако на микроуровне, увеличение размера вместилища имеет ряд последствий:

Алгоритмы, разработанные под допущения одного символа, одного байта, больше не работают даже для Европейских языков (они никогда не работали для Восточно-азиатских языков). Их нужно изменить, чтобы приспособить многобайтовое отображение символов. Убедитесь, что вся обработка всегда работает с полными символами. Полный символ может занять от одного до четырех байт в кодировке UTF-8, и одну или две единицы 16-битного кода в UTF-16. Для позиций символа, всегда используйте индекс first byte (первого байта) или code unit(элемент кода) символа.
Обычно, спецификации любой длины нужно пересмотреть для того, чтобы убедиться, что они будут базироваться на основе байтов, символов, UTF-16 code units (элемент кода), или глифов. Каждая основа имеет смысл в некоторых ситуациях, но должно быть ясно, какая из них применяется. Использование основанного на символах определения гарантирует достаточно места, но может занять больше места, чем необходимо, так как каждый символ теперь требует 4 байта. Использование основанного на байтах определения позволяет избежать такого размера, но может значительно ограничить количество символов. Лучшими, конечно, есть схемы, которые выделяют достаточно места для хранения данного текста. Другие приложения, управляющие пространством (например, несколько "символов", которые могут отображаться в поле формы) могут не иметь возможности что-то сделать с несколькими логическими символами, а вместо этого необходимо подсчитать количество единиц визуального текста (так называемые графемы).
Размер текста изменяется при каждом его преобразовании из одного кодирования в другое. Нет фиксированных коэффициентов, применимых для оценки размера необходимого вместилища, так что единственный способ узнать это - действительности превратить текст. Необходимо соблюдать осторожность, чтобы избежать сокращения. Если сокращение на самом деле необходимо, как и в некоторых отображаемых контекстах, особое внимание надо обратить на сокращение границ символа или графемы.

Использование библиотек

Для работы с Unicode, часто выгоднее использовать программные библиотеки , которые предназначены для поддержки Unicode. Старые библиотеки могут не так хорошо поддерживать Unicode , или вообще не поддерживать.

Определение и назначение языка

Хотя Unicode позволяет многоязычные программы и документы, есть много процессов, которые требуют знания об использовании фактического языка. Такие процессы варьируются от простого сложения к поиску и проверке правописания.

APIs, базирующиеся на основе Unicode должны позволять спецификацию языка (языков), что используется там где только такие знания могут пригодиться и язык контента созданного пользователями должен быть записан там где это возможно. Там где нельзя определить язык в ресурсе, может потребоваться библиотека определения языка.

Чтобы помочь другим программам, язык веб-контента, нужно назначать с использованием HTTP заголовка Content-Language или HTML/XML атрибутов lang.

Вопросы по шрифтам

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

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

Изображение того же идеографического символа Unicode, но с двумя разными представлениями глифов.

 з›直 з›直 

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

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

Одно из решений - следить за языком, который используется, и передать браузеру язык и шрифты, используемые для языка. Для одноязычных страниц простой и эффективный подход - использование для языка специальной таблицы стилей. Для многоязычных страниц, вы должны использовать атрибут lang HTML тэгов для определения языка; несколько браузеров используют эту информацию для выбора правильного шрифта. Для точного контроля над шрифтом вы также можете использовать классы для определения языка и класс селекторов в таблице стилей, чтобы установить шрифт. CSS 2.1 селекторы псевдо класса языка, которые будут выбирать непосредственно на основе атрибута(ов) языка, не поддерживаются Internet Explorer и поэтому имеют ограниченную полезность. Смотрите Результаты тестирования: Зависимый от языка стайлинг.

Перенос данных

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

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

Стратегии для преобразования данных будут изменяться в зависимости от ряда факторов:

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

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

Решение вопросов относительно размера текста

Как уже упоминалось в Вопросы относительно Размера Текста (выше), преобразование текста в Unicode, как правило, происходит за требований расширенного вместилища, и вы должны тщательно рассмотреть вопрос о целесообразности измерения длины текста в байтах, символах или UTF-16 code units (элементы кода). Чтобы уменьшить влияние увеличенных размеров поля переключите CHAR поля в базах данных SQL на VARCHAR, что позволит базе данных выделить столько пространства сколько необходимо.

При измерении текста, некоторые базы данных не дают вам выбора. Например, MySQL всегда измеряет с точки зрения Unicode BMP символов, в результате чего получается 3 байта на символ. Другие, такие как Oracle, позволяют выбирать между семантикой символа или байта. Другие системы хранения данных, которые накладывают ограничения на размер скорее всего измеряют в байтах.

При переносе, которое включает в себя перекодировку, будьте осторожны, чтобы избежать сокращения. В некоторых случаях, к сожалению, вы не сможете это сделать, через такие внешние ограничения, как 30 байтный лимит в Oracle для схемы имен объектов в словарях данных (использование символов ASCII для схемы имен помогает избежать этой проблемы). В таких случаях, по крайней мере убедитесь, в сокращении в пределах символа.

Кроме того: обратите внимание, что может быть расширение текста за счет перевода. Смотрите Размер текста в переводе.

Выявление ASCII данных

Следует определить наборы данных (файлы, таблицы базы данных, столбики базы данных), которые полностью закодированы в ASCII. Если требуется Unicode кодирования - UTF-8, то для таких наборов данных преобразования не требуется, поскольку последовательности байтов ASCII идентичны соответствующим последовательностям байтов UTF-8. Кроме того, индексы над ASCII текстовыми полями справедливы и для соответствующих UTF-8 или UTF-16 текстовых полей, если только они не основаны на порядке сортировки чувствительном к языку. Тем не менее, вы должны быть строгими в определении ASCII наборов данных. Термин "ASCII" часто ошибочно используется для таких вещей, которые не являются ASCII, такие как обычный текст (в любой кодировке) или текст в таких кодировках, как ISO 8859-1 или Windows-1252. Кроме того, ряд кодировок был разработан, чтобы вписаться в 7-битные последовательности байтов, представляя совершенно разные наборы символов из ASCII.

Чтобы убедиться, что набор данных действительно находится в ASCII, проверьте следующее:

Все значения байтов в наборе данных находятся в диапазоне от 0x00 до 0x7F. ASCII не использует значения байтов выше за 0x7F.
Не используются такие значения байтов, как 0x0E, 0x0F, и 0x1B. Присутствие этих значений байтов, скорее всего, указывает, что данные действительности закодированы в кодировке ISO-2022.
Если символы "+" и "-" встречаются, то промежуточные байты не действительны для BASE-64. Если они есть, то не исключено, что текст закодирован в кодировке UTF-7. Обратите внимание, что UTF-7 по возможности надо избегать через потенциальную угрозу XSS атак.
Такие последовательности символов, как "~{" и "~}" не встречаются. Если вы их встретили, то текст, вероятно, закодированный в кодировке HZ.

Действия в условиях неопределенности

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

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

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

Значение Numeric Character References (Числовых Ссылок)

Базы данных сохраняя созданный пользователями контент, часто содержат числовые ссылки (NCRs) на введенные пользователями символы отличные от ASCII такие, как "Œ" (Œ) или "€" (€). Многие браузеры создают NCRs тогда, когда пользователи вводят текст в поля формы, которые не могут быть выражены в кодировке символов формы. NCRs отлично работают, если текст впоследствии перепоказаний в HTML. Однако, для других процессов, они не работают потому, что они не совпадают с текстом, который они представляют в поиске, они сортируются в неправильном месте, или они игнорируются при преобразовании. При переходе на Unicode также было бы хорошо превратить NCRs в соответствующие символы Unicode. Однако, вы должны быть осторожны, чтобы избежать преобразований, которые меняют значения текста (преобразование из "&" в "&") или преобразования в текст который будет отфильтрован по соображениям безопасности.

Использование BOM (маркер порядка байтов)

При переходе из устаревших кодировок в Unicode, принято использовать устаревшие кодировки и Unicode параллельно, и вы должны их различать. В общем случае, это требует спецификаций кодировки. Однако, если вам нужно отличить только одно определенное устаревшее кодирование (например, старую кодировку сайта по умолчанию) и UTF-8, Вы можете использовать Unicode Маркер Порядка Байтов (BOM) в качестве префикса для идентификации строк UTF-8. Это особенно удобно, если нет оговорки о спецификации кодировки, например, в обычных текстовых файлах или в cookies (куки). BOM в UTF-8 - последовательность байтов 0xEF 0xBB 0xBF, которая вряд ли понадобилась бы в любой устаревшей кодировке.

Считыватель данных, который идентифицирует их кодирование, таким образом, для определения кодирования читает первые три байта. Если байты соответствуют BOM, то три байта зачищаются и оставшийся контент возвращается как UTF-8. Если байты не соответствуют BOM, то весь контент превращается из устаревшего кодирования в UTF-8. Однако, эта зачистка не является автоматической, и это влияет на некоторые платформы или языки. Например, PHP файл, который начинается с BOM будет истолкован неправильно PHP процессором. Так что этот трюк лучше ограничить и использовать для известных частей вашего сайта или кода.

Преобразование текстовых файлов

Обычные текстовые файлы, которые используют одну кодировку легко превратить. Например, инструмент iconv доступен на большинстве систем основанных на Unix/Linux. В системах, которые не имеют его, удобно установить Java Development Kit и использовать его инструмент native2ascii:

native2ascii -encoding _''sourceencoding'' ''sourcefile'' |
      native2ascii -reverse -encoding ''targetencoding'' >
      ''targetfile''

Для небольшого количества файлов, также можно использовать редакторы: TextPad на Windows, TextEdit на Mac, или jEdit на любой платформе, есть лишь несколько редакторов, которые могут преобразовывать файлы. Заметим, что некоторые редакторы такие, как Notepad (Блокнот), любят приставлять Unicode byte-order mark (BOM) спереди Unicode файлов, что в случае UTF-8 файлов не являются необходимыми и могут вызвать проблемы с программным обеспечением, при чтении файлов.

Преобразование структурированных файлов

Структурированные файлы в данном контексте - любые файлы, кроме баз данных SQL, имеющие компоненты, которые могут иметь различные кодировки или что имеют ограниченную длину. Примеры: log files (файлы журнала), в которых различные записи могут использовать различные кодировки; сообщение электронной почты, где разные заголовки и MIME компоненты могут использовать различные кодировки, и заголовки имеют ограниченную длину; и cookies (куки), которые часто рассматриваются, как имеющие несколько полей. Для таких файлов, каждый компонент должен быть преобразован отдельно, и ограничения длины должны рассматриваться отдельно для каждого компонента.

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

База данных SQL на самом деле состоит из двух компонентов: компонент сервера, который фактически управляет данными, а также клиентский компонент, который взаимодействует с другими приложениями (например, PHP или Java runtime) и взаимодействует с компонентами сервера. Кодирование, которое клиент использует для связи с сервером можно установить отдельно от кодирования символов, которое использует сервер; сервер преобразует его в случае необходимости.

В зависимости от размера базы данных и ее требований к безотказной работе, доступные различные стратегии для преобразования:

Дамп и перезагрузка: содержимое базы данных сбрасывается в текстовый файл, превращается в желаемое кодирование Unicode, и загружается в новую базу даних. Эта стратегия проста, но работает только для баз данных, которые можно перевести в автономный режим на длительный период, необходимый для преобразования.
Создать новую базу данных Unicode: создается новая база данных, использующая кодировку Unicode и поверх копируется контент из старой базы данных и с ходу делается преобразование. Транзакции, которые обновляют или удаляют контент, который уже скопирован должны быть отражены в новой базе данных. Когда новая база данных настигает старую, доступ переключается для новой базы данных. Как правило, это лучшая стратегия для производства баз данных, но она требует доступности достаточного количества серверного оборудования баз данных для запуска двух баз данных в параллельном режиме.
Добавить Unicode столбцы: В этой модели, каждый текстовый столбец в устаревшей кодировке спаренный с новым столбцом в Unicode кодировке. Поля в этого столбика заняты, а потом еще и меняются запросы для доступа к Unicode столбику вместо столбика устаревшего кодирования. Если устаревшее кодирование точно известно, то столбик устаревшего кодирования можно удалить. Эта стратегия может понадобиться, если на диске не хватает места для создания абсолютно новой базы данных и, если код доступа к базе данных приемлемо мал.
Преобразования на месте: Некоторые базы данных, такие как MySQL, имеют возможность на месте превратить таблицу с одной кодировки в другую. Это работает только для баз данных, которые можно перевести в автономный режим на период, необходимый для преобразования.
Преобразование в месте с тэгом кодирования: Если база данных только управляет байтами, и все интерпретации байт как текста делаются за пределами базы данных, то можно делать преобразования на месте и отслеживать прогресс используя тэг кодирования на каждой записи. Процессы, которые имеют доступ к базе данных должны быть проинформированы о тэге кодирования и превращать байты, которые они хранят в базе данных или извлекать из базы данных с их и в их собственные кодировки. Если база данных содержит только одно устаревшее кодирование, BOM можно использовать, чтобы отличить Unicode строки.

Язык и документация SQL имеют дурную привычку использовать термин "character set" (набор символов) для кодировок символов, игнорируя тот, факт, что UTF-8 и UTF-16 (и даже GB18030) являются разными кодировками одного и того же набора символов.

Особенности Oracle

Oracle имеет общую поддержку Unicode, начиная с 8-й версии, но поддержка дополнительных символов доступна только начиная с версии 9r2, и поддержка Unicode 3.2 только начиная с 10-й версии. Также до 9-й версии немного трудно использовать такие типы данных, как NCHAR и NVARCHAR. Oracle обеспечивает всестороннюю поддержку Globalization Support Guides (Руководство Поддержки Глобализации) для таких версий: 9r1, 9r2, 10r1, и 10r2. Особенно актуальны разделы по вопросам Character Set Migration (Переход) и Character Set Scanner (Сканер).

Кодирование символов избранное для базы данных Oracle устанавливается для всей базы данных, включая данные, схемы и запросы, с одним исключением: NCHAR и NVARCHAR типы всегда используют Unicode. Для базы данных предлагаются различные Unicode кодирования, как для целой базы так и для таких типов данных как NCHAR и NVARCHAR. Для базы данных правильными являются UTF-8 под названием AL32UTF8, и вариант UTF8, кодирующий дополнительные символы в виде двух 3-байтных последовательностей. Для перехода баз данных в Unicode, вы должны использовать AL32UTF8(базы данных, которые уже используют UTF8 в большинстве случаев могут продолжают это делать - разница между этими кодировками может повлиять на параметры сортировки и индексации в базе данных, но в целом это не имеет большого значения, так как клиентский интерфейс превращает UTF8 чтобы исправить UTF-8). Для таких типов данных, как NCHAR и NVARCHAR UTF-16 доступен под названием AL32UTF8, рядом с вариантом кодирования UTF8. Семантику спецификаций длины для таких типов данных, как CHAR, VARCHAR2, и LONG можно установить используя NLS_LENGTH_SEMANTICS, с байтовой семантикой по умолчанию, в то время, как типы данных NCHAR и NVARCHAR всегда используют символьную семантику.

Для правильного преобразования между кодированием (ямы), что используется в пределах базы данных в кодировке клиента очень важно определить NLS_LANG переменную среду на стороне клиента. Эта переменная описывает язык, территорию, и кодирования, что используется клиентской операционной системой. Oracle имеет множество других параметров, чтобы указать в базе данных чувствительное к локали поведение; они вообще могут быть установлены отдельно от кодировки до тех пор пока кодирование может представлять символы выбранной локали. Unicode поддерживает все языковые стандарты (локали).

Oracle обеспечивает встроенную поддержку для нескольких стратегий преобразования. Инструмент Character Set Scanner помогает в выявлении возможного преобразования и сокращении проблем в анализе предварительного преобразования. Утилиты экспорта и импорта помогают в выполнении дампа и перезагрузке стратегии. Добавлять Unicode столбики легко, так как NCHAR и NVARCHAR типы данных поддерживают Unicode независимо от кодировки базы данных. Преобразования на месте с тэгом кодирования возможно, если сама база данных не растолкует текст - ALTER DATABASE CHARSET заявление может быть использовано для того, чтобы информировать базу данных о фактическом кодировании когда преобразование будет завершено.

Есть сообщения, что NCHAR типы данных не поддерживаются в PHP Oracle Call Interface.

Особенности MySQL

Чтобы получить поддержку Unicode в базах данных MySQL, вы должны использовать версию MySQL 4.1 или выше. Для получения информации о переходе на эту версию и о возможных проблемах совместимости смотрите Обновление Character Sets с MySQL 4.0. Подробную информацию о поддержке кодировки символов в MySQL, смотрите в разделе документации MySQL Поддержка Character Set. Кодирование символов для контента базы данных можно установить отдельно на уровне сервера, базы данных, таблицы или столбца. Если кодирование явно не задано, то оно наследуется от следующего более высокого уровня.

Кодированием по умолчанию в MySQL есть latin1, а именно, ISO-8859-1. Unicode кодирования, которые поддерживаются называются utf8 и ucs2. Обычно рекомендованным кодированием для MySQL должно быть utf8. Оба utf8 и ucs2 ограничены для символов Unicode Basic Multilingual Plane (BMP), так что нет никакой поддержки для дополнительных символов в MySQL. В результате utf8 не является полностью совместимой реализацией UTF-8 (хотя для большинства случаев это нормально). Такие типы данных, как NCHAR и NVARCHAR всегда используют utf8.

Спецификации длины для символьных типов данных интерпретированы в Unicode BMP символы, так спецификация CHAR(5) CHARACTER SET utf8 зарезервирует 15 байт. Такие meta данные как имена пользователей, всегда хранятся в UTF-8, поэтому нелатинские названия можно использовать. Кодирования символов для клиентского подключения можно установить отдельно для клиента, подключения, и результатов, но, чтобы избежать путаницы, лучше установить их все вместе, используя SETВ NAMESВ 'utf8'. Кодирование ucs2 не поддерживается для клиентских подключений, так что нет никаких оснований использовать это кодирование для контента базы данных.

Сортировки, связанные с кодировками символов, поэтому они всегда должны устанавливаться в то же время, что и кодирование. Если utf8 используется без указания о сортировке, то по умолчанию используется такая сортировка, как utf8_general_ci. Это устаревший алгоритм сортировки, что не является хорошим для любого конкретного языка. Сортировка utf8_unicode_ci лучшая по умолчанию, так как она реализует Unicode Collation Algorithm (UCA) и работает для многих языков, специально не поддерживается названной сортировкой. Вы также можете выбрать одну из language-named UTF-8 сортировок, чтобы получить language-specific сортировку "строго" основанную на UCA. Смотрите список сортировок для Unicode Character Sets. MySQL поддерживает функцию CONVERT, которая позволяет преобразовывать результаты запроса из одного кодирования в другое. MySQL также поддерживает преобразование на месте из одного кодирования в другое с помощью ALTER statement: ALTER TABLE table CONVERT TO CHARACTER SET utf8 COLLATE collation;.

В некоторых случаях, кодирование столбика в схеме может быть неправильно назначенное - например, данные UTF-8 можно сохранить в базе данных MySQL под названием кодирования latin1, ранее MySQL действительно поддерживала UTF-8, или Японские данные можно отметить sjis в то время, когда в действительности они используют Shift-JIS версию Windows, которую MySQL называет cp932 (смотрите The cp932 Character Set для получения дополнительной информации по этому поводу). В таких случаях столбик можно перемаркировать без преобразования путем изменения его типа на двоичный эквивалент (BINARY, VARBINARY, BLOB), затем вернуться обратно к символам (CHAR, VARCHAR, TEXT) с правильным названием кодирования, например, для TEXT столбика: ALTER TABLE table CHANGE column column BLOB; ALTER TABLE table CHANGE column column TEXT CHARACTER SET utf8 COLLATION collation;. Вы можете и должны изменить вместе все столбцы одной таблицы для того, чтобы свести к минимуму затраты на перестройку таблицы.

Примечание: PHP клиент для MySQL по умолчанию указывает latin1 как кодирование для каждого нового соединения, поэтому необходимо вставить заявление SET NAMES 'utf8' для каждого нового соединения.

Преобразование имен файлов

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

Если точно можно определить кодировку имени файла, то его можно преобразовать в UTF-8, и Byte Order Mark можно использовать, чтобы отметить его как преобразованный. Если кодирование не определено, возможно понадобится создать базу данных параллельно к файловой системе для записи обнаруженного кодирования и, возможно, UTF-8 версии, так что оригинальное имя файла может храниться неподалеку для дальнейшего исправления кодировки.

Тестирование с помощью Unicode

Не имеет смысла тестировать Unicode поддержку с ASCII текстом. Убедитесь, что вы проверяете обработку данных пользователя с текстом на разных языках, которые вы будете поддерживать:

Восточноевропейские системы письма: ελληνικά, русский
Восточно-Азиатские языки: 中文, 日本語, 한국어
Юго-Восточные Азиатские языки: Tiếng Việt, ไทย
Индийские языки: हिंदी

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

Чтобы показать, что текст в пользовательском интерфейсе вашей программы обрабатывается правильно, полезной будет такая стратегия тестирования, как псевдо-локализация. Инструменты псевдо-перевода могут автоматически заменять ASCII символы на сообщение пользовательского интерфейса с эквивалентными латинскими символами на всю ширину с Unicode диапазона от U+FF01 до U+FF5E (English -> Ｅｎｇｌｉｓｈ) или с другими буквами с диакритическими знаками из полного Латинского диапазона (English -> Ëñgłíšh).

Вопросы, требующие особого внимания при тестировании поддержки Unicode:

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

Некоторые руководящие принципы для тестирования Unicode поддержки и интернационализации можно найти на: Международные Основы Тестирования

Дополнительные материалы

Поддержка Character Set для MySQL.
Учимся Печатать на Японском и Других Языках содержит информацию о настройке и использовании всех распространенных операционных систем для многоязычного тестирования.