Назад | Перейти на главную страницу

Есть ли недостатки использования UTF8 в базе данных Oracle?

Мы устанавливаем заказ настроенной базы данных oracle, и они спрашивают нас, какую кодировку символов мы хотели бы иметь. Приложение (на Java) только на английском языке, но пользователи из разных уголков мира.

Есть ли какие-либо причины НЕ использовать UTF8 или другой набор символов Юникода?

Но будьте осторожны:

Не используйте набор символов с именем UTF8 в качестве набора символов базы данных, если это не требуется для совместимости с клиентами и серверами Oracle Database в версии 8.1.7 и более ранних, или если это явно не запрошено поставщиком вашего приложения. Несмотря на очень похожее имя, UTF8 не является надлежащей реализацией кодировки Unicode UTF-8. Если набор символов UTF8 используется там, где ожидается обработка UTF-8, могут возникнуть проблемы с потерей данных и безопасностью. Это особенно верно для данных, связанных с Интернетом, таких как XML и URL-адреса.

Oracle рекомендует AL32UTF8 как набор символов базы данных. AL32UTF8 - это имя Oracle для кодировки UTF-8 стандарта Unicode.

У вас должно быть два варианта:

  1. Выбери свой набор символов базы данных (использован VARCHAR2, CHAR, CLOB типы данных).
  2. Выбери свой набор национальных символов (использован NVARCHAR2, NCHAR, NCLOB типы данных).

Так как видел здесь :

Oracle рекомендует использовать Unicode для всех новых развертываний системы.

Наборы национальных символов могут быть только Unicode: UTF-8 или UTF-16. Поэтому выбор одного и того же набора символов для обоих будет излишним ...

Мой совет (вы говорите, что ваше приложение только на английском языке):

  • Попросите, чтобы набор символов вашей базы данных был UTF-8.
  • Попросите, чтобы ваш национальный набор символов был UTF-16.

И вот мой общий совет по определению вашей схемы. Таблица за таблицей, столбец за столбцом (я беру VARCHAR2/NVARCHAR2 образец здесь):

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

Есть ли какие-либо причины НЕ использовать UTF8 или другой набор символов Юникода?

Только один; у вас есть существующий набор данных, для которого вы не можете гарантировать текущую кодировку кодировки.

В этом случае вы, вероятно, захотите исправить это и по-прежнему использовать UTF8.

Нет, совсем нет.

Полушутка: да, со старыми клиентами, которые не знают UTF, больше нельзя подключиться.