Unicode

Unicode, formalmente el estándar Unicode, es un estándar de tecnología de la información para la codificación, representación y manejo consistentes de texto expresado en la mayoría de los países del mundo. sistemas de escritura. El estándar, que es mantenido por Unicode Consortium, define a partir de la versión actual (15.0) 149 186 caracteres que cubren 161 escrituras modernas e históricas, así como símbolos, emoji (incluso en colores) y códigos de formato y control no visual.

El éxito de Unicode en la unificación de conjuntos de caracteres ha llevado a su uso generalizado y predominante en la internacionalización y localización de software informático. El estándar se ha implementado en muchas tecnologías recientes, incluidos los sistemas operativos modernos, XML y la mayoría de los lenguajes de programación modernos.

El repertorio de caracteres Unicode está sincronizado con ISO/IEC 10646, y cada uno es código por código idéntico al otro. El estándar Unicode, sin embargo, incluye más que solo el código base. Además de las codificaciones de caracteres, la publicación oficial del Consorcio incluye una amplia variedad de detalles sobre los scripts y cómo mostrarlos: reglas de normalización, descomposición, intercalación, representación y orden de visualización de texto bidireccional para textos multilingües, etc. El Estándar también incluye archivos de datos de referencia y gráficos visuales para ayudar a los desarrolladores y diseñadores a implementar correctamente el repertorio.

Unicode se puede almacenar utilizando varias codificaciones diferentes, que traducen los códigos de caracteres en secuencias de bytes. El estándar Unicode define tres y existen varias otras codificaciones, todas en la práctica codificaciones de longitud variable. Las codificaciones más comunes son UTF-8 compatible con ASCII, UTF-16 compatible con ASCII-in (compatible con el obsoleto UCS-2) y el estándar de codificación chino Unicode GB18030, que no es oficial. Estándar Unicode, pero se usa en China e implementa Unicode por completo.

Origen y desarrollo

Unicode tiene el objetivo explícito de trascender las limitaciones de las codificaciones de caracteres tradicionales, como las definidas por el estándar ISO/IEC 8859, que encuentran un amplio uso en varios países del mundo pero siguen siendo en gran medida incompatibles entre sí. Muchas codificaciones de caracteres tradicionales comparten un problema común en el sentido de que permiten el procesamiento informático bilingüe (generalmente utilizando caracteres latinos y la escritura local), pero no el procesamiento informático multilingüe (procesamiento informático de escrituras arbitrarias mezcladas entre sí).

Unicode, en su intención, codifica los caracteres subyacentes (grafemas y unidades similares a grafemas) en lugar de los glifos variantes (representaciones) de dichos caracteres. En el caso de los caracteres chinos, esto a veces conduce a controversias sobre cómo distinguir el carácter subyacente de sus glifos variantes (ver unificación de Han).

En el procesamiento de texto, Unicode asume la función de proporcionar un punto de código único, un número, no un glifo, para cada carácter. En otras palabras, Unicode representa un carácter de forma abstracta y deja la representación visual (tamaño, forma, fuente o estilo) a otro software, como un navegador web o un procesador de textos. Sin embargo, este simple objetivo se complica debido a las concesiones hechas por los diseñadores de Unicode con la esperanza de fomentar una adopción más rápida de Unicode.

Los primeros 256 puntos de código se hicieron idénticos al contenido de ISO/IEC 8859-1 para que sea trivial convertir el texto occidental existente. Muchos caracteres esencialmente idénticos se codificaron varias veces en diferentes puntos de código para preservar las distinciones utilizadas por las codificaciones heredadas y, por lo tanto, permitir la conversión de esas codificaciones a Unicode (y viceversa) sin perder ninguna información. Por ejemplo, los "formularios de ancho completo" La sección de puntos de código abarca un duplicado completo del alfabeto latino porque las fuentes chinas, japonesas y coreanas (CJK) contienen dos versiones de estas letras, "de ancho completo" coincidiendo con el ancho de los caracteres CJK y el ancho normal. Para otros ejemplos, vea caracteres duplicados en Unicode.

Los ganadores del premio Unicode Bulldog incluyen muchos nombres influyentes en el desarrollo de Unicode, como Tatsuo Kobayashi, Thomas Milo, Roozbeh Pournader, Ken Lunde y Michael Everson.

Historia

Según las experiencias con el estándar de código de caracteres de Xerox (XCCS) desde 1980, los orígenes de Unicode se remontan a 1987, cuando Joe Becker de Xerox con Lee Collins y Mark Davis de Apple comenzaron a investigar los aspectos prácticos de crear un código universal. conjunto de caracteres. Con aportes adicionales de Peter Fenwick y Dave Opstad, Joe Becker publicó un borrador de propuesta para un "sistema de codificación de caracteres de texto multilingüe/internacional en agosto de 1988, tentativamente llamado Unicode". Explicó que "el nombre 'Unicode' pretende sugerir una codificación única, unificada y universal.

En este documento, titulado Unicode 88, Becker describió un modelo de caracteres de 16 bits:

Unicode tiene la intención de abordar la necesidad de una codificación de texto mundial viable y fiable. Unicode podría describirse aproximadamente como "ASCII de todo el cuerpo" que se ha estirado a 16 bits para abarcar los caracteres de todos los idiomas vivos del mundo. En un diseño correctamente diseñado, 16 bits por personaje son más que suficientes para este propósito.

Su diseño original de 16 bits se basó en la suposición de que solo sería necesario codificar aquellos scripts y caracteres de uso moderno:

Unicode da mayor prioridad a garantizar la utilidad para el futuro que preservar antigüedades pasadas. Unicode pretende en primera instancia a los personajes publicados en 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¹⁴ = 16.384. Más allá de esos caracteres de uso moderno, todos los demás pueden definirse como obsoletos o raros; son mejores candidatos para el registro de uso privado que para la congestión de la lista pública de Unicodes generalmente útiles.

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 RLG, y Glenn Wright de Sun Microsystems, y en 1990, Michel Suignard y Asmus Freytag de Microsoft y Rick McGowan de NeXT se unieron al grupo. A fines de 1990, se había completado la mayor parte del trabajo sobre el mapeo de los estándares de codificación de caracteres 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 y, en octubre de 1991, se publicó el primer volumen del estándar Unicode. El segundo volumen, que cubre las ideografías Han, se publicó en junio de 1992.

En 1996, se implementó un mecanismo de sustitución de caracteres en Unicode 2.0, por lo 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 secuencias de comandos históricas (por ejemplo, jeroglíficos egipcios) y miles de caracteres obsoletos o de uso poco frecuente que no se había previsto que necesitaran codificación. Entre los caracteres que originalmente no estaban destinados a Unicode, rara vez se utilizan caracteres chinos o kanji, muchos de los cuales forman parte de nombres personales y de lugares, lo que los hace mucho más esenciales de lo previsto en la arquitectura original de Unicode.

La especificación Microsoft TrueType versión 1.0 de 1992 usaba el nombre 'Apple Unicode' en lugar de 'Unicode' para el Id. de plataforma en la tabla de nombres.

Consorcio Unicode

