Migración a Unicode

Este artículo proporciona pautas para realizar la migración de software y de datos a Unicode. Comprende la planificación de la migración, y el diseño y la implementación de software habilitado para Unicode.

Se da por sentado que se tiene una comprensión básica de Unicode y de los principios de la codificación de caracteres. A continuación, enumeramos algunas fuentes de información acerca de estos temas:

¿Por qué migrar a Unicode?

Existen diversas razones por las que adoptar Unicode:

Se debe tener en cuenta que el simple cambio de codificación de caracteres de sus páginas a Unicode no eliminará todos los problemas de codificación de caracteres. En realidad, durante la migración existe un riesgo significativamente mayor de dichos errores, debido a que se deben convertir a Unicode los datos existentes y no siempre se conoce la codificación actual. Este documento brinda consejos sobre la manera de minimizar los riesgos y proporcionar mecanismos a fin de corregir problemas de conversión de caracteres.

Planificación de la migración

A fin de focalizar la migración a Unicode, es necesario comprender la utilización de las codificaciones de caracteres en su configuración actual y decidir sobre la utilización interna y externa de las codificaciones de caracteres del diseño basado en Unicode. Además, debe conocer el estado de compatibilidad de Unicode en los componentes de software en los que confía y, según el caso, la planificación de migración para dichos componentes. De este modo, podrá planificar la actualización del software que ha de basarse en Unicode y la conversión de los datos existentes a las codificaciones Unicode.

Asimismo, sería conveniente desarrollar un proyecto de migración a Unicode para mejorar la internacionalización en general. En particular, debe considerar si es posible utilizar las capacidades plurilingües de Unicode a fin de superar los obstáculos innecesarios entre los diversos públicos, culturas o idiomas. Tendría sentido tener un único sitio a nivel mundial con contenido plurilingüe compartido, a pesar de tener diversas interfaces de usuario localizadas, especialmente para aquellos sitios o aplicaciones que permitan la comunicación entre usuarios y que, por lo tanto, alojen o transmitan contenido generado por los usuarios.

Comprensión de la utilización actual de la codificación de caracteres

Como punto de partida, es necesario comprender en profundidad de qué manera opera la codificación de caracteres en su software actual. Identifique los componentes del software y los contenedores de datos: interfaz de usuario (front end), procesador de entrada (back end), almacenamiento, API, interfaces web, etc., y aclare la utilización de las codificaciones:

Es posible que la última pregunta sea sorprendente; sin embargo, reviste particular importancia. La falta de información correcta relacionada con la codificación de caracteres que se utiliza en los textos que ingresan desde la parte externa del sitio (por ejemplo, canales de contenidos o datos ingresados por los usuarios) o que ya se han incorporado a la recopilación de datos es un problema habitual que se debe tratar con especial atención. (En realidad, es necesario prestar atención a dichos casos incluso si no realizara la conversión a Unicode). Esta falta de información correcta puede expresarse de diferentes maneras:

A fin de manejar tales situaciones, se utiliza, en general, la detección de codificaciones de caracteres. Mediante la detección de codificación se intenta determinar la codificación utilizada en una secuencia de bytes en función de las características de la propia secuencia de bytes. En la mayoría de los casos, es un proceso estadístico que necesita largas secuencias de bytes de ingreso, aunque pueda mejorar su precisión mediante la utilización de otra información disponible para su aplicación. Debido al alto índice de errores, con frecuencia es necesario proporcionarle a las personas maneras de descubrir y corregir errores. Esto requiere mantener disponible la secuencia de bytes original para su posterior reconversión. Algunos ejemplos de bibliotecas de detección de codificaciones incluyen:

Verificación de fundamentos

Con frecuencia, la implementación de un software dependerá de otro software:

Necesitará verificar si el software del que depende admite Unicode o que, al menos, no le ocasione inconvenientes en su adopción. Por lo general, será necesario actualizarlo a versiones más recientes de plataformas subyacentes y, en algunos casos, será necesario migrar desde plataformas obsoletas a otras más recientes.

Decisión sobre la utilización de la codificación de caracteres para uso interno

Unicode ofrece tres formas de codificación: UTF-8, UTF-16 y UTF-32. En el caso del transporte por toda la red o del almacenamiento en archivos, UTF-8 por lo general funciona mejor debido a su compatibilidad con ASCII, mientras que los bytes similares a ASCII que se incluyen en el texto UTF-16 y UTF-32 son problemáticos para algunos dispositivos de red o herramientas de procesamiento de archivos. En el caso del procesamiento de memoria interna, las tres formas de codificación pueden ser útiles y, con frecuencia, la mejor elección dependerá de las bibliotecas y las plataformas de programación que utilice: Java, JavaScript, ICU y la mayoría de los API de Windows se basan en UTF-16, mientras que los sistemas Unix tienden a preferir UTF-8. El tamaño del almacenamiento rara vez constituye un factor que interviene en la decisión entre UTF-8 y UTF-16, debido a que cualquiera de ellos puede tener un mejor perfil de tamaño, que dependerá de la combinación de etiquetas de los idiomas europeos o asiáticos. El UTF-32 no resulta eficaz para el almacenamiento y, por lo tanto, se utiliza con muy poca frecuencia con dicho fin; sin embargo, es muy conveniente para el procesamiento. Además, algunas bibliotecas, por ejemplo, Java e ICU, proporcionan descriptores de acceso y API de procesamiento en términos de puntos de codificación UTF-32. La conversión entre las tres formas de codificación es rápida y segura; por lo tanto, la utilización de diferentes formas de codificación en distintos componentes de grandes sistemas de software es bastante factible y habitual.

