Переход на Unicode

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

Предполагается общее представление о Unicode и принципах кодировки символов. Некоторые источники информации об этом включают в себя:

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

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

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

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

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

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

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

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

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

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

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

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

Вы должны проверить поддерживает ли 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. Вот рекомендации для распространенных случаев:

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

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

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

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

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

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

Последовательность байтов может быть правильно интерпретирована как текст, только если кодировка символов известна. Многие приложения написаны так, что они просто перемещают последовательности байтов, не называя кодировку. Как уже выше было сказано это всегда вызывает проблемы. Но это случается в случаях, когда все пользователи общаются на одном языке или готовы адаптироваться к некоторому неправильно сделанному контенту на странице. В процессе перехода на Unicode, каждый язык будет обрабатываться как минимум в двух кодировках, устаревшее кодирование для языка и 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. Однако в других случаях, нет четкой спецификации доступно ли кодирование или текст, приходит от источника, которому нельзя полностью доверять, чтобы обеспечить правильную спецификацию. В таких случаях более сложный процесс, требует определения кодировки символов и позднее нужно включить исправление допущенных ошибок:

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

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

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

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

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

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

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

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

В 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%

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

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

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

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

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

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

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

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

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

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

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

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

<span style="font-size:3em;font-family:sans-serif;">
<span lang="zh-Hans-CN" style="font-family: simsun, hei, sans-serif;">з›直</span>
<span lang="ja" style="font-family: 'ms gothic', osaka;">з›直</span>
</span>

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

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

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

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

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

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

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

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

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

Как уже упоминалось в Вопросы относительно Размера Текста (выше), преобразование текста в 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, проверьте следующее:

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

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

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

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

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

Использование 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) и взаимодействует с компонентами сервера. Кодирование, которое клиент использует для связи с сервером можно установить отдельно от кодирования символов, которое использует сервер; сервер преобразует его в случае необходимости.

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

Язык и документация 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 текстом. Убедитесь, что вы проверяете обработку данных пользователя с текстом на разных языках, которые вы будете поддерживать:

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

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

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

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