 |
|
Управление преобразованием данных между сервером с поддержкой Юникода и клиентом, не поддерживающим Юникод
Как сохранить целостность символьных данных, если на сервере данные хранятся в формате Юникод, а в клиентском приложении, которое работает с этими данными, используется специфическая кодовая страница.
Ввод данных
Когда данные в формате, отличном от Юникода, с любой кодовой страницей отправляются клиентом серверу для сохранения в формате Юникод, они могут быть корректно сохранены при выполнении одного из следующих условий:
Символьные строки отправляются серверу как параметры удаленного вызова процедуры (RPC).
Строковым константам предшествует заглавная буква N. Это необходимо независимо от того, поддерживает ли клиентское приложение формат Юникод. Если префикс N не указан, SQL Server выполнит преобразование строки в кодовую страницу, соответствующую параметрам сортировки базы данных, действующим по умолчанию. Любые символы, не входящие в эту кодовую страницу, будут утрачены.
Получение данных
Если клиентское приложение не поддерживает Юникод и извлекает данные в буферы с форматом, отличным от Юникода, клиент может извлекать или изменять только те данные, которые представлены кодовой страницей клиентского компьютера. Это означает, что символы ASCII можно извлечь всегда, потому что их представление одинаково во всех кодовых страницах, в то время как любые данные в формате, отличном от ASCII, зависят от преобразования кодовых страниц.
Предположим, что имеется приложение, которое разработано для США, но должно быть развернуто в Японии. Так как базы данных SQL Server поддерживают Юникод, в одних и тех же таблицах можно хранить и английский, и японский текст, несмотря на то, что приложение не было изменено для работы с текстом как с данными Юникод. Если приложение соответствует одному из двух вышеуказанных вариантов, японские пользователи смогут использовать приложение, работающее с иным форматом, для ввода и получения данных на японском языке, а американские пользователи смогут вводить и получать данные на английском языке. Все данные пользователей обеих категорий при этом сохраняются неизменными в том же столбце базы данных и представляются в формате Юникод. В этой ситуации можно создать поддерживающее Юникод приложение, формирующее отчеты на основе полного набора данных. Однако американские пользователи не смогут просматривать строки с данными на японском языке, потому что это приложение не сможет отображать символы, отсутствующие в их кодовой странице (1252).
Такое положение приемлемо, если пользователям не нужно просматривать записи пользователей другой категории. Если же пользователю приложения нужно просматривать или изменять записи с текстом, который не может быть представлен одной кодовой страницей, возможен только один вариант: изменить приложение так, чтобы оно могло работать с данными в формате Юникод.
Веб-приложения
Если клиентская программа создана на основе веб-технологий или подключается к странице ASP (Active Server Pages), клиентская 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 %>