El almacenamiento de texto cuya codificación de caracteres no es conocida con certeza constituye una excepción a la regla de sólo Unicode. Con frecuencia, dicho texto debe interpretarse mediante la utilización de detección de codificaciones de caracteres. Además, la detección de codificaciones de caracteres no es un proceso confiable. Por lo tanto, se deberán mantener activos los bytes originales (junto con la codificación de caracteres detectada), de manera que se pueda reconvertir el texto si una persona corrigiera la selección de codificación.

Decisión sobre la utilización de codificaciones de caracteres para interfaces externas

A fin de establecer una comunicación con el mundo fuera de la aplicación, se deberá utilizar UTF-8 siempre que sea posible. Sin embargo, existen diversas situaciones en las que no es posible controlar la codificación o es necesario comunicarse con sistemas que no son compatibles con UTF-8. A continuación, se describen recomendaciones para casos comunes:

En general, el texto entrante deberá convertirse a la codificación Unicode lo antes posible y, si se debe enviar el texto saliente en una codificación que no es Unicode, se deberá convertir de Unicode a otra codificación lo más tarde posible. Sin embargo, si no es posible determinar la codificación del texto entrante con certeza, entonces se deberá almacenar el texto original junto con la información relacionada con la codificación probable. De este modo, será posible tomar una acción correctiva en el caso de que la codificación fuera errónea.

Creación de una estrategia

Para el caso de aplicaciones o sitios simples, quizás se pueda cambiar todo el software a fin de basarlo en Unicode, convertir todos los datos a una codificación Unicode y pasar de una versión anterior a Unicode a la versión de Unicode en un instante. Sin embargo, diversos sitios o aplicaciones ofrecen interfaces externas, tienen grandes cuerpos de códigos y acumulan enormes conjuntos de datos; por consiguiente, su conversión constituye un gran proyecto con dependencias múltiples que se deben planificar cuidadosamente. A continuación, incluimos un análisis de los subproyectos probables:

Algunos de estos subproyectos se pueden ejecutar en paralelo o en un orden diferente, según la situación específica de su producto. Por ejemplo, es posible que la migración de la implementación de su producto se demore por dependencias en otros componentes de software que aún no hayan progresado lo suficiente en la migración. Por otro lado, se podrán migrar las bases de datos SQL a Unicode mucho antes, debido a que el componente de clientes del software de la base de datos aísla los clientes de la codificación utilizada en la base de datos y realiza la conversión de la codificación de caracteres cuando es necesario. La migración temprana de base de datos tiene beneficios: simplifica las pruebas debido a que la base de datos se puede probar independientemente del software que se esté utilizando, mientras que la realización de pruebas de software de mayor nivel típicamente requiere una base de datos y podrá permitirle combinar múltiples bases de datos por separado mediante la utilización de codificaciones preexistentes en una sola base de datos plurilingüe.

Diseño para Unicode

Especificaciones de codificaciones de caracteres

Las secuencias de bytes sólo se podrán interpretar correctamente como texto si se conoce la codificación de caracteres. Diversas aplicaciones se escriben de modo que sólo puedan moverse por secuencias de bytes sin nombrar la codificación de caracteres. Tal como se analizó anteriormente, esto siempre ha ocasionado problemas. No obstante, ha funcionado en diversos casos en los que todos los usuarios hablaban el mismo idioma o deseaban adaptarlo a algún contenido que se visualice de manera incorrecta en la página. Sin embargo, durante la transición a Unicode, cada idioma se manejará con al menos dos codificaciones, la codificación preexistente para ese idioma y UTF-8. Por consiguiente, la especificación de la codificación para cada secuencia de bytes será de vital importancia a fin de evitar una gran cantidad de errores de corrupción de datos.

Las codificaciones de caracteres se podrán especificar de diversas maneras:

Nombres de codificaciones de caracteres

Existe un estándar para nombrar las codificaciones de caracteres en Internet, el RFC 2978 y un registro de juego de caracteres IANA asociado. Sin embargo, el uso real con frecuencia es diferente. Diversas codificaciones tienen diferentes variantes o complementos que son compatibles con juegos de caracteres extendidos y con frecuencia los diferentes software utilizan nombres distintos para la misma codificación o el mismo nombre para diferentes codificaciones. Por ejemplo, el nombre ISO-8859-1 con frecuencia se utiliza para describir datos que en realidad utiliza la codificación Windows-1252. Esta última codificación (página del código 1252 de Microsoft Windows) es muy similar a la ISO-8859-1, pero le asigna caracteres gráficos a la extensión de bytes entre 0x80 y 0x9F. Diversas aplicaciones Web (por ejemplo, exploradores, motores de búsqueda, etc.) procesan el contenido que contiene la etiqueta ISO 8859-1 como si en cambio utilizara la codificación Windows-1252, debido a que, con fines prácticos, Windows-1252 es un "súper set" de ISO 8859-1. Otras aplicaciones, tales como conversores de codificación (como iconv o ICU) son bastante literales; por consiguiente, se deberá especificar el nombre de codificación correcta a fin de obtener los resultados adecuados.

