Migración a 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:

• En la especificación del formato: la especificación del formato de datos podrá especificar la codificación de caracteres directamente o mediante un mecanismo de determinación simple a fin de detectar la codificación de caracteres al observar el comienzo de la secuencia de bytes. Por ejemplo, la especificación de la clase de Java String , que especifica el UTF-16, y la especificación JSON, que prescribe la utilización de codificaciones Unicode y la manera de distinguirlos.

• Como parte de la secuencia de bytes: La especificación del formato de datos podrá proporcionar un mecanismo para especificar la codificación de caracteres como parte de la secuencia de bytes. La especificación XML lo hace de manera elegante mediante la utilización de la declaración de codificación, la especificación de HTML lo hace de manera menos elegante mediante la utilización de la etiqueta meta. En el caso de aquellos formatos de datos que permiten dicha especificación, los datos podrán contener la especificación de la codificación a menos que la secuencia de bytes se encuentre en UTF-8 y la especificación asegure la detección correcta de UTF-8 (como para XML). En el caso de los archivos HTML, la etiqueta meta que especifica el tipo de contenido y la codificación de caracteres deberá ser el primer subelemento del elemento head y no deberá estar precedido de caracteres que no sean ASCII.

• Datos externos a la secuencia de bytes: en muchos casos, el contenedor de la secuencia de bytes proporciona la especificación de la codificación. Algunos ejemplos incluyen HTTP o MIME, donde el campo de encabezado Content-Type puede especificar la codificación de caracteres y las bases de datos, y donde se especifica la codificación como parte de la configuración de la base de datos o del esquema. Nuevamente, si existen dichas capacidades, los datos textuales las deberían utilizar. En algunos casos, por ejemplo, al enviar HTML por HTTP, la especificación de la codificación externa podrá duplicar a aquella que fuera parte de la secuencia de bytes, lo cual es beneficioso porque los exploradores prefieren el encabezado HTTP, mientras que la etiqueta meta es la única especificación que permanecerá si se guarda el archivo en un disco.

• Especificaciones de interfaces: las especificaciones de las interfaces que aceptan o devuelven secuencias de bytes sin ninguna especificación de la codificación de caracteres indicada anteriormente puede (y debe) especificar la codificación de caracteres utilizada. La especificación puede ser absoluta o relacionada con la configuración del entorno. Por ejemplo, algunas bibliotecas proporcionan funciones que aceptan o devuelven secuencias en UTF-8, mientras que otras aceptan o devuelven secuencias codificadas en alguna codificación preexistente.

• Por contexto: La codificación de caracteres puede derivar del contexto en el cual se produce la secuencia de bytes. Por ejemplo, los exploradores generalmente envían datos de formularios en la codificación de caracteres de la página web que contiene el formulario. Es una forma de especificación muy débil debido a que la secuencia de bytes con frecuencia se transfiere fuera del contexto, por ejemplo, a los archivos de registro, donde ya no es posible reconstruir la codificación. Además, los usuarios a veces cambian la codificación del explorador de modo que la codificación de los datos del formulario devuelto ya no coincide con la codificación de la página generada por la aplicación web. La utilización de UTF-8 constituye una manera de minimizar el daño resultante de esta débil forma de especificación de la codificación debido a que elimina la necesidad de los usuarios de cambiar la codificación del explorador y debido a que la detección de la codificación de caracteres funciona mejor con UTF-8 que con la mayoría de las otras codificaciones.

• Mediante acuerdo externo: en caso de que no se aplique ninguno de los casos anteriores, por ejemplo, archivos de texto plano, se deberá realizar un acuerdo externo relacionado con la codificación. Tal acuerdo podrá, por ejemplo, ser parte de un acuerdo de licencia de un canal de contenidos. Los primeros cuatro mecanismos son mejores que los últimos dos y deben preferirse siempre que sea posible. Cualquiera de ellos será mejor que no especificar la codificación en absoluto.

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:

• Interprete todas las especificaciones de codificaciones de caracteres disponibles. Si existe una especificación disponible confiable, no debe hacer nada más.
• Si existe una especificación de la codificación de caracteres disponible pero no es completamente confiable, deberá validarla. La validación es posible para aquellas codificaciones que imponen restricciones en secuencias de bytes válidas, por ejemplo, UTF-8, EUC-KR e ISO 2022-JP. Si se convierte el texto en una codificación diferente para procesamiento interno, con frecuencia la validación sólo será un efecto secundario de la conversión y no será necesario realizar ninguna conversión, aunque si se requerirá aún la validación. Si la secuencia de bytes es no válida para la codificación especificada, deberá rechazar el ingreso y solicitar al proveedor la ejecución del ingreso correcto (en el caso de XML, la especificación requerirá el rechazo). Sin embargo, en aquellos casos en los que no tiene control sobre los datos, se deberá continuar con el paso siguiente.
• Si no existe especificación de la codificación de caracteres disponible o si se produjo un error en la validación, utilice la detección de la codificación de caracteres a fin de detectar la codificación probable.
• Si la codificación de caracteres se determinó mediante la detección (en lugar de la especificación y la validación), mantenga la secuencia de bytes original a fin de poder reconvertirla en una codificación de caracteres diferente en lo sucesivo. Deberá proporcionar un mecanismo de interfaces de usuarios que le permita a los usuarios anular la codificación de caracteres especificada o detectada y rehacer la conversión. Almacene la codificación de caracteres utilizada más recientemente que corresponde a la secuencia de bytes junto con la secuencia de bytes, en especial si el usuario la ha seleccionado, a fin de evitar rehacer de manera innecesaria todos los pasos descritos anteriormente.

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:

• Correo electrónico: diversas aplicaciones anteriores de correo electrónico no son compatibles con UTF-8. Por el momento, el correo electrónico saliente, por lo tanto, se deberá convertir a una codificación preexistente que pueda representar su contenido completo; el UTF-8 sólo se deberá utilizar en aquellos casos en los que no se pueda encontrar una codificación preexistente.

• Exploradores móviles: los sistemas móviles no siempre son compatibles con UTF-8. Por lo tanto, puede ser necesario seleccionar otras codificaciones basadas en el dispositivo específico.

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:

• Mapeos alternativos de ciertos caracteres: En algunas codificaciones de Asia del Este, algunos caracteres tienen múltiples interpretaciones. Por ejemplo, el valor 0x5C en Shift-JIS se podrá interpretar como "\" en los nombres de archivos, pero se interpretará como "¥" en los datos financieros. Cuando se realice el mapeo a Unicode, se deberá tomar una decisión acerca de si se lo debe mapear a U+005C "\" o a U+00A5 "¥". El enfoque que comúnmente se da consiste en mapearlo a U+005C, que funciona para el sistema de archivos y que diversas fuentes japonesas mostrarán como "¥". Sin embargo, si el comportamiento de su aplicación pudiera depender del mapeo (por ejemplo, análisis de valores de monedas), deberá tomar las medidas necesarias a fin de controlar el resultado. En el caso del ejemplo, podría mapear 0x5C al código de moneda "JPY" antes de realizar la conversión y, a continuación, "JPY" a U+00A5 después de la conversión.

• Caracteres de uso privado: algunas codificaciones de caracteres, incluidas Unicode y la mayoría de las codificaciones de Asia del Este, tienen extensiones de puntos de codificaciones reservadas para uso privado o que sólo están sin definir. Con frecuencia, se utilizan para caracteres de uso personal o específicos de una empresa: por ejemplo, el emoji definido por los operadores móviles japoneses. Los conversores de caracteres estándar no saben de qué manera mapear dichos caracteres. En el caso de las aplicaciones en las que es de vital importancia la compatibilidad de caracteres de uso privado, deberá utilizar conversores de caracteres personalizados o soluciones temporales, por ejemplo, referencias de caracteres numéricos, a fin de garantizar el mapeo correcto.