El Consorcio Unicode es una organización sin fines de lucro que coordina el desarrollo de Unicode. Los miembros de pleno derecho incluyen la mayoría de las principales empresas de software y hardware informático con algún interés en los estándares de procesamiento de texto, incluidas Adobe, Apple, Facebook, Google, IBM, Microsoft, Netflix y SAP SE.

A lo largo de los años, varios países o agencias gubernamentales han sido miembros del Consorcio Unicode. Actualmente, solo el Ministerio de Dotaciones y Asuntos Religiosos (Omán) es miembro de pleno derecho con derecho a voto.

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 tienen un tamaño y alcance limitados y son incompatibles con entornos multilingües.

Guiones cubiertos

Unicode actualmente cubre la mayoría de los principales sistemas de escritura que se utilizan en la actualidad.

A partir de 2022, la última versión de Unicode incluye un total de 161 guiones (que abarcan alfabetos, abugidas y silabarios), aunque todavía hay guiones que aún no están codificados, en particular los que se utilizan principalmente en textos históricos, litúrgicos y religiosos. contextos académicos. También se producen más adiciones de caracteres a los guiones ya codificados, 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, V.S. Umamaheswaran) mantiene la lista de guiones que son candidatos o candidatos potenciales para la codificación y sus asignaciones de bloques de código tentativas en la página Hoja de ruta de Unicode del sitio web de Unicode Consortium. Para algunos scripts en la hoja de ruta, como el script pequeño de Jurchen y Khitan, se han hecho propuestas de codificación y están trabajando en el proceso de aprobación. Para otros guiones, como maya (además de números) y rongorongo, aún no se ha hecho ninguna propuesta y están a la espera de un acuerdo sobre el repertorio de personajes y otros detalles de las comunidades de usuarios involucradas.

Algunos scripts inventados modernos 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 de ConScript Unicode. junto con asignaciones de códigos de áreas de uso privado no oficiales pero ampliamente utilizadas.

También hay una iniciativa de fuentes Unicode medievales centrada en caracteres medievales latinos especiales. Parte de estas propuestas ya se han incluido en Unicode.

Iniciativa de codificación de scripts

La Iniciativa de codificación de scripts, 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 adiciones propuestas a la norma en los últimos años.

Versiones

El Consorcio Unicode y la Organización Internacional de Normalización (ISO) han desarrollado juntos un repertorio compartido tras la publicación inicial de El estándar Unicode en 1991; 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 de Unicode difieren de sus equivalentes ISO de dos maneras importantes.

Si bien el UCS es un mapa de caracteres simple, Unicode especifica las reglas, los algoritmos y las 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, en profundidad, temas 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, incluidos los necesarios 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 central completa, los anexos estándar y las tablas de códigos. Sin embargo, Unicode 5.0, publicado 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 libro de bolsillo impreso bajo demanda. 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 importante entre UCS y Unicode: la frecuencia con la que se publican versiones actualizadas y se agregan nuevos caracteres. El estándar Unicode ha lanzado regularmente versiones ampliadas anuales, ocasionalmente con más de una versión lanzada en un año calendario y con casos raros en los que el lanzamiento programado tuvo que posponerse. Por ejemplo, en abril de 2020, solo un mes después de la publicación de la versión 13.0, Unicode Consortium anunció que había cambiado la fecha de lanzamiento prevista para la versión 14.0, retrasándola seis meses desde marzo de 2021 hasta septiembre de 2021 debido a la pandemia de COVID-19.

La última versión de Unicode, 15.0.0, se lanzó el 13 de septiembre de 2022. Se actualizaron varios anexos, incluidos los mecanismos de seguridad de Unicode (UTS n.º 39), y se codificaron un total de 4489 caracteres nuevos, incluidos 20 caracteres emoji nuevos, como "inalámbrico" (red) símbolo y corazones en diferentes colores como rosa, dos nuevos guiones, extensión CJK Unified Ideographs y múltiples adiciones a bloques existentes.

Hasta ahora, se han publicado las siguientes versiones principales y secundarias del estándar Unicode. Las versiones actualizadas, que no incluyen ningún cambio en el repertorio de personajes, se indican con el tercer número (por ejemplo, "versión 4.0.1") y se omiten en la siguiente tabla.

• v
• t
• e

Historia de la versión Unicode y cambios notables a caracteres y scripts

Versión	Fecha	Libro	Corresponde a la edición ISO/IEC 10646	Scripts	Personajes
					Total	Adiciones notables