Determinación de la codificación de caracteres

Cada vez que una secuencia de bytes se interprete como texto y se procese, se deberá conocer su codificación de caracteres. En diversos casos, la determinación de la codificación de caracteres es tan trivial que ni siquiera se la considera, por ejemplo, cuando se procesa una secuencia en un lenguaje de programación que especifica que las secuencias están codificadas en UTF-16. Sin embargo, en otros casos, no existe una clara especificación que indique que la codificación de caracteres se encuentra disponible o que el texto proviene de una fuente respecto de la cual no se puede confiar completamente que proporcionará la especificación correcta. En dichos casos, se requiere un proceso más complicado a fin de determinar la codificación de caracteres y permitir la corrección posterior de los errores cometidos:

Declaración y selección de codificación de caracteres

Cuando envíe texto, será necesario seleccionar la codificación de caracteres adecuada en función del formato de datos y del destinatario. La sección Decisión sobre la utilización de la codificación de caracteres para interfaces externas describe la utilización de la codificación en función de los formatos de datos. En la mayoría de los casos, se recomienda la codificación Unicode. Sin embargo, existen dos excepciones principales:

Independientemente de la codificación utilizada, la codificación de caracteres se deberá especificar de manera no ambigua mediante la utilización de uno de los mecanismos descritos en la sección Especificaciones de la codificación de caracteres.

Conversión de codificaciones de caracteres

Cuando se espera que el texto se encuentre en una codificación de caracteres en primer lugar y en una codificación de caracteres diferente en segundo lugar, será necesario realizar una conversión de codificación. ICU e iconv son algunas de las bibliotecas utilizadas de forma habitual para la conversión de codificaciones de caracteres; sin embargo, algunas plataformas, tales como Java y Perl, contienen sus propias bibliotecas de conversión.

Cuando utilice bibliotecas, es importante utilizar los nombres de codificación correctos que corresponden a la biblioteca específica. Para obtener más información, consulte la sección Nombres de codificaciones de caracteres.

Existen problemas de conversión específicos que pueden afectar algunos productos en particular:

Normalización

Algunos caracteres tienen más de una manera de estar representados en Unicode. Unicode define diversas maneras de eliminar estas diferencias cuando no afectan el procesamiento de textos. Para obtener más información acerca de la normalización, consulte CharMod-Norm.

Unicode no indica el momento de utilizar un formulario de normalización de Unicode específico. Sin embargo, existen diversos procesos que funcionan mejor si el texto está normalizado, en particular, aquellos procesos relacionados con la comparación de textos tales como el procesamiento de expresión regular, la búsqueda y la colación. Algunas bibliotecas que realizan estos procesos ofrecen normalización como parte del proceso; de otro modo, se deberá asegurar de que el texto esté normalizado antes de utilizar estos procesos. En general, para aplicaciones web, se recomienda la forma C de normalización (NFC). Sin embargo, algunos procesos, tales como los nombres de dominio internacionalizados, utilizan otras formas de normalización.

Algunos idiomas requerirán la normalización antes del procesamiento debido a que los diferentes métodos de ingreso pueden generar secuencias distintas de puntos de codificación Unicode. El idioma vietnamita es un buen ejemplo, debido a que la disposición del teclado vietnamita en Windows 2000 en adelante proporciona secuencias de caracteres diferentes a las que proporciona la mayoría de otros software de entrada de datos vietnamita. Existen problemas similares con una gran cantidad de idiomas africanos, por ejemplo, el yoruba.

Problemas relacionados con el tamaño del texto

El almacenamiento de texto como Unicode con frecuencia ocupa más espacio que su almacenamiento en codificaciones preexistentes. La cantidad exacta de expansión dependerá del idioma y del texto en particular involucrado. Las expansiones de algunas codificaciones comunes podrían ser las siguientes:

Codificación de fuente

Idiomas

UTF-8

UTF-16

ASCII Inglés, malayo, ... 0% 100%
ISO-8859-1 Europeo occidental 10% 100%
ISO-8859-7, texto plano Griego 90% 100%
ISO-8859-7, 50% de etiquetas Griego 45% 100%
TIS-620, texto plano Tailandés 190% 100%
TIS-620, 50% de etiquetas Tailandés 95% 100%
EUC-KR, texto plano Coreano 50% 5%
EUC-KR, 50% de etiquetas Coreano 25% 55%