• Versiones de mapeos y codificaciones de caracteres: existen diversas codificaciones de caracteres que han evolucionado con el tiempo, al igual que los mapeos entre ellas. Por ejemplo, el mapeo desde HKSCS hacia Unicode: Las versiones anteriores de HKSCS debían realizar mapeos de diversos caracteres en el área de utilización privada de Unicode debido a que Unicode no era compatible con los caracteres; sin embargo, más tarde, estos caracteres se agregaron al repertorio de caracteres Unicode y se cambiaron los mapeos desde HKSCS a fin de poder mapear caracteres agregados recientemente. En general, se debe asegurar de utilizar las últimas versiones de los conversores de caracteres.

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:

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:

• Los algoritmos que fueron diseñados con la suposición de un carácter y un byte ya no sirven incluso para los idiomas europeos (nunca han servido para idiomas de Asia del Este). Es necesario cambiarlos a fin de adaptar las representaciones de caracteres de múltiples bytes. Asegúrese de que todo el procesamiento opere siempre con caracteres completos. Los caracteres completos pueden ocupar entre uno y cuatro bytes en UTF-8 y una o dos unidades de códigos de 16 bits en UTF-16. Para posiciones de caracteres, utilice siempre el índice del primer byte o unidad de código del carácter.
• En particular, será necesario revisar las especificaciones de longitud a fin de observar si deberán basarse en bytes, en caracteres, en unidades de código UTF-16 o en glifos. Cada una de las bases se aplica en algunas situaciones, pero será necesario aclarar la que se debe aplicar. La utilización de una definición basada en caracteres garantizará contar con el espacio suficiente, pero podrá consumir más almacenamiento que lo estrictamente necesario debido a que cada carácter ahora requiere 4 bytes. La utilización de definiciones basadas en bytes evita la expansión de tamaño, pero podrá restringir demasiado el número de caracteres. Por supuesto, es mejor disponer de esquemas que asignen sólo el espacio suficiente para contener un texto específico. Es posible que otras aplicaciones dirigidas por espacio (tales como la cantidad de "caracteres" que se pueden visualizar en el campo de un formulario) no se relacionen en absoluto con la cantidad de caracteres lógicos y en cambio sea necesario contar las unidades de texto visuales con números (llamadas grafemas).
• El tamaño del texto cambiará cuando se convierta el texto de una codificación a la otra. No existen multiplicadores fijos que puedan aplicarse a fin de calcular el tamaño del almacenamiento necesario; por consiguiente, la única manera de saberlo consiste realmente en convertir el texto. Se deberá tener cuidado a fin de evitar el truncamiento. Si el truncamiento fuera absolutamente necesario, como ocurre en algunos contextos de visualización, se deberá tener cuidado en truncar los límites de grafemas o caracteres.

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):

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.

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:

• Que todos los valores de bytes dentro del conjunto de datos se encuentren dentro del rango de 0x00 a 0x7F. ASCII no utiliza valores de bytes superiores a 0x7F.

• Que no se utilicen los valores de bytes 0x0E, 0x0F y 0x1B. La presencia de estos valores de bytes probablemente indique que en realidad los datos tienen alguna codificación ISO-2022.

• Si aparecen los caracteres "+" y "-", los bytes intervinientes no serán BASE-64 válidos. Si son válidos, es posible que el texto en el que se encuentren tengan la codificación UTF-7. Tenga en cuenta que se debe evitar UTF-7 siempre que sea posible debido a la posibilidad de sufrir ataques XSS.

• Las secuencias de caracteres "~{" y "~}" no aparecerán. En caso de que aparezcan, probablemente el texto tendrá la codificación HZ.

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:

• Realice una prueba a fin de evaluar la precisión de la detección de codificación. Utilice el algoritmo de detección que quiera utilizar en un conjunto secundario de datos, convierta los datos de la codificación detectada a Unicode y familiarice a las personas con los idiomas utilizados para la verificación de resultados. Si la precisión no cumple con los requisitos, pruebe con otros algoritmos de detección o utilice otra información adicional disponible para su aplicación.
• Si los datos tienen información codificada asociada (pero no confía en ésta completamente), concéntrese en aquellos casos en los que el algoritmo de detección percibe una codificación diferente. Será útil a fin de dirigir la atención a las mejoras necesarias relacionadas con la utilización de información adicional.
• Después de la migración, proporcione maneras de corregir la codificación en lo sucesivo. Una solución consiste en proporcionar una interfaz de usuario que le permita al usuario indicar la codificación real, la cual luego se almacena con el texto y se utiliza para reconvertir el texto. A fin de lograrlo, necesitará mantener la secuencia de bytes original disponible, junto con el nombre de la codificación detectada. La elección de almacenar además una versión Unicode del texto dependerá de la frecuencia a la que se accede al texto; para aquel texto al cual se accede con frecuencia, quizás convendrá almacenar en caché la versión Unicode, mientras que para otro tipo de textos será mejor evitar el almacenamiento y regenerar la versión Unicode sobre la marcha cuando sea necesario.

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, "Œ" (Œ) o "€" (€). 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 "&" 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:

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:

• Descargar y recargar: Los contenidos de la base de datos se descargan en un archivo de texto, convertido a la codificación Unicode deseada, y se cargan en una nueva base de datos. Es una estrategia simple, pero sólo funciona con bases de datos que se puedan tomar fuera de línea durante el período de tiempo extendido que se necesita para realizar la conversión.
• Crear una nueva base de datos Unicode: Se creará una nueva base de datos que utiliza la codificación Unicode, se copiará el contenido de la base de datos anterior y se realizará la conversión durante este proceso. Se deberán replicar a la nueva base de datos aquellas transacciones que impliquen actualización o borrado de contenido ya copiado. Cuando la anterior base de datos se haya incorporado a la nueva, se cambiará el acceso a la nueva base de datos. En general, es la mejor estrategia para las bases de datos de producción, pero requiere de suficiente disponibilidad del hardware del servidor de la base de datos a fin de ejecutar las dos bases de datos en paralelo.
• Agregar columnas Unicode: en este modelo, cada columna de texto en una codificación preexistente se coloca a la par de la nueva columna de codificación Unicode. Los campos de esta columna están poblados y, por consiguiente, se cambian las consultas a fin de acceder a la columna Unicode en lugar de la columna de codificación preexistente. Si la codificación preexistente era conocida con certeza, se podrá eliminar la columna de codificación preexistente. Puede ser necesario emplear esta estrategia si no hubiera suficiente espacio en el disco disponible para crear una base de datos completamente nueva y si el código de acceso a la base de datos fuera razonablemente reducido.
• Convertir en el lugar: algunas bases de datos, por ejemplo, MySQL, tienen la capacidad de convertir una tabla en el lugar desde una codificación hacia la otra. Esto sólo funciona con aquellas bases de datos que se puedan tomar fuera de línea durante el período necesario para la conversión.
• Convertir en el lugar con etiqueta de codificación: Si la base de datos sólo administra bytes y la interpretación total de los bytes como texto se realiza fuera de la base de datos, será posible realizar la conversión en el lugar y mantener un registro del progreso mediante la utilización de una etiqueta de codificación por cada registro. Los procesos de acceso a la base de datos necesitarán conocer la etiqueta de codificación y convertir los bytes que almacenan o deberán extraerlos de la base de datos hacia sus propias codificaciones. Si la base de datos sólo contiene una única codificación preexistente, la BOM se podrá utilizar para distinguir las secuencias Unicode.

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.

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.

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;.

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.