1.0.0	Octubre de 1991	ISBN 0-201-56788-1 (Vol. 1)		24	7.129	El repertorio inicial cubre estos scripts: árabe, armenio, bengalí, bopomofo, cirílico, devanagari, georgiano, griego y copto, Gujarati, Gurmukhi, Hangul, hebreo, hiragana, Kannada, Katakana, Lao, latín, Malayalam, Oriya, Tamil, Telugu, tailandés y tibetano.
1.0.1	Junio de 1992	ISBN 0-201-60845-6 (Vol. 2)		25	28.327 (21.204 añadidos; 6 eliminados)	Se define el conjunto inicial de 20,902 CJK Unified Ideographs.
1.1	Junio de 1993		ISO/IEC 10646-1:1993	24	34.168 (5.963 añadidos); 89 eliminados; 33 reclasificado como control caracteres)	4,306 más Sílabas Hangul agregadas al conjunto original de 2.350 caracteres. Tibetano eliminado.
2.0	Julio de 1996	ISBN 0-201-48345-9	ISO/IEC 10646-1:1993 más Enmiendas 5, 6 y 7	25	38.885 (11.373 añadidos); 6,656 eliminado)	Conjunto original de sílabas Hangul eliminado, y un nuevo conjunto de sílabas Hangul 11,172 agregado en una nueva ubicación. Tibetano agregó en una nueva ubicación y con un repertorio de carácter diferente. Mecanismo de caracteres cruzados definido, y Plane 15 y Plane 16 Áreas de Uso Privado asignadas.
2.1	Mayo de 1998		ISO/IEC 10646-1:1993 más Enmiendas 5, 6 y 7, así como dos caracteres de la Enmienda 18	25	38.887 (2 añadidas)	Euro sign and Object Replacement Caracter añadido.
3.0	Septiembre de 1999	ISBN 0-201-61633-5	ISO/IEC 10646-1:2000	38	49.194 (10.307 añadidos)	Cherokee, Ethiopic, Khmer, Mongolian, Burmese, Ogham, Runic, Sinhala, Syriac, Thaana, Unified Canadian Aboriginal Syllabics, and Yi Syllables added, as well as a set of Braille patterns.
3.1	Marzo de 2001		ISO/IEC 10646-1:2000 ISO/IEC 10646-2:2001	41	94.140 (44.946 añadidos)	Deseret, gótico y antiguo Italic añadido, así como conjuntos de símbolos para la música occidental y la música bizantina, y 42.711 adicionales CJK Unified Ideographs.
3.2	Marzo de 2002		ISO/IEC 10646-1:2000 más Enmienda 1 ISO/IEC 10646-2:2001	45	95.156 (1,016 añadidos)	Guiones filipinos Buhid, Hanunó'o, Tagalog y Tagbanwa añadidos.
4.0	Abril de 2003	ISBN 0-321-18578-1	ISO/IEC 10646:2003	52	96.382 (1.226 añadidos)	Syllabary chipriota, Limbu, Linear B, Osmanya, Shavian, Tai Le y Ugaritic añadido, así como símbolos Hexagram.
4.1	Marzo de 2005		ISO/IEC 10646:2003 más Enmienda 1	59	97.655 (1,273 añadidos)	Buginese, Glagolitic, Kharoshthi, New Tai Lue, Old Persian, Syloti Nagri, y Tifinagh añadió, y Coptic fue desunificado de griego. También se agregaron números griegos antiguos y símbolos musicales.
5.0	Julio de 2006	ISBN 0-321-48091-0	ISO/IEC 10646:2003 más Enmiendas 1 y 2, así como cuatro caracteres de la Enmienda 3	64	99.024 (1.369 añadidos)	Balinese, Cuneiform, N'Ko, Phags-pa y Phoenician añadido.
5.1	Abril de 2008		ISO/IEC 10646:2003 más Enmiendas 1, 2, 3 y 4	75	100.648 (1.624 añadidos)	Carian, Cham, Kayah Li, Lepcha, Lycian, Lydian, Ol Chiki, Rejang, Saurashtra, Sundanese, y Vai añadido, así como conjuntos de símbolos para el Phaistos Disc, azulejos Mahjong, y azulejos Domino. También hubo adiciones importantes para Burmese, adiciones de letras y abreviaturas escribales utilizadas en manuscritos medievales, y la adición de Capital ẞ.
5.2	Octubre de 2009	ISBN 978-1-936213-00-9	ISO/IEC 10646:2003 más Enmiendas 1, 2, 3, 4, 5 y 6	90	107.296 (6.648 añadidos)	Avestan, Bamum, jeroglíficos egipcios (el conjunto Gardiner, que comprende 1.071 caracteres), Imperial Arameo, Pahlavi Inscriptional, Parthian inscriptional, Javanese, Kaithi, Lisu, Meetei Mayek, Old South Arabian, Old Turkic, Samaritan, Tai Tham y Tai Viet añadido. 4.149 Ideografías unificadas CJK (CJK-C), así como Jamo extendido para el viejo Hangul, y caracteres para el sánscrito Védico.
6.0	Octubre de 2010	ISBN 978-1-936213-01-6	ISO/IEC 10646:2010 más el signo de rupia india	93	109.384 (2,088 añadidos)	Batak, Brahmi, Mandaic, símbolos de tarjetas de juego, símbolos de transporte y mapa, símbolos alquímicos, emoticonos y emojis. 222 adicionales CJK Unified Ideographs (CJK-D) añadido.
6.1	Enero de 2012	ISBN 978-1-936213-02-3	ISO/IEC 10646:2012	100	110.116 (732 añadidos)	Chakma, Meroitic cursive, Meroitic hieroglyphs, Miao, Sharada, Sora Sompeng y Takri.
6.2	Septiembre de 2012	ISBN 978-1-936213-07-8	ISO/IEC 10646:2012 más el signo de lira turca	100	110.117 (1 añadido)	Firma de lira turca.
6.3	Septiembre de 2013	ISBN 978-1-936213-08-5	ISO/IEC 10646:2012 más seis caracteres	100	110.122 (5 añadidas)	5 caracteres de formato bidireccional.
7.0	Junio de 2014	ISBN 978-1-936213-09-2	ISO/IEC 10646:2012 más Enmiendas 1 y 2, así como el signo Ruble	123	112.956 (2.834 añadidos)	Bassa Vah, Caucasian Albanian, Duployan, Elbasan, Grantha, Khojki, Khudawadi, Linear A, Mahajani, Manichaean, Mende Kikakui, Modi, Mro, Nabataean, Old North Arabian, Old Permic, Pahawh Hmong, Palmyrene, Pau Cin Hau, Psalter Pahl Tihuiti
8.0	Junio 2015	ISBN 978-1-936213-10-8	ISO/IEC 10646:2014 más Enmienda 1, así como el signo Lari, nueve ideografías unificadas CJK y 41 caracteres emoji	129	120.672 (7.716 añadidos)	Ahom, jeroglíficos anatólicos, Hatran, Multani, Old Hungarian, SignWriting, 5,771 CJK Ideografías unificadas, un conjunto de letras minúsculas para Cherokee, y cinco modificadores de tono de piel emoji.
9.0	Junio 2016	ISBN 978-1-936213-13-9	ISO/IEC 10646:2014 más Enmiendas 1 y 2, así como Adlam, Newa, símbolos de televisión japonesa, y 74 emoji y símbolos	135	128.172 (7.500 añadidos)	Adlam, Bhaiksuki, Marchen, Newa, Osage, Tangut y 72 emoji.
10.0	Junio de 2017	ISBN 978-1-936213-16-0	ISO/IEC 10646:2017 más 56 caracteres emoji, 285 caracteres hentaigana y 3 caracteres de la plaza Zanabazar	139	136.690 (8.518 añadidos)	Zanabazar Square, Soyombo, Masaram Gondi, Nüshu, hentaigana (hiragana no estándar), 7,494 CJK Ideografías unificadas, 56 emoji y símbolo bitcoin.
11.0	Junio 2018	ISBN 978-1-936213-19-1	ISO/IEC 10646:2017 más Enmienda 1, así como 46 Mtavruli mayúsculas georgianas, 5 ideografías unificadas CJK y 66 caracteres emoji.	146	137.374 (684 añadidos)	Dogra, Georgian Mtavruli maya, Gunjala Gondi, Hanifi Rohingya, Indic Siyaq Numbers, Makasar, Medefaidrin, Old Sogdian y Sogdian, números mayas, 5 Ideografías unificadas CJK, símbolos para xiangqi (ajedrez chino) y calificaciones estelares, y 145 emoji.
12.0	Marzo 2019	ISBN 978-1-936213-22-1	ISO/IEC 10646:2017 más Enmiendas 1 y 2, así como 62 caracteres adicionales.	150	137.928 (554 añadido)	Elymaic, Nandinagari, Nyiakeng Puachue Hmong, Wancho, Miao script adiciones para varios idiomas Miao y Yi de China, hiragana y katakana pequeñas letras para escribir japonés arcaico, fracciones históricas tamiles y símbolos, letras lao para Pali, letras latinas para transliteración egipcia y urglyph formato controles.
12.1	Mayo 2019	ISBN 978-1-936213-25-2		150	137.929 (1 añadido)	Añade un solo personaje en U+32FF para la forma de ligadura cuadrada del nombre de la era Reiwa.
13.0	Marzo 2020	ISBN 978-1-936213-26-9	ISO/IEC 10646:2020	154	143,859 (5.930 añadidos)	Chorasmian, Dives Akuru, Khitan script pequeño, Yezidi, 4,969 CJK unified ideographs added (including 4,939 in Ext. G), Arabic script additions used to write Hausa, Wolof, and other languages in Africa and other additions used to write Hindko and Punjabi in Pakistan, Bopomofo additions used for Cantonesetext compatibility
14.0	Septiembre 2021	ISBN 978-1-936213-29-0		159	144.697 (838 añadidos)	Toto, Cypro-Minoan, Vithkuqi, Old Uyghur, Tangsa, adiciones de scripts latinos en bloques SMP (Ext-F, Ext-G) para uso en la SIP extendida, adiciones de escritura árabe para uso en idiomas a través de África y en Irán, Pakistán, Malasia, Indonesia, Java y Bosnia, y para escribir honoríficos, adiciones para el símbolo de India
15.0	Septiembre 2022	ISBN 978-1-936213-32-0		161	149.186 (4.489 añadidos)	Kawi y Mundari, varios nuevos personajes, incluyendo 20 emoji, 4,192 ideografías CJK, y personajes de control para jeroglíficos egipcios.