A nivel de macros, en realidad esto no es tan importante. En la actualidad, en el ancho de banda de red y en el almacenamiento predominan los videos, las imágenes y los archivos de sonido, mientras que el texto consume sólo una fracción. Podría impactar en aquellos sistemas de almacenamiento que almacenen sólo texto. Si el tamaño del texto es en realidad un inconveniente, se podrá reducir mediante la compresión.

Sin embargo, a nivel de microcomputadora, el aumento en el tamaño de almacenamiento plantea diversas implicancias:

Utilización de bibliotecas

Cuando se trabaja con Unicode, a menudo es conveniente utilizar bibliotecas de software especializadas en la compatibilidad con Unicode. Es posible que las bibliotecas anteriores no tengan plena compatibilidad con Unicode o que no sean compatibles en absoluto.

Declaración y determinación del idioma

Mientras que Unicode permite la utilización de documentos y aplicaciones plurilingües, existen diversos procesos que requieren tener conocimientos acerca del idioma real que se utiliza. Dichos procesos varían desde simplemente expresarlo en mayúsculas hasta buscar y verificar la ortografía.

Por lo tanto, los API basados en Unicode deberán permitir la especificación del(de los) idioma(s) utilizado(s) cada vez que sea necesario dicho conocimiento. Además, se deberá registrar el idioma del contenido generado por el usuario cuando sea posible. En aquellos casos en los que no sea posible captar el idioma desde la fuente, podría ser útil tener una biblioteca de detección de idiomas.

A fin de ayudar a otras aplicaciones, se deberá declarar el idioma del contenido web, cuando se lo conozca, mediante la utilización del encabezado Content-Language de HTTP o los atributos lang de HTML/XML.

Problemas relacionados con las fuentes

En aquellos sitios web que utilicen Unicode, se deberá tener más cuidado con la especificación de fuentes que en los sitios web que utilicen codificaciones preexistentes. Existen diversos idiomas que tienen tradiciones de escritura específicas o únicas, aún cuando comparten un script con otros idiomas. En otros casos, la compatibilidad de las fuentes puede ser un obstáculo debido a la necesidad de las fuentes de mostrar scripts específicos que no estén instalados en la mayoría de los sistemas.

Por ejemplo, los sistemas de escritura china y japonesa comparten una gran cantidad de caracteres, pero tienen diferentes tradiciones tipográficas; por consiguiente, las fuentes chinas en general no se pueden utilizar para los textos japoneses y viceversa. Por ejemplo, aquí se muestran los mismos caracteres que utilizan fuentes chinas y japonesas (junto con el código HTML utilizado para generar la captura de pantalla):

Imagen de los mismos caracteres ideográficos de Unicode, pero con dos representaciones de glifos diferentes.

<span style="font-size:3em;font-family:sans-serif;">
<span lang="zh-Hans-CN" style="font-family: simsun, hei, sans-serif;">直</span>
<span lang="ja" style="font-family: 'ms gothic', osaka;">直</span>
</span>

Cuando se utilizan codificaciones preexistentes, los exploradores frecuentemente adivinan el idioma desde la codificación y eligen una fuente adecuada.

Debido a que Unicode es compatible con los idiomas chino y japonés, no es posible aplicar este recurso con páginas codificadas con Unicode y, como resultado, se podrá obtener una fuente inadecuada o incluso una combinación inadecuada de fuentes utilizadas para visualizar el contenido.

Una solución consiste en controlar el idioma utilizado e informar tanto del idioma como de las fuentes preferidas del idioma al explorador. En el caso de las páginas monolingües, la utilización de una hoja de estilo específica del idioma constituye un enfoque simple y eficaz. En el caso de las páginas plurilingües, se deberá utilizar el atributo lang en las etiquetas HTML a fin de identificar el idioma; algunos exploradores utilizan esta información como guía para seleccionar la fuente correcta. A fin de obtener el control preciso de la fuente, podrá utilizar además clases para la identificación del idioma y selectores de clases en la hoja de estilo para configurar la fuente. Internet Explorer no es compatible con los selectores pseudo-clase de lenguaje CSS 2.1 que realizan directamente selecciones basadas en el(los) atributo(s) del idioma; por consiguiente, su utilidad es limitada. Consultar Resultados de las pruebas: Estilos que dependen del idioma.

Migración de datos

En diversas situaciones, la conversión de datos asociada a un producto será el mayor desafío al migrar el producto a Unicode. Por ejemplo, algunas aplicaciones poseen una cantidad específica de bases de datos o acceden a ellas, algunas de las cuales son administradas por motores de bases de datos como Oracle o MySQL. Otras utilizan mecanismos de acceso y formatos de archivo personalizados. Estas bases de datos, independientemente de su tipo, deben migrarse para ser compatibles con Unicode.

