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 soportar el uso de texto escrito en todos los principales sistemas de escritura del mundo . La versión 15.1 de la norma [A] define149 813 caracteres [3] y 161 guiones utilizados 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 miles de emoji , cuyo desarrollo continuo lo lleva a cabo el Consorcio 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 . En última instancia, Unicode es capaz de codificar más de 1,1 millones de caracteres.
Unicode ha suplantado en gran medida el entorno anterior de innumerables 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 del texto en Internet, incluida la mayoría de las páginas web , y la compatibilidad relevante 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 ISO/IEC 10646 , siendo cada uno código por código idéntico entre sí. 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 scripts y brindan 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 de caracteres del estándar en secuencias de bytes. El propio estándar Unicode define tres codificaciones: UTF-8 , UTF-16 y UTF-32 , aunque existen varias otras. De estos, UTF-8 es el más utilizado por un amplio margen, en parte debido a su compatibilidad con versiones anteriores de ASCII .
Unicode se diseñó originalmente con la intención de trascender las limitaciones presentes en todas las codificaciones de texto diseñadas hasta ese momento: se dependía de cada codificación para su uso en su propio contexto, pero sin ninguna expectativa particular de compatibilidad con ninguna otra. De hecho, dos codificaciones elegidas eran a menudo totalmente inviables cuando se usaban juntas, y el texto codificado en una era interpretado como caracteres basura por la otra. La mayoría de las codificaciones sólo habían sido diseñadas para facilitar la interoperación entre un puñado de escrituras (a menudo principalmente entre una escritura determinada y caracteres latinos ), no entre una gran cantidad de escrituras y no con todas las escrituras admitidas siendo tratadas de manera consistente.
La filosofía que sustenta Unicode busca codificar los caracteres subyacentes ( grafemas y unidades similares a grafemas) en lugar de distinciones gráficas consideradas meras variantes de glifos 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 variantes ortográficas en caracteres Han , existe un desacuerdo considerable sobre qué diferencias justifican sus propias codificaciones y cuáles son sólo 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. Muchas cuestiones de representación visual, incluidos el tamaño, la forma y el estilo, deben quedar a discreción 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 de la norma.
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 escrituras de Europa occidental. Para preservar las distinciones hechas por diferentes codificaciones heredadas, permitiendo así la conversión entre ellas y Unicode sin 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 Formularios de ancho medio y ancho completo abarca un duplicado semántico completo del alfabeto latino, porque las codificaciones CJK heredadas contenían caracteres de "ancho completo" (que coincidían con el ancho de los caracteres CJK) y de "medio ancho" (que coincidían con la escritura latina ordinaria).
El premio Unicode Bulldog se otorga a personas consideradas influyentes en el desarrollo de Unicode, y los ganadores incluyen a 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, Joe Becker , empleado de Xerox , junto con Lee Collins y Mark Davis , empleados de Apple , comenzaron a investigar los aspectos prácticos de la creación de un conjunto de caracteres universal. [8] Con aportaciones adicionales 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, tentativamente llamado Unicode". Explicó que "el nombre 'Unicode' pretende sugerir una codificación universal, unificada y única". [7]
En este documento, titulado Unicode 88 , Becker describió un esquema utilizando caracteres de 16 bits : [7]
Unicode está destinado a abordar la necesidad de una codificación de texto mundial viable y confiable. Unicode podría describirse aproximadamente como " 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 diseñado adecuadamente, 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 las escrituras y los caracteres en 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 primer lugar 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 sin duda 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 Unicode se expandió 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 unieron 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 incorporó en California el 3 de enero de 1991, [9] y el primer volumen de The Unicode Standard se publicó en octubre. El segundo volumen, que ahora añade 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 muchas escrituras históricas, como los jeroglíficos egipcios , y miles de caracteres obsoletos u raramente utilizados cuya inclusión en el estándar no se había previsto. Entre estos caracteres se encuentran varios caracteres CJK que rara vez se utilizan; muchos de ellos se utilizan principalmente en nombres propios, lo que los hace mucho más necesarios para una codificación universal que la arquitectura Unicode original prevista. [10]
La versión 1.0 de la especificación TrueType de Microsoft, publicada en 1992, utilizaba el nombre "Apple Unicode" en lugar de "Unicode" para el ID de plataforma en la tabla de nombres.
El Unicode Consortium es una organización sin fines de lucro que coordina el desarrollo de Unicode. Los miembros de pleno derecho incluyen a la mayoría de las principales empresas de software y hardware (y algunas otras) con algún interés en los estándares de procesamiento de texto, incluidas Adobe , Apple , Google , IBM , Meta (anteriormente como Facebook), Microsoft , Netflix y SAP . [11]
A lo largo de los años, varios países o agencias gubernamentales han sido miembros del Consorcio Unicode. Actualmente, sólo el Ministerio de Dotaciones y Asuntos Religiosos (Omán) es miembro de pleno derecho con derecho a voto. [11]
El Consorcio tiene el ambicioso objetivo de eventualmente reemplazar 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 tienen un tamaño y alcance limitados y son incompatibles con entornos multilingües .
Unicode actualmente cubre la mayoría de los principales sistemas de escritura que se utilizan en la actualidad. [12] [ se necesita una mejor fuente ]
A partir de 2024 [actualizar], un total de 161 escrituras [13] están incluidas en la última versión de Unicode (que cubre alfabetos , abugidas y silabarios ), aunque todavía hay escrituras que aún no están codificadas, particularmente aquellas utilizadas principalmente en eventos históricos, litúrgicos y contextos académicos. También se añaden caracteres a las escrituras ya codificadas, así como símbolos, en particular para las matemáticas y la música (en forma de notas y símbolos rítmicos).
El Comité de Hoja de Ruta de Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) [14] mantiene la lista de scripts que son candidatos o candidatos potenciales para codificación y sus asignaciones de bloques de código tentativos en la página Hoja de Ruta de Unicode [15] de Unicode. Sitio web del consorcio . Para algunos guiones de la hoja de ruta, como los guiones grandes Jurchen y Khitan , se han realizado propuestas de codificación y están avanzando en el proceso de aprobación. Para otros guiones, como Mayan (aparte de los números) y Rongorongo , aún no se ha hecho ninguna propuesta y se espera que las comunidades de usuarios involucradas lleguen a un acuerdo sobre el repertorio de personajes y otros detalles.
Algunas escrituras inventadas modernas que aún no se han incluido en Unicode (p. ej., Tengwar ) o que no califican para su inclusión en Unicode debido a la falta de uso en el mundo real (p. ej., Klingon ) se enumeran en el Registro Unicode de ConScript , junto con otras no oficiales. pero asignaciones de códigos de áreas de uso privado ampliamente utilizadas .
También existe una iniciativa de fuentes medievales Unicode centrada en caracteres medievales latinos especiales. Parte de estas propuestas ya han sido incluidas 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 estaban 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 se diferencian de sus equivalentes ISO en dos aspectos importantes.
Si bien 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 y 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 principal completa, los anexos estándar [nota 2] y tablas 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 principal, publicada como un libro de bolsillo de impresión bajo demanda. [18] El texto completo, por otro lado, se publica como 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 UCS y Unicode: la frecuencia con la que se publican versiones actualizadas y se agregan nuevos caracteres. El estándar Unicode ha publicado periódicamente versiones ampliadas anuales, ocasionalmente con más de una versión publicada en un año calendario y en 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 15.1, la última versión, se lanzó el 12 de septiembre de 2023. Es una actualización menor de la versión 15.0, lanzada el 13 de septiembre de 2022, que agregó un total de 4489 caracteres nuevos, incluidos dos scripts nuevos, una extensión de CJK Unified Bloque de ideogramas y múltiples adiciones a bloques existentes. Se agregaron 33 nuevos emoji, como el símbolo " inalámbrico " (red) y corazones de colores adicionales. [19] [20]
Hasta el momento, se han publicado las siguientes versiones del estándar Unicode . Las versiones de actualización, 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 siguiente tabla. [21]
El Consorcio Unicode normalmente publica una nueva versión del Estándar Unicode una vez al año, u ocasionalmente dos veces al año. La versión 16.0, la próxima versión principal, está programada para publicarse en 2024 y se prevé que incluya seis nuevas escrituras ( Todhri , Sunuwar , Gurung Khema , Kirat Rai , Garay y Ol Onal ), números birmanos adicionales para los alfabetos Shan y Mon. , símbolos adicionales para informática heredada y al menos seis nuevos emoji. [56] [57]
El estándar Unicode define un espacio de código : [58] una secuencia de números enteros llamados puntos de código [59] que cubren el intervalo , anotado según el estándar como U+0000 – U+10FFFF . [60] El espacio de código es una representación sistemática, independiente de la arquitectura, del estándar Unicode ; El texto real se procesa como datos binarios mediante 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, [61] y los propios puntos de código se escriben como números hexadecimales . Siempre se escriben al menos cuatro dígitos hexadecimales, antepuestos ceros a la izquierda según sea necesario. Por ejemplo, el punto de código U+00F7 ÷ SIGNO DE DIVISIÓN se rellena con dos ceros a la izquierda, pero U+13254 𓉔 JEROGLIFO EGIPCIO O004 ( 
) no está acolchado. [62]
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 en BMP como una única 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 en 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 personajes se asignan dentro de bloques con nombre de personajes relacionados. El tamaño de un bloque es siempre múltiplo de 16 y, a menudo, es múltiplo de 128, pero por lo demás es arbitrario. Los caracteres necesarios para un script determinado pueden estar distribuidos en varios bloques diferentes y potencialmente separados dentro del espacio de código.
A cada punto de código se le asigna una clasificación, que aparece 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ún más. 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.
El1024 puntos en el rango U+D800 – U+DBFF se conocen como puntos de código sustituto alto , y los puntos de código en el rango U+DC00 – U+DFFF (1024 puntos de código) se conocen como puntos de código de bajo sustituto . Un punto de código sustituto alto seguido de un punto de código sustituto bajo forma un par sustituto en UTF-16 para representar puntos de código mayores que U+FFFF . En principio, estos puntos de código no se pueden usar de otra manera, aunque en la práctica esta regla a menudo se ignora, especialmente cuando no se usa UTF-16.
Se garantiza que un pequeño conjunto de puntos de código nunca se asignará a personajes, aunque terceros pueden hacer 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. [63] 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 personajes deja1 111 998 puntos de código disponibles para su uso.
Los puntos de código de uso privado se consideran asignados, pero intencionalmente no tienen ninguna interpretación especificada por el estándar Unicode [64], de modo que cualquier intercambio de dichos puntos de código requiere un acuerdo independiente entre el remitente 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 que tienen una semántica particular, ya sea que tengan una forma de glifo visible o que representen un espacio visible. A partir de Unicode 15.1, hay149 641 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 vecinos. Por ejemplo, U+200C ZERO WIDTH NON-JOINER y U+200D ZERO WIDTH JOINER se pueden usar para cambiar el comportamiento de configuración predeterminado de caracteres adyacentes (por ejemplo, para inhibir ligaduras o solicitar la formación de ligaduras). Hay 172 caracteres de formato en Unicode 15.1.
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 tal como se definen en ISO/IEC 6429 . U+0089 TABULACIÓN DE LÍNEA , U+008A AVANCE 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 según la página de códigos Windows-1252 , anteriormente ampliamente utilizada en contextos de Europa occidental.
En conjunto, 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 han sido asignados. A partir de Unicode 15.1, hay824 652 puntos de código reservado.
El conjunto de caracteres gráficos y de formato definidos por Unicode no corresponde directamente al repertorio de caracteres abstractos representables bajo Unicode. Unicode codifica caracteres asociando un carácter abstracto con un punto de código particular. [65] Sin embargo, no todos los caracteres abstractos están codificados 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 arriba y un acento agudo , que se requiere en lituano , está representada por 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. [66]
Todos los personajes asignados tienen un nombre único e inmutable con el que se identifican. Esta inmutabilidad ha sido garantizada desde la versión 2.0 del estándar Unicode mediante su política de estabilidad de nombres. [63] En los casos en que un nombre sea gravemente defectuoso y engañoso, o tenga un error tipográfico grave, se puede definir un alias formal que se recomienda a las solicitudes utilizar en lugar del nombre del personaje oficial. Por ejemplo, U+A015 ꀕ YI SYLLABLE WU tiene el alias formal YI SYLLABLE ITERATION MARK , y U+FE18 ︘ FORMULARIO DE PRESENTACIÓN PARA SOPORTE LENTICULAR BLANCO VERTICAL DERECHO KC ET ( sic ) tiene el alias formal FORMATO DE PRESENTACIÓN PARA SOPORTE LENTICULAR BLANCO VERTICAL DERECHO KC ET ( sic ) hora del este . [67]
Unicode incluye un mecanismo para modificar caracteres que amplía enormemente el repertorio de glifos admitidos. Esto cubre el uso de la combinación de signos diacríticos que el usuario puede agregar después del carácter base. Se pueden aplicar simultáneamente varios signos diacríticos combinados al mismo carácter. Unicode también contiene versiones precompuestas de la mayoría de las combinaciones de letras y signos diacríticos en uso normal. Estos simplifican la conversión hacia y desde codificaciones heredadas y permiten que las aplicaciones utilicen Unicode como formato de texto interno sin tener que implementar la combinación de caracteres. Por ejemplo, ése puede representar en Unicode como U+0065 e LETRA E MINÚSCULA LATINA seguida de U+0301 ◌́ COMBINANDO ACENTO AGUDO ), y de manera equivalente como el carácter precompuesto U+00E9 é LETRA E MINÚSCULA LATINA CON AGUDA . Por lo tanto, los usuarios suelen tener 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.
Actualmente, los caracteres CJK solo tienen códigos para radicales que no se pueden componer y formas precompuestas. La mayoría de los caracteres han han sido compuestos intencionalmente o reconstruidos como composiciones de elementos ortográficos más simples llamados radicales , 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 requeridos, 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 añaden una inmensa complejidad a la propuesta. De hecho, los intentos de diseñar codificaciones CJK basándose en la composición de radicales se han topado con dificultades derivadas de la realidad de que los caracteres chinos no se descomponen tan simple ni tan regularmente como lo hace el Hangul.
El bloque 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 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 una representación alternativa para caracteres codificados en otro lugar:
Este proceso es diferente de una codificación formal de un ideograma. No existe una descripción canónica de ideogramas no codificados; no hay ninguna semántica asignada a los ideogramas descritos; no existe equivalencia definida para los ideogramas descritos. Conceptualmente, las descripciones ideográficas se parecen más a la frase inglesa "una 'e' con un acento agudo" que a la secuencia de caracteres <U+0065, U+0301>.
Muchas escrituras, incluidas la á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 configuración 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 de The Unicode Standard ), que se convirtió en la prueba. de concepto para OpenType (de Adobe y Microsoft), Graphite (de SIL International ) o AAT (de Apple).
Las instrucciones también están integradas en las fuentes para indicarle al sistema operativo cómo generar correctamente diferentes secuencias de caracteres. Una solución simple para la colocación de marcas combinadas o signos diacríticos es asignar a las marcas un ancho de cero y colocar el glifo a la izquierda o a la derecha del lado izquierdo (dependiendo de la dirección de la escritura con la que se pretende usar). Una marca manejada de esta manera aparecerá sobre cualquier carácter que la preceda, pero no ajustará su posición en relación con el ancho o alto del glifo base; puede resultar visualmente incómodo y puede superponerse a algunos glifos. El apilamiento real es imposible, pero se puede aproximar en casos limitados (por ejemplo, las vocales y marcas tonales que combinan la parte superior tailandesa pueden estar a diferentes alturas para empezar). Generalmente, este enfoque sólo es efectivo en fuentes monoespaciadas, pero puede usarse como método de representación alternativo cuando fallan métodos más complejos.
Varios subconjuntos de Unicode están estandarizados: Microsoft Windows, ya que Windows NT 4.0 admite WGL-4 con 657 caracteres, que se considera compatible con 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: [69] MES-1 (solo escritura latina, 335 caracteres), MES-2 (latín, griego y cirílico, 1062 caracteres) [70] y MES-3A y MES-3B. (dos subconjuntos más grandes, que no se muestran aquí). MES-2 incluye todos los caracteres de MES-1 y WGL-4.
La norma DIN 91379 [71] 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. Este estándar admite todos los idiomas oficiales de todos los países de la Unión Europea, así como los idiomas minoritarios alemanes y los idiomas oficiales de Islandia, Liechtenstein, Noruega y Suiza. Para permitir la transliteración de nombres en otros sistemas de escritura a la escritura latina según las normas ISO pertinentes, se proporcionan todas las combinaciones necesarias de letras básicas y signos diacríticos.
El software de renderizado que no puede procesar un carácter Unicode de manera adecuada a menudo lo muestra 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 personajes. La fuente Last Resort de Apple mostrará un glifo sustituto que indica el rango Unicode del carácter, y la fuente alternativa Unicode 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 del formato de transformación Unicode (UTF) y las codificaciones del conjunto de caracteres codificados universales (UCS). Una codificación asigna (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 asignan códigos que apuntan a una secuencia única de bytes. [72] 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 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 uno a cuatro bytes por punto de código y, al ser compacto para escrituras latinas 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 de texto general.
Las codificaciones UCS-2 y UTF-16 especifican la marca de orden de bytes (BOM) Unicode para usar al principio de archivos de texto, que se pueden usar para la detección de orden de bytes (o detección de endianidad de bytes ). La lista de materiales, codificada como U+FEFF BYTE ORDER MARK , tiene la importante propiedad de no ambigüedad en el reordenamiento 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 al comienzo del texto transmite el espacio sin interrupción de ancho cero (un carácter sin apariencia y ningún efecto más que prevenir la formación de ligaduras ).
El mismo carácter convertido a UTF-8 se convierte en la secuencia de bytes EF BB BF. El estándar Unicode permite que la lista de materiales "pueda servir como firma para texto codificado UTF-8 donde el conjunto de caracteres no está marcado". [73] 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 posibles patrones en UTF-8 (por ejemplo, no puede haber bytes solitarios con el bit alto establecido) significa que debería ser posible distinguir UTF-8 de otras codificaciones de caracteres sin depender de la lista de materiales.
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 endianismo, 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 usa ampliamente como representación interna de texto en programas (a diferencia del texto almacenado o transmitido), ya que cada sistema operativo Unix que usa los compiladores gcc para generar software lo usa como codificación estándar de " caracteres anchos ". Algunos lenguajes de programación, como Seed7 , utilizan UTF-32 como representación interna para cadenas y caracteres. Las versiones recientes del lenguaje de programación Python (comenzando con 2.2) también se pueden configurar para usar UTF-32 como representación de cadenas Unicode, difundiendo efectivamente 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 limitado admitido por 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 scripts compatibles con 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. El 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. [74] 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 97,8% de todas las páginas web (y 987 de las 1000 páginas web mejor clasificadas). [75] 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 ahora declara que su codificación solo es ASCII en lugar de UTF-8. [76] 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 , [77] han requerido soporte para UTF-8 desde la publicación del RFC 2277 en 1998, que especificaba que todos los protocolos IETF "DEBEN poder utilizar el juego de caracteres UTF-8". . [78]
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 utiliza casi exclusivamente para construir nuevos sistemas de procesamiento de información. Los primeros usuarios tendían a utilizar 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 era la forma menos disruptiva de agregar soporte para caracteres que no son BMP. El sistema de este tipo más conocido es Windows NT (y sus descendientes, 2000 , XP , Vista , 7 , 8 , 10 y 11 ), que utiliza UTF-16 como única codificación de caracteres interna. Los entornos de código de bytes Java y .NET , macOS y KDE también lo utilizan para la representación interna. Se puede instalar soporte parcial para Unicode en Windows 9x a través de Microsoft Layer para Unicode .
UTF-8 (originalmente desarrollado para Plan 9 ) [79] se ha convertido en la codificación de almacenamiento principal en la mayoría de los sistemas operativos tipo Unix (aunque algunas bibliotecas también utilizan otros) porque es un reemplazo relativamente fácil de los conjuntos de caracteres ASCII extendidos tradicionales . UTF-8 es también 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üe 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 las distribuciones 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.
ISO/IEC 14755 , [80] que estandariza métodos para ingresar caracteres Unicode desde sus puntos de código, especifica varios métodos. Existe el método Básico , donde una secuencia inicial es seguida por la representación hexadecimal del punto de código y la secuencia final . También se especifica un método de entrada de selección de pantalla , donde los caracteres se enumeran en una tabla en una pantalla, como con un programa de mapa de caracteres.
Las herramientas en línea para encontrar el punto de código de un carácter conocido incluyen Unicode Lookup [81] de Jonathan Hedley y Shapecatcher [82] de Benjamin Milde. En la búsqueda Unicode, se ingresa una clave de búsqueda (por ejemplo, "fracciones") y se devuelve una lista de los caracteres correspondientes con sus puntos de código. En Shapecatcher, según el contexto de Shape , se dibuja el personaje en un cuadro y se devuelve una lista de caracteres que se aproxima 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 "Asunto:") o en el cuerpo de texto del mensaje; en ambos casos se identifica el juego de caracteres original así como una codificación de transferencia. Para la transmisión por correo electrónico de Unicode, se recomienda el juego 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 de software de correo electrónico.
El IETF ha definido [83] [84] un marco para el correo electrónico internacionalizado utilizando UTF-8 y ha actualizado [85] [86] [87] [88] varios protocolos de acuerdo con ese marco.
La adopción de Unicode en el correo electrónico ha sido muy lenta. [ cita necesaria ] Parte del texto de Asia oriental todavía está codificado en codificaciones como ISO-2022 , y algunos dispositivos, como los teléfonos móviles, [ cita necesaria ] todavía no pueden manejar correctamente los datos Unicode. Sin embargo, el soporte ha ido mejorando. 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 de documentos desde HTML 4.0. Los navegadores web admiten Unicode, especialmente UTF-8, durante muchos años. Solía haber problemas de visualización resultantes principalmente de problemas relacionados con las fuentes ; por ejemplo, la versión 6 y anteriores de Microsoft Internet Explorer no representaba muchos puntos de código a menos que se le indicara explícitamente que usara una fuente que los contuviera. [89]
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, [90] comprenden caracteres de la mayoría de los puntos del 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 l prefijo) deben mostrarse en todos los navegadores como Δ, É, ק, م, ๗, あ, 叶, 葉. y 말.
Al especificar URI , por ejemplo como URL en solicitudes HTTP , los caracteres que no sean ASCII deben estar codificados en porcentaje .
En principio, Unicode no se ocupa de las fuentes per se , considerándolas opciones de implementación. [91] Cualquier carácter determinado puede tener muchos alógrafos , desde las letras más comunes en negrita, cursiva y base hasta estilos decorativos complejos. Una fuente es "compatible con Unicode" si se puede acceder a los glifos de la fuente mediante puntos de código definidos en El estándar Unicode . [92] La norma 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 comerciales basadas en Unicode están ampliamente disponibles, ya que TrueType y OpenType admiten Unicode (y el formato de fuente abierto web (WOFF y WOFF2 ) se basa en ellos). Estos formatos de fuentes 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 único archivo de fuente. (Sin embargo, cada fuente dentro de la colección todavía tiene el límite de 65,535). Un archivo TrueType Collection normalmente tendría una extensión de archivo ".ttc".
Existen miles de fuentes en el mercado, pero menos de una docena, a veces descritas como fuentes "pan-Unicode", intentan admitir la mayoría del repertorio de caracteres Unicode. En cambio, las fuentes basadas en Unicode normalmente se centran en admitir sólo ASCII básico y secuencias de comandos o conjuntos de caracteres o símbolos particulares. Varias razones justifican este enfoque: las aplicaciones y los documentos rara vez necesitan representar 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 aplicaciones muestran una inteligencia cada vez mayor 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 coherente de instrucciones de representación para decenas de miles de glifos constituye una tarea monumental; una empresa de este tipo pasa el punto de rendimientos decrecientes para la mayoría de los tipos de letra.
Unicode soluciona parcialmente el problema de nueva línea que ocurre al intentar leer un archivo de texto en diferentes plataformas. Unicode define una gran cantidad de caracteres que las aplicaciones conformes deben reconocer como terminadores de línea.
En términos de 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 plataforma. Al hacerlo, Unicode proporciona una forma de evitar las soluciones históricas dependientes de la plataforma. No obstante, pocas o ninguna solución Unicode han adoptado estos separadores de línea y párrafo Unicode como únicos caracteres canónicos de final de línea. Sin embargo, un enfoque común para resolver este problema es mediante la normalización de nueva línea. Esto se consigue 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 (que en realidad no importa ya que es una operación interna solo para renderizar). 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 con respecto a la unificación Han, o Unihan, especialmente la adición adicional 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 la deliberación dentro del comité, la unificación Han ha sido constantemente uno de los aspectos más controvertidos del estándar Unicode desde la génesis del proyecto. [93]
Los estándares de conjuntos de caracteres existentes, como el japonés JIS X 0208 (codificado por Shift JIS ), definían criterios de unificación, es decir, reglas para determinar cuándo una variante de carácter chino debe considerarse una diferencia de escritura a mano/fuente (y, por lo tanto, unificada), frente a una diferencia ortográfica ( 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. [94] 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 los chinos, japoneses y coreanos comparten muchos caracteres en común, a veces también se percibe que la unificación Han trata a los tres como la misma cosa. [95]
Existen codificaciones alternativas utilizadas con menos frecuencia, a menudo anteriores a Unicode, con modelos de caracteres que difieren de este paradigma, con el objetivo de preservar las diversas diferencias estilísticas entre 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 fue ampliamente adoptado entre el público japonés. Otra es la codificación CCCII adoptada por los sistemas bibliotecarios de Hong Kong , Taiwán y 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 bibliotecarios. [96] Aunque el trabajo en Apple basado en el CJK Thesaurus 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 estilo JIS. [94]
La primera versión de Unicode tenía un repertorio de menos de 21.000 caracteres Han, en gran medida limitados a aquellos de uso moderno relativamente común. A partir de la versión 15.1, el estándar ahora codifica más de 97.000 caracteres Han, y se continúa trabajando para agregar miles más, en su mayoría caracteres variantes históricas y dialectales utilizadas en toda la sinosfera .
Los tipos de letra modernos proporcionan un medio para abordar algunos de los problemas prácticos al representar caracteres Han unificados con varias representaciones gráficas regionales. La tabla OpenType 'locl' permite que un renderizador seleccione un glifo diferente para cada punto de código según la configuración regional del texto. [97] Las secuencias de variación Unicode también pueden proporcionar anotaciones en el texto para una selección de glifos deseada; esto requiere el registro de la variante específica en la Base de Datos de Variaciones Ideográficas .
Si los glifos apropiados para caracteres en la misma escritura difieren sólo en cursiva, Unicode generalmente los ha unificado, como se puede ver en la comparación entre un conjunto de glifos en cursiva de siete caracteres que aparecen típicamente en ruso, búlgaro tradicional, macedonio y Textos en serbio a la derecha, lo que significa que las diferencias se muestran mediante tecnología de fuentes inteligentes o cambiando las fuentes manualmente. Se utiliza la misma técnica OpenType 'locl'. [98]
Unicode fue diseñado para proporcionar 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 regresar y recuperar el mismo archivo. sin emplear una interpretación dependiente del contexto. Esto ha significado que en Unicode existan arquitecturas heredadas inconsistentes, como la combinación de signos diacríticos y caracteres precompuestos , lo que brinda más de un método para representar un texto. Esto es más pronunciado en las tres formas diferentes de codificación del 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 el software heredado. La falta de coherencia en varias asignaciones entre codificaciones japonesas anteriores, como Shift-JIS o EUC-JP y Unicode, provocó discrepancias en la conversión de formato de ida y vuelta , en particular la asignación del carácter JIS X 0208 '～' (1-33, WAVE DASH) , muy utilizado en datos de bases de datos heredadas, ya sea U+FF5E～FULLWIDTH TILDE (en Microsoft Windows ) o U+301C〜WAVE DASH (otros proveedores). [99]
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 una gran cantidad de código heredado con este uso. [100] (Esta codificación también reemplaza la tilde '~' 0x7E con macron '¯', ahora 0xAF). La separación de estos caracteres existe en ISO 8859-1 , mucho antes de Unicode.
A las escrituras índicas , como el tamil y el devanagari, se les asignan a cada una solo 128 puntos de código, lo que coincide con el estándar ISCII . La representación correcta del texto Unicode Indic 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 componentes. Algunos eruditos 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 otro tipo únicamente con fines de compatibilidad con versiones anteriores. [101] [102] [103] La codificación de cualquier ligadura nueva en Unicode no se producirá, en parte, porque el conjunto de ligaduras depende de la fuente y Unicode es una codificación independiente de las variaciones de fuente. El mismo tipo de problema surgió para la escritura tibetana en 2003, cuando la Administración de Normalización de China propuso codificar 956 sílabas tibetanas precompuestas, [104] pero el comité ISO correspondiente ( ISO/IEC JTC 1/SC 2 ) rechazó su codificación . [105]
La compatibilidad con el alfabeto tailandés ha sido criticada por el orden de los caracteres tailandeses. Las vocales เ, แ, โ, ใ, ไ que se escriben a la izquierda de la consonante anterior están en orden visual en lugar de fonético, a diferencia de las representaciones Unicode de otras escrituras índicas. 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 la que siempre se había escrito el tailandés en los teclados. Este problema de orden complica ligeramente el proceso de clasificación Unicode, ya que requiere búsquedas en tablas para reordenar los caracteres tailandeses para la clasificación. [95] Incluso si Unicode hubiera adoptado la codificación según el orden hablado, seguiría siendo problemático cotejar las palabras en el orden del diccionario. Por ejemplo, la palabra แสดง [sa dɛːŋ] "realizar" comienza con un grupo de consonantes "สด" (con una vocal inherente a la consonante "ส"), la vocal แ-, en orden hablado vendría después de la ด, pero en un diccionario, la palabra se clasifica tal como está escrita, con la vocal después de ส.
Los caracteres con signos diacríticos generalmente se pueden representar como un único carácter precompuesto o como una secuencia descompuesta de una letra base más una o más marcas sin espacio. Por ejemplo, ḗ (e precompuesta con macron y aguda arriba) y ḗ (e seguida por la combinación de macron arriba y la combinación de aguda arriba) deben representarse de manera idéntica, apareciendo ambas como una e con un macron (◌̄) y acento agudo (◌ ́), pero en la práctica, su apariencia puede variar según el motor de renderizado y las fuentes que se utilicen para mostrar los caracteres. De manera similar, los puntos bajos , necesarios en la romanización del índico , a menudo se colocarán incorrectamente. [ cita necesaria ] 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 usando una fuente Unicode especializada como Charis SIL que usa Tecnologías Graphite , OpenType ("gsub") o AAT para funciones de renderizado avanzadas.
El estándar Unicode ha impuesto reglas destinadas a garantizar la estabilidad. [106] Dependiendo del rigor de una norma, se puede prohibir o permitir un cambio. Por ejemplo, un "nombre" dado a un punto de código no puede cambiar ni 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 desde la versión 1. Al mismo tiempo, Unicode declaró que, de ahora en adelante, un nombre asignado a un punto de código nunca cambiaría. Esto implica que cuando se publican errores, no se pueden corregir, incluso si son triviales (como sucedió en un caso con la ortografía BRAKCET de BRACKET en el nombre de un personaje). En 2006, se publicó por primera vez una lista de anomalías en los nombres de los personajes y, en junio de 2021, había 104 caracteres con problemas identificados, [107] por ejemplo:
Si bien Unicode define el designador (nombre) del script como " Phags_Pa ", en los nombres de caracteres de ese script, se agrega un guión: U+A840 ꡀ PHAGS-PA LETTER KA . [110] [111] Esto, sin embargo, no es una anomalía, sino la regla: los guiones se reemplazan por guiones bajos en los designadores de escritura. [110]
Unicode tiene una gran cantidad de homoglifos , muchos de los cuales se ven muy similares o idénticos a las letras ASCII. La sustitución de estos puede crear un identificador o URL que parezca correcto, pero que dirija a una ubicación diferente a la esperada. [112] Además, los homoglifos también se pueden utilizar para manipular la salida de los sistemas de procesamiento del lenguaje natural (NLP) . [113] La mitigación requiere no permitir estos caracteres, mostrarlos de manera diferente o exigir que se resuelvan con el mismo identificador; [114] Todo esto es complicado debido al enorme y cambiante conjunto de personajes. [115] [116]
Dos investigadores, uno de la Universidad de Cambridge y el otro de la Universidad de Edimburgo , publicaron en 2021 un aviso de seguridad en el que afirman 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ó " Fuente troyana ". [117] En respuesta, los editores de código comenzaron a resaltar marcas para indicar cambios forzados en la dirección del texto. [118]
2.2 El campo fuente
Bob Belleville
hizo la propuesta inicial para un conjunto de "Señales Universales"
en
Xerox PARC
. Muchas personas contribuyeron con 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 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 se ha demostrado a lo largo de los años en una línea internacional de productos de sistemas de comunicación multilingüe.
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 etiquetado de idioma y la función GSUB OpenType 'locl').
Medios de los comunes
Libros de texto de Wikilibros