Arquitectura y terminología

Codespace y Code Points

El estándar Unicode define a codespace, un conjunto de valores numéricos que van desde 0 hasta 10FF₁₆, llamado code points y denotado U+0000 a través de U+10FF ("U+" seguido por el valor de punto de código en hexadecimal, que se prepone con ceros que conducen a un mínimo de cuatro dígitos; e. g., U+00F7 para el signo de división . pero U+13254 ()no U+013254) para el jeroglífico egipcio .). De estos 2¹⁶ + 2²⁰ puntos de código definidos, los puntos de código de U+D800 a través de U+DFFF, que se utilizan para codificar pares surrogados en UTF-16, están reservados por el Estándar Unicode y pueden no ser usados para codificar caracteres válidos, resultando en un total neto de 2¹⁶ − 2¹¹ + 2²⁰ = 1.112.064 puntos de código asignables.

Codificar planos y bloques

El espacio de códigos Unicode se divide en diecisiete planos, numerados del 0 al 16. El plano 0 es el plano multilingüe básico (BMP), que contiene los caracteres más utilizados. Se accede a todos los puntos de código en 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 en los Planos 1 a 16 (planos complementarios) 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. Aunque los bloques tienen un tamaño arbitrario, siempre son un múltiplo de 16 puntos de código y, a menudo, un múltiplo de 128 puntos de código. Los caracteres requeridos para un guión dado pueden distribuirse en varios bloques diferentes.

Propiedad de categoría general

Cada punto de código tiene una única propiedad de categoría general. Las principales categorías se denotan: letra, marca, número, puntuación, símbolo, separador y otros. Dentro de estas categorías, hay subdivisiones. En la mayoría de los casos, se deben usar otras propiedades para especificar suficientemente las características de un punto de código. Las posibles Categorías Generales son:

Categoría general (Propiedad de carácter de autor) v t e
Valor	Categoría Mayor, menor	Tipo básico	Carácter asignado	Conde (en 15,0)	Observaciones
L, Carta; LC, Carta Casada (Lu, Ll y Lt solamente)
Lu	Carta, mayúscula	Gráfico	Cara	1.831
Ll	Carta, minúscula	Gráfico	Cara	233
Lt	Letter, titlecase	Gráfico	Cara	31	Ligaduras que contienen mayúsculas seguidas de letras minúsculas (por ejemplo, Dž, Lj, Nj y Dz)
Lm	Carta, modificador	Gráfico	Cara	397	Una carta modificadora
Lo siento.	Carta, otra	Gráfico	Cara	131.612	Un ideógrafo o una letra en un alfabeto unicase
M, Mark
Mn	Mark, no ritmo	Gráfico	Cara	1,985
Mc	Mark, espaciado combinando	Gráfico	Cara	452
Me	Mark, encerrando	Gráfico	Cara	13
N, Número
Nd	Número, dígito decimal	Gráfico	Cara	680	Todos estos, y sólo estos, tienen Tipo Numérico = De
Nl	Número, carta	Gráfico	Cara	236	Números compuestos de letras o símbolos de letras (por ejemplo, números romanos)
No	Número, otro	Gráfico	Cara	915	E.g., fracciones vulgares, dígitos superscriptos y subscriptos
P, Punturación
Pc	Puntura, conector	Gráfico	Cara	10	Incluye caracteres espaciantes como "_", y otros caracteres de corbata espaciantes. A diferencia de otros caracteres de puntuación, estos pueden clasificarse como caracteres de "palabra" por bibliotecas de expresión regulares.
Pd	Puntura, dash	Gráfico	Cara	26	Incluye varios caracteres de hifeno
Ps	Puntura, abierta	Gráfico	Cara	79	Personajes de apertura
Pe	Puntura, cerca	Gráfico	Cara	77	Personajes de cierre
Pi	Puntura, cita inicial	Gráfico	Cara	12	Marca de citas de apertura. No incluye la marca de citas "neutral" de ASCII. Puede comportarse como Ps o Pe dependiendo del uso
Pf	Puntura, cita final	Gráfico	Cara	10	Marca de citas de cierre. Puede comportarse como Ps o Pe dependiendo del uso
Po	Puntura, otra	Gráfico	Cara	628
S, Signatura
Sm	Símbolo, matemáticas	Gráfico	Cara	948	Símbolos matemáticos (por ejemplo, +, −, =, ×, ÷, √, √, ∊, ل). No incluye paréntesis y corchetes, que están en las categorías Ps y Pe. Tampoco incluye !, *, -, o /, que a pesar de uso frecuente como operadores matemáticos, se consideran principalmente como "punturación".
Sc	Signatura, moneda	Gráfico	Cara	63	Símbolos de moneda
Sk	Símbolo, modificador	Gráfico	Cara	125
Así que...	Signatura, otra	Gráfico	Cara	6.634
Z, Separador
Zs	Separador, espacio	Gráfico	Cara	17	Incluye el espacio, pero no TAB, CR, o LF, que son Cc
Zl	Separador, línea	Formato	Cara	1	Sólo U+2028 LINE SEPARATOR (LSEP)
Zp	Separador, párrafo	Formato	Cara	1	Sólo U+2029 PARAGRAPH SEPARATOR (PSEP)
C, Otros
Cc	Otros, control	Control	Cara	65 (nunca cambiará)	No nombre,
Cf	Otros, formato	Formato	Cara	170	Incluye el himno blando, caracteres de control de unión (ZWNJ y ZWJ), caracteres de control para apoyar el texto bidireccional y caracteres de etiquetas de idioma
Cs	Other, surrogate	Surrogate	No (sólo utilizado en UTF-16)	2.048 (nunca cambiará)	No nombre,
Co	Otros usos privados	Uso privado	Carácter (pero ninguna interpretación especificada)	137.468 totales (nunca cambiarán) (6.400 en BMP, 131.068 en Planes 15-16)	No nombre,
Cn	Otros, no asignados	Noncharacter	No	66 (nunca cambiará)	No nombre,
		Reservado	No	825.279	No nombre,
^ "Tabla 4-4: Categoría general" (PDF). El estándar Unicode. Unicode Consortium. Septiembre 2022. ^ a b "Tabla 2-3: Tipos de puntos de código" (PDF). El estándar Unicode. Unicode Consortium. Septiembre 2022. ^ "DerivedGeneralCategory.txt". El Consorcio Unicode. 2022-04-26. ^ "5.7.1 Valores generales de la categoría". UTR #44: Base de datos de caracteres Unicode. Unicode Consortium. 2020-03-04. ^ a b c d e Unicode Personaje Codificación Políticas de Estabilidad: Propiedad Estabilidad de valor Política de estabilidad: Algunos grupos de gc nunca cambiarán. gc=Nd corresponde con Numeric Type=De (decimal). ^ "Anexo C: Propiedades de compatibilidad (§ word)". Expresiones Ordinarias Unicode. Versión 23. Consorcio Unicode. 2022-02-08. Unicode Technical Standard #18. ^ a b c d e "Tabla 4-9: Construcción de etiquetas de punta de código" (PDF). El estándar Unicode. Unicode Consortium. Septiembre 2022. A Code Point Label puede ser utilizado para identificar un punto de código sin nombre. Por ejemplo. - No.hhhh- No. El Nombre permanece en blanco, lo que puede evitar sustituir inadvertidamente, en la documentación, un Nombre de Control con un verdadero código de Control. Unicode también utiliza Uninot un carácter confidencial para <noncharacter confianza.

