Compartir a través de


Administrar la conversión de datos entre un servidor Unicode y un cliente que no sea de Unicode

En este tema se describe cómo preservar la integridad de los datos de caracteres si el almacenamiento de datos del servidor se produce en Unicode, pero la aplicación cliente que interactúa con los datos utiliza una página de códigos específica.

Entrada de datos

Cuando se envían datos que no son de Unicode desde el cliente para almacenarlos en el servidor de Unicode, los datos de cualquier cliente con cualquier página de códigos se pueden almacenar correctamente si se cumple una de las siguientes condiciones:

  • Las cadenas de caracteres se envían al servidor como parámetros de una llamada a procedimiento remoto (RPC).

  • Las constantes de las cadenas están precedidas por la letra N mayúscula. Esta condición es obligatoria independientemente de que la aplicación cliente sea compatible con Unicode. Si no tiene el prefijo N, SQL Server convertirá la cadena en la página de códigos que corresponda a la intercalación predeterminada de la base de datos. Los caracteres que no se encuentren en esta página de códigos se perderán.

Recuperación de datos

Si la aplicación cliente no está habilitada para Unicode y recupera datos en búferes que no son de Unicode, un cliente sólo podrá recuperar o modificar los datos que estén representados en la página de códigos del equipo cliente. Esto significa que siempre se podrán recuperar los caracteres ASCII, ya que su representación es igual en todas las páginas de códigos, mientras que los datos que no son de ASCII dependen de la conversión que se realice de una página de códigos a otra.

Por ejemplo, supongamos que usted tiene una aplicación que actualmente se ejecuta sólo en los Estados Unidos (EE.UU.), pero que se implementa en Japón. Debido a que la base de datos de SQL Server es compatible con Unicode, se podrá almacenar tanto el texto en inglés como en japonés en las mismas tablas, aunque la aplicación aún no haya sido modificada para tratar el texto como Unicode. Siempre y cuando la aplicación cumpla con una de las dos opciones anteriores, los usuarios japoneses podrán utilizar la aplicación que no es de Unicode para indicar y recuperar datos en japonés, mientras que los usuarios estadounidenses podrán hacer lo propio con los datos en inglés. Todos los datos de ambos conjuntos de usuarios se almacenan intactos en la misma columna de la base de datos y se representan como de Unicode. En una situación como ésta, se podría implementar una aplicación de informe de Unicode que genere informes que abarquen todo el conjunto de datos. Sin embargo, los usuarios estadounidenses no podrán ver las filas de texto japonés, ya que la aplicación no permite mostrar caracteres que no existan en su página de códigos (1252).

Esta situación podría resultar aceptable si ninguno de los grupos de usuarios tiene necesidad de ver los registros del otro. Si el usuario de una aplicación tiene que poder ver o modificar registros con texto que no puede estar representado en una única página de códigos, no existe otra alternativa que modificar la aplicación para que ésta pueda utilizar Unicode.

Aplicaciones basadas en Web

Si el programa cliente está basado en Web o se conecta a Páginas Active Server (ASP), habrá especificaciones de metadatos en la página HTML cliente como en la página ASP del servidor. Se deben realizar estas especificaciones para determinar cómo deben convertirse las cadenas de caracteres entre el servidor, el motor ASP y el explorador del cliente.

En la página HTML cliente, el atributo META debe especificar que los datos del conjunto de caracteres deben convertirse en el esquema de codificación del cliente mediante la especificación de un código CHARSET. Por ejemplo, la siguiente página HTML indica al cliente que debe convertir los datos de caracteres a la página de códigos 950 (chino tradicional) especificando big5 como código CHARSET. Para ver los códigos de conjuntos de caracteres correspondientes al atributo META, vaya a este sitio web de Microsoft.

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

En la página ASP del servidor, debe indicar a la aplicación Web de ASP qué página de códigos está usando el explorador del cliente. Puede especificar la propiedad Session.CodePage o la directiva @CodePage. Estos métodos administrarán la conversión de datos del servidor al cliente y también las solicitudes de clientes GET y POST. En los siguientes ejemplos, se utilizan ambos métodos para especificar la conversión a y de la página de códigos del cliente, que es 950 (chino tradicional).

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

Por último, debe recordar anteponer la letra N (en mayúscula) a todos los literales de cadenas.