La migración de datos a Unicode es además un buen momento para considerar la consolidación de bases de datos que previamente estaban separadas debido a diferentes codificaciones de caracteres. La utilización de una única base de datos a nivel mundial o de sólo algunas bases de datos para las principales regiones puede simplificar la implementación y el mantenimiento, y puede permitir compartir contenidos entre mercados diferentes; por consiguiente, Unicode es la herramienta ideal para estas situaciones debido a que puede representar texto en todos los idiomas. Sin embargo, cuando se realice la consolidación se deberá tener en cuenta que permanecerán vigentes otras restricciones relacionadas con los contenidos compartidos, por ejemplo, disponibilidad de idiomas, condiciones de licencias y restricciones culturales o legales del material de publicación vinculado con contenidos de política, religión, sexo y violencia.

Las estrategias de conversión de datos variará en función de varios factores:

Debido a las variaciones en estos factores, no existe una receta simple que pueda seguirse para convertir las bases de datos de un producto. A continuación, se describe un análisis de algunas consideraciones comunes; sin embargo, en general, será necesario crear un plan de conversión adecuado para cada producto. Dicho plan probablemente tendrá diversas fases de análisis, conversión con verificación de resultados de la conversión y recuperación en caso de errores.

Manejo de problemas relacionados con el tamaño del texto

Como se indica en la sección Problemas relacionados con el tamaño del texto (arriba), en general, la conversión de texto a Unicode genera requisitos de almacenamiento expandidos; por consiguiente, es necesario considerar cuidadosamente si se debe medir la longitud del texto en bytes, caracteres o unidades de código UTF-16. Con el propósito de reducir el impacto del aumento en los tamaños de campos, puede tener sentido cambiar los campos CHAR en las bases de datos SQL a VARCHAR; por consiguiente, la base de datos podrá distribuir la cantidad de espacio que necesite.

En el caso de la medición de textos, algunas bases de datos no brindan opciones. Por ejemplo, MySQL siempre mide en términos de caracteres BMP de Unicode, cuyo resultado es de 3 bytes por carácter. Otros, como Oracle, permiten la selección entre semántica de bytes o caracteres. Otros sistemas de almacenamiento que imponen límites de tamaño probablemente se miden en bytes.

Durante la migración, que implica la conversión de la codificación, se deberá tener cuidado a fin de evitar el truncamiento. Desafortunadamente, en algunos casos es posible que no pueda hacerlo debido a limitaciones externas, tales como el límite de Oracle de 30 bytes para los nombres de objetos de esquemas en diccionarios de datos (la utilización de caracteres ASCII para nombres de esquemas ayuda a evitar este inconveniente). En esos casos, al menos se deberá asegurar de truncar en un límite de carácter.

También: tenga en cuenta que puede haber expansión de texto debido a la traducción. Consulte Tamaño del texto en la traducción.

Identificación de datos ASCII

Vale la pena identificar los conjuntos de datos (archivos, tablas de bases de datos, columnas de bases de datos) que se encuentran completamente en ASCII. Si la codificación Unicode deseada es UTF-8, no será necesario realizar la conversión para dichos conjuntos de datos debido a que las secuencias de bytes de ASCII son idénticas a las secuencias de bytes UTF-8 correspondientes. Además, los índices sobre los campos de texto ASCII son también válidos para los campos de texto UTF-8 o UTF-16 correspondientes, a menos que se basen en órdenes de clasificación con distinción de idiomas. Sin embargo, se deberá ser estricto al identificar los conjuntos de datos ASCII. El término "ASCII" frecuentemente se utiliza erróneamente para aquello que no es ASCII, tal como el texto plano (en cualquier codificación) o el texto de codificaciones Windows-1252 o ISO 8859-1. Además, se han diseñado diversas codificaciones de caracteres a fin de encajarlos en secuencias de bytes de 7 bits y, al mismo tiempo, representar juegos de caracteres de ASCII completamente diferentes.

A fin de verificar que el conjunto de datos se encuentra efectivamente en ASCII, controle lo siguiente:

Manejo de datos desconocidos

Como se mencionó anteriormente, en algunos casos las bases de datos contienen texto con codificación desconocida. La detección de codificación de caracteres se podrá utilizar para tener una idea de la codificación; sin embargo no es un proceso confiable. A fin de manejar los datos desconocidos, será necesario seguir algunos pasos adicionales:

Por cuestiones de simplicidad, las siguientes secciones asumen que la codificación se puede determinar con certeza y, por consiguiente, que la conversión es un evento que ocurre sólo una vez. Si este no fuera el caso, será necesario ajustar las estrategias.

Referencias de caracteres numéricos con sentido

Las bases de datos que contienen contenidos generados por los usuarios frecuentemente incluyen referencias de caracteres numéricos (NCR) para aquellos caracteres que no son ASCII y que hayan ingresado los usuarios, por ejemplo, "&#x0152;" (Œ) o "&#x20AC;" (€). Diversos exploradores generan las NCR cuando los usuarios ingresan texto en campos de formularios que no se pueden expresar con la codificación de caracteres del formulario. Las NCR funcionan correctamente si, posteriormente, el texto se vuelve a visualizar en HTML. Sin embargo, no funcionan con otros procesos debido a que no coinciden con el texto que representan en la búsqueda, se clasifican en el lugar equivocado o son ignorados por la conversión de mayúsculas y minúsculas. Por consiguiente, la migración a Unicode es además un buen momento para convertir las NCR a los caracteres Unicode correspondientes. Sin embargo, deberá tener cuidado a fin de evitar conversiones que cambien el significado del texto (como lo haría la conversión de "&amp;" a "&") o la conversión a texto que se hubiera filtrado por razones de seguridad.