Los puntos de código en el rango U+D800–U+DBFF (1024 puntos de código) se conocen como puntos de código sustitutos altos, 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 sustitutos bajos. Un punto de código suplente alto seguido de un punto de código suplente bajo forman un par suplente en UTF-16 para representar puntos de código mayores que U+FFFF. De lo contrario, estos puntos de código no se pueden usar (esta regla a menudo se ignora en la práctica, especialmente cuando no se usa UTF-16).

Se garantiza que nunca se utilizará un pequeño conjunto de puntos de código para codificar caracteres, aunque las aplicaciones pueden utilizar estos puntos de código internamente si lo desean. Hay sesenta y seis de estos no caracteres: U+FDD0–U+FDEF y cualquier punto de código que termine en el valor FFFE o FFFF (es decir, 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. Al igual que los sustitutos, la regla de que estos no se pueden usar a menudo se ignora, aunque la operación de la marca de orden de bytes (BOM) asume que U+FFFE nunca será el primer punto de código en un texto.

Excluidos los sustitutos y los que no son personajes, quedan 1 111 998 puntos de código disponibles para su uso.

Los puntos de código de uso privado se consideran caracteres asignados, pero no tienen una interpretación especificada por el estándar Unicode, por lo que cualquier intercambio de tales caracteres requiere un acuerdo entre el remitente y el receptor sobre su interpretación. Hay tres áreas de uso privado en el espacio de códigos Unicode:

• Área de Uso Privado: U+E000–U+F8FF (6.400 caracteres),
• Área de uso privado suplementario-A: U+F0000–U+FFD (65,534 caracteres),
• Área de uso privado suplementario-B: U+100000–U+10FFFD (65,534 caracteres).

Los caracteres gráficos son caracteres definidos por Unicode para tener una semántica particular y tienen una forma de glifo visible o representan un espacio visible. A partir de Unicode 15.0 hay 149 014 caracteres gráficos.

Los caracteres de formato son caracteres que no tienen una apariencia visible, pero pueden tener un efecto en la apariencia o el comportamiento de los caracteres vecinos. Por ejemplo, U+200C ZERO WIDTH NO-JOINER y U+200D ZERO WIDTH JOINER se puede usar para cambiar el comportamiento de forma predeterminado de los caracteres adyacentes (por ejemplo, para inhibir ligaduras o solicitar la formación de ligaduras). Hay 172 caracteres de formato en Unicode 15.0.

Sesenta y cinco puntos de código (U+0000–U+001F y U+007F–U+009F) están reservados como códigos de control y corresponden a los códigos de control C0 y C1 definidos en ISO /IEC 6429. U+0009 (tabulador), U+000A (salto de línea) y U+000D (retorno de carro) se utilizan ampliamente en textos codificados en Unicode. En la práctica, los puntos de código C1 a menudo se traducen incorrectamente (mojibake) como los caracteres heredados de Windows-1252 utilizados por algunos textos en inglés y Europa occidental.

Los caracteres gráficos, los caracteres de formato, los caracteres de código de control y los caracteres de uso privado se conocen colectivamente como caracteres asignados. Los puntos de código reservados son aquellos puntos de código que están disponibles para su uso, pero que aún no se han asignado. A partir de Unicode 15.0, hay 825 279 puntos de código reservados.

Personajes abstractos

El conjunto de caracteres gráficos y de formato definidos por Unicode no se corresponde directamente con el repertorio de caracteres abstractos que es representable bajo Unicode. Unicode codifica caracteres asociando un carácter abstracto con un punto de código particular. Sin embargo, no todos los caracteres abstractos se codifican como un solo carácter Unicode y algunos caracteres abstractos pueden representarse en Unicode mediante una secuencia de dos o más caracteres. Por ejemplo, una letra latina minúscula "i" con un ogonek, un punto arriba y un acento agudo, que es obligatorio 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 exclusivos para caracteres abstractos que no están codificados directamente en Unicode.

Todos los caracteres gráficos, de formato y de uso privado tienen un nombre único e inmutable por el cual pueden ser identificados. Esta inmutabilidad ha sido garantizada desde Unicode versión 2.0 por la política de Estabilidad de nombres. En los casos en que el nombre sea gravemente defectuoso y engañoso, o tenga un error tipográfico grave, se puede definir un alias formal y se anima a las aplicaciones a utilizar el alias formal 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 PRESENTACION PARA BRA LENTICULAR BLANCO DERECHO VERTICALKCET (sic) tiene el alias formal FORMA DE PRESENTACION PARA SOPORTE LENTICULAR BLANCO DERECHO VERTICALCKET.

Personajes confeccionados versus compuestos

Unicode incluye un mecanismo para modificar caracteres que amplía enormemente el repertorio de glifos compatibles. Esto cubre el uso de marcas diacríticas combinadas que el usuario puede agregar después del carácter base. Se pueden aplicar múltiples signos diacríticos combinados simultáneamente al mismo carácter. Unicode también contiene versiones precompuestas de la mayoría de las combinaciones de letras/diacríticos en uso normal. Estos simplifican la conversión hacia y desde codificaciones heredadas y permiten que las aplicaciones usen Unicode como un formato de texto interno sin tener que implementar la combinación de caracteres. Por ejemplo, é se puede representar en Unicode como U+0065 (LETRA E MINÚSCULA LATINA) seguido de U+0301 (COMBINACIÓN DE ACENTO AGUDO), pero también se puede representar como el carácter precompuesto U+00E9 (LETRA E MINÚSCULA LATINA CON AGUDO). Por lo tanto, en muchos casos, los usuarios tienen múltiples formas de codificar el mismo carácter. Para lidiar con esto, Unicode proporciona el mecanismo de equivalencia canónica.

Un ejemplo de esto surge con Hangul, el alfabeto coreano. Unicode proporciona un mecanismo para componer sílabas Hangul con sus subcomponentes individuales, conocido como Hangul Jamo. Sin embargo, también proporciona 11.172 combinaciones de sílabas precompuestas a partir del jamo más común.

Los caracteres CJK actualmente tienen códigos solo para su forma precompuesta. Aún así, la mayoría de esos caracteres comprenden elementos más simples (llamados radicales), por lo que, en principio, Unicode podría haberlos descompuesto como lo hizo con Hangul. Esto habría reducido en gran medida la cantidad de puntos de código requeridos, al tiempo que permitiría mostrar prácticamente todos los caracteres imaginables (lo que podría eliminar algunos de los problemas causados por la unificación de Han). Algunos métodos de entrada, como Cangjie y Wubi, utilizan una idea similar. Sin embargo, los intentos de hacer esto para la codificación de caracteres se han topado con el hecho de que los caracteres chinos no se descomponen de manera tan simple o regular como lo hace Hangul.

Se proporcionó un conjunto de radicales en Unicode 3.0 (radicales CJK entre U+2E80 y U+2EFF, radicales KangXi en U+2F00 a U+2FDF y caracteres de descripción ideográfica de U+2FF0 a U+2FFB), pero el estándar Unicode (cap. 12.2 de Unicode 5.2) advierte contra el uso de secuencias de descripción ideográficas como una representación alternativa para caracteres previamente codificados:

Este proceso es diferente a un formal codificación de un ideógrafo. No hay descripción canónica de los ideógrafos no codificados; no hay semántica asignada a los ideógrafos descritos; no hay equivalencia definida para los ideógrafos descritos. Conceptualmente, las descripciones ideográficas son más parecidas a la frase en inglés "an 'e' con un acento agudo en ella" que a la secuencia de caracteres "U+0065, U+0301].

Ligaduras

Muchas escrituras, incluidas la árabe y la devanāgarī, tienen reglas ortográficas especiales que requieren que ciertas combinaciones de formas de letras se combinen en formas de ligaduras especiales. Las reglas que rigen la formación de ligaduras pueden ser bastante complejas y requieren tecnologías especiales de creación de guiones 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 instrucciones también están incrustadas en las fuentes para decirle al sistema operativo cómo generar correctamente diferentes secuencias de caracteres. Una solución simple para la colocación de marcas de combinación 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 margen lateral izquierdo (dependiendo de la dirección de la escritura con la que se pretenda 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 la altura del glifo base; puede ser 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 de combinación superior tailandesas y las marcas de tono pueden estar a diferentes alturas para empezar). En general, este enfoque solo es efectivo en fuentes monoespaciadas, pero se puede usar como un método de representación alternativo cuando fallan los métodos más complejos.

Subconjuntos estandarizados

Varios subconjuntos de Unicode están estandarizados: Microsoft Windows desde Windows NT 4.0 es compatible con WGL-4 con 657 caracteres, que se considera compatible con todos los idiomas europeos contemporáneos que usan escritura latina, griega o cirílica. Otros subconjuntos estandarizados de Unicode incluyen los subconjuntos europeos multilingües: MES-1 (solo alfabetos latinos, 335 caracteres), MES-2 (1062 caracteres latinos, griegos y cirílicos) y MES-3A & MES-3B (dos subconjuntos más grandes, que no se muestran aquí). Tenga en cuenta que MES-2 incluye todos los caracteres de MES-1 y WGL-4.

La norma DIN 91379 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 especificación admite todos los idiomas oficiales de los países de la Unión Europea, así como los idiomas oficiales de Islandia, Liechtenstein, Noruega y Suiza, y también los idiomas minoritarios alemanes. Para permitir la transliteración de nombres en otros sistemas de escritura a la escritura latina de acuerdo con los estándares ISO relevantes, se proporcionan todas las combinaciones necesarias de letras base y signos diacríticos.

WGL-4, MES-1 MES-2

Row	Celdas	Rango(s)
00	20–7E	Latín básico (00–7F)
	A0-FF	Suplemento latino-1 (80–FF)
01	00–13, 14–15, 16–2B, 2C-2D, 2E-4D, 4E-4F, 50-7E, 7F	Latin Extended-A (00–7F)
	8F, 92, B7, DE-EF, FA-FF	Latin Extended-B (80–FF ...)
02	18–1B, 1E–1F	Latin Extended-B ()... 00-4F)
	59, 7C, 92	Prórrogas de la SIP (50–AF)
	BB-BD, C6, C7, C9, D6, D8-DB, DC, DD, DF, EE	Cartas de Modificadores de Spacing (B0-FF)
