SQL Server 2005/2008 UTF-8 Collation / Charset

16

Я не могу найти вариант (ы) непосредственно к набору UTF-8rellated Collations/Charsetsв SQL Server 2005/2008, так же , как можно установить в другой SQL двигателей, но в службах SQL Server 2005/2008 есть только латинские и SQL сортировки.

Есть ли возможность принудительно установить / установить эти параметры сортировки / кодировки в ядре SQL Server (для обеих версий) 2005/2008 на ОС Win2008?

mKorbel
источник

Ответы:

13

Нет, нет SQL Server не поддерживает UTF-8.

Вам нужно определить ваши столбцы как nvarchar / nchar, если вы хотите данные в юникоде. Обратите внимание, что внутренне SQL Server хранит это как UCS-2.

Обратите внимание, что это было запрошено от MS на Connect, и есть более старая статья KB . И немного информации в этом блоге тоже

ГБН
источник
6
Кроме того, если вы собираетесь выполнять какое-либо сопоставление текста на nvarchar с иностранными символами, вам нужно сопоставить строку, отформатированную с N перед строкой (например, N'οοκονόμον ').
swasheck
Изменилось ли это поведение в любой недавней версии сервера SQL?
Сейрия
@Seiyria: нет, такое же поведение
gbn
Любой, кто найдет свой путь к этому ответу, пожалуйста, перейдите на страницу MS Connect и проголосуйте, что MS поддерживает UTF-8 на SQL Server. Спасибо: D
DarcyThomas
@DarcyThomas Это становится реальностью в SQL Server 2019, хотя это все еще не то, что нужно использовать, если у них нет явной необходимости в этом. Пожалуйста, смотрите мой ответ для деталей.
Соломон Руцкий,
2

Вы не можете установить UTF-8 как набор символов, потому что это не набор символов, это кодировка.

Если вы хотите сохранить текст Unicode, вы используете nvarcharтип данных.

Если вы хотите сохранить текст, закодированный с использованием UTF-8, вы сохраните его как двоичные данные ( varbinary).

Guffa
источник
1

Начиная с SQL Server 2019 (в настоящее время находится в бета-версии / «Предварительный просмотр сообщества»), существует встроенная поддержка UTF-8 посредством новой серии сопоставлений UTF-8. ОДНАКО, возможность использовать UTF-8 не означает, что вы должны. Есть определенные недостатки использования UTF-8, такие как:

  1. Только первые 128 кодовых точек занимают 1 байт (то есть стандартный 7-битный набор ASCII)
  2. Следующие почти 2000 кодовых точек занимают 2 байта, следовательно, нет экономии пространства по сравнению с UTF-16 / NVARCHAR
  3. Остальные 63 тыс. Кодовых точек в BMP (т. Е. Диапазон U + 0800 - U + FFFF) - все 3 байта, следовательно, на 1 байт больше, чем тот же символ в UTF-16 / NVARCHAR.
  4. Просто укажите: дополнительные символы имеют 4 байта в обеих кодировках, так что нет никакой разницы между ними
  5. Несмотря на то, что вы можете сэкономить место с помощью UTF-8, есть очень хороший шанс, что для этого вы снизите производительность.

На самом деле это сводится к следующему: UTF-8 - это дизайн формата хранения, позволяющий 8-разрядным системам (которые обычно были разработаны с использованием расширенных кодовых страниц ASCII и ASCII) использовать Юникод без каких-либо нарушений или каких-либо изменений существующих файлы, чтобы держать вещи в рабочем состоянии. UTF-8 отлично подходит для файловых систем и сетей, но данные, хранящиеся внутри SQL Server, тоже нет. Тот факт, что данные, которые оказываются в основном (или полностью) в пределах стандартного диапазона ASCII, требует меньше места, чем те же данные при хранении в формате UTF-16 /, NVARCHARявляется побочным эффектом. Конечно, это побочный эффект, который может оказаться полезным, но это решение должен принять тот, кто понимает как данные, так и последствия / недостатки этого решения. Этоне функция для общего пользования.

Кроме того, основной сценарий использования UTF-8 (в SQL Server) предназначен для кода приложения, уже использующего UTF-8, возможно, уже с другой СУБД, которая его поддерживает, и нет никакого желания или возможности обновлять код приложения / схему БД использовать NVARCHARтипы данных (для таблиц, переменных, параметров и т. д.) или префикс строковых литералов заглавными буквами «N». Цель аналогична причине существования UTF-8: разрешить коду приложения использовать Unicode без изменения общей структуры или отображения недействительных существующих данных. Если это описывает вашу ситуацию, тогда используйте UTF-8, но имейте в виду, что в ней все еще есть несколько ошибок / проблем.

Если у вас нет явной необходимости работать с Юникодом без использования NVARCHARстроковых литералов с префиксом N или заглавными буквами «N», то единственный другой сценарий, в котором UTF-8 является преимуществом, - это наличие МНОГО в основном стандартных данных ASCII, которые необходимо учитывать Используемые вами символы Юникода NVARCHAR(MAX)(это означает, что сжатие данных не будет работать), и таблица часто обновляется (поэтому индекс кластерного хранилища столбцов, вероятно, не поможет).

Для получения полной информации, пожалуйста, смотрите мой пост:

Собственная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк?

Соломон Руцкий
источник
0

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

Но я работал на SQL Server 2008, и в итоге он не поддерживал кодировку UTF-8. Здесь я мог видеть все ??????????? поскольку UTF-8 не поддерживается в SQL 2008.

Все, что я сделал, это изменил весь varchar на nvarchar, и я смог правильно видеть арабский символ. Также я изменяю свою сортировку базы данных 2008 года на SQL_Latin1_General_CP1256_CI_AS

Халим
источник