Codifique sus documentos XML en UTF-8

(Pista: El tamaño no importa)

Unicode es un conjunto superior de cualquier carácter computarizado significante ubicado hoy en la tierra. UTF-8 es la codificación binaria correcta del conjunto de caracteres Unicode. Este artículo presenta el argumento de por qué todos los documentos XML deberían ser generados exclusivamente en UTF-8. El resultado es un universo de documentos más robusto, más interoperable.

Elliotte Rusty Harold, Profesor adjunto, Polytechnic University

Elliotte Rusty HaroldElliotte Rusty Harold es originariamente de Nueva Orleans, a donde regresa periódicamente en busca de un tazón decente de gumbo. Sin embargo, reside en el barrio Prospect Heights de Brooklyn con su esposa Beth y sus gatos Charm (por el quark) y Marjorie (por su suegra). Es profesor adjunto de ciencias informáticas en la Polytechnic University, en donde enseña tecnología Java y programación orientada a objetos. Su website Cafe au Lait se ha convertido en uno de los sitios Java independientes más populares de Internet, sitio derivado, Cafe con Leche, se ha convertido en uno de los sitios XML más populares. Entre sus libros se incluyen Effective XML, Processing XML with Java, Java Network Programming y The XML 1.1 Bible. Actualmente está trabajando en el XOM API para procesar XML, el motor Jaxen XPath y la herramienta Jester de cobertura de pruebas.



12-11-2012

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea Compresión de datos y XML

El servicio de Google Sitemaps causó recientemente un mínimo revuelo en la comunidad XML al requerir que todos los sitemaps sean publicados exclusivamente en la codificación UTF-8 de Unicode. Google ni siquiera permite codificaciones alternativas de Unicode como UTF-16, mucho menos codificaciones no Unicode como ISO-8859-1. Técnicamente, esto significa que Google está utilizando un analizador XML defectuoso, porque la Recomendación XML necesita específicamente que "Todos los procesadores XML DEBEN aceptar las codificaciones UTF-8 y UTF-16 de Unicode 3.1". Sin embargo, ¿es realmente un gran problema?

Cualquiera puede utilizar UTF-8

La universalidad es la primera razón y la más convincente para elegir UTF-8. Puede manejar prácticamente cualquier script en uso en el planeta hoy. Todavía existen algunas brechas, pero son cada vez más oscuras y ya están siendo rellenadas. Los scripts que permanecen sin cubrir típicamente no han sido implementados en ningún otro conjunto de caracteres; y si han sido utilizados, no están disponibles en XML. Como mucho, están cubiertos por alguna fuente injertada en conjuntos de caracteres de un byte como Latin-1. El soporte real para estos scripts minoritarios llegará primero y seguramente solo en Unicode.

Sin embargo, este es solo un argumento para utilizar Unicode. ¿Por qué elegir UTF-8 en vez de UTF-16 u otros codificadores Unicode? Una de las razones más simples es un soporte de herramientas amplio. Prácticamente cualquier editor importante que pueda utilizar con XML maneja UTF-8, incluidos JEdit, BBEdit, Ecplise, emacs e incluso el bloc de notas. No hay otro codificador de Unicode que se jacte de tener semejante soporte de herramientas amplio entre herramientas XML y no XML.

En algunos casos, por ejemplo, BBEdit y Eclipse, UTF-8 no es el conjunto de caracteres determinado. Es hora de que todos los valores predeterminados sean modificados: todas las herramientas deberían salir de fábrica con UTF-8 como el codificador predeterminado seleccionado. Hasta que esto suceda, estamos atascados en un lío de archivos no interoperables que se rompen al ser transferidos a través de bordes nacionales, de plataforma y lingüísticos. Pero hasta que todos los programas sean predeterminados en UTF-8, es fácil cambiar las predeterminaciones manualmente. Por ejemplo, en Eclipse, los paneles de preferencias "General/Editors" que se muestran en la Ilustración 1 le permiten especificar que todos los archivos deberán ser UTF-8. Notará que Eclipse desea predeterminarlo a MacRoman; sin embargo, si usted permite esto, sus archivos no se compilarán cuando los transfiera a programadores que trabajan con Microsoft® Windows® o cualquier computadora fuera de América y Europa Occidental.

Ilustración 1 Cambios en la configuración de caracteres predeterminados en Eclipse
Eclipse character set preferences

Por supuesto que para que UTF-8 funcione, los desarrolladores con los cuales usted intercambia archivos deben utilizar UTF-8 también; pero eso no debería ser un problema. UTF-8 no está limitado a unos cuantos scripts ni a una plataforma minoritaria como MacRoman. UTF-8 funciona bien para todos. Este no es el caso de MacRoman, Latin-1, SJIS y varios otros conjuntos de caracteres de legado.