03	74–75, 7A, 7E, 84–8A, 8C, 8E–A1, A3–CE, D7, DA–E1	Griego (70-FF)
04	00–5F, 90–91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9	Cirílico (00–FF)
1E	02–03, 0A–0B, 1E–1F, 40–41, 56–57, 60–61, 6A–6B, 80-85, 9B, F2-F3	Latin Extended Additional (00–FF)
1F	00–15, 18–1D, 20–45, 48–4D, 50–57, 59, 5B, 5D, 5F–7D, 80–B4, B6–C4, C6–D3, D6–DB, DD–EF, F2–F4, F6–FE	Griego extendido (00–FF)
20	13 a 14, 15, 17, 18-19, 1A-1B, 1C-1D, 1E, 20–22, 26, 30, 32–33, 39–3A, 3C, 3E, 44, 4A	Puntura general (00–6F)
	7F, 82	Superscriptos y Subscriptos (70–9F)
	A3-A4, A7, AC, AF	Símbolos de moneda (A0-CF)
21	05, 13, 16, 22, 26, 2E	Símbolos tipo cartas (00-4F)
	5B–5E	Número de formularios (50-8F)
	90-93, 94–95, A8	Flechas (90-FF)
22	00, 02, 03, 06, 08–09, 0F, 11–12, 15, 19–1A, 1E–1F, 27 a 28, 29, 2A, 2B, 48, 59, 60–61, 64–65, 82–83, 95, 97	Operadores matemáticos (00–FF)
23	02, 0A, 20–21, 29–2A	Técnica diversa (00–FF)
25	00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50-6C	Dibujo de caja (00–7F)
	80, 84, 88, 8C, 90 a 93	Elementos de bloque (80–9F)
	A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6	Formas geométricas (A0-FF)
26	3A–3C, 40, 42, 60, 63, 65–66, 6A, 6B	Símbolos diversos (00–FF)
F0	(01–02)	Zona de uso privado (00-FF...)
FB	01–02	Formas de presentación alfabética (00-4F)
FF	FD	Especiales