Utilización de la BOM

Durante la migración de las codificaciones preexistentes a Unicode, es habitual utilizar codificaciones preexistentes y Unicode en paralelo. Además, deberá poder distinguirlas. En el caso general, se requieren especificaciones de codificaciones de caracteres. Sin embargo, si es necesario distinguir entre sólo un tipo de codificación preexistente específica (por ejemplo, la codificación predeterminada anterior del sitio) y UTF-8, podrá utilizar la marca de orden de bytes Unicode (BOM) como prefijo a fin de identificar las secuencias UTF-8. Esto es particularmente útil si no se hubiera previsto la especificación de la codificación de caracteres, por ejemplo, en archivos de texto plano o en cookies. La BOM en UTF-8 representa la secuencia de bytes 0xEF 0xBB 0xBF, la cual es muy improbable que tenga sentido en una codificación preexistente.

El lector de datos que identifica su codificación de este modo leerá los primeros tres bytes a fin de determinar la codificación. Si los bytes coinciden con la BOM, se eliminarán los tres bytes y se devolverá el contenido restante a UTF-8. Si no coinciden, todo el contenido se convertirá de la codificación preexistente a UTF-8. Sin embargo, esta eliminación no es automática e interfiere con algunas plataformas o idiomas. Por ejemplo, los archivos PHP que comienzan con una BOM no serán interpretados adecuadamente por el procesador PHP. Por consiguiente, es mejor limitar este recurso a partes conocidas de su sitio o código.

Conversión de archivos de texto plano

Los archivos de texto plano que utilizan una única codificación de caracteres se convierten fácilmente. Por ejemplo, la herramienta iconv está disponible en la mayoría de los sistemas Unix/Linux. En aquellos sistemas que no la tienen, un enfoque conveniente consiste en instalar un kit de desarrollo en Java y utilizar su herramienta native2ascii:

native2ascii -encoding _''sourceencoding'' ''sourcefile'' | native2ascii -reverse -encoding ''targetencoding'' > ''targetfile''

Para cantidades reducidas de archivos, también es posible utilizar editores: TextPad en Windows, TextEdit en Mac o jEdit en cualquier plataforma son sólo algunos de los editores que pueden convertir archivos. Tenga en cuenta que algunos editores, por ejemplo, Notepad, prefieren prefijar los archivos Unicode con una marca de orden de bytes (BOM) de Unicode, lo cual es innecesario para el caso de archivos UTF-8 y puede ocasionar problemas con el software que lee los archivos.

Conversión de archivos estructurados

En este contexto, archivos estructurados significa cualquier archivo, independientemente de las bases de datos SQL, que tengan componentes que pudieran tener codificaciones diferentes o que tengan limitaciones de longitud. Por ejemplo: archivos de registro, donde las entradas diferentes pueden utilizar codificaciones diferentes; correo electrónico, donde los diferentes encabezados y los componentes del cuerpo MIME pueden utilizar codificaciones diferentes y los encabezados tienen limitaciones de longitud; y las cookies, que frecuentemente son tratadas como si tuvieran campos múltiples. Para dichos archivos, se debe convertir cada uno de los componentes por separado y se deben tratar las limitaciones de longitud de cada componente por separado.

Conversión de bases de datos SQL

Una base de datos SQL en realidad contiene dos componentes: Un componente del servidor, que en realidad maneja los datos, y un componente cliente, que interactúa con otro software (por ejemplo, PHP o tiempo de ejecución Java) y se comunica con los componentes del servidor. La codificación de caracteres que utiliza el cliente para comunicarse con el servidor se puede configurar en forma separada a las codificaciones de caracteres que utiliza el servidor; éste realizará la conversión si fuera necesario.

Dependiendo del tamaño de la base de datos y de sus requisitos de tiempo de funcionamiento, es posible utilizar diversas estrategias de conversión:

Desafortunadamente, el lenguaje SQL y la documentación a menudo utilizan el término "juego de caracteres" para la codificación de caracteres e ignoran el hecho de que UTF-8 y UTF-16 (e incluso GB18030) son codificaciones diferentes que pertenecen al mismo juego de caracteres.

Temas específicos de Oracle

Oracle tiene compatibilidad general con Unicode a partir de la versión 8; sin embargo, la compatibilidad con los caracteres complementarios sólo está disponible con la versión 9r2 y la compatibilidad con Unicode 3.2 sólo está disponible a partir de la versión 10. Además, la utilización de los tipos de datos NCHAR y NVARCHAR en versiones anteriores a la versión 9 es bastante complicada. Oracle ofrece pautas de compatibilidad de globalización (Globalization Support Guides) integrales para las versiones 9r1, 9r2, 10r1 y 10r2. Los capítulos relacionados con la Migración de juegos de caracteres (Character Set Migration) y con el Escáner de juegos de caracteres (Character Set Scanner) son particularmente relevantes.

