Хранение многобайтовых в SQL Server

Question

Каким должен быть тип данных в SQL Server для хранения многобайтовых символов? NVARCHAR или VARCHAR

Answer 1

Если вы хотите сохранить исходную строку в МБ, то получится рискованно. На самом деле ваш лучший выбор - тип varbinary, поскольку ни varchar, ни nvarchar не являются правильными типами для строк MB.

Вместо вас я бы преобразовал строку МБ в Unicode, используя MultiByteToWideChar , и сохранил бы ее как NVARCHAR, а при необходимости снова применил ее в приложении Unicode к строке MB, используя WideCharToMultiByte . Таким образом, данные в базе данных будут согласованы для любого другого использования, которое ожидает строки Unicode и / или Ascii, не так много пользователей, готовых работать с многобайтовыми строками, хранящимися как байтовые массивы ...

Answer 2

Это должен быть NCHAR или NVARCHAR ... [ Редактировать ] ... после преобразования их в UCS-2 .

В обоих случаях хранятся символы Unicode (с использованием набора символов UCS-2). Используйте NCHAR для полей с фиксированной длиной (фиксированное количество символов) и NVARCHAR для полей переменной длины.

Преимущество использования UCS-2 состоит в том, что вся поддерживающая логика проще, поскольку для символов требуется ровно два байта для хранения. Недостатком является то, что много места теряется, если большая часть текста использует в основном символы ASCII.

Спасибо, Ремус Русану, за то, что указал, что многобайтовые строки НЕ напрямую совместимы с наборами UCS Unicode. Если вы действительно говорите UTF-8 или UTF-16, он не будет храниться или обрабатываться SQL-сервером должным образом до его преобразования в UCS-2.

Если кто-то только пытается сохранить эти данные, без поиска по ним и т. Д. Формат VARBINARY действительно полезен. В противном случае нужно конвертировать, как я предлагаю. (UCS-2 должен обрабатывать большинство, но, увы, не все наборы символов там).

Answer 3

Можно хранить UTF-8 в полях varchar, если вам действительно нужно, но есть целый ряд предостережений.

• Нет готовых инструментов данных возможность правильно отображать данные без явных преобразований.

• Перевод всех наборов символов ДОЛЖЕН быть отключено в драйверах данных.

• Система не должна принимать усеченные данные если он не понимает границы.

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

Это работает, если у вас нет другого выбора, и вам нужно поддерживать кодировку, например UTF8, без реорганизации вашего приложения и схемы. Работает довольно хорошо для веб-приложений, где ввод и вывод основаны на браузере. Сказав все это, я все равно рекомендую перейти на NVARCHAR и конвертировать в UCS2.