UTF-8 también funciona mejor con herramientas que no esperan recibir datos multibyte. Otros formatos Unicode como UTF-16 tienden a contener muchos bytes cero. Más que un par de herramientas interpretan estos bytes como fin del archivo u otro delimitador especial con efectos inesperados, no anticipados y, por lo general, desagradables. Por ejemplo, si los datos UTF-16 están cargados ingenuamente en una cadena C, la cadena puede ser truncada en el segundo byte del primer carácter ASCII. Los archivos UTF-8 solo contienen nulos que realmente deben ser nulos. Por supuesto que usted no elegiría procesar sus documentos XML con semejante herramienta ingenua. Sin embargo, los documentos terminan, por lo general, en lugares extraños en sistemas de legado donde nadie realmente consideró o entendió las consecuencias de poner nuevo vino en viejas botellas. Es menos probable que UTF-8 cause problemas para sistemas que no están preparados para Unicode y XML que UTF-16 u otras codificaciones Unicode.


Lo que dicen las especificaciones

XML fue el primer gran estándar en promocionar UTF-8 incondicionalmente, pero eso fue solo el principio de una tendencia. Cada vez más, los cuerpos estándar están recomendando UTF-8. Por ejemplo, las URL que contienen caracteres no ASCII fueron un problema persistente en la Web por un largo tiempo. Una URL que contenía caracteres no ASCII que trabajó en una computadora falló cuando se la cargó en una Mac y viceversa. Este problema fue recientemente eliminado cuando el World Wide Web Consortium (W3C) y el Grupo Especial sobre Ingeniería de Internet (IETF) acordaron que todas las URL serían codificadas en UTF-8 y nada más.

Tanto W3C como IETF se han hecho recientemente más inflexibles acerca de elegir UTF-8 primero, último y solo algunas veces. El Modelo de Caracteres W3C para la World Wide Web 1.0: Los fundamentos indican: "Cuando se necesita una codificación de caracteres única, la codificación de caracteres DEBE ser UTF-8, UTF-16 o UTF-32. US-ASCII es altamente compatible con UTF-8 (una cadena US-ASCII también es una cadena UTF-8, ver [RFC 3629]) y, por ello, UTF-8 es apropiada si se desea la compatibilidad con US-ASCII". En la práctica, la compatibilidad con US-ASCII es tan útil que es casi un requisito. El W3C explica sabiamente: "En otras situaciones, como para API, UTF-16 o UTF-32 puede ser más apropiado. Las posibles razones para elegir uno de estos incluyen la eficiencia de los procesos internos y la interoperatividad con otros procesos".

Puedo creer el argumento acerca de la eficiencia del procesamiento interno. Por ejemplo, la representación interna de cadenas del lenguaje Java™ está basada en UTF-16, lo que hace que el indexado a la cadena sea más rápido. Sin embargo, el código Java nunca expone esta representación interna a los programas con los que intercambia datos. En cambio, para el intercambio externo de datos, se utiliza un java.io.Writer, y la serie de caracteres está explícitamente especificada. Cuando hace esta elección, se prefiere UTF-8 totalmente.

El IETF es incluso más explícito. La política IETF Charset [RFC 2277] plantea en un lenguaje no incierto:

Los protocolos DEBEN poder utilizar el conjunto de caracteres UTF-8, el cual consiste en el conjunto de caracteres codificados ISO 10646 combinado con el esquema de codificación de caracteres UTF-8, como se define en el [10646] Anexo R (publicado en la Enmienda 2) para todo texto.

Los protocolos PUEDEN especificar, además, cómo utilizar otros conjuntos de caracteres para otros esquemas de codificación para ISO 10646, como UTF-16, pero la falta de habilidad para utilizar UTF-8 es una violación a esta política; tal violación necesitará de un procedimiento de variación ([BCP9] sección 9) con una justificación clara y sólida en el documento de especificación del protocolo antes de ser ingresada o superada en la pista de estándares.

Para protocolos existentes o protocolos que transportan datos de almacenes de datos, soportan otros conjuntos de caracteres o incluso utilizan otro predeterminado que no sea UTF-8, puede ser un requisito. Esto es aceptable, pero el soporte UTF-8 DEBE ser posible.

Conclusión: El soporte de protocolos de legado y archivos puede requerir la aceptación de conjuntos de caracteres y codificaciones que no sean UTF-8 por algún tiempo, pero evitaré tener que hacerlo. Cada protocolo, aplicación o documento nuevo debería utilizar UTF-8.


Chino, japonés y coreano

Un error de concepto común es que UTF-8 es un formato de compresión. No lo es. Los caracteres en el intervalo ASCII ocupan solo la mitad del espacio en UTF-8 de lo que ocupan en otras codificaciones de Unicode, particularmente UTF-16. Sin embargo, algunos de los caracteres requieren hasta un 50% más de espacio para ser codificados en UTF-8, especialmente ideogramas chinos, japoneses y coreanos (CJK).