La codificación de caracteres seleccionada de la base de datos de Oracle se configura para toda la base de datos, incluidos los datos, los esquemas y las consultas con una única excepción: los tipos NCHAR y NVARCHAR siempre utilizan Unicode. Se ofrecen diferentes codificaciones Unicode para las bases de datos en general y para los tipos de datos NCHAR y NVARCHAR. En el caso de la base de datos, existen UTF-8 correctos con el nombre AL32UTF8 y una variante de UTF8 que codifica los caracteres complementarios como dos secuencias de 3 bytes. Para bases de datos que migran a Unicode, deberá utilizar AL32UTF8 (las bases de datos que ya utilizan UTF8 podrán seguir utilizándolas; la diferencia entre estas codificaciones podrá afectar a la colación y la indexación dentro de la base de datos, pero en general, no importará demasiado debido a que la interfaz del cliente convertirá el UTF8 a UTF-8 correcto). Para los tipos de datos NCHAR y NVARCHAR, el UTF-16 estará disponible con el nombre AL32UTF8, junto con la variante de codificación UTF8. La semántica de las especificaciones de longitud para los tipos de datos CHAR, VARCHAR2 y LONG se podrá configurar mediante la utilización de NLS_LENGTH_SEMANTICS, con semántica de bytes predeterminada, mientras que los tipos de datos NCHAR y NVARCHAR utilizarán siempre la semántica de caracteres.

A fin de obtener una conversión adecuada entre las codificaciones utilizadas dentro de la base de datos hacia la codificación del cliente, es esencial definir la variable del entorno NLS_LANG del lado del cliente. Esta variable describe el idioma, el territorio y la codificación que es utilizada por el cliente OS. Oracle tiene muchas configuraciones diferentes a fin de especificar el comportamiento que distingue ubicaciones en la base de datos; éstas generalmente se pueden configurar por separado desde la codificación en tanto y en cuanto la codificación pueda representar los caracteres de la ubicación seleccionada. Unicode es compatible con todas las ubicaciones.

Oracle proporciona compatibilidad incorporada para diversas estrategias de conversión. La herramienta Escáner de juegos de caracteres ayuda a identificar los posibles problemas relacionados con la conversión y el truncamiento en el análisis previo a la conversión. Los servicios de exportación e importación ayudan a implementar una estrategia de descarga y recarga de datos. El agregado de columnas Unicode es sencillo debido a que los tipos de datos NCHAR y NVARCHAR son compatibles con Unicode independientemente de la codificación de la base de datos. La conversión en el lugar con una etiqueta de codificación será posible si la base de datos en sí misma no interpreta el texto. Se podrá utilizar la declaración ALTER DATABASE CHARSET a fin de informar la codificación real a la base de datos una vez que se haya completado la conversión.

Existen informes en los cuales los tipos de datos NCHAR no son compatibles en la interfaz de llamadas de Oracle PHP.

Temas específicos de MySQL

A fin de obtener compatibilidad Unicode en las bases de datos MySQL, necesitará utilizar MySQL 4.1 o una versión superior. Para obtener información relacionada con la actualización a esta versión y con los posibles problemas relacionados con la compatibilidad, consulte Actualización de juegos de caracteres de MySQL 4.0. Para obtener más información relacionada con la compatibilidad de codificaciones de caracteres en MySQL, consulte el capítulo denominado Compatibilidad de juegos de caracteres de la documentación de MySQL. La codificación de caracteres del contenido de la base de datos se podrá configurar por separado en el nivel del servidor, base de datos, tabla o columna. En aquellos casos en los que no esté configurado de manera explícita, se heredará desde el próximo nivel superior.

La codificación predeterminada de MySQL es latin1, es decir, ISO-8859-1. Las codificaciones compatibles de Unicode se denominan utf8 y ucs2. Generalmente, la codificación de caracteres recomendada para MySQL debe ser utf8. Ambosutf8 y ucs2 se limitan a los caracteres del Plano Plurilingüe Básico (BMP) de Unicode; por consiguiente, no existe compatibilidad con los caracteres complementarios de MySQL. Como resultado, utf8 no es una implementación de cumplimiento total de UTF-8 (aunque es adecuada para la mayoría de los propósitos). Los tipos de datos NCHAR y NVARCHAR siempre utilizan utf8.

Se interpretará que las especificaciones de longitud para los tipos de datos de caracteres se encuentran en los caracteres Unicode BMP; por consiguiente, la especificación CHAR(5) CHARACTER SET utf8 reservará 15 bytes. Los metadatos, por ejemplo, nombres de usuarios, siempre se almacenan en UTF-8; por consiguiente, es posible utilizar nombres que no sean latinos. La codificación de caracteres para la conexión con el cliente se puede configurar por separado en función del cliente, la conexión y los resultados; sin embargo, para evitar confusión, es mejor configurarlas todas juntas mediante SET NAMES 'utf8'. La codificación ucs2 no es compatible con la conexión del cliente, de modo que tampoco existe una buena razón para utilizar esta codificación para el contenido de la base de datos.

