Unicode , formalmente el Estándar Unicode , [nota 1] es un estándar de codificación de texto mantenido por el Consorcio Unicode diseñado para admitir el uso de texto en todos los sistemas de escritura del mundo que se puedan digitalizar. La versión 16.0 del estándar [A] define154 998 caracteres y 168 escrituras [3] utilizadas en diversos contextos ordinarios, literarios, académicos y técnicos.
Muchos caracteres comunes, incluidos los números, la puntuación y otros símbolos, están unificados dentro del estándar y no se tratan como específicos de ningún sistema de escritura determinado. Unicode codifica 3790 emoji , y el Consorcio continúa desarrollándolos como parte del estándar. [4] Además, la adopción generalizada de Unicode fue en gran parte responsable de la popularización inicial de los emoji fuera de Japón. Unicode es capaz de codificar más de 1,1 millones de caracteres.
Unicode ha reemplazado en gran medida el entorno anterior de una miríada de conjuntos de caracteres incompatibles , cada uno utilizado en diferentes configuraciones regionales y en diferentes arquitecturas informáticas. Unicode se utiliza para codificar la gran mayoría de textos en Internet, incluidas la mayoría de las páginas web , y la compatibilidad con Unicode se ha convertido en una consideración común en el desarrollo de software contemporáneo.
El repertorio de caracteres Unicode está sincronizado con la norma ISO/IEC 10646 , siendo todos idénticos código por código. Sin embargo, el estándar Unicode es más que un simple repertorio dentro del cual se asignan caracteres. Para ayudar a los desarrolladores y diseñadores, el estándar también proporciona gráficos y datos de referencia, así como anexos que explican conceptos relacionados con varios sistemas de escritura, proporcionando orientación para su implementación. Los temas cubiertos por estos anexos incluyen la normalización de caracteres , la composición y descomposición de caracteres , la intercalación y la direccionalidad . [5]
El texto Unicode se procesa y almacena como datos binarios utilizando una de varias codificaciones , que definen cómo traducir los códigos abstractos del estándar para caracteres en secuencias de bytes. El propio estándar Unicode define tres codificaciones: UTF-8 , UTF-16 y UTF-32 , aunque existen varias más. De ellas, UTF-8 es la más utilizada por un amplio margen, en parte debido a su compatibilidad con versiones anteriores de ASCII .
Unicode se diseñó originalmente con la intención de superar las limitaciones presentes en todas las codificaciones de texto diseñadas hasta ese momento: cada codificación se utilizaba en su propio contexto, pero sin expectativas particulares de compatibilidad con ninguna otra. De hecho, a menudo, dos codificaciones cualesquiera elegidas eran totalmente inviables cuando se utilizaban juntas, y el texto codificado en una era interpretado como caracteres basura por la otra. La mayoría de las codificaciones solo se habían diseñado para facilitar la interoperabilidad entre un puñado de escrituras (a menudo, principalmente, entre una determinada escritura y caracteres latinos ), no entre una gran cantidad de escrituras y no para que todas las escrituras admitidas se trataran de manera coherente.
La filosofía que sustenta a Unicode busca codificar los caracteres subyacentes ( grafemas y unidades similares a grafemas) en lugar de distinciones gráficas consideradas meras variantes de los mismos, que en cambio se manejan mejor mediante el tipo de letra , mediante el uso de marcado o por algún otro medio. En casos particularmente complejos, como el tratamiento de las variantes ortográficas en los caracteres Han , existe un desacuerdo considerable sobre qué diferencias justifican sus propias codificaciones y cuáles son solo variantes gráficas de otros caracteres.
En el nivel más abstracto, Unicode asigna un número único llamado punto de código a cada carácter. Muchos aspectos de la representación visual (como el tamaño, la forma y el estilo) están pensados para que queden a criterio del software que realmente reproduce el texto, como un navegador web o un procesador de textos . Sin embargo, en parte con la intención de fomentar una rápida adopción, la simplicidad de este modelo original se ha vuelto algo más elaborada con el tiempo y se han hecho varias concesiones pragmáticas a lo largo del desarrollo del estándar.
Los primeros 256 puntos de código reflejan el estándar ISO/IEC 8859-1 , con la intención de trivializar la conversión de texto ya escrito en alfabetos de Europa occidental. Para preservar las distinciones hechas por diferentes codificaciones heredadas, permitiendo así la conversión entre ellas y Unicode sin ninguna pérdida de información, a muchos caracteres casi idénticos a otros , tanto en apariencia como en función prevista, se les asignaron puntos de código distintos. Por ejemplo, el bloque Formas de ancho medio y ancho completo abarca un duplicado semántico completo del alfabeto latino, porque las codificaciones CJK heredadas contenían caracteres tanto de "ancho completo" (que coincidían con el ancho de los caracteres CJK) como de "ancho medio" (que coincidían con el alfabeto latino ordinario).
El premio Unicode Bulldog se otorga a personas consideradas influyentes en el desarrollo de Unicode, y entre los destinatarios se incluyen Tatsuo Kobayashi , Thomas Milo, Roozbeh Pournader , Ken Lunde y Michael Everson . [6]
Los orígenes de Unicode se remontan a la década de 1980, a un grupo de personas con conexiones con el Estándar de Código de Caracteres de Xerox (XCCS). [7] En 1987, el empleado de Xerox Joe Becker , junto con los empleados de Apple Lee Collins y Mark Davis , comenzaron a investigar los aspectos prácticos de la creación de un conjunto de caracteres universal. [8] Con el aporte adicional de Peter Fenwick y Dave Opstad , [7] Becker publicó un borrador de propuesta para un "sistema de codificación de caracteres de texto internacional/multilingüe en agosto de 1988, llamado provisionalmente Unicode". Explicó que "el nombre 'Unicode' pretende sugerir una codificación única, unificada y universal". [7]
En este documento, titulado Unicode 88 , Becker describió un esquema que utiliza caracteres de 16 bits : [7]
Unicode tiene como objetivo abordar la necesidad de una codificación de textos mundial fiable y viable. Unicode podría describirse a grandes rasgos como un " ASCII de cuerpo ancho " que se ha ampliado a 16 bits para abarcar los caracteres de todos los idiomas vivos del mundo. En un diseño bien diseñado, 16 bits por carácter son más que suficientes para este propósito.
Esta decisión de diseño se tomó basándose en el supuesto de que sólo los scripts y caracteres de uso "moderno" requerirían codificación: [7]
Unicode da mayor prioridad a garantizar la utilidad para el futuro que a preservar antigüedades pasadas. Unicode apunta en primera instancia a los caracteres publicados en el texto moderno (por ejemplo, en la unión de todos los periódicos y revistas impresos en el mundo en 1988), cuyo número es indudablemente muy inferior a 2 14 = 16.384. Más allá de esos caracteres de uso moderno, todos los demás pueden definirse como obsoletos o raros; estos son mejores candidatos para el registro de uso privado que para congestionar la lista pública de Unicode generalmente útil.
A principios de 1989, el grupo de trabajo de Unicode se amplió para incluir a Ken Whistler y Mike Kernaghan de Metaphor, Karen Smith-Yoshimura y Joan Aliprand de Research Libraries Group , y Glenn Wright de Sun Microsystems . En 1990, Michel Suignard y Asmus Freytag de Microsoft y Rick McGowan de NeXT también se habían unido al grupo. A finales de 1990, se había completado la mayor parte del trabajo de reasignación de los estándares existentes y estaba listo un borrador de revisión final de Unicode.
El Consorcio Unicode se constituyó en California el 3 de enero de 1991, [9] y el primer volumen del Estándar Unicode se publicó en octubre de ese mismo año. El segundo volumen, que ahora incorpora los ideogramas Han, se publicó en junio de 1992.
En 1996, se implementó un mecanismo de caracteres sustitutos en Unicode 2.0, de modo que Unicode ya no estaba restringido a 16 bits. Esto aumentó el espacio de código Unicode a más de un millón de puntos de código, lo que permitió la codificación de muchos alfabetos históricos, como los jeroglíficos egipcios , y miles de caracteres raramente utilizados u obsoletos que no se habían previsto para su inclusión en el estándar. Entre estos caracteres hay varios caracteres CJK raramente utilizados, muchos de los cuales se utilizan principalmente en nombres propios, lo que los hace mucho más necesarios para una codificación universal de lo que la arquitectura Unicode original previó. [10]
La versión 1.0 de la especificación TrueType de Microsoft, publicada en 1992, utilizó el nombre "Apple Unicode" en lugar de "Unicode" para el ID de plataforma en la tabla de nombres.
El Consorcio Unicode es una organización sin fines de lucro que coordina el desarrollo de Unicode. Entre sus miembros de pleno derecho se encuentran la mayoría de las principales empresas de software y hardware informático (y algunas otras) con algún interés en los estándares de procesamiento de texto, entre ellas Adobe , Apple , Google , IBM , Meta (anteriormente Facebook), Microsoft , Netflix y SAP . [11]
A lo largo de los años, varios países y organismos gubernamentales han sido miembros del Consorcio Unicode. En la actualidad, sólo el Ministerio de Dotaciones y Asuntos Religiosos (Omán) es miembro pleno con derecho a voto. [11]
El Consorcio tiene el ambicioso objetivo de reemplazar eventualmente los esquemas de codificación de caracteres existentes con Unicode y sus esquemas estándar de Formato de Transformación Unicode (UTF), ya que muchos de los esquemas existentes son limitados en tamaño y alcance y son incompatibles con entornos multilingües .
Unicode cubre actualmente la mayoría de los principales sistemas de escritura que se utilizan hoy en día. [12] [ se necesita una mejor fuente ]
A partir de 2024 [update], un total de 168 escrituras [13] están incluidas en la última versión de Unicode (que abarca alfabetos , abugidas y silabarios ), aunque todavía hay escrituras que aún no están codificadas, en particular las que se utilizan principalmente en contextos históricos, litúrgicos y académicos. También se producen más adiciones de caracteres a las escrituras ya codificadas, así como símbolos, en particular para matemáticas y música (en forma de notas y símbolos rítmicos).
El Comité de la Hoja de Ruta de Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) [14] mantiene la lista de escrituras que son candidatas o candidatas potenciales para codificación y sus asignaciones tentativas de bloques de código en la página de la Hoja de Ruta de Unicode [15] del sitio web del Consorcio Unicode . Para algunas escrituras en la Hoja de Ruta, como Jurchen y Khitan , se han hecho propuestas de codificación y están avanzando en el proceso de aprobación. Para otras escrituras, como Numidian y Rongorongo , todavía no se ha hecho ninguna propuesta, y esperan un acuerdo sobre el repertorio de caracteres y otros detalles de las comunidades de usuarios involucradas.
Algunas escrituras inventadas modernas que aún no se han incluido en Unicode (por ejemplo, Tengwar ) o que no califican para su inclusión en Unicode debido a la falta de uso en el mundo real (por ejemplo, Klingon ) están incluidas en el Registro Unicode de ConScript , junto con asignaciones de códigos de Áreas de uso privado no oficiales pero ampliamente utilizadas .
También existe una Iniciativa de Fuentes Unicode Medievales centrada en caracteres latinos medievales especiales. Parte de estas propuestas ya se han incluido en Unicode.
La Script Encoding Initiative [16] , un proyecto dirigido por Deborah Anderson en la Universidad de California, Berkeley, se fundó en 2002 con el objetivo de financiar propuestas para scripts que aún no están codificados en el estándar. El proyecto se ha convertido en una fuente importante de propuestas de adiciones al estándar en los últimos años. [17]
El Consorcio Unicode, junto con la ISO, han desarrollado un repertorio compartido tras la publicación inicial del Estándar Unicode : Unicode y el Conjunto de caracteres codificados universales (UCS) de la ISO utilizan nombres de caracteres y puntos de código idénticos. Sin embargo, las versiones Unicode difieren de sus equivalentes ISO en dos aspectos importantes.
Mientras que el UCS es un mapa de caracteres simple, Unicode especifica las reglas, algoritmos y propiedades necesarias para lograr la interoperabilidad entre diferentes plataformas e idiomas. Por lo tanto, el estándar Unicode incluye más información, que cubre temas en profundidad como la codificación bit a bit, la intercalación y la representación. También proporciona un catálogo completo de propiedades de caracteres, incluidas las necesarias para admitir texto bidireccional , así como gráficos visuales y conjuntos de datos de referencia para ayudar a los implementadores. Anteriormente, el estándar Unicode se vendía como un volumen impreso que contenía la especificación básica completa, anexos estándar, [nota 2] y gráficos de códigos. Sin embargo, la versión 5.0, publicada en 2006, fue la última versión impresa de esta manera. A partir de la versión 5.2, solo se puede comprar la especificación básica, publicada como un libro de bolsillo impreso a pedido. [18] El texto completo, por otro lado, se publica como un PDF gratuito en el sitio web de Unicode.
Una razón práctica para este método de publicación destaca la segunda diferencia significativa entre el UCS y Unicode: la frecuencia con la que se publican versiones actualizadas y se añaden nuevos caracteres. El estándar Unicode ha publicado regularmente versiones ampliadas anuales, en ocasiones con más de una versión publicada en un año calendario y con casos excepcionales en los que el lanzamiento programado tuvo que posponerse. Por ejemplo, en abril de 2020, un mes después de la publicación de la versión 13.0, el Consorcio Unicode anunció que había cambiado la fecha de lanzamiento prevista para la versión 14.0, retrasándola seis meses hasta septiembre de 2021 debido a la pandemia de COVID-19 .
Unicode 16.0, la última versión, se lanzó el 10 de septiembre de 2024. Agregó 5185 caracteres y siete nuevas escrituras: Garay , Gurung Khema , Kirat Rai , Ol Onal , Sunuwar , Todhri y Tulu-Tigalari . [19]
Hasta el momento, se han publicado las siguientes versiones del estándar Unicode . Las versiones actualizadas, que no incluyen ningún cambio en el repertorio de caracteres, se indican con el tercer número (por ejemplo, "versión 4.0.1") y se omiten en la tabla siguiente. [20]
El Consorcio Unicode publica normalmente una nueva versión del Estándar Unicode una vez al año. Se prevé que la versión 17.0, la próxima versión principal, incluya 4301 nuevos caracteres CJK unificados . [57] [58]
El estándar Unicode define un espacio de código : [59] una secuencia de números enteros llamados puntos de código [60] en el rango de 0 a1 114 111 , anotado según el estándar como U+0000 – U+10FFFF . [61] El espacio de código es una representación sistemática e independiente de la arquitectura del estándar Unicode ; el texto real se procesa como datos binarios a través de una de varias codificaciones Unicode, como UTF-8 .
En esta notación normativa, el prefijo de dos caracteres U+siempre precede a un punto de código escrito, [62] y los puntos de código en sí se escriben como números hexadecimales . Siempre se escriben al menos cuatro dígitos hexadecimales, con ceros iniciales antepuestos según sea necesario. Por ejemplo, el punto de código U+00F7 ÷ SIGNO DE DIVISIÓN se rellena con dos ceros iniciales, pero U+13254 𓉔 JEROGLIFO EGIPCIO O004 ( 
) no está rellenado. [63]
Hay un total de 2 20 + (2 16 − 2 11 ) =1 112 064 puntos de código válidos dentro del espacio de código. (Este número surge de las limitaciones de la codificación de caracteres UTF-16 , que puede codificar los 2 16 puntos de código en el rango U+0000 a U+FFFF, excepto los 2 11 puntos de código en el rango U+D800 a U+DFFF , que se utilizan como pares sustitutos para codificar los 2 20 puntos de código en el rango U+10000 a U+10FFFF ).
El espacio de código Unicode se divide en 17 planos , numerados del 0 al 16. El plano 0 es el plano multilingüe básico (BMP) y contiene los caracteres más utilizados. Se accede a todos los puntos de código del BMP como una sola unidad de código en codificación UTF-16 y se pueden codificar en uno, dos o tres bytes en UTF-8. Se accede a los puntos de código de los planos 1 a 16 (los planos suplementarios ) como pares sustitutos en UTF-16 y se codifican en cuatro bytes en UTF-8 .
Dentro de cada plano, los caracteres se asignan dentro de bloques con nombre de caracteres relacionados. El tamaño de un bloque siempre es un múltiplo de 16 y, a menudo, un múltiplo de 128, pero en otros casos es arbitrario. Los caracteres necesarios para una determinada secuencia de comandos pueden distribuirse en varios bloques diferentes, potencialmente disjuntos, dentro del espacio de código.
A cada punto de código se le asigna una clasificación, que se indica como la propiedad Categoría general del punto de código . Aquí, en el nivel superior, los puntos de código se clasifican como Letra, Marca, Número, Puntuación, Símbolo, Separador u Otro. En cada categoría, cada punto de código se subcategoriza a su vez. En la mayoría de los casos, se deben utilizar otras propiedades para describir adecuadamente todas las características de cualquier punto de código determinado.
ElLos 1024 puntos en el rango U+D800 – U+DBFF se conocen como puntos de código de alto sustituto , y los puntos de código en el rango U+DC00 – U+DFFF (Los puntos de código de 1024 caracteres se conocen como puntos de código de sustitución baja . Un punto de código de sustitución alta seguido de un punto de código de sustitución baja forma un par de sustitución en UTF-16 para representar puntos de código mayores que U+FFFF . En principio, estos puntos de código no se pueden utilizar de otra manera, aunque en la práctica esta regla suele ignorarse, especialmente cuando no se utiliza UTF-16.
Se garantiza que nunca se asignará un pequeño conjunto de puntos de código a caracteres, aunque terceros pueden hacer un uso independiente de ellos a su discreción. Hay 66 de estos no caracteres : U+FDD0 – U+FDEF y los dos últimos puntos de código en cada uno de los 17 planos (por ejemplo, U+FFFE , U+FFFF , U+1FFFE , U+1FFFF , ..., U+10FFFE , U+10FFFF ). El conjunto de no caracteres es estable y nunca se definirán nuevos no caracteres. [64] Al igual que los sustitutos, la regla de que no se pueden utilizar a menudo se ignora, aunque la operación de la marca de orden de bytes supone que U+FFFE nunca será el primer punto de código en un texto. La exclusión de sustitutos y no caracteres deja1 111 998 puntos de código disponibles para su uso.
Los puntos de código de uso privado se consideran asignados, pero no tienen una interpretación especificada intencionalmente por el Estándar Unicode [65], de modo que cualquier intercambio de dichos puntos de código requiere un acuerdo independiente entre el emisor y el receptor en cuanto a su interpretación. Hay tres áreas de uso privado en el espacio de código Unicode:
Los caracteres gráficos son aquellos definidos por el estándar Unicode para tener una semántica particular, ya sea que tengan una forma de glifo visible o representen un espacio visible. A partir de Unicode 16.0, existen154 826 caracteres gráficos.
Los caracteres de formato son caracteres que no tienen una apariencia visible pero que pueden tener un efecto en la apariencia o el comportamiento de los caracteres adyacentes. Por ejemplo, U+200C ZERO WIDTH NON-JOINER y U+200D ZERO WIDTH JOINER se pueden utilizar para cambiar el comportamiento de modelado predeterminado de los caracteres adyacentes (por ejemplo, para inhibir las ligaduras o solicitar la formación de ligaduras). Hay 172 caracteres de formato en Unicode 16.0.
65 puntos de código, los rangos U+0000 – U+001F y U+007F – U+009F , están reservados como códigos de control , correspondientes a los códigos de control C0 y C1 según se definen en ISO/IEC 6429. U +0089 TABULACIÓN DE LÍNEA , U+008A SALTO DE LÍNEA y U+000D RETORNO DE CARRO se utilizan ampliamente en textos que utilizan Unicode. En un fenómeno conocido como mojibake , los puntos de código C1 se decodifican incorrectamente de acuerdo con la página de códigos Windows-1252 , que anteriormente se utilizaba ampliamente en contextos de Europa occidental.
Juntos, los caracteres gráficos, de formato, de código de control y de uso privado se denominan colectivamente caracteres asignados . Los puntos de código reservados son aquellos puntos de código que son válidos y están disponibles para su uso, pero que aún no se han asignado. A partir de Unicode 15.1, hay819 467 puntos de código reservados.
El conjunto de caracteres gráficos y de formato definidos por Unicode no se corresponde directamente con el repertorio de caracteres abstractos representables bajo Unicode. Unicode codifica caracteres asociando un carácter abstracto con un punto de código particular. [66] Sin embargo, no todos los caracteres abstractos se codifican como un único carácter Unicode, y algunos caracteres abstractos pueden representarse en Unicode mediante una secuencia de dos o más caracteres. Por ejemplo, una letra minúscula latina "i" con un ogonek , un punto encima y un acento agudo , que se requiere en lituano , se representa mediante la secuencia de caracteres U+012F ; U+0307 ; U+0301 . Unicode mantiene una lista de secuencias de caracteres con nombres únicos para caracteres abstractos que no están codificados directamente en Unicode. [67]
Todos los caracteres asignados tienen un nombre único e inmutable con el que se los identifica. Esta inmutabilidad ha sido garantizada desde la versión 2.0 del Estándar Unicode por su política de Estabilidad de Nombres. [64] En los casos en que un nombre es seriamente defectuoso y engañoso, o tiene un error tipográfico grave, se puede definir un alias formal que se recomienda que las aplicaciones utilicen en lugar del nombre oficial del carácter. Por ejemplo, U+A015 ꀕ YI SÍLABA WU tiene el alias formal YI SÍLABA ITERACIÓN MARCA , y U+FE18 ︘ FORMA DE PRESENTACIÓN PARA SOPORTE LENTICULAR BLANCO DERECHO VERTICAL ( sic ) tiene el alias formal FORMA DE PRESENTACIÓN PARA SOPORTE LENTICULAR BLANCO DERECHO VERTICAL . [68]
Unicode incluye un mecanismo para modificar caracteres que amplía en gran medida el repertorio de glifos admitido. Esto cubre el uso de marcas diacríticas de combinación que el usuario puede agregar después del carácter base. Se pueden aplicar múltiples diacríticos de combinación simultáneamente al mismo carácter. Unicode también contiene versiones precompuestas de la mayoría de las combinaciones de letras y diacríticos en el uso normal. Esto simplifica la conversión hacia y desde codificaciones heredadas y permite que las aplicaciones usen Unicode como un formato de texto interno sin tener que implementar caracteres de combinación. Por ejemplo, ése puede representar en Unicode como U+0065 e LETRA E MINÚSCULA LATINA seguida de U+0301 ◌́ ACENTO AGUDO COMBINADO ), y equivalentemente como el carácter precompuesto U+00E9 é LETRA E MINÚSCULA LATINA CON ACENTO AGUDO . Por lo tanto, los usuarios a menudo tienen múltiples formas equivalentes de codificar el mismo carácter. El mecanismo de equivalencia canónica dentro del estándar Unicode garantiza la intercambiabilidad práctica de estas codificaciones equivalentes.
Un ejemplo de esto surge con el alfabeto coreano Hangul : Unicode proporciona un mecanismo para componer sílabas Hangul a partir de sus subcomponentes individuales Hangul Jamo . Sin embargo, también proporciona11 172 combinaciones de sílabas precompuestas a partir del jamo más común.
En la actualidad, los caracteres CJK solo tienen códigos para radicales no componibles y formas precompuestas. La mayoría de los caracteres Han se han compuesto intencionalmente a partir de elementos ortográficos más simples llamados radicales o se han reconstruido como composiciones de ellos , por lo que, en principio, Unicode podría haber permitido su composición como lo hizo con Hangul. Si bien esto podría haber reducido en gran medida la cantidad de puntos de código necesarios, además de permitir la síntesis algorítmica de muchos caracteres nuevos arbitrarios, las complejidades de las etimologías de los caracteres y la naturaleza post-hoc de los sistemas radicales agregan una inmensa complejidad a la propuesta. De hecho, los intentos de diseñar codificaciones CJK sobre la base de la composición de radicales se han encontrado con dificultades que resultan de la realidad de que los caracteres chinos no se descomponen de manera tan simple o tan regular como lo hace Hangul.
El bloque de suplemento de radicales CJK está asignado al rango U+2E80 – U+2EFF y los radicales Kangxi están asignados a U+2F00 – U+2FDF . El bloque de secuencias de descripción ideográfica cubre el rango U+2FF0 – U+2FFB , pero el estándar Unicode advierte contra el uso de sus caracteres como representación alternativa de caracteres codificados en otro lugar:
Este proceso es diferente de la codificación formal de un ideograma. No existe una descripción canónica de los ideogramas no codificados; no se asigna ninguna semántica a los ideogramas descritos; no se define ninguna equivalencia para los ideogramas descritos. Conceptualmente, las descripciones ideográficas se parecen más a la frase inglesa "una 'e' con acento agudo" que a la secuencia de caracteres <U+0065, U+0301>.
Muchos sistemas de escritura, incluidos el árabe y el devanāgarī , tienen reglas ortográficas especiales que requieren que ciertas combinaciones de formas de letras se combinen en formas de ligadura especiales . Las reglas que rigen la formación de ligaduras pueden ser bastante complejas y requieren tecnologías especiales de modelado de escritura, como ACE (motor caligráfico árabe de DecoType en la década de 1980 y utilizado para generar todos los ejemplos árabes en las ediciones impresas del estándar Unicode ), que se convirtió en la prueba de concepto para OpenType (de Adobe y Microsoft), Graphite (de SIL International ) o AAT (de Apple).
Las fuentes también incluyen instrucciones que indican al sistema operativo cómo generar correctamente las distintas secuencias de caracteres. Una solución sencilla para la colocación de las marcas de combinación o diacríticos es asignarles un ancho de cero y colocar el glifo en sí a la izquierda o derecha del glifo lateral izquierdo (según la dirección de la escritura con la que se pretende utilizar). Una marca gestionada de esta manera aparecerá sobre cualquier carácter que la preceda, pero no ajustará su posición en relación con el ancho o la altura del glifo base; puede resultar visualmente extraño y puede superponerse a algunos glifos. El apilamiento real es imposible, pero se puede aproximar en casos limitados (por ejemplo, las vocales y marcas de tono de combinación superior tailandesas pueden estar a diferentes alturas para empezar). Por lo general, este enfoque solo es eficaz en fuentes monoespaciadas, pero se puede utilizar como un método de representación alternativo cuando fallan los métodos más complejos.
Varios subconjuntos de Unicode están estandarizados: Microsoft Windows desde Windows NT 4.0 admite WGL-4 con 657 caracteres, lo que se considera que admite todos los idiomas europeos contemporáneos que utilizan la escritura latina, griega o cirílica. Otros subconjuntos estandarizados de Unicode incluyen los subconjuntos europeos multilingües: [70] MES-1 (sólo escrituras latinas; 335 caracteres), MES-2 (latino, griego y cirílico; 1062 caracteres) [71] y MES-3A y MES-3B (dos subconjuntos más grandes, no se muestran aquí). MES-2 incluye todos los caracteres de MES-1 y WGL-4.
La norma DIN 91379 [72] especifica un subconjunto de letras Unicode, caracteres especiales y secuencias de letras y signos diacríticos para permitir la representación correcta de nombres y simplificar el intercambio de datos en Europa. Esta norma es compatible con todos los idiomas oficiales de todos los países de la Unión Europea, así como con las lenguas minoritarias alemanas y los idiomas oficiales de Islandia, Liechtenstein, Noruega y Suiza. Para permitir la transliteración de nombres en otros sistemas de escritura al alfabeto latino de acuerdo con las normas ISO pertinentes, se proporcionan todas las combinaciones necesarias de letras base y signos diacríticos.
El software de renderizado que no puede procesar un carácter Unicode de forma adecuada suele mostrarlo como un rectángulo abierto o como U+FFFD para indicar la posición del carácter no reconocido. Algunos sistemas han intentado proporcionar más información sobre dichos caracteres. La fuente Last Resort de Apple mostrará un glifo sustituto que indica el rango Unicode del carácter, y la fuente Unicode de reserva de SIL International mostrará un cuadro que muestra el valor escalar hexadecimal del carácter.
Se han especificado varios mecanismos para almacenar una serie de puntos de código como una serie de bytes.
Unicode define dos métodos de mapeo: las codificaciones de Formato de Transformación Unicode (UTF) y las codificaciones de Conjunto Universal de Caracteres Codificados (UCS). Una codificación mapea (posiblemente un subconjunto de) el rango de puntos de código Unicode a secuencias de valores en algún rango de tamaño fijo, denominado unidades de código . Todas las codificaciones UTF mapean puntos de código a una secuencia única de bytes. [73] Los números en los nombres de las codificaciones indican el número de bits por unidad de código (para codificaciones UTF) o el número de bytes por unidad de código (para codificaciones UCS y UTF-1 ). UTF-8 y UTF-16 son las codificaciones más comúnmente utilizadas. UCS-2 es un subconjunto obsoleto de UTF-16; UCS-4 y UTF-32 son funcionalmente equivalentes.
Las codificaciones UTF incluyen:
UTF-8 utiliza de una a cuatro unidades de 8 bits ( bytes ) por punto de código y, al ser compacto para los alfabetos latinos y compatible con ASCII, proporciona la codificación estándar de facto para el intercambio de texto Unicode. FreeBSD y las distribuciones de Linux más recientes lo utilizan como reemplazo directo de las codificaciones heredadas en el manejo general de texto.
Las codificaciones UCS-2 y UTF-16 especifican la marca de orden de bytes (BOM) Unicode para usar al comienzo de los archivos de texto, que se puede usar para la detección del orden de bytes (o detección del orden de bytes ). La BOM, codificada como U+FEFF ZERO WIDTH NO-BREAK SPACE , tiene la importante propiedad de no tener ambigüedad en la reordenación de bytes, independientemente de la codificación Unicode utilizada; U+FFFE (el resultado del intercambio de bytes U+FEFF ) no equivale a un carácter legal, y U+FEFF en lugares distintos del comienzo del texto transmite el espacio sin separación de ancho cero.
El mismo carácter convertido a UTF-8 se convierte en la secuencia de bytes EF BB BF. El estándar Unicode permite que el BOM "pueda servir como firma para texto codificado en UTF-8 donde el conjunto de caracteres no está marcado". [74] Algunos desarrolladores de software lo han adoptado para otras codificaciones, incluido UTF-8, en un intento de distinguir UTF-8 de las páginas de códigos locales de 8 bits . Sin embargo, RFC 3629, el estándar UTF-8, recomienda que se prohíban las marcas de orden de bytes en los protocolos que utilizan UTF-8, pero analiza los casos en los que esto puede no ser posible. Además, la gran restricción de patrones posibles en UTF-8 (por ejemplo, no puede haber ningún byte solitario con el bit alto establecido) significa que debería ser posible distinguir UTF-8 de otras codificaciones de caracteres sin depender del BOM.
En UTF-32 y UCS-4, una unidad de código de 32 bits sirve como una representación bastante directa del punto de código de cualquier carácter (aunque el orden de bits, que varía según las diferentes plataformas, afecta la forma en que la unidad de código se manifiesta como una secuencia de bytes). En las otras codificaciones, cada punto de código puede representarse mediante un número variable de unidades de código. UTF-32 se utiliza ampliamente como una representación interna de texto en programas (a diferencia del texto almacenado o transmitido), ya que todos los sistemas operativos Unix que utilizan los compiladores gcc para generar software lo utilizan como la codificación estándar de " caracteres anchos ". Algunos lenguajes de programación, como Seed7 , utilizan UTF-32 como una representación interna para cadenas y caracteres. Las versiones recientes del lenguaje de programación Python (a partir de la 2.2) también pueden configurarse para utilizar UTF-32 como la representación de cadenas Unicode, lo que difunde de manera efectiva dicha codificación en software codificado de alto nivel .
Punycode , otra forma de codificación, permite la codificación de cadenas Unicode en el conjunto de caracteres limitados que admite el Sistema de nombres de dominio (DNS) basado en ASCII . La codificación se utiliza como parte de IDNA , que es un sistema que permite el uso de nombres de dominio internacionalizados en todos los alfabetos que admite Unicode. Las propuestas anteriores y ahora históricas incluyen UTF-5 y UTF-6 .
GB18030 es otra forma de codificación para Unicode, de la Administración de Normalización de China . Es el conjunto de caracteres oficial de la República Popular China (RPC). BOCU-1 y SCSU son esquemas de compresión Unicode. La RFC del Día de los Inocentes de 2005 especificó dos codificaciones UTF de parodia, UTF-9 y UTF-18 .
Unicode, en forma de UTF-8 , ha sido la codificación más común para la World Wide Web desde 2008. [75] Tiene una adopción casi universal, y gran parte del contenido que no es UTF-8 se encuentra en otras codificaciones Unicode, por ejemplo, UTF-16 . A partir de 2024 [update], UTF-8 representa en promedio el 97,8% de todas las páginas web (y 987 de las 1000 páginas web mejor clasificadas). [76] Aunque muchas páginas solo usan caracteres ASCII para mostrar contenido, UTF-8 fue diseñado con ASCII de 8 bits como un subconjunto y casi ningún sitio web declara ahora que su codificación es solo ASCII en lugar de UTF-8. [77] Más de un tercio de los idiomas rastreados tienen un uso 100% de UTF-8.
Todos los protocolos de Internet mantenidos por Internet Engineering Task Force , por ejemplo FTP , [78] han requerido soporte para UTF-8 desde la publicación de RFC 2277 en 1998, que especificó que todos los protocolos IETF "DEBEN poder usar el juego de caracteres UTF-8". [79]
Unicode se ha convertido en el esquema dominante para el procesamiento y almacenamiento interno de texto. Aunque una gran cantidad de texto todavía se almacena en codificaciones heredadas, Unicode se usa casi exclusivamente para construir nuevos sistemas de procesamiento de información. Los primeros en adoptarlo tendieron a usar UCS-2 (el precursor obsoleto de dos bytes de longitud fija de UTF-16) y luego pasaron a UTF-16 (el estándar actual de longitud variable), ya que esta era la forma menos disruptiva de agregar soporte para caracteres no BMP. El sistema más conocido de este tipo es Windows NT (y sus descendientes, 2000 , XP , Vista , 7 , 8 , 10 y 11 ), que usa UTF-16 como la única codificación de caracteres interna. Los entornos de código de bytes Java y .NET , macOS y KDE también lo usan para la representación interna. Se puede instalar soporte parcial para Unicode en Windows 9x a través de Microsoft Layer for Unicode .
UTF-8 (desarrollado originalmente para Plan 9 ) [80] se ha convertido en la principal codificación de almacenamiento en la mayoría de los sistemas operativos tipo Unix (aunque algunas bibliotecas también utilizan otras) porque es un reemplazo relativamente fácil para los conjuntos de caracteres ASCII extendidos tradicionales . UTF-8 también es la codificación Unicode más común utilizada en documentos HTML en la World Wide Web .
Los motores de representación de texto multilingües que utilizan Unicode incluyen Uniscribe y DirectWrite para Microsoft Windows, ATSUI y Core Text para macOS, y Pango para GTK+ y el escritorio GNOME .
Debido a que los diseños de teclado no pueden tener combinaciones de teclas simples para todos los caracteres, varios sistemas operativos proporcionan métodos de entrada alternativos que permiten el acceso a todo el repertorio.
La norma ISO/IEC 14755 [ 81] , que estandariza los métodos para introducir caracteres Unicode a partir de sus puntos de código, especifica varios métodos. Existe el método básico , en el que una secuencia de inicio va seguida de la representación hexadecimal del punto de código y la secuencia de finalización . También se especifica un método de entrada por selección de pantalla , en el que los caracteres se enumeran en una tabla en una pantalla, como en un programa de mapas de caracteres.
Las herramientas en línea para encontrar el punto de código de un carácter conocido incluyen Unicode Lookup [82] de Jonathan Hedley y Shapecatcher [83] de Benjamin Milde. En Unicode Lookup, se ingresa una clave de búsqueda (por ejemplo, "fracciones") y se devuelve una lista de caracteres correspondientes con sus puntos de código. En Shapecatcher, basado en Shape context , se dibuja el carácter en un cuadro y se devuelve una lista de caracteres que se aproximan al dibujo, con sus puntos de código.
MIME define dos mecanismos diferentes para codificar caracteres no ASCII en el correo electrónico, dependiendo de si los caracteres están en los encabezados del correo electrónico (como el "Asunto:") o en el cuerpo del texto del mensaje; en ambos casos, se identifica el conjunto de caracteres original, así como una codificación de transferencia. Para la transmisión de correo electrónico de Unicode, se recomienda el conjunto de caracteres UTF-8 y la codificación de transferencia Base64 o Quoted-printable , dependiendo de si gran parte del mensaje consta de caracteres ASCII . Los detalles de los dos mecanismos diferentes se especifican en los estándares MIME y generalmente están ocultos para los usuarios del software de correo electrónico.
La IETF ha definido [84] [85] un marco para el correo electrónico internacionalizado utilizando UTF-8, y ha actualizado [86] [87] [88] [89] varios protocolos de acuerdo con ese marco.
La adopción de Unicode en el correo electrónico ha sido muy lenta. [ cita requerida ] Algunos textos del este de Asia todavía están codificados en codificaciones como ISO-2022 , y algunos dispositivos, como los teléfonos móviles, [ cita requerida ] aún no pueden manejar correctamente los datos Unicode. Sin embargo, la compatibilidad ha mejorado. Muchos de los principales proveedores de correo gratuito, como Yahoo! Mail , Gmail y Outlook.com , lo admiten.
Todas las recomendaciones del W3C han utilizado Unicode como conjunto de caracteres para sus documentos desde HTML 4.0. Los navegadores web han admitido Unicode, especialmente UTF-8, durante muchos años. Solían existir problemas de visualización que se debían principalmente a problemas relacionados con las fuentes ; por ejemplo, la versión 6 y anteriores de Microsoft Internet Explorer no mostraban muchos puntos de código a menos que se les indicara explícitamente que utilizaran una fuente que los contuviera. [90]
Aunque las reglas de sintaxis pueden afectar el orden en el que se permite que aparezcan los caracteres, los documentos XML (incluido XHTML ), por definición, [91] comprenden caracteres de la mayoría de los puntos de código Unicode, con la excepción de:
Los caracteres HTML se manifiestan directamente como bytes según la codificación del documento, si la codificación los admite, o los usuarios pueden escribirlos como referencias de caracteres numéricos según el punto de código Unicode del carácter. Por ejemplo, las referencias Δ, Й, ק, م, ๗, あ, 叶, 葉, y 말(o los mismos valores numéricos expresados en hexadecimal, con omo prefijo) deberían aparecer en todos los navegadores como Δ, Й, ק, م, ๗, あ, 叶, 葉 y 말.
Al especificar URI , por ejemplo como URL en solicitudes HTTP , los caracteres no ASCII deben codificarse en porcentaje .
Unicode no se ocupa en principio de las fuentes per se , viéndolas como opciones de implementación. [92] Cualquier carácter dado puede tener muchos alógrafos , desde las más comunes negrita, cursiva y formas de letras base hasta estilos decorativos complejos. Una fuente es "compatible con Unicode" si se puede acceder a los glifos de la fuente utilizando puntos de código definidos en el estándar Unicode . [93] El estándar no especifica un número mínimo de caracteres que deben incluirse en la fuente; algunas fuentes tienen un repertorio bastante pequeño.
Las fuentes gratuitas y de venta minorista basadas en Unicode están ampliamente disponibles, ya que TrueType y OpenType admiten Unicode (y Web Open Font Format (WOFF y WOFF2 ) se basa en ellos). Estos formatos de fuente asignan puntos de código Unicode a glifos, pero los archivos de fuentes OpenType y TrueType están restringidos a 65.535 glifos. Los archivos de colección proporcionan un mecanismo de "modo de espacio" para superar este límite en un solo archivo de fuente. (Sin embargo, cada fuente dentro de la colección aún tiene el límite de 65.535). Un archivo de colección TrueType normalmente tendría una extensión de archivo ".ttc".
Existen miles de fuentes en el mercado, pero menos de una docena de fuentes (a veces descritas como fuentes "pan-Unicode") intentan soportar la mayoría del repertorio de caracteres de Unicode. En cambio, las fuentes basadas en Unicode generalmente se enfocan en soportar solo ASCII básico y escrituras particulares o conjuntos de caracteres o símbolos. Varias razones justifican este enfoque: las aplicaciones y los documentos rara vez necesitan reproducir caracteres de más de uno o dos sistemas de escritura; las fuentes tienden a demandar recursos en entornos informáticos; y los sistemas operativos y las aplicaciones muestran una inteligencia creciente con respecto a la obtención de información de glifos de archivos de fuentes separados según sea necesario, es decir, sustitución de fuentes . Además, diseñar un conjunto consistente de instrucciones de reproducción para decenas de miles de glifos constituye una tarea monumental; tal empresa pasa el punto de rendimiento decreciente para la mayoría de los tipos de letra.
Unicode soluciona parcialmente el problema de las nuevas líneas que se produce al intentar leer un archivo de texto en diferentes plataformas. Unicode define una gran cantidad de caracteres que las aplicaciones compatibles deben reconocer como terminadores de línea.
En cuanto a la nueva línea, Unicode introdujo U+2028 LINE SEPARATOR y U+2029 PARAGRAPH SEPARATOR . Este fue un intento de proporcionar una solución Unicode para codificar párrafos y líneas semánticamente, reemplazando potencialmente todas las diversas soluciones de la plataforma. Al hacerlo, Unicode proporciona una forma de evitar las soluciones históricas dependientes de la plataforma. No obstante, pocas soluciones Unicode, si es que hay alguna, han adoptado estos separadores de línea y párrafo Unicode como los únicos caracteres canónicos de final de línea. Sin embargo, un enfoque común para resolver este problema es a través de la normalización de nueva línea. Esto se logra con el sistema de texto Cocoa en Mac OS X y también con las recomendaciones XML y HTML del W3C. En este enfoque, cada carácter de nueva línea posible se convierte internamente en una nueva línea común (cuál no importa realmente, ya que es una operación interna solo para la representación). En otras palabras, el sistema de texto puede tratar correctamente el carácter como una nueva línea, independientemente de la codificación real de la entrada.
El Grupo de Investigación Ideográfica (IRG) tiene la tarea de asesorar al Consorcio y a la ISO en relación con la unificación del Han, o Unihan, especialmente la incorporación de ideogramas unificados y de compatibilidad del CJK al repertorio. El IRG está compuesto por expertos de cada región que históricamente ha utilizado caracteres chinos . Sin embargo, a pesar de las deliberaciones dentro del comité, la unificación del Han ha sido consistentemente uno de los aspectos más controvertidos del Estándar Unicode desde la génesis del proyecto. [94]
Los estándares de conjuntos de caracteres existentes, como el japonés JIS X 0208 (codificado por Shift JIS ), definieron criterios de unificación, es decir, reglas para determinar cuándo un carácter chino variante debe considerarse una diferencia de escritura a mano/fuente (y, por lo tanto, unificado), frente a una diferencia ortográfica (que debe codificarse por separado). El modelo de caracteres de Unicode para caracteres CJK se basó en los criterios de unificación utilizados por JIS X 0208, así como en los desarrollados por la Asociación para un Código Chino Común en China. [95] Debido al principio del estándar de codificar variantes semánticas en lugar de estilísticas, Unicode ha recibido críticas por no asignar puntos de código a ciertas variantes de kanji raras y arcaicas , lo que posiblemente complica el procesamiento de nombres japoneses antiguos y poco comunes. Dado que pone especial énfasis en que el chino, el japonés y el coreano comparten muchos caracteres en común, la unificación Han también se percibe a veces como si tratara a los tres como la misma cosa. [96]
Existen codificaciones alternativas menos utilizadas, a menudo anteriores a Unicode, con modelos de caracteres que difieren de este paradigma, destinados a preservar las diversas diferencias estilísticas entre las formas de caracteres regionales y/o no estándar. Un ejemplo es el Código TRON preferido por algunos usuarios para manejar texto japonés histórico, aunque no ampliamente adoptado entre el público japonés. Otro es la codificación CCCII adoptada por los sistemas de bibliotecas en Hong Kong , Taiwán y los Estados Unidos . Estos tienen sus propios inconvenientes en el uso general, lo que lleva a que la codificación Big5 (introducida en 1984, cuatro años después de CCCII) se haya vuelto más común que CCCII fuera de los sistemas de bibliotecas. [97] Aunque el trabajo en Apple basado en el Tesauro CJK de Research Libraries Group , que se utilizó para mantener la variante EACC de CCCII, fue uno de los predecesores directos del conjunto Unihan de Unicode , Unicode adoptó el modelo de unificación de estilo JIS. [95]
La primera versión de Unicode tenía un repertorio de menos de 21.000 caracteres han, limitados en gran medida a los de uso moderno relativamente común. A partir de la versión 16.0, el estándar ahora codifica más de 97.000 caracteres han, y se sigue trabajando para agregar miles más, en su mayoría caracteres históricos y variantes dialectales utilizados en toda la sinosfera .
Los tipos de letra modernos ofrecen un medio para abordar algunas de las cuestiones prácticas a la hora de representar caracteres Han unificados con diversas representaciones gráficas regionales. La tabla OpenType 'locl' permite que un renderizador seleccione un glifo diferente para cada punto de código en función de la configuración regional del texto. [98] Las secuencias de variación Unicode también pueden proporcionar anotaciones en el texto para una selección de glifo deseada; esto requiere el registro de la variante específica en la Base de datos de variación ideográfica .
Si bien los glifos apropiados para caracteres en el mismo sistema de escritura difieren solo en la cursiva, Unicode generalmente los ha unificado, como se puede ver en la comparación entre un conjunto de glifos de cursiva de siete caracteres que aparecen típicamente en textos en ruso, búlgaro tradicional, macedonio y serbio a la derecha, lo que significa que las diferencias se muestran a través de la tecnología de fuentes inteligentes o cambiando las fuentes manualmente. Se utiliza la misma técnica OpenType 'locl'. [99]
Para su uso en el alfabeto turco y el alfabeto azerí , Unicode incluye una I minúscula sin punto (ı) y una I mayúscula con punto ( İ ) independientes. Sin embargo, se utilizan las letras ASCII habituales para la I minúscula con punto y la I mayúscula sin punto , de forma similar a como se manejaban en la anterior norma ISO 8859-9 . Por lo tanto, las comparaciones sin distinción entre mayúsculas y minúsculas para esos idiomas tienen que utilizar reglas diferentes a las comparaciones sin distinción entre mayúsculas y minúsculas para otros idiomas que utilizan el alfabeto latino. [100]
Por el contrario, la eth islandesa (ð) , la D barrada (đ) y la D retrofleja (ɖ) , que normalmente [nota 4] parecen iguales en mayúsculas (Đ), reciben el tratamiento opuesto y se codifican por separado en ambas mayúsculas (a diferencia de la anterior ISO 6937 , que unifica las formas mayúsculas). Aunque permite una comparación sin distinción entre mayúsculas y minúsculas sin necesidad de conocer el idioma del texto, este enfoque también tiene problemas, ya que requiere medidas de seguridad relacionadas con los ataques de homoglifos . [101]
Si se espera que la letra I minúscula conserve su título cuando se aplica un diacrítico también depende de las convenciones locales.
Unicode tiene una gran cantidad de homoglifos , muchos de los cuales parecen muy similares o idénticos a las letras ASCII. La sustitución de estos puede generar un identificador o URL que parezca correcto, pero que dirija a una ubicación diferente a la esperada. [102] Además, los homoglifos también se pueden usar para manipular la salida de los sistemas de procesamiento del lenguaje natural (PLN) . [103] La mitigación requiere rechazar estos caracteres, mostrarlos de manera diferente o requerir que se resuelvan en el mismo identificador; [104] todo esto es complicado debido al enorme y cambiante conjunto de caracteres. [105] [106]
En 2021, dos investigadores, uno de la Universidad de Cambridge y el otro de la Universidad de Edimburgo , publicaron un aviso de seguridad en el que afirmaban que las marcas BiDi se pueden utilizar para hacer que grandes secciones de código hagan algo diferente de lo que parecen hacer. El problema se denominó " Trojan Source ". [107] En respuesta, los editores de código comenzaron a resaltar las marcas para indicar cambios forzados en la dirección del texto. [108]
Unicode was designed to provide code-point-by-code-point round-trip format conversion to and from any preexisting character encodings, so that text files in older character sets can be converted to Unicode and then back and get back the same file, without employing context-dependent interpretation. That has meant that inconsistent legacy architectures, such as combining diacritics and precomposed characters, both exist in Unicode, giving more than one method of representing some text. This is most pronounced in the three different encoding forms for Korean Hangul. Since version 3.0, any precomposed characters that can be represented by a combined sequence of already existing characters can no longer be added to the standard to preserve interoperability between software using different versions of Unicode.
Injective mappings must be provided between characters in existing legacy character sets and characters in Unicode to facilitate conversion to Unicode and allow interoperability with legacy software. Lack of consistency in various mappings between earlier Japanese encodings such as Shift-JIS or EUC-JP and Unicode led to round-trip format conversion mismatches, particularly the mapping of the character JIS X 0208 '～' (1-33, WAVE DASH), heavily used in legacy database data, to either U+FF5E ～ FULLWIDTH TILDE (in Microsoft Windows) or U+301C 〜 WAVE DASH (other vendors).[109]
Some Japanese computer programmers objected to Unicode because it requires them to separate the use of U+005C \ REVERSE SOLIDUS (backslash) and U+00A5 ¥ YEN SIGN, which was mapped to 0x5C in JIS X 0201, and a lot of legacy code exists with this usage.[110] (This encoding also replaces tilde '~' 0x7E with macron '¯', now 0xAF.) The separation of these characters exists in ISO 8859-1, from long before Unicode.
Indic scripts such as Tamil and Devanagari are each allocated only 128 code points, matching the ISCII standard. The correct rendering of Unicode Indic text requires transforming the stored logical order characters into visual order and the forming of ligatures (also known as conjuncts) out of components. Some local scholars argued in favor of assignments of Unicode code points to these ligatures, going against the practice for other writing systems, though Unicode contains some Arabic and other ligatures for backward compatibility purposes only.[111][112][113] Encoding of any new ligatures in Unicode will not happen, in part, because the set of ligatures is font-dependent, and Unicode is an encoding independent of font variations. The same kind of issue arose for the Tibetan script in 2003 when the Standardization Administration of China proposed encoding 956 precomposed Tibetan syllables,[114] but these were rejected for encoding by the relevant ISO committee (ISO/IEC JTC 1/SC 2).[115]
Thai alphabet support has been criticized for its ordering of Thai characters. The vowels เ, แ, โ, ใ, ไ that are written to the left of the preceding consonant are in visual order instead of phonetic order, unlike the Unicode representations of other Indic scripts. This complication is due to Unicode inheriting the Thai Industrial Standard 620, which worked in the same way, and was the way in which Thai had always been written on keyboards. This ordering problem complicates the Unicode collation process slightly, requiring table lookups to reorder Thai characters for collation.[96] Even if Unicode had adopted encoding according to spoken order, it would still be problematic to collate words in dictionary order. E.g., the word แสดง [sa dɛːŋ] "perform" starts with a consonant cluster "สด" (with an inherent vowel for the consonant "ส"), the vowel แ-, in spoken order would come after the ด, but in a dictionary, the word is collated as it is written, with the vowel following the ส.
Characters with diacritical marks can generally be represented either as a single precomposed character or as a decomposed sequence of a base letter plus one or more non-spacing marks. For example, ḗ (precomposed e with macron and acute above) and ḗ (e followed by the combining macron above and combining acute above) should be rendered identically, both appearing as an e with a macron (◌̄) and acute accent (◌́), but in practice, their appearance may vary depending upon what rendering engine and fonts are being used to display the characters. Similarly, underdots, as needed in the romanization of Indic languages, will often be placed incorrectly.[citation needed] Unicode characters that map to precomposed glyphs can be used in many cases, thus avoiding the problem, but where no precomposed character has been encoded, the problem can often be solved by using a specialist Unicode font such as Charis SIL that uses Graphite, OpenType ('gsub'), or AAT technologies for advanced rendering features.
The Unicode Standard has imposed rules intended to guarantee stability.[116] Depending on the strictness of a rule, a change can be prohibited or allowed. For example, a "name" given to a code point cannot and will not change. But a "script" property is more flexible, by Unicode's own rules. In version 2.0, Unicode changed many code point "names" from version 1. At the same moment, Unicode stated that, thenceforth, an assigned name to a code point would never change. This implies that when mistakes are published, these mistakes cannot be corrected, even if they are trivial (as happened in one instance with the spelling BRAKCET for BRACKET in a character name). In 2006 a list of anomalies in character names was first published, and, as of June 2021, there were 104 characters with identified issues,[117] for example:
While Unicode defines the script designator (name) to be "Phags_Pa", in that script's character names, a hyphen is added: U+A840 ꡀ PHAGS-PA LETTER KA.[120][121] This, however, is not an anomaly, but the rule: hyphens are replaced by underscores in script designators.[120]
In 1978, the initial proposal for a set of "Universal Signs" was made by Bob Belleville at Xerox PARC. Many persons contributed ideas to the development of a new encoding design. Beginning in 1980, these efforts evolved into the Xerox Character Code Standard (XCCS) by the present author, a multilingual encoding that has been maintained by Xerox as an internal corporate standard since 1982, through the efforts of Ed Smura, Ron Pellar, and others.
Unicode arose as the result of eight years of working experience with XCCS. Its fundamental differences from XCCS were proposed by Peter Fenwick and Dave Opstad (pure 16-bit codes) and by Lee Collins (ideographic character unification). Unicode retains the many features of XCCS whose utility has been proved over the years in an international line of communication multilingual system products.
Select this deployment format if your system supports variable fonts and you prefer to use only one language, but also want full character coverage or the ability to language-tag text to use glyphs that are appropriate for the other languages (this requires an app that supports language tagging and the OpenType 'locl' GSUB feature).
Media from Commons
Textbooks from Wikibooks