Pero incluso cuando se está codificando XML CJK en UTF-8, el tamaño real obtenido comparado con UTF-16 probablemente no sea tan grande. Por ejemplo, un documento XML chino contiene muchos caracteres ASCII como <, >, &, =, ", ' y espacio. Estos son todos más pequeños en UTF-8 que en UTF-16. El factor de disminución y expansión exacto va a variar de un documento al otro, pero de cualquier modo es poco probable que la diferencia sea convincente.

Finalmente, cabe destacar que los scripts ideográficos como los chinos o japoneses tienden a ser parsimoniosos con los caracteres comparado con scripts alfabéticos como latín o cirílico. Un gran número absoluto de estos caracteres requiere tres o más bytes por carácter para representar estos scripts de manera completa; esto significa que las mismas palabras y oraciones pueden ser expresadas en menos caracteres de lo que son expresadas en lenguajes como inglés y ruso. Por ejemplo, el ideograma japonés para árbol es 木. (Parece un pequeño árbol). Esto ocupa tres bytes en UTF-8, por cuanto que la palabra en inglés "tree" comprende cuatro letras y cuatro bytes. El ideograma japonés para arboleda es æž— (dos árboles cerca). Esto todavía ocupa tres bytes en UTF-8, por cuanto la palabra en inglés "grove" comprende cinco letras y requiere cinco bytes. El ideograma japonés 森 (tres árboles) todavía ocupa solo tres bytes. Sin embargo, el equivalente en inglés "forest" toma seis.

Si es la compresión lo que usted está buscando, entonces comprima el XML mediante zip o gzip. El UTF-8 comprimido probablemente se acerque en tamaño al UTF-16 comprimido, sin importar la diferencia del tamaño inicial. El que sea más grande inicialmente tendrá más redundancia para el algoritmo de compresión a reducir.


Solidez

La verdadera sorpresa es que por diseño, UTF-8 es un formato mucho más sólido y fácilmente interpretable que cualquier otro codificador de texto diseñado antes o después. Primero, UTF-8 no tiene problemas de extremidad como UTF-16. Los UTF-8 big-endian y little-endian son idénticos, porque UTF-8 está definido en términos de bytes de 8 bits en vez de palabras de 16 bits. UTF-8 no es ambiguo acerca del orden de los bytes que debe ser resuelto con una marca de orden de bytes u otros heurísticos.

Una característica incluso más importante de UTF-8 es que no hay estado. Cada byte de una cadena o secuencia UTF-8 es inequívoco. En UTF-8, usted siempre sabe dónde está, es decir, dado un determinado byte es posible determinar inmediatamente si es un carácter de un solo byte, el primer byte de un carácter de dos bytes, el segundo byte de un carácter de dos bytes, o el segundo o tercer o cuarto byte de un carácter de tres o cuatro bytes. (Estas no son todas las posibilidades, pero es para dar una idea). En UTF-16 no siempre se sabe si el byte "0x41" es la letra "A". Algunas veces lo es, otras veces no lo es. Se debe realizar un seguimiento de demasiados estados para saber dónde se está ubicado en la secuencia. Si un solo byte se pierde, todos los datos de ese punto en adelante son corrompidos. En UTF-8, los bytes perdidos o mezclados son aparentemente legibles y no corrompen el resto de los datos.

UFT-8 no es ideal para todos los propósitos. Las aplicaciones pueden requerir acceso aleatorio a índices específicos dentro de un documento o pueden operar más rápidamente cuando utilizan una codificación con anchura fija como UCS2 o UTF-32. (UTF-16 es una codificación de caracteres con anchura variable, una vez que los pares suplentes son considerados). Sin embargo, el procesamiento XML no es tal aplicación. La especificación XML prácticamente requiere que los analizadores comiencen en el primer byte de un documento XML y que continúen analizando hasta el final, y que todos los analizadores existentes operen como este. El acceso aleatorio más rápido no asistiría al procesamiento XML en ninguna forma significativa; de manera que aunque esto puede ser una buena razón para utilizar una codificación distinta en una base de datos u otro sistema, no aplica a XML.


Resumen

En un mundo cada vez más internacionalizado donde los límites lingüísticos y políticos se vuelven cada vez más difusos, los conjuntos de caracteres dependientes del entorno local ya no son viables. Unicode es el único conjunto que puede interoperar a través de la Tierra en muchos entornos locales. UTF-8 es la codificación correcta para Unicode:

  • Ofrece un soporte de herramientas amplio, incluida la mejor compatibilidad con sistemas ASCII de legado.
  • Es directo y eficiente para procesar.
  • Es resistente a la corrupción.
  • Es neutral a las plataformas.

Ha llegado el momento de dejar de lado la discusión acerca de los conjuntos de caracteres y las codificaciones: elija UTF-8 y termine con esta discusión.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Industries
ArticleID=845263
ArticleTitle=Codifique sus documentos XML en UTF-8
publish-date=11122012