Программирование на стороне клиента.

Управление преобразованием данных между кодовыми страницами клиента и сервера

Как сохранить целостность символьных данных, когда база данных не сохраняет символьные данные при помощи типов данных Юникод и когда клиентские приложения, взаимодействующие с данными, не поддерживают Юникод. В этой ситуации кодовые страницы хранилища данных и кодовые страницы клиентского приложения должны быть одинаковыми. Если эти кодовые страницы различны, то при преобразовании между клиентом и сервером может возникнуть потеря некоторых символов.

Не поддерживается отключение функции AutoTranslate драйвера SQL Server ODBC для вставки данных с сервера, определенных другой кодовой страницей, из сервера. Хотя, даже если AutoTranslateотключена, это не предотвращает преобразование кодовых страниц для событий языка SQL. В результате, если кодовые страницы клиента и базы данных не совпадают, то преобразование кодовых страниц будет в основном применяться к отправляемым и принимаемым сервером символьным строкам отличного от Юникода типа.

По возможности следует избегать такой ситуации. Наилучшим для сервера с определенной кодовой страницей является связь с клиентами, использующими ту же кодовую страницу. Вторым приемлемым решением является использование другой кодовой страницы, имеющей практически такую же кодировку. Например, кодовая страница 1252 (Latin1) и кодовая страница 850 (Multilingual Latin1) обладают практически одинаковыми кодировками, поэтому большинство символов в этих двух кодовых страницах могут быть преобразованы из одной страницы в другую без потери данных.

Если приходится связываться с клиентами при помощи различных кодовых страниц, то правильным решением является сохранение данных в столбцах Юникод. Если ни один из этих вариантов неосуществим, то альтернативой является хранение данных в двоичных столбцах с типами данных binary, varbinary или varbinary(max). Однако двоичные данные могут сортироваться и сравниваться только двоичным способом. Это делает их менее гибкими, чем символьные данные.

Управление преобразованием данных между сервером с поддержкой Юникода и клиентом, не поддерживающим Юникод

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

Ввод данных

Когда данные в формате, отличном от Юникода, с любой кодовой страницей отправляются клиентом серверу для сохранения в формате Юникод, они могут быть корректно сохранены при выполнении одного из следующих условий:

Символьные строки отправляются серверу как параметры удаленного вызова процедуры (RPC).

Строковым константам предшествует заглавная буква N. Это необходимо независимо от того, поддерживает ли клиентское приложение формат Юникод. Если префикс N не указан, SQL Server выполнит преобразование строки в кодовую страницу, соответствующую параметрам сортировки базы данных, действующим по умолчанию. Любые символы, не входящие в эту кодовую страницу, будут утрачены.

Получение данных

Если клиентское приложение не поддерживает Юникод и извлекает данные в буферы с форматом, отличным от Юникода, клиент может извлекать или изменять только те данные, которые представлены кодовой страницей клиентского компьютера. Это означает, что символы ASCII можно извлечь всегда, потому что их представление одинаково во всех кодовых страницах, в то время как любые данные в формате, отличном от ASCII, зависят от преобразования кодовых страниц.

Предположим, что имеется приложение, которое разработано для США, но должно быть развернуто в Японии. Так как базы данных SQL Server поддерживают Юникод, в одних и тех же таблицах можно хранить и английский, и японский текст, несмотря на то, что приложение не было изменено для работы с текстом как с данными Юникод. Если приложение соответствует одному из двух вышеуказанных вариантов, японские пользователи смогут использовать приложение, работающее с иным форматом, для ввода и получения данных на японском языке, а американские пользователи смогут вводить и получать данные на английском языке. Все данные пользователей обеих категорий при этом сохраняются неизменными в том же столбце базы данных и представляются в формате Юникод. В этой ситуации можно создать поддерживающее Юникод приложение, формирующее отчеты на основе полного набора данных. Однако американские пользователи не смогут просматривать строки с данными на японском языке, потому что это приложение не сможет отображать символы, отсутствующие в их кодовой странице (1252).

Такое положение приемлемо, если пользователям не нужно просматривать записи пользователей другой категории. Если же пользователю приложения нужно просматривать или изменять записи с текстом, который не может быть представлен одной кодовой страницей, возможен только один вариант: изменить приложение так, чтобы оно могло работать с данными в формате Юникод.

Веб-приложения

Если клиентская программа создана на основе веб-технологий или подключается к странице ASP (ActiveServerPages), клиентская HTML-страница и серверная ASP-страница связаны со спецификацией метаданных. Эти спецификации необходимы для определения способа преобразования символьных строк при их передаче между сервером, ядром ASP и клиентским браузером.

В клиентской HTML-странице атрибут META должен указывать, что данные следует преобразовать в схему кодирования клиента — для этого служит код CHARSET. Например, на следующей HTML-странице значение big5 кода CHARSET указывает, что клиент должен преобразовать символьные данные в кодовую страницу 950 (традиционный китайский).

<HTML>

<HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=big5">

<!--

-->

</HEAD>

<BODY>

<!--

body

-->

</BODY>

</HTML>

В серверной ASP-странице нужно сообщить веб-приложению ASP, какая кодовая страница используется клиентским браузером. Это можно сделать при помощи свойства Session.CodePage или директивы @CodePage. Эти параметры будут определять способ преобразования данных, передаваемых сервером клиенту, и обработки клиентских запросов GET и POST. В следующих примерах оба этих метода используются для определения преобразования данных в кодовую страницу клиента, и наоборот; кодовая страница клиента имеет номер 950 (традиционный китайский).

<%@ Language=VBScriptcodepage=950 %>

<% Session.CodePage=950 %>

Управление преобразованием данных между различными схемами кодирования Юникода

Сохранение целостности символьных данных, когда и серверное хранилище, и взаимодействующее с данными клиентское приложение поддерживают Юникод, но используют различные схемы кодирования. SQL Server для хранения данных Юникода применяет схему кодирования UCS-2. Однако многие клиенты для обработки Юникода используют другие схемы кодирования, как правило, UTF-8. Это часто относится к веб-приложениям.

Поскольку и в этом случае преобразование выполняется, фактически, из одной кодировки в другую, то для решения этой задачи по-прежнему подходят многие из подобных решений, обсуждавшихся в разделах Управление преобразованием данных между сервером с поддержкой Юникода и клиентом, не поддерживающим Юникод и Управление преобразованием данных между кодовыми страницами клиента и сервера. Строковые константы символов Юникода, отправляемые на сервер, должны начинаться с прописной буквы N. Для веб-приложений в атрибуте META клиентской HTML-страницы указывается код CHARSET. Например, при использовании схемы кодирования Юникода UTF-8 следует указать параметр CHARSET = utf-8. На стороне сервера схема кодирования указывается в свойстве Session.CodePage или директиве @Codepage. Например, codepage=65001 задает кодировку UTF-8. При выполнении этих указаний службы IIS версии 5.0 и более поздних версий согласованным образом выполняют преобразования из UTF-8 в UCS-2 и обратно без дополнительных действий со стороны пользователя.

В приложениях VisualBasic символьные строки обрабатываются в кодировке UCS-2. поэтому нет необходимости явно задавать преобразование кодировки между этими приложениями и экземпляром SQL Server.