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, dos codificaciones elegidas solían ser 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ó asumiendo 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 [actualizar], 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ódigos. (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 enumera 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.
Se considera que los puntos de código de uso privado están asignados, pero el estándar Unicode no especifica intencionalmente ninguna interpretación de ellos [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 enormemente el repertorio de glifos admitido. Esto cubre el uso de signos diacríticos de combinación que el usuario puede agregar después del carácter base. Se pueden aplicar múltiples signos 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 signos diacríticos en el uso normal. Esto simplifica la conversión hacia y desde codificaciones heredadas y permite que las aplicaciones utilicen 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 "an 'e' with an acute accent on it" 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. Entre las propuestas anteriores y ahora históricas se 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 [actualizar], UTF-8 representa en promedio el 98,3% de todas las páginas web (y 983 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 macOS y también con las recomendaciones XML y HTML de 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 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 deshabilitar estos caracteres, mostrarlos de manera diferente o requerir que se resuelvan en el mismo identificador; [104] todo esto es complicado debido al enorme y constantemente 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 fue diseñado para proporcionar una conversión de formato de ida y vuelta punto por punto de código hacia y desde cualquier codificación de caracteres preexistente, de modo que los archivos de texto en conjuntos de caracteres más antiguos se puedan convertir a Unicode y luego volver a Unicode y obtener de nuevo el mismo archivo, sin emplear una interpretación dependiente del contexto. Esto ha significado que las arquitecturas heredadas inconsistentes, como la combinación de diacríticos y caracteres precompuestos , existen en Unicode, lo que proporciona más de un método para representar algún texto. Esto es más pronunciado en las tres formas de codificación diferentes para el Hangul coreano . Desde la versión 3.0, cualquier carácter precompuesto que pueda representarse mediante una secuencia combinada de caracteres ya existentes ya no se puede agregar al estándar para preservar la interoperabilidad entre el software que utiliza diferentes versiones de Unicode.
Se deben proporcionar asignaciones inyectivas entre caracteres en conjuntos de caracteres heredados existentes y caracteres en Unicode para facilitar la conversión a Unicode y permitir la interoperabilidad con software heredado. La falta de consistencia en varias asignaciones entre codificaciones japonesas anteriores como Shift-JIS o EUC-JP y Unicode condujo a desajustes de conversión de formato de ida y vuelta , particularmente la asignación del carácter JIS X 0208 '～' (1-33, WAVE DASH), muy utilizado en datos de bases de datos heredadas, a U+FF5E～FULLWIDTH TILDE (en Microsoft Windows ) o U+301C〜WAVE DASH (otros proveedores). [109]
Algunos programadores informáticos japoneses se opusieron a Unicode porque les exige separar el uso de U+005C \ REVERSE SOLIDUS (barra invertida) y U+00A5 ¥ YEN SIGN , que se asignó a 0x5C en JIS X 0201, y existe mucho código heredado con este uso. [110] (Esta codificación también reemplaza la tilde '~' 0x7E con el macrón '¯', ahora 0xAF). La separación de estos caracteres existe en ISO 8859-1 , mucho antes de Unicode.
A los sistemas de escritura índicos, como el tamil y el devanagari, se les asignan solo 128 puntos de código, lo que coincide con el estándar ISCII . La correcta representación del texto índico Unicode requiere transformar los caracteres de orden lógico almacenados en orden visual y la formación de ligaduras (también conocidas como conjunciones) a partir de los componentes. Algunos académicos locales argumentaron a favor de la asignación de puntos de código Unicode a estas ligaduras, yendo en contra de la práctica de otros sistemas de escritura, aunque Unicode contiene algunas ligaduras árabes y de otros tipos solo por motivos de compatibilidad con versiones anteriores. [111] [112] [113] La codificación de nuevas ligaduras en Unicode no se realizará, en parte, porque el conjunto de ligaduras depende de la fuente, y Unicode es una codificación independiente de las variaciones de la fuente. El mismo tipo de problema surgió con la escritura tibetana en 2003 cuando la Administración de Normalización de China propuso codificar 956 sílabas tibetanas precompuestas, [114] pero estas fueron rechazadas para codificación por el comité ISO pertinente ( ISO/IEC JTC 1/SC 2 ). [115]
El soporte del alfabeto tailandés ha sido criticado por su ordenación de los caracteres tailandeses. Las vocales เ, แ, โ, ใ, ไ que se escriben a la izquierda de la consonante precedente están en orden visual en lugar de orden fonético, a diferencia de las representaciones Unicode de otros alfabetos índicos. Esta complicación se debe a que Unicode heredó el Estándar Industrial Tailandés 620 , que funcionaba de la misma manera y era la forma en que siempre se había escrito el tailandés en los teclados. Este problema de ordenación complica ligeramente el proceso de cotejo de Unicode, requiriendo búsquedas en tablas para reordenar los caracteres tailandeses para la cotejo. [96] Incluso si Unicode hubiera adoptado la codificación según el orden hablado, todavía sería problemático cotejar palabras en orden de diccionario. Por ejemplo, la palabra แสดง [sa dɛːŋ] "realizar" comienza con un grupo consonántico "สด" (con una vocal inherente para la consonante "ส"), la vocal แ-, en el orden hablado vendría después de la ด, pero en un diccionario, la palabra se coteja como está escrita, con la vocal siguiendo a la ส.
Los caracteres con marcas diacríticas generalmente se pueden representar como un solo carácter precompuesto o como una secuencia descompuesta de una letra base más una o más marcas sin espaciado. Por ejemplo, ḗ (e precompuesta con macrón y acento agudo encima) y ḗ (e seguida por el macrón combinado encima y el acento agudo combinado encima) deben representarse de manera idéntica, ambas apareciendo como una e con macrón (◌̄) y acento agudo (◌́), pero en la práctica, su apariencia puede variar dependiendo del motor de representación y las fuentes que se estén usando para mostrar los caracteres. De manera similar, los puntos bajos , como se necesita en la romanización de las lenguas índicas , a menudo se colocarán incorrectamente. [ cita requerida ] Los caracteres Unicode que se asignan a glifos precompuestos se pueden usar en muchos casos, evitando así el problema, pero cuando no se ha codificado ningún carácter precompuesto, el problema a menudo se puede resolver utilizando una fuente Unicode especializada como Charis SIL que utiliza tecnologías Graphite , OpenType ('gsub') o AAT para funciones de representación avanzadas.
El estándar Unicode ha impuesto reglas destinadas a garantizar la estabilidad. [116] Dependiendo de la rigurosidad de una regla, un cambio puede ser prohibido o permitido. Por ejemplo, un "nombre" dado a un punto de código no puede y no cambiará. Pero una propiedad "script" es más flexible, según las propias reglas de Unicode. En la versión 2.0, Unicode cambió muchos "nombres" de puntos de código de la versión 1. Al mismo tiempo, Unicode declaró que, a partir de entonces, un nombre asignado a un punto de código nunca cambiaría. Esto implica que cuando se publican errores, estos no se pueden corregir, incluso si son triviales (como sucedió en un caso con la ortografía BRAKCET por BRACKET en el nombre de un personaje). En 2006 se publicó por primera vez una lista de anomalías en los nombres de personajes y, a junio de 2021, había 104 caracteres con problemas identificados, [117] por ejemplo:
Aunque Unicode define el designador de script (nombre) como " Phags_Pa ", en los nombres de caracteres de ese script se agrega un guion: U+A840 ꡀ PHAGS-PA LETRA KA . [120] [121] Sin embargo, esto no es una anomalía, sino la regla: los guiones se reemplazan por guiones bajos en los designadores de script. [120]
Bob Belleville
realizó la propuesta inicial de un conjunto de "Signos universales"
en
Xerox PARC
. Muchas personas aportaron ideas para el desarrollo de un nuevo diseño de codificación. A partir de 1980, estos esfuerzos evolucionaron hasta convertirse en el
Estándar de código de caracteres de Xerox
(XCCS) del presente autor, una codificación multilingüe que Xerox ha mantenido como estándar corporativo interno desde 1982, gracias a los esfuerzos de Ed Smura, Ron Pellar y otros.
Unicode surgió como resultado de ocho años de experiencia laboral con XCCS. Sus diferencias fundamentales con respecto a XCCS fueron propuestas por Peter Fenwick y Dave Opstad (códigos puros de 16 bits) y por
Lee Collins
(unificación de caracteres ideográficos). Unicode conserva las numerosas características de XCCS cuya utilidad ha quedado demostrada a lo largo de los años en una línea internacional de productos de sistemas de comunicación multilingües.
Seleccione este formato de implementación si su sistema admite fuentes variables y prefiere usar solo un idioma, pero también desea una cobertura completa de caracteres o la capacidad de etiquetar texto por idioma para usar glifos que sean apropiados para los otros idiomas (esto requiere una aplicación que admita el etiquetado de idiomas y la función OpenType 'locl' GSUB).
Medios de comunicación de Commons
Libros de texto de Wikilibros