Хранение данных UTF-16 / Unicode в SQL Server - PullRequest
Новая
       79

Хранение данных UTF-16 / Unicode в SQL Server

5 голосов
/ 30 апреля 2009

Согласно это , SQL Server 2K5 использует UCS-2 для внутреннего использования. Он может хранить данные UTF-16 в UCS-2 (с соответствующими типами данных, nchar и т. Д.), Однако, если есть дополнительный символ, он сохраняется как 2 символа UCS-2.

Это приводит к очевидным проблемам со строковыми функциями, а именно к тому, что SQL Server обрабатывает один символ как 2.

Я несколько удивлен, что SQL Server в основном способен обрабатывать только UCS-2, и даже более того, это не исправлено в SQL 2K8. Я действительно ценю, что некоторые из этих персонажей могут быть не такими уж общими.

Помимо функций, предложенных в статье, любые предложения о наилучшем подходе к работе с (поврежденными) строковыми функциями и данными UTF-16 в SQL Server 2K5.

Ответы [ 3 ]

6 голосов
/ 11 октября 2012

SQL Server 2012 теперь поддерживает UTF-16, включая суррогатные пары. См. http://msdn.microsoft.com/en-us/library/ms143726(v=sql.110).aspx, особенно раздел «Дополнительные символы».

Таким образом, одно из исправлений исходной проблемы - использование SQL Server 2012.

2 голосов
/ 30 апреля 2009

Строковые функции прекрасно работают со строками символов Юникода; те, которые заботятся о количестве символов, рассматривают двухбайтовый символ как один символ, а не два символа. Единственные, на что нужно обратить внимание - это len () и datalength (), которые возвращают разные значения при использовании юникода. Конечно, они возвращают правильные значения - len () возвращает длину в символах, а datalength () возвращает длину в байтах. Они просто разные из-за двухбайтовых символов.

Итак, до тех пор, пока вы используете правильные функции в вашем коде, все должно работать прозрачно.

РЕДАКТИРОВАТЬ : просто дважды проверил Books Online , данные Unicode работали без проблем со строковыми функциями с SQL Server 2000.

EDIT 2 : Как указано в комментариях, строковые функции SQL Server не поддерживают полный набор символов Unicode из-за отсутствия поддержки парсинга суррогатов вне плоскости 0 (или, другими словами, Строковые функции SQL Server распознают только до 2 байтов на символ.) SQL Server будет правильно хранить и возвращать данные, однако любая строковая функция, основанная на количестве символов, не будет возвращать ожидаемые значения. Наиболее распространенный способ обойти это, кажется, либо обрабатывать строку вне SQL Server, либо использовать интеграцию CLR для добавления функций обработки строк с поддержкой Unicode.

0 голосов
/ 06 февраля 2010

что-то добавить, что я только что выучил трудный путь:

если вы используете поле «n» в oracle (я запускаю 9i) и обращаетесь к нему через .net oracleclient, то кажется, что будет работать только параметризованный sql ... префикс N'string 'unicode, похоже, не работает Хитрость, если у вас есть некоторые встроенные SQL.

и под «работой» я имею в виду: он потеряет все символы, не поддерживаемые базовой кодировкой. Так что в моих случаях английские буквы работают нормально, кириллица превращается в вопросительные знаки / мусор.

это более полная дискуссия на эту тему: http://forums.oracle.com/forums/thread.jspa?threadID=376847

Интересно, можно ли установить переменную ORA_NCHAR_LITERAL_REPLACE в строке подключения или что-то в этом роде.

...