Я не могу найти вариант (ы) непосредственно к набору UTF-8rellated Collations/Charsetsв SQL Server 2005/2008, так же , как можно установить в другой SQL двигателей, но в службах SQL Server 2005/2008 есть только латинские и SQL сортировки.
Есть ли возможность принудительно установить / установить эти параметры сортировки / кодировки в ядре SQL Server (для обеих версий) 2005/2008 на ОС Win2008?
Ответы:
Нет, нет SQL Server не поддерживает UTF-8.
Вам нужно определить ваши столбцы как nvarchar / nchar, если вы хотите данные в юникоде. Обратите внимание, что внутренне SQL Server хранит это как UCS-2.
Обратите внимание, что это было запрошено от MS на Connect, и есть более старая статья KB . И немного информации в этом блоге тоже
Вы не можете установить UTF-8 как набор символов, потому что это не набор символов, это кодировка.
Если вы хотите сохранить текст Unicode, вы используете nvarcharтип данных.
Если вы хотите сохранить текст, закодированный с использованием UTF-8, вы сохраните его как двоичные данные ( varbinary).
Начиная с SQL Server 2019 (в настоящее время находится в бета-версии / «Предварительный просмотр сообщества»), существует встроенная поддержка UTF-8 посредством новой серии сопоставлений UTF-8. ОДНАКО, возможность использовать UTF-8 не означает, что вы должны. Есть определенные недостатки использования UTF-8, такие как:
NVARCHARNVARCHAR.На самом деле это сводится к следующему: 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: Спаситель или Лжепророк?
В моем случае мне приходилось отображать арабские символы, а моя база данных была в 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