Compartilhar via


Gerenciando a conversão de dados entre um servidor Unicode e um cliente não-Unicode

Este tópico descreve como preservar a integridade de dados de caracteres quando o armazenamento de dados do lado do servidor estiver em Unicode, mas o aplicativo do lado do cliente, que interage com os dados, usar uma página de código específica.

Entrada de dados

Quando dados não-Unicode forem enviados do cliente para serem armazenados no servidor em Unicode, os dados de qualquer cliente com qualquer página de código poderão ser armazenados corretamente se uma das seguintes condições for verdadeira:

  • Cadeias de caracteres são enviadas ao servidor como parâmetros de uma chamada de procedimento remoto (RPC).

  • As constantes de cadeia são precedidas da letra maiúscula N. Isso é solicitado independentemente se o aplicativo do lado do cliente reconhece ou não Unicode. Sem o prefixo N, o SQL Server converterá a cadeia para a página de código correspondente ao agrupamento padrão do banco de dados. Qualquer caractere não localizado nessa página de código será perdido.

Recuperação de dados

Se o aplicativo do cliente não for habilitado para Unicode e recuperar os dados em buffers não-Unicode, o cliente somente poderá restaurar ou modificar os dados que puderem ser representados pela página de código da máquina do cliente. Isso significa que os caracteres ASCII podem ser restaurados sempre, pois a representação dos caracteres ASCII é a mesma em todas as páginas de código, enquanto dados não-ASCII dependem da conversão página de código em página de código.

Por exemplo, suponha que você tenha um aplicativo que está sendo executado atualmente apenas nos Estados Unidos da América (E.U.A), porém, será implantado no Japão. Pelo banco de dados SQL Server reconhecer Unicode, tanto os textos em inglês quantos os textos em japonês podem ser armazenados na mesma tabela, mesmo que o aplicativo ainda não tenha sido modificado para lidar com texto como Unicode. Contanto que o aplicativo esteja de acordo com uma das duas opções anteriores, os usuários japoneses poderão usar o aplicativo não-Unicode para inserir e recuperar dados em japonês, e os usuários americanos poderão inserir e recuperar dados em inglês. Todos os dados de ambos os conjuntos de usuários são armazenados na mesma coluna do banco de dados e representados como Unicode. Nesta situação, um aplicativo de relatório habilitado para Unicode, que gera relatórios que abrangem o conjunto de dados completo, pode ser implantado. Entretanto, os usuários americanos não podem exibir as linhas em japonês, porque o aplicativo não pode exibir qualquer caractere que não exista na sua página de código (1252).

Essa situação poderia ser aceitável se os dois grupos de usuários não tivessem que exibir os registros uns dos outros. Se um usuário do aplicativo precisar exibir ou modificar os registros com um texto que não pode ser representado por uma única página de código, não há alternativa a não ser modificar o aplicativo a fim de que use Unicode.

Aplicativos com base na Web

Se o programa do lado do cliente tem como base a Web ou se conecta a uma página ASP (Active Server Pages), há especificações de metadados para a página HTML do lado do cliente e para a página ASP do lado do servidor. Essas especificações devem ser feitas para determinar como as cadeias de caracteres devem ser convertidas entre o servidor, o mecanismo ASP e o navegador do cliente.

Na página HTML do lado do cliente, o atributo META deve especificar que os dados do conjunto de caracteres devem ser convertidos para o esquema de codificação do cliente, especificando um código CHARSET. Por exemplo, a página HTML a seguir instrui o cliente a converter os dados de caractere para a página de código 950 (chinês tradicional), especificando big5 como o código CHARSET. Para visualizar os códigos de conjunto de caracteres para o atributo META, vá para este site da Microsoft.

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=big5">
<!-- 
     
-->
</HEAD>
<BODY>
<!--
   body
-->
</BODY>
</HTML>

Na página ASP do lado do servidor, você deve instruir o aplicativo ASP da Web sobre qual página de código do navegador do cliente está em uso. Você pode especificar a propriedade Session.CodePage ou a diretiva @CodePage. Esses métodos manipularam a conversão dos dados do servidor para o cliente, bem como ambas as solicitações GET e POST do cliente. Nos exemplos a seguir, ambos os métodos são usados para especificar a conversão para e da página de código do cliente, que é 950 (Chinês tradicional).

<%@ Language=VBScript codepage=950 %>
<%  Session.CodePage=950 %>

Finalmente, você deve se lembrar de colocar a letra N antes dos literais de cadeia de caracteres.