La colación se relaciona con la codificación de caracteres; por consiguiente, siempre se deberá configurar en el mismo momento que la codificación. Si se utiliza utf8 sin especificar la colación, se utilizará la colación utf8_general_ci predeterminada. Este es un algoritmo de colación preexistente que no es adecuado para ningún idioma en particular. La colación utf8_unicode_ci es una mejor colación preexistente, debido a que implementa el Algoritmo de Colación Unicode (UCA) y funciona con diversos idiomas que no son compatibles específicamente con ninguna colación denominada. Además, podrá seleccionar una de las colaciones UTF-8 denominadas por el idioma a fin de obtener las colaciones específicas y "orientadas" a los idiomas en función del UCA. Consulte la lista de colaciones de los Juegos de caracteres Unicode. MySQL es compatible con la función CONVERT, que permite la conversión de los resultados de una consulta de una codificación a la otra. Además, MySQL es compatible con la conversión en el lugar de una codificación a la otra mediante la utilización de la declaración ALTER: ALTER TABLE table CONVERT TO CHARACTER SET utf8 COLLATE collation;.

En algunos casos, es posible que la codificación de una columna se declare de manera incorrecta en el esquema; por ejemplo, los datos UTF-8 pudieron haberse guardado en una base de datos MySQL con el nombre de codificación latin1 antes de que MySQL realmente fuera compatible con UTF-8, o se pudieron haber etiquetado datos en japonés como sjis cuando en realidad se utilizaba la versión Windows de Shift-JIS, la cual MySQL denomina cp932 (para obtener más información sobre este caso, consultar Juego de caracteres cp932). En esos casos, se puede etiquetar nuevamente la columna sin realizar la conversión mediante el cambio de su tipo a un equivalente binario (BINARY, VARBINARY, BLOB) y, a continuación, volver a los caracteres (CHAR, VARCHAR, TEXT) con el nombre de codificación correcto, por ejemplo, para una columna TEXT: ALTER TABLE table CHANGE column column BLOB; ALTER TABLE table CHANGE column column TEXT CHARACTER SET utf8 COLLATION collation;. Se puede y se deben cambiar a la vez todas las columnas de una tabla a fin de minimizar los gastos indirectos derivados de la reconstrucción de la tabla.

Nota: De manera predeterminada, el cliente PHP de MySQL especifica latin1 como la codificación de conexión para cada conexión nueva; por consiguiente, será necesario insertar la declaración SET NAMES 'utf8' para cada conexión nueva.

Conversión de nombres de archivos

Diversos sistemas operativos de servidores (por ejemplo, !FreeBSD, Red Hat) almacenan nombres de archivos como secuencias de bytes simples, cuya interpretación depende de los procesos de niveles superiores. Los procesos de servidores podrán interpretar las secuencias de bytes en función de la codificación de caracteres de la ubicación en la que se ejecuten o simplemente trasladarlas a los procesos de clientes. Por lo tanto, la codificación real deberá estar determinada por la evaluación de la manera en la que se creó el nombre, lo que se podría realizar mediante la página web en la codificación predeterminada del usuario o del sitio en particular. Si no es definitivo, se podrá utilizar también la detección de codificación de caracteres.

Si la codificación del nombre de un archivo se puede determinar con certeza, se podrá convertir a UTF-8 y se podrá utilizar la marca de orden de bytes para marcarla como convertida. Si la codificación es incierta, es posible que sea necesario crear una base de datos paralela al sistema de archivos a fin de registrar la codificación detectada y posiblemente la versión UTF-8; por consiguiente, se podrá guardar el nombre del archivo original a fin de realizar una corrección posterior de la codificación.

Pruebas con Unicode

La prueba de compatibilidad de Unicode con el texto ASCII no es útil. Asegúrese de probar el manejo de datos de usuarios con texto en una variedad de idiomas que serán compatibles:

Las pruebas con estos idiomas requerirán que configure su computadora a fin de obtener compatibilidad con éstos. El capítulo denominado Aprenda a escribir en japonés en el teclado y en otros idiomas le brinda información acerca de cómo hacer esto en todos los sistemas operativos comunes.

A fin de demostrar que se ha manejado correctamente el texto en la interfaz de usuario de su aplicación, la pseudo-localización es una estrategia de prueba útil. Las herramientas de pseudo-traducción pueden reemplazar automáticamente los caracteres ASCII en los mensajes de interfaces de usuarios con caracteres latinos de ancho completo equivalentes de la extensión Unicode U+FF01 a U+FF5E (inglés -> English) o con letras variantes que incluyen marcas diacríticas de la extensión latina completa (inglés -> Ëñgłíšh).

A continuación, se describen algunos de los problemas a los cuales se debe prestar especial atención cuando se prueba la compatibilidad con Unicode:

Algunas de las pautas correspondientes a las pruebas de internacionalización y compatibilidad con Unicode están disponibles en: Conceptos básicos sobre pruebas internacionales