Unicode es un estándar industrial cuyo objetivo es proporcionar el medio por el que un texto en cualquier forma e idioma pueda ser codificado para el uso informático.
El establecimiento de Unicode ha involucrado un ambicioso proyecto para reemplazar los esquemas de codificación de caracteres existentes, muchos de los cuales están muy limitados en tamaño y son incompatibles con entornos multilingües. Unicode se ha vuelto el más extenso y completo esquema de codificación de caracteres, siendo el más dominante en la internacionalización y adaptación local del software informático. El estándar ha sido implementado en un número considerable de tecnologías recientes, que incluyen XML, Java y sistemas operativos modernos.
Unicode tiene el propósito explícito de trascender las limitaciones de los códigos de caracteres tradicionales, como los definidos por el estándar ISO 8859, utilizado en numerosos países del mundo, pero que continúa incompatible entre ellos en gran parte. Buena parte de los codificadores de caracteres tradicionales comparten un problema en común: permiten procesamientos informáticos bilingües (generalmente usando caracteres latinos y del idioma local), pero no multilingües (procesamiento informático de idiomas arbitrarios mezclados entre ellos).
Unicode intenta codificar los caracteres esenciales —grafemas— más que las representaciones variantes para dichos caracteres. En caso de los caracteres chinos, esto lleva a veces a constantes controversias sobre la distinción entre caracteres esenciales y sus representaciones variantes (véase http://en.wikipedia.org/wiki/Han_unification y http://en.wikipedia.org/wiki/Radical_%28Chinese_character%29).
En procesamiento de textos, Unicode juega el papel de proveer un único punto de código (code point) para cada carácter. En otras palabras, Unicode representa un carácter de forma abstracta, y deja la representación visual (tamaño, dimensión, fuente o estilo) a otro software, como un navegador web o un procesador de texto. No obstante, esta simplicidad se complica con las concesiones hechas por los diseñadores de Unicode, con la esperanza de animar una mayor "adopción" de Unicode.
Los primeros 256 puntos de código fueron idénticos al contenido del ISO 8859-1, para trivializar la conversión del texto occidental existente. Muchos de los caracteres esenciales se codificaron varias veces en distintos puntos de código para preservar distinciones utilizadas por codificaciones hereditarias y permitir conversiones de aquellas codificaciones a Unicode (y viceversa) sin perder ningún tipo de información. Por ejemplo, la sección de fullwidth forms de los puntos de código abarca un alfabeto latino completo, separado de la sección de alfabeto latino principal. En fuentes CJK (fuentes para chino, japonés y coreano), estos caracteres fueron representados tanto en su forma fullwidth como en otra en la que su ancho está reducido a la mitad.
Además de que Unicode permite combinaciones de caracteres, también dispone de versiones precompuestas de la mayoría de combinaciones de letras diacríticas en uso. Estas versiones hacen conversiones desde y hacia las más simples codificaciones hereditarias y permiten que las aplicaciones utilicen Unicode como un formato de texto interno sin tener que implementar combinaciones de caracteres. Por ejemplo, é puede representarse en Unicode como U+0065 (letra latina minúscula e) seguido de U+0301 (acento agudo), pero puede también representarse directamente por el precompuesto U+00E9.
El estándar Unicode también incluye un número de ítems relacionados, como las propiedades de caracteres, formas de normalización de textos y órdenes de visualización bidireccional (para la correcta visualización de texto que contenga escrituras de derecha a izquierda —Árabe o Hebreo— y de izquierda a derecha a la vez).
Unicode ha ido añadiendo escrituras y cubrirá aún más, incluyendo escrituras históricas menos utilizadas, incluso aquellas extinguidas para propósitos académicos:
No hay planes inmediatos para incorporar jeroglíficos egipcios o escritura Maya. NOTA: Los jeroglíficos egipcios han sido propuestos para la versión de UNICODE 4.1
También ocurren adiciones posteriores de caracteres a las escrituras ya codificadas, como los símbolos, en particular para música y matemáticas. El mapa itinerario de Unicode enlista escrituras sin incluir con asignaciones tentativas de bloques de código. Escrituras inventadas, muchas de las cuales no están cualificadas para la inclusión en Unicode debido a la carencia de uso en el mundo real, están listados en el Registro Unicode ConScript, acompañado por los códigos no oficiales de asignación del Área de Uso Privado. De forma similar, considerables variantes de letras medievales y ligaduras no incluidas en Unicode, están codificadas en la Iniciativa de Fuente de Unicode Medieval.
Hubo también propuestas sobre la inclusión de escrituras élficas como el Tengwar o el Cirth, de la ficticia Tierra Media de J. R. R. Tolkien, en el Plano 1 en 1993. ** El Consorcio retiró el borrador para incorporar cambios, propuestos por los seguidores de Tolkien, y no se consideró hasta 2005.
Tanto el Klingon como el Élfico son asignados en el Registro Unicode ConScript.
Primero se publicó El Estándar Unicode (ISBN 0321185781) en 1991, y sigue desarrollando estándares basados en el original. Unicode fue desarrollado conjuntamente con la Organización Internacional para la Estandarización (ISO) y comparte su repertorio con ISO/IEC 10646. Unicode e ISO/IEC 10646 funcionan equivalentemente como codificadores de caracteres, pero el Estándar Unicode contiene mucha más información para implementar, cubriendo en profundidad, temas como la codificación bitwise, collation y la renderización. Unicode enumera una vasta cantidad de propiedades para los caracteres, incluyendo aquellas necesarias para soportar texto bidireccional. Ambos estándares utilizan una terminología ligeramente diferente. Cuando se escribe un carácter en Unicode, es normal escribirlo como una "U+" seguido de un número hexadecimal indicando el punto del código del carácter. Para puntos de código usando el formato gráfico BMP, se usan cuatro dígitos, para los puntos de código fuera del formato gráfico BMP son usados cinco o seis dígitos, según sea requerido. Las versiones antiguas del mismo estándar utilizaban notaciones similares, pero con reglas ligeramente diferentes. Por ejemplo, Unicode 3.0 utlizaba "U-" seguido de ocho dígitos, y permitía que se utilizara "U+" solamente con exactamente 4 dígitos para poder indicar una unidad de código, no un punto de código.
La lógica interna de la mayoría del software de 8 bits permite de forma típicasolamente 8 bits para cada carácter, haciendo imposible utilizar más de 256 puntos en código sin procesamiento especial. El software de 16 bits solamente puede guardar poco más de 6 decenas de miles de caracteres. Unicode, por otro lado ha definido más de 90.000 caracteres codificados. Los diseñadores de los sistemas entonces han tenido que sugerir muchos métodos y mecanismos para implementar Unicode; el método implementado depende del espacio de almacenamiento disponible, la compatibilidad de los códigos fuentes y la inter-operatividad con otros sistemas.
Unicode define dos métodos de "mapeo" o de localización de caracteres:
Las codificaciones incluyen:
Los números en los nombres de los códigos indican la cantidad de bits de cada carácter (para las codificaciones UTF) o el número de bytes por carácter (para las UCS).
A continuación se describen en el mismo orden algunos detalles sobre cada tipo de codificacón:
UTF-8 utiliza de uno hasta 4 bytes por cada punto de código y, siendo relativamente compacto (para la escritura basada en caracteres latinos) y compatible con ASCII. Proporciona la codificación estándar para el intercambio de texto en Unicode. También es utilizado por las más recientes versiones de Linux como reemplazo a la herencia de códigos en el manejo de textos en general.
Las codificaciones UCS-2 y UTF-16 especifican la BOM o la Marca de Orden de Byte especifica el Unicode para usarlo al principio de los archivos de texto. Algunos desarrolladores de software lo han adoptado para otras codificaciones, incluyendo UTF-8, la cual no necesita una indicación de orden de byte. En este caso intenta marcar el archivo indicando que contiene texto Unicode. El punto código de la BOM, U+FEFF tiene la importante propiedad de la inambigüedad, sin importar la codificación Unicode utilizada. Las unidades FE y FF nunca aparecen en UTF-8; U+FFFE (el resultado del intercambio the U+FEFF) no es igual a un carácter válido, y U+FEFF transporta la longitud-cero o espacio sin roptura (un carácter sin apariencia y sin otro efecto más que prevenir la formación de ligaduras). El mismo carácter convertido a UTF-8 se convierte en la siguiente secuencia de bytes EF BB BF.
En los códigos UTF-32 y UCS-4, un código de 32 bits funciona como una representación directa y confiable de cualquier punto de código de un carácter (aunque la endianness, que varia dependiendo de la arquitectura del procesador de cada computadora, afecta como se manifiesta el valor del código en su secuencia de bits). Aunque en otros casos, cada código puede ser representado por un código de valores de números variables.
UTF-16, mientras tanto, la cual normalmente asigna 16 bits por cada punto de código (la misma que UCS-2) aunque a veces asigna 32, es utilizada por muchas APIs (Interfaz de Programación de Aplicaciones por sus siglas en inglés). Mayormente por rasones históricas que datan desde los días en que Unicode estaba basado en UCS-2 o era una interfaz con otras APIs que usaban UTF-16 . UTF-16 es el formato estándar para la API de Windows (aunque el soporte para sustitutos no esta habilitado por omisión), para la de Java y la de ambientes .NET bytecode.
UCS-4 y UTF-32 no son comúnmente utilizados, ya que no más de 21 de los 32 bits asignados a cada punto de código serán alguna ves utilizados, lo que si se esta volviendo común es la implementación del código UCS-4 en la programación para el almacenamiento interno del texto codificado.
GB18030 es otra forma de codificación para el Unicode, pero proveniente de la Administración para la Estandarización de China.
Una situación similar ocurre con el hangul. Unicode ofrece el mecanismo para crear silabas hangul con el Hangul Jamo. Aunque, también provee de sílabas hangul prediseñadas (11,172 de ellas para ser exactos).
Los ideogramas provenientes de China, Corea y Japón actualmente solo tienen códigos para su forma prediseñada. Aunque, la mayoría de estos ideagramas se componen de elementos más simples (también llamados radicales) así que Unicode podrá descomponerlos como ocurre con el hangul. Esto reduciría enormemente el número de puntos de código requeridos, aunque permitiría la visualización de virtualmente cualquier ideograma concebible (lo que permitiría resolver algunos de los problemas causados por la Unificación Han). Una idea similar cubre algunos métodos de entrada, como el Cangjie y el Wubi. Aunque, algunos intentos de hacer esto para la codificación de caracteres han tropezado con el hecho de que los ideogramas no se descomponen tan fácil o tan regularmente como parece que deberían.
Un juego de radicales fue otorgado en Unicode 3.0 (radicales Chinos, Japoneses y Coreanos entre U+2E80 y UY+2EFF, radicales KanXi de U+2F00 a U+2FDF y descripción ideográfica de caracteres desde U+2FF0 hasta U+2FFB), pero el Unicode estándar (sección 11.1 de Unicode 4.1) advierte contra el uso de secuencias de descripciones ideográficas como una representación alterna para los caracteres previamente codificados:
Combinar símbolos, como en el complejo método de moldeo de caracteres requerido para dibujar propiamente texto Arábico y en muchos otros alfabetos, depende normalmente de tecnologías, como OpenType (de Adobe y Microsoft), Graphite (de Sil International y AAT (de Apple), en los cuales un diseñador de fuentes incluye instrucciones en la fuente, explicandole al software como imprimir diferentes secuencias de caracteres corrrectamente. Las fuentes de tamaño fijo algunas veces emplean otro método: escribiendo el símbolo combinado a la izquierda de su propio espacio; este método, sin embargo funciona solamente para algunos caracteres y estos no se apilarán adecuadamente.
Incluso en la actualidad la mayoría del software aun no puede manejar confiablemente muchas características no aceptadas por los viejos formatos de fuentes, así que combinar caracteres usualmente no funciona de forma correcta. En teoría (prediseñado con una "e" testada y acentuada) y (una "e" seguida de de la combinación de un signo de testar y una tílde arriba de la letra) tienen una apariencia idéntica, ambas dando una "e" testada y tildada, pero en la práctica, sus apariencias pueden variar enormemente dependiendo del uso que le dé el software.
También puntos inferiores, que son necesarios en el alfabeto Indú romanizado, serán desplegados muy a menudo incorrectamente. Por ejemplo:
Por supuesto, tales problemas no muestran una debilidad del Unicode en sí, sino revelan los errores y debilidades en la tecnología aplicada al dibujado (rendering) y a las fuentes. También se hace notar la existencia de símbolos preestablecidos para muchos caracteres preestablecidos, por ejemplo: .
Otras persona han denigrado el Unicode al afirmar que es un complot contra las culturas asiáticas perpetrado por los occidentales sin ningún conocimiento de como son usados los caracteres en chino, coreano o japonés, a pesar de que un buen número de expertos de los tres continentes en el Grupo Ideográfico del Poniente (IRG por sus siglas en inglés). El IRG avisa al consorcio del Unicode y al ISO y a la Unificación Han de las nuevas adiciones al repertorio y de la identificación de símbolos en los tres lenguajes sobre cuales de ellos se pueden tratar como variaciones de estilo del mísmo carácter histórico. La unificación Han se ha convertido en uno de los aspectos más controversiales del Unicode.
Unicode es duramente criticado dor no permitir el uso de los símbolos alternos y antiguso del kanji, lo cual, se dice, que complica el procesaminto del japonés antiguo y de nombres japoneses poco usuales, estas críticas siguen aunque Unicode sigue completamente las recomendaciones de maestros del lenguaje japonés y del gobierno japonés. Incluso han habido numerosos intentos de crear un Unicode alternativo. (para saber más en inglés: Entre los muchos propuestos se encuentra el TRON (aunque no es ampliamente adoptado en Japón, algunos, en especial aquellos que necesitan manejar texto escrito en japonés antiguo, favorecen este estándar); y el UTF-2000. Aunque es verdad que muchos símbolos antiguos no fueron incluidos en las primeras versiones del Unicode estándar, Unicode 4.0 contiene más de 90,000 carecteres Han, muchísimos más que cualquier otro diccionario o estándar, y que el proceso de agregar caracteres de la temprana escritura de China, Corea y Japón continua.
El incluir el Lenguaje Thai también ha sido criticado por su orden ilógico de caracteres. Esta complicación es debido a que el Unicode ha heredado el Estándar Industrial Thai 620, el cual funcionaba de la misma manera. Este problema de orden complica el proceso de comparación de Unicode (para saber más en inglés:*).
Incluso algunos que se oponen al Unicode se quejan aún de que no puede manejar más de 65.535 caracteres, una limitación que fue removida desde el Unicode 2.0.
Pero como vemos, nadie se queda indiferente, o bien le odian o le aclaman, pues algunos gobiernos, como el gobierno de India, han mostrado enorme interés en el proyecto, de hecho es miembro con derecho a voto en el consorcio de Unicode.
Por otro lado UTF-8 (desarrollado por Plan 9) se ha convertido en la codificación principal de la mayotia de los sistemas operativos similares o basados en Unix (aunque otros también son usados por algunas bibliotecas) debido a que es relativamente fácil hacer el reemplazo por caracteres de los juegos de caracteres extendidos ASCII.
La adopción de Unicode en el correo electrónico ha sido muy lenta. La mayoría del texto del este de Asia esta codificado todavía en codificaciones locales como Shift-JIS y muchos porgramas de correo comúnmente utilizados, si es que son compatibles con Unicode, aún no puede manejar los datos de Unicode correctmante. No se espera que esta situación cambie en un futuro cercano.
Aunque las reglas de sintaxis pueden modificar el orden en que a los caracteres se les permite aparecer, los documentos de ambos lenguajes: HTML 4.0 y XML 1.0; por definición abarcan caracteres de muchos de los puntos código de Unicode, con excepción de:
Estos caracteres se manifiestan directamente como bytes de acuerdo a la documentación de cada codificacón, si ésta es compatible con Unicode, o bién el usuario puede escribirlos directamente como referencias numéricas de caracteres basado en el punto código de Unicode de cada carácter, siempre y cuando la codificación de cada documento permita utilizar los dígitos necesarios para escribir las referencias (todos los códigos aprobados para uso en el internet lo permiten). Por ejemplo, las referencias: Δ, Й, ק, م, ๗, あ, 叶, 葉, y 냻 ( o el mismo valor numérico expresado en hexadecimal con como el prefijo) se muestran en el navegador como Δ, Й, ק, م, ๗, あ, 叶, 葉 y 냻, siempre y cuando la fuente correcta exista, estos símbolos corresponden a: la letra griega delta mayuscula, la letra cirílica "i corta", la letra hebrea "Qof", la letra arábiga "Meem", el número Thai 7, la letra japonesa Hiragana "A", el símbolo del Chino simplificado para "Hoja", el símbolo de laescritura tradicional china para "Hoja" y la silaba coreana "Nyelh", respectivamente.
Codificación de caracteres | Normas ISO | Protocolos y formatos de nivel de presentación
Unicode | Уникод | ইউনিকোড | Unicode | Unikod | Unicode | Unicode | Unicode | Unicode | Unicode | Unicode | Unicode | Unikodo | Unicode | Unicode | Unicode | Unicode | יוניקוד | यूनिकोड | Unicode | Unicode | Unicode | Unicode | Unicode | უნიკოდი | ಯುನಿಕೋಡ್ | 유니코드 | यूनिकोड | Unicode | Unicode | Unikods | युनिकोड | Unicode | Unicode | Unicode | Unicode | Unicode | Unicode | Юникод | Unikod | Unicode | Unicode | Unicode | Уникод | Unicode | யுனிகோடு | ยูนิโคด | Unicode | Юнікод | Unicode | Unicôde | Unicode | Thong-iōng-bé