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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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