El software de renderizado que no puede procesar correctamente un carácter Unicode a menudo lo muestra como un rectángulo abierto, o el "carácter de reemplazo" (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 Unicode Fallback de SIL International mostrará un cuadro que muestra el valor escalar hexadecimal del carácter.

Mapeo y codificaciones

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 Unicode Transformation Format (UTF) y las codificaciones Universal Coded Character Set (UCS). Una codificación asigna (posiblemente un subconjunto de) el rango de puntos de código de Unicode a secuencias de valores en un rango de tamaño fijo, denominado unidades de código. Todas las codificaciones UTF asignan puntos de código a una secuencia única de bytes. 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 uno a cuatro bytes para cada punto de código, maximiza la compatibilidad con ASCII
• UTF-EBCDIC, similar a UTF-8 pero diseñado para la compatibilidad con EBCDIC (no parte de El estándar Unicode)
• UTF-16, utiliza una o dos unidades de código de 16 bits por punto de código, no puede codificar sustitutos
• UTF-32, utiliza una unidad de código de 32 bits por punto de código

UTF-8 utiliza de uno a cuatro bytes por punto de código y, al ser compacto para 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 pueden usar para la detección del orden de bytes (o detección de terminación de bytes). La lista de materiales, punto de código U+FEFF, tiene la propiedad importante de la falta de 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 que no sean el 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 en UTF-8 donde el conjunto de caracteres no está marcado". Algunos desarrolladores de software lo han adoptado para otras codificaciones, incluido UTF-8, en un intento por 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 las marcas de orden de bytes estén prohibidas en los protocolos que usan UTF-8, pero analiza los casos en los que esto puede no ser posible. Además, la gran restricción sobre los posibles patrones en UTF-8 (por ejemplo, no puede haber ningún byte solitario con el conjunto de bits alto) 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 endianness, que varía según las diferentes plataformas, afecta cómo se manifiesta la unidad de código como una secuencia de bytes). En las otras codificaciones, cada punto de código puede estar representado por un número variable de unidades de código. UTF-32 se usa ampliamente como una representación interna de texto en los programas (a diferencia del texto almacenado o transmitido), ya que todos los sistemas operativos Unix que usan los compiladores gcc para generar software lo usan como el "carácter ancho&#34 estándar.; codificación Algunos lenguajes de programación, como Seed7, usan UTF-32 como representación interna para cadenas y caracteres. Las versiones recientes del lenguaje de programación Python (a partir de la 2.2) también se pueden configurar para usar UTF-32 como 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 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 día de los inocentes' Day RFC de 2005 especificó dos codificaciones UTF de parodia, UTF-9 y UTF-18.

Adopción

Unicode, en forma de UTF-8, ha sido la codificación más común para la World Wide Web desde 2008. Tiene una adopción casi universal y gran parte del contenido que no es UTF-8 se encuentra en otras codificaciones Unicode., p.ej. UTF-16. A partir de 2022, UTF-8 representa en promedio el 97,8 % de todas las páginas web (y 988 de las 1000 páginas web mejor clasificadas). Aunque muchas páginas solo usan caracteres ASCII para mostrar contenido, UTF-8 se diseñó con ASCII de 8 bits como subconjunto y casi ningún sitio web ahora declara que su codificación es solo ASCII en lugar de UTF-8. Más de un tercio de los idiomas rastreados tienen un uso del 100 % de UTF-8.

Todos los protocolos de Internet mantenidos por el Grupo de trabajo de ingeniería de Internet, p. FTP, han requerido soporte para UTF-8 desde la publicación de RFC 2277 en 1998, que especificaba que todos los protocolos IETF "DEBEN poder usar el juego de caracteres UTF-8".

Sistemas operativos

Unicode se ha convertido en el esquema dominante para el procesamiento interno y el almacenamiento 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 usuarios tendían 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 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 interna de caracteres. Los entornos de bytecode de Java y.NET, macOS y KDE también lo utilizan para la representación interna. El soporte parcial para Unicode se puede instalar en Windows 9x a través de Microsoft Layer para Unicode.

UTF-8 (desarrollado originalmente para Plan 9) se ha convertido en la codificación de almacenamiento principal en la mayoría de los sistemas operativos similares a Unix (aunque algunas bibliotecas también usan otros) porque es un reemplazo relativamente fácil para los juegos 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.

Métodos de entrada

Debido a que los diseños de teclado no pueden tener combinaciones de teclas simples para todos los caracteres, varios sistemas operativos brindan métodos de entrada alternativos que permiten el acceso a todo el repertorio.

ISO/IEC 14755, 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 personaje conocido incluyen Unicode Lookup de Jonathan Hedley y Shapecatcher 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, basado en el contexto Shape, 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.

Correo electrónico

MIME define dos mecanismos diferentes para codificar caracteres que no son 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 juego 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, por lo general, se ocultan a los usuarios del software de correo electrónico.

El IETF ha definido un marco para el correo electrónico internacionalizado mediante UTF-8 y ha actualizado varios protocolos de acuerdo con ese marco.

La adopción de Unicode en el correo electrónico ha sido muy lenta. Parte del texto de Asia oriental todavía está codificado en codificaciones como ISO-2022, y algunos dispositivos, como los teléfonos móviles, 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.

Internet

Todas las recomendaciones del W3C han utilizado Unicode como su conjunto de caracteres del documento desde HTML 4.0. Los navegadores web han sido compatibles con Unicode, especialmente UTF-8, durante muchos años. Solía haber problemas de visualización como resultado principalmente de problemas relacionados con la fuente; p.ej. v6 y versiones anteriores de Microsoft Internet Explorer no generaron muchos puntos de código a menos que se les indique explícitamente que usen una fuente que los contenga.

Aunque las reglas de sintaxis pueden afectar el orden en que se permite que aparezcan los caracteres, los documentos XML (incluido XHTML), por definición, comprenden caracteres de la mayoría de los puntos de código Unicode, con la excepción de:

• la mayoría de los códigos de control C0,
• los puntos de código no asignados permanentemente D800-DFFF,
• FFFE o FFFF.

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 Δ, Й, ק, &# 1605;, ๗, あ, 叶, &;#33865;, y 말 (o los mismos valores numéricos expresados en hexadecimal, con &#x como prefijo) deberían 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.

Fuentes

En principio, Unicode no se preocupa por las fuentes per se, ya que las considera opciones de implementación. Cualquier carácter dado puede tener muchos alógrafos, desde las formas de 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. 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 minoristas 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 ellas). 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 "modo de intervalo" mecanismo 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 de ".ttc".

Existen miles de fuentes en el mercado, pero menos de una docena, a veces descritas como "pan-Unicode" Fuentes: intente admitir la mayoría del repertorio de caracteres de Unicode. En cambio, las fuentes basadas en Unicode generalmente se enfocan en admitir solo ASCII básico y secuencias de comandos particulares o conjuntos de caracteres o símbolos. 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 las 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 consistente de instrucciones de representación para decenas de miles de glifos constituye una tarea monumental; tal empresa pasa el punto de rendimientos decrecientes para la mayoría de los tipos de letra.

Nuevas líneas

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 deberían reconocer como terminadores de línea.

En cuanto a la nueva línea, Unicode introdujo U+2028 SEPARADOR DE LÍNEA y U+2029 SEPARADOR DE PÁRRAFOS. 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 sortear las soluciones históricas dependientes de la plataforma. No obstante, pocas soluciones Unicode, si es que alguna, han adoptado estos separadores de línea y párrafo Unicode como los únicos caracteres canónicos de final de línea. Sin embargo, un enfoque común para resolver este problema es a través de la normalización de nueva línea. Esto se logra con el sistema de texto Cocoa en Mac OS X y también con las recomendaciones W3C XML y HTML. En este enfoque, todos los caracteres de nueva línea posibles se convierten internamente en una nueva línea común (que realmente 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.

Problemas

Unificación Han

La unificación de Han (la identificación de formas en los idiomas de Asia oriental que se pueden tratar como variaciones estilísticas del mismo carácter histórico) se ha convertido en uno de los aspectos más controvertidos de Unicode, a pesar de la presencia de una mayoría de expertos de los tres regiones en el Grupo de Investigación Ideográfica (IRG), que asesora al Consorcio e ISO sobre adiciones al repertorio y sobre la unificación de Han.

Unicode ha sido criticado por no codificar por separado formas antiguas y alternativas de kanji que, según los críticos, complica el procesamiento de nombres japoneses antiguos y japoneses poco comunes. Esto se debe a menudo al hecho de que Unicode codifica caracteres en lugar de glifos (las representaciones visuales del carácter básico que suelen variar de un idioma a otro). La unificación de los glifos conduce a la percepción de que se están fusionando los lenguajes mismos, no solo la representación básica de los caracteres. Ha habido varios intentos de crear codificaciones alternativas que preserven las diferencias estilísticas entre los caracteres chinos, japoneses y coreanos en oposición a la política de Unicode de unificación Han. Un ejemplo de uno es TRON (aunque no se adopta ampliamente en Japón, hay algunos usuarios que necesitan manejar texto japonés histórico y lo favorecen).

Aunque el repertorio de menos de 21 000 caracteres Han en la primera versión de Unicode se limitaba en gran medida a los caracteres de uso moderno común, Unicode ahora incluye más de 97 000 caracteres Han, y el trabajo continúa para agregar miles de caracteres históricos y dialectales más utilizados en China, Japón, Corea, Taiwán y Vietnam.

La tecnología de fuente moderna proporciona un medio para abordar el problema práctico de la necesidad de representar un carácter Han unificado en términos de una colección de representaciones alternativas de glifos, en forma de secuencias de variación Unicode. Por ejemplo, las tablas tipográficas avanzadas de OpenType permiten seleccionar una de varias representaciones alternativas de glifos al realizar el proceso de mapeo de caracteres a glifos. En este caso, la información se puede proporcionar en texto sin formato para designar qué forma de carácter alternativo seleccionar.

Caracteres en cursiva o cursiva en cirílico

Si los glifos apropiados para caracteres en la misma escritura difieren solo en la cursiva, Unicode generalmente los ha unificado, como se puede ver en la comparación entre un conjunto de siete caracteres' glifos en cursiva como aparecen típicamente en los textos 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 fuente inteligente o cambiando fuentes manualmente.

Asignación a conjuntos de caracteres heredados

Unicode se diseñó 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. Eso ha significado que las arquitecturas heredadas inconsistentes, como la combinación de signos diacríticos y caracteres precompuestos, existen en Unicode, lo que brinda 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 Hangul coreano. Desde la versión 3.0, los caracteres precompuestos que se pueden representar mediante una secuencia combinada de caracteres ya existentes ya no se pueden agregar al estándar para preservar la interoperabilidad entre el software que usa diferentes versiones de Unicode.

Se deben proporcionar asignaciones inyectivas entre los caracteres de los conjuntos de caracteres heredados existentes y los caracteres en Unicode para facilitar la conversión a Unicode y permitir la interoperabilidad con el software heredado. La falta de consistencia 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, a U+FF5E ～ TILDE DE ANCHO COMPLETO (en Microsoft Windows) o U+301C 〜 WAVE DASH (otros proveedores).

Algunos programadores informáticos japoneses se opusieron a Unicode porque les obliga a 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. (Esta codificación también reemplaza la tilde '~' 0x7E con macron '¯', ahora 0xAF). La separación de estos caracteres existe en ISO 8859-1, desde mucho antes de Unicode.

Escrituras índicas

A las escrituras índicas, como el tamil y el devanagari, solo se les asignan 128 puntos de código, lo que coincide con el estándar ISCII. La representación correcta del texto Unicode Indic requiere la transformación de los caracteres de orden lógico almacenados en un orden visual y la formación de ligaduras (también conocidas como conjuntos) a partir de componentes. Algunos académicos locales argumentaron a favor de las asignaciones de puntos de código Unicode a estas ligaduras, yendo en contra de la práctica de otros sistemas de escritura, aunque Unicode contiene algo de árabe y otras ligaduras solo con fines de compatibilidad con versiones anteriores. No se codificará ninguna ligadura nueva en Unicode, 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ó para la escritura tibetana en 2003 cuando la Administración de Normalización de China propuso codificar 956 sílabas tibetanas precompuestas, pero el comité ISO correspondiente rechazó la codificación (ISO/IEC JTC 1/SC 2).

La compatibilidad con el alfabeto tailandés ha sido criticada por ordenar 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 que siempre se había escrito tailandés en los teclados. Este problema de ordenamiento complica ligeramente el proceso de intercalación de Unicode, lo que requiere búsquedas en tablas para reordenar los caracteres tailandeses para la intercalación. 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 el orden hablado vendría después de la ด, pero en un diccionario, la palabra se coteja tal como está escrita, con la vocal siguiendo el ส.

Combinar personajes

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 espacio. Por ejemplo, ḗ (e precompuesta con macron y aguda arriba) y ḗ (e seguida de la combinación macron arriba y la combinación aguda arriba) deben representarse de manera idéntica, ambas apareciendo como una e con macron y acento agudo, pero en la práctica, su la apariencia puede variar según el motor de representación 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. puede resolverse mediante el uso de una fuente Unicode especializada como Charis SIL que utiliza tecnologías Graphite, OpenType o AAT para funciones de representación avanzadas.

Anomalías

El estándar Unicode ha impuesto reglas destinadas a garantizar la estabilidad. Dependiendo del rigor de una regla, se puede prohibir o permitir un cambio. Por ejemplo, un "nombre" dado a un punto de código no puede y no cambiará. Pero un "guión" La propiedad es más flexible, según las propias reglas de Unicode. En la versión 2.0, Unicode cambió muchos "nombres" desde la versión 1. En el mismo momento, Unicode declaró que a partir de ese momento, un nombre asignado a un punto de código nunca más cambiaría. Esto implica que cuando se publican errores, estos errores no se pueden corregir, incluso si son triviales (como sucedió en un caso con la ortografía BRAKCET para 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 personajes con problemas identificados, por ejemplo:

• U+2118 ℘ SCRIPT CAPITAL P: Es una pequeña carta. La capital es U+1D4AB P MATHEMATICAL SCRIPT CAPITAL P.
• U+034F ͏ GRAPHEME COMBINING No se une a los grafemas.
• U+A015 ꀕ YI SYLLABLE WU: Esto no es una sílaba Yi, sino una marca de iteración Yi.
• U+FE18 〗 PRESENTATION FORM FOR VERTICAL Right WHITE LENTICULAR BRAKCET: corchete está escrito incorrectamente. (Los errores de etiquetado se resuelven utilizando nombres de alias Unicode).

Mientras que Unicode define el designador de secuencia de comandos (nombre) como "Phags Pa", en los nombres de los personajes de esa secuencia de comandos se agrega un guión: U+A840 ꡀ LETRA KA DE PHAGS-PA.

Problemas de seguridad

Unicode tiene una gran cantidad de homoglifos, muchos de los cuales se parecen mucho o son idénticos a las letras ASCII. La sustitución de estos puede hacer que un identificador o URL parezca correcto, pero que dirija a una ubicación diferente a la esperada, y también podría usarse para manipular la salida de los sistemas de procesamiento de lenguaje natural (NLP).

La mitigación requiere no permitir estos caracteres, mostrarlos de manera diferente o requerir que se resuelvan en el mismo identificador; todo esto es complicado debido al enorme conjunto de personajes que cambia constantemente.

En 2021 se emitió un aviso de seguridad de dos investigadores, uno de la Universidad de Cambridge y otro de la misma y de la Universidad de Edimburgo, en el que afirman que los códigos BIDI se pueden usar para hacer grandes secciones de código. hacer algo diferente de lo que parecen hacer.