Unicode

Los orígenes de Unicode se remontan a la década de 1980, a un grupo de personas vinculadas al Estándar de Código de Caracteres (XCCS) de Xerox . ^{[ 6 ]} En 1987, Joe Becker , empleado de Xerox , junto con Lee Collins y Mark Davis , empleados de Apple , comenzaron a investigar la viabilidad de crear un conjunto de caracteres universal. ^{[ 7 ]} Con aportaciones adicionales de Peter Fenwick y Dave Opstad , ^{[ 6 ]} Becker publicó en agosto de 1988 un borrador de propuesta para un «sistema internacional/multilingüe de codificación de caracteres de texto, denominado provisionalmente Unicode». Explicó que «el nombre "Unicode" pretende sugerir una codificación única, unificada y universal». ^{[ 6 ]}

En este documento, titulado Unicode 88 , Becker describió un esquema que utiliza caracteres de 16 bits : ^{[ 6 ]}

Unicode se diseñó para satisfacer la necesidad de una codificación de texto mundial práctica y fiable. Unicode podría describirse, a grandes rasgos, como un sistema ASCII de amplio espectro , ampliado a 16  bits para abarcar los caracteres de todos los idiomas vivos del mundo. En un diseño adecuado, 16  bits por carácter son más que suficientes para este propósito.

Esta decisión de diseño se tomó sobre la base de que solo los alfabetos y caracteres de uso "moderno" requerirían codificación: ^{[ 6 ]}

Unicode prioriza la utilidad futura por encima de la conservación de caracteres antiguos. Su objetivo principal son los caracteres publicados en textos modernos (por ejemplo, en la unión de todos los periódicos y revistas impresos en el mundo en 1988), cuyo número es indudablemente muy inferior a ^2¹⁴ = 16 384. Más allá de estos caracteres de uso moderno, todos los demás pueden considerarse obsoletos o poco comunes; estos son mejores candidatos para el registro de uso privado que para saturar la lista pública de caracteres Unicode de uso general.

A principios de 1989, el grupo de trabajo de Unicode se amplió para incluir a Ken Whistler y Mike Kernaghan de Metaphor, Karen Smith-Yoshimura y Joan Aliprand de Research Libraries Group , y Glenn Wright de Sun Microsystems . Research Libraries Group tenía una solución existente para conjuntos de caracteres de Asia Oriental, que se convirtió en una de las entradas para el conjunto de caracteres Unicode. ^{[ 7 ]} En 1990, Michel Suignard y Asmus Freytag de Microsoft y Rick McGowan de NeXT también se unieron al grupo. Para finales de 1990, la mayor parte del trabajo de reasignación de los estándares existentes se había completado, y un borrador final de revisión de Unicode estaba listo.

El Consorcio Unicode se constituyó en California el 3 de enero de 1991, ^{[ 8 ]} y el primer volumen del Estándar Unicode se publicó en octubre de ese mismo año. El segundo volumen, que ahora incluía los ideogramas Han, se publicó en junio de 1992.

En 1996, se implementó un mecanismo de caracteres sustitutos en Unicode 2.0, por lo que Unicode dejó de estar restringido a 16 bits. Esto aumentó el espacio de códigos Unicode a más de un millón de puntos de código, lo que permitió la codificación de muchos sistemas de escritura históricos, como los jeroglíficos egipcios , y miles de caracteres poco utilizados u obsoletos que no se habían previsto para su inclusión en el estándar. Entre estos caracteres se encuentran varios caracteres CJK poco utilizados , muchos de los cuales se emplean principalmente en nombres propios, lo que los hace mucho más necesarios para una codificación universal de lo que preveía la arquitectura Unicode original. ^{[ 9 ]}

El Consorcio Unicode es una organización sin fines de lucro que coordina el desarrollo de Unicode. Entre sus miembros de pleno derecho se encuentran la mayoría de las principales empresas de software y hardware (y algunas otras) con interés en los estándares de procesamiento de texto, como Adobe , Apple , Google , IBM , Meta (anteriormente Facebook), Microsoft , Netflix y SAP . ^{[ 10 ]}

A lo largo de los años, varios países u organismos gubernamentales han sido miembros del Consorcio Unicode. ^{[ 10 ]}

El Consorcio tiene el ambicioso objetivo de reemplazar eventualmente los esquemas de codificación de caracteres existentes con Unicode y sus esquemas estándar de formato de transformación Unicode (UTF), ya que muchos de los esquemas existentes son limitados en tamaño y alcance y son incompatibles con entornos multilingües .

El premio Unicode Bulldog se otorga a personas consideradas influyentes en el desarrollo de Unicode, entre cuyos galardonados se encuentran Tatsuo Kobayashi , Thomas Milo, Roozbeh Pournader, Ken Lunde y Michael Everson . ^{[ 11 ]}

A partir de septiembre de 2025Un total de 172 ^{[ 12 ]} sistemas de escritura ( alfabetos , abugidas y silabarios ) están incluidos en Unicode, cubriendo la mayoría de los principales sistemas de escritura en uso hoy en día. ^{[ 13 ] [ 14 ]} Todavía hay sistemas de escritura que no están codificados, particularmente aquellos utilizados principalmente en contextos históricos, litúrgicos y académicos. También se producen nuevas adiciones de caracteres a los sistemas de escritura ya codificados, así como símbolos , en particular para matemáticas y música .

El Comité de la Hoja de Ruta de Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) ^{[ 15 ]} mantiene la lista de escrituras que son candidatas o candidatas potenciales para la codificación y sus asignaciones tentativas de bloques de código en la página de la Hoja de Ruta de Unicode ^{[ 16 ]} del sitio web del Consorcio Unicode . Para algunas escrituras en la Hoja de Ruta, como la escritura grande Jurchen y Khitan , se han hecho propuestas de codificación y están en proceso de aprobación. Para otras escrituras, como Numidian y Rongorongo , aún no se ha hecho ninguna propuesta y están a la espera de un acuerdo sobre el repertorio de caracteres y otros detalles de las comunidades de usuarios involucradas.

Algunos sistemas de escritura modernos inventados que aún no se han incluido en Unicode (por ejemplo, Tengwar ) o que no cumplen los requisitos para su inclusión en Unicode debido a la falta de uso en el mundo real (por ejemplo, Klingon ) figuran en el Registro Unicode de ConScript , junto con asignaciones de códigos de área de uso privado no oficiales pero ampliamente utilizadas.

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

La Iniciativa de Codificación de Escrituras (SEI), ^{[ 17 ]} un proyecto creado por Deborah Anderson en la Universidad de California, Berkeley , se fundó en 2002 con el objetivo de financiar propuestas para escrituras que aún no se habían codificado en el estándar. Actualmente dirigida por Anushah Hossain, SEI se ha convertido en una importante fuente de propuestas de adición al estándar en los últimos años. ^{[ 18 ]} Aunque SEI colabora con el Consorcio Unicode y el proceso de estándares ISO/IEC 10646, opera de forma independiente, brindando apoyo a la investigación técnica, lingüística e histórica necesaria para preparar propuestas formales. SEI mantiene una base de datos de escrituras que aún no se han codificado en el Estándar Unicode en el sitio web del proyecto. ^{[ 19 ]}

El Consorcio Unicode, junto con la ISO, ha desarrollado un repertorio común tras la publicación inicial del Estándar Unicode : Unicode y el Conjunto Universal de Caracteres Codificados (UCS) de la ISO utilizan nombres de caracteres y puntos de código idénticos. Sin embargo, las versiones Unicode difieren de sus equivalentes ISO en dos aspectos importantes.

Si bien el UCS es un mapa de caracteres simple, Unicode especifica las reglas, algoritmos y propiedades necesarias para lograr la interoperabilidad entre diferentes plataformas e idiomas. Por lo tanto, el Estándar Unicode incluye más información, abarcando 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 diagramas 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 del estándar, ^{[ nota 1 ]} y los diagramas de código. 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 impreso bajo demanda. ^{[ 20 ]} El texto completo, por otro lado, se publica como un PDF gratuito en el sitio web de Unicode.

Una razón práctica para este método de publicación pone de manifiesto la segunda diferencia significativa entre el UCS y Unicode: la frecuencia con la que se publican versiones actualizadas y se añaden nuevos caracteres. El estándar Unicode ha publicado regularmente versiones ampliadas anuales, en ocasiones con más de una versión en un mismo año natural y, en raras ocasiones, con retrasos en la publicación prevista. 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 modificado la fecha de lanzamiento prevista para la versión 14.0, posponiéndola seis meses, hasta septiembre de 2021, debido a la pandemia de COVID-19 .

Hasta la fecha, se han publicado las siguientes versiones del Estándar Unicode . Las versiones de actualización, que no incluyen cambios en el repertorio de caracteres, se indican con el tercer número (por ejemplo, "versión 4.0.1") y se omiten en la tabla siguiente. ^{[ 21 ]}

El estándar Unicode define un espacio de códigos : ^{[ 59 ]} una secuencia de enteros llamados puntos de código ^{[ 60 ]} en el rango de 0 a1 114 111 , notado según el estándar como U+0000 – U+10FFFF . ^{[ 61 ]} El espacio de códigos es una representación sistemática e independiente de la arquitectura del estándar Unicode ; el texto real se procesa como datos binarios a través de una de varias codificaciones Unicode, como UTF-8 .

En esta notación normativa, el prefijo de dos caracteres U+siempre precede a un punto de código escrito, y los puntos de código en sí se escriben como números hexadecimales . ^{[ nota 2 ]} Siempre se escriben al menos cuatro dígitos hexadecimales, con ceros iniciales añadidos según sea necesario. Por ejemplo, el punto de código U+00F7 ÷ SIGNO DE DIVISIÓN se rellena con dos ceros iniciales, pero U+13254 𓉔 JEROGLIFO EGIPCIO O004 ( ) no se rellena. ^{[ 63 ]}

Hay un total de1 112 064 puntos de código válidos dentro del espacio de códigos. ^{[ 64 ]} Este número surge de las limitaciones de la codificación de caracteres UTF-16 , que puede codificar los 2 ¹⁶ puntos de código en el rango U+0000 a U+FFFF excepto los 2 ¹¹ puntos de código en el rango U+D800 a U+DFFF , que se utilizan como pares sustitutos para codificar los 2 ²⁰ puntos de código en el rango U+10000 a U+10FFFF .

El espacio de códigos 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. Todos los puntos de código en el BMP se acceden como una sola unidad de código en la codificación UTF-16 y se pueden codificar en uno, dos o tres bytes en UTF-8. Los puntos de código en los planos del 1 al 16 (los planos suplementarios ) se acceden como pares subrogados en UTF-16 y se codifican en cuatro bytes en UTF-8 .

Dentro de cada plano, los caracteres se distribuyen en bloques con nombre que contienen caracteres relacionados. El tamaño de un bloque siempre es un múltiplo de 16, y a menudo un múltiplo de 128, pero por lo demás es arbitrario. Los caracteres necesarios para un sistema de escritura determinado pueden estar repartidos en varios bloques diferentes, potencialmente disjuntos, dentro del espacio de código.

A cada punto de código se le asigna una clasificación, que se indica como su propiedad de Categoría General . En el nivel superior, los puntos de código se clasifican como Letra, Marca, Número, Puntuación, Símbolo, Separador u Otro. Dentro de cada categoría, cada punto de código se subcategoriza. En la mayoría de los casos, se deben utilizar otras propiedades para describir adecuadamente todas las características de un punto de código determinado.

El1024 puntos en el rango U+D800 – U+DBFF se conocen como puntos de código sustitutos altos , y puntos de código en el rango U+DC00 – U+DFFF (Los puntos de código U+FFFF ( 1024 puntos de código) se conocen como puntos de código subrogados bajos . Un punto de código subrogado alto seguido de un punto de código subrogado bajo forma un par subrogado 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 suele ignorarse, especialmente cuando no se usa UTF-16.

Se garantiza que un pequeño conjunto de puntos de código nunca se asignará a caracteres, 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. ^{[ 65 ]} Al igual que con los sustitutos, la regla de que estos no se pueden usar a menudo se ignora, aunque el funcionamiento de la marca de orden de bytes asume que U+FFFE nunca será el primer punto de código en un texto. La exclusión de sustitutos y no caracteres deja1 111 998 puntos de código disponibles para su uso.

Los puntos de código de uso privado se consideran asignados, pero intencionalmente no tienen una interpretación especificada por el Estándar Unicode ^{[ 66 ],} de modo que cualquier intercambio de dichos puntos de código requiere un acuerdo independiente entre el emisor y el receptor en cuanto a su interpretación. Hay tres áreas de uso privado en el espacio de códigos Unicode:

• Zona de uso privado: U+E000 – U+F8FF (6400 caracteres),
• Área de uso privado suplementaria-A: U+F0000 – U+FFFFD (65 534 caracteres),
• Área de uso privado suplementaria-B: U+100000 – U+10FFFD (65 534 caracteres).

Los caracteres gráficos son aquellos definidos por el estándar Unicode para tener una semántica particular, ya sea que tengan una forma de glifo visible o representen un espacio visible. A partir de Unicode 17.0, hay159 629 caracteres gráficos.

Los caracteres de formato son aquellos que no tienen una apariencia visible, pero que pueden afectar la apariencia o el comportamiento de los caracteres adyacentes. Por ejemplo, U+200C ZERO WIDTH NON-JOINER y U+200D ZERO WIDTH JOINER se pueden usar para cambiar el comportamiento de forma predeterminado de los caracteres adyacentes (por ejemplo, para inhibir las ligaduras o solicitar su formación). Unicode 17.0 incluye 172 caracteres de formato.

Se reservan 65 puntos de código, los rangos U+0000 – U+001F y U+007F – U+009F , como códigos de control , correspondientes a los códigos de control C0 y C1 definidos en ISO/IEC 6429. U +0009 TAB , U+000A SALTO DE LÍNEA y U+000D RETORNO DE CARRO se utilizan ampliamente en textos que emplean 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 , que antes se utilizaba ampliamente 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 se han asignado. A partir de Unicode 17.0, existen814 664 puntos de código reservados.

El conjunto de caracteres gráficos y de formato definidos por Unicode no se corresponde directamente con el repertorio de caracteres abstractos representables en Unicode. Unicode codifica caracteres asociando un carácter abstracto con un punto de código específico. ^{[ 67 ]} Sin embargo, no todos los caracteres abstractos se codifican como un único carácter Unicode, y algunos pueden representarse en Unicode mediante una secuencia de dos o más caracteres. Por ejemplo, la letra minúscula latina "i" con un ogonek , un punto encima y un acento agudo , que es necesaria en lituano , se representa mediante la secuencia de caracteres U+012F ; U+0307 ; U+0301 . Unicode mantiene una lista de secuencias de caracteres con nombres únicos para los caracteres abstractos que no se codifican directamente en Unicode. ^{[ 68 ]}

Todos los caracteres asignados tienen un nombre único e inmutable mediante el cual se identifican. Esta inmutabilidad se ha garantizado desde la versión 2.0 del Estándar Unicode mediante su política de Estabilidad de Nombres. ^{[ 65 ]} 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 que las aplicaciones utilicen en lugar del nombre oficial del carácter. Por ejemplo, U+A015 ꀕ YI SYLLABLE WU tiene el alias formal YI SYLLABLE ITERATION MARK , y U+FE18 ︘ PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET ( sic ) tiene el alias formal PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRA CK ET . ^{[ 69 ]}

Unicode incluye un mecanismo para modificar caracteres que amplía enormemente el repertorio de glifos compatibles. Esto abarca el uso de signos diacríticos combinables que el usuario puede añadir después del carácter base. Se pueden aplicar varios signos diacríticos combinables simultáneamente al mismo carácter. Unicode también contiene versiones precompuestas de la mayoría de las combinaciones de letras y signos diacríticos de uso común. Estas simplifican la conversión desde y hacia codificaciones antiguas y permiten que las aplicaciones utilicen Unicode como formato de texto interno sin tener que implementar caracteres combinables. Por ejemplo, ése puede representar en Unicode como U+0065 e LETRA MINÚSCULA LATINA E seguida de U+0301 ◌ ́ ACENTO AGUDO COMBINABLE , y de forma equivalente como el carácter precompuesto U+00E9 é LETRA MINÚSCULA LATINA E CON ACENTO AGUDO . Por lo tanto, los usuarios suelen tener varias 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 hechas a partir del jamo más común.

Actualmente, los caracteres CJK solo tienen códigos para radicales no componibles y formas precompuestas. La mayoría de los caracteres Han se han compuesto intencionalmente a partir de elementos ortográficos más simples llamados radicales , o se han reconstruido como composiciones de estos. Por lo tanto, en principio, Unicode podría haber permitido su composición, como lo hizo con el Hangul. Si bien esto podría haber reducido considerablemente la cantidad de puntos de código necesarios, además de permitir la síntesis algorítmica de muchos caracteres nuevos arbitrarios, la complejidad de las etimologías de los caracteres y la naturaleza a posteriori de los sistemas de radicales añaden una enorme complejidad a la propuesta. De hecho, los intentos de diseñar codificaciones CJK basadas en la composición de radicales se han topado con dificultades derivadas de la realidad de que los caracteres chinos no se descomponen de forma tan simple ni tan regular como el Hangul.

El bloque Suplemento de radicales CJK se asigna al rango U+2E80 – U+2EFF , y los radicales Kangxi se asignan 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 representación alternativa para caracteres codificados en otros lugares:

Este proceso es diferente de la codificación formal de un ideograma. No existe una descripción canónica de los ideogramas no codificados; no se asigna ninguna semántica a los ideogramas descritos; no se define ninguna equivalencia para los ideogramas descritos. Conceptualmente, las descripciones ideográficas se asemejan más a la frase en inglés "una 'e' con acento agudo" que a la secuencia de caracteres < U+0065, U+0301 > .

La ligadura Devanāgarī ddhrya (द् + ध् + र् + य = द्ध्र्य) de JanaSanskritSans ^{[ 70 ]}

La ligadura árabe lām - alif ( ل ‎ +‎ ا ‎ =‎ لا )

Muchos sistemas de escritura, incluidos el árabe y el devanagari , tienen reglas ortográficas especiales que requieren que ciertas combinaciones de formas de letras se combinen para formar ligaduras especiales . Las reglas que rigen la formación de ligaduras pueden ser bastante complejas, lo que requiere tecnologías especiales de modelado de escritura como ACE (Arabic Calligraphic Engine de DecoType en la década de 1980, utilizado para generar todos los ejemplos árabes en las ediciones impresas del estándar Unicode ), que se convirtió en la prueba de concepto para OpenType (de Adobe y Microsoft), Graphite (de SIL International ) o AAT (de Apple).

Las fuentes también incluyen instrucciones para indicar al sistema operativo cómo generar correctamente diferentes secuencias de caracteres. Una solución sencilla para la colocación de marcas de combinación o diacríticos consiste en asignarles un ancho de cero y situar el glifo a la izquierda o a la derecha del lado izquierdo (según la dirección del alfabeto con el que se vayan a utilizar). Una marca manejada de esta forma aparecerá sobre el carácter que la precede, pero no ajustará su posición con respecto al ancho o alto del glifo base; puede resultar visualmente poco estético y superponerse a algunos glifos. El apilamiento real es imposible, pero se puede aproximar en casos limitados (por ejemplo, las vocales de combinación superior y las marcas de tono tailandesas pueden simplemente tener diferentes alturas inicialmente). Generalmente, este enfoque solo es efectivo en fuentes monoespaciadas, pero puede utilizarse como método de renderizado alternativo cuando fallan métodos más complejos.

Se estandarizan varios subconjuntos de Unicode: Microsoft Windows, desde Windows NT 4.0, admite WGL-4 con 657 caracteres, que se considera compatible con todos los idiomas europeos contemporáneos que utilizan los alfabetos latino, griego o cirílico. Otros subconjuntos estandarizados de Unicode incluyen los subconjuntos europeos multilingües: ^{[ 71 ]} MES-1 (solo alfabetos latinos; 335 caracteres), MES-2 (latín, griego y cirílico; 1062 caracteres) ^{[ 72 ]} y MES-3A y MES-3B (dos subconjuntos más grandes, no mostrados aquí). MES-2 incluye todos los caracteres de MES-1 y WGL-4.

La norma DIN 91379 ^{[ 73 ]} especifica un subconjunto de letras Unicode, caracteres especiales y secuencias de letras y signos diacríticos para permitir la representación correcta de nombres y simplificar el intercambio de datos en Europa. Esta norma es compatible con todos los idiomas oficiales de los países de la Unión Europea, así como con las lenguas minoritarias alemanas y los idiomas oficiales de Islandia, Liechtenstein, Noruega y Suiza. Para permitir la transliteración de nombres en otros sistemas de escritura al alfabeto latino según las normas ISO pertinentes, se proporcionan todas las combinaciones necesarias de letras base y signos diacríticos.

El software de renderizado que no puede procesar correctamente un carácter Unicode suele mostrarlo como un rectángulo abierto o como U+FFFD para indicar la posición del carácter no reconocido. Algunos sistemas han intentado proporcionar más información sobre dichos caracteres. La fuente Last Resort de Apple muestra un glifo sustituto que indica el rango Unicode del carácter, y la fuente alternativa de SIL International muestra un recuadro con 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 mapea (posiblemente un subconjunto de) el rango de puntos de código Unicode a secuencias de valores en un rango de tamaño fijo, denominadas unidades de código . Todas las codificaciones UTF mapean puntos de código a una secuencia única de bytes. ^{[ 74 ]} Los números en los nombres de las codificaciones indican el número de bits por unidad de código (para las codificaciones UTF) o el número de bytes por unidad de código (para las 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 , que utiliza de una a cuatro unidades de 8 bits por punto de código , ^{[ nota 3 ]} y tiene máxima compatibilidad con ASCII
• UTF-16 , que utiliza una unidad de 16 bits por punto de código por debajo de U+010000 , y un par sustituto de dos unidades de 16 bits por punto de código en el rango de U+010000 a U+10FFFF.
• UTF-32 , que utiliza una unidad de 32 bits por punto de código.
• UTF-EBCDIC , no especificado como parte del estándar Unicode , que utiliza de una a cinco unidades de 8 bits por punto de código, destinado a maximizar la compatibilidad con EBCDIC.

UTF-8 utiliza de una a cuatro unidades de 8 bits ( 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 la mayoría de las distribuciones Linux recientes lo utilizan como reemplazo directo de las codificaciones antiguas en el manejo general de texto.

Las codificaciones UCS-2 y UTF-16 especifican la marca de orden de bytes (BOM) de Unicode para su uso al inicio de los archivos de texto, que puede utilizarse para la detección del orden de bytes (o detección del orden de bytes ). La BOM, codificada como U+FEFF ZERO WIDTH NO-BREAK SPACE , tiene la importante propiedad de no ambigüedad en la reordenación de bytes, independientemente de la codificación Unicode utilizada; U+FFFE (el resultado del intercambio de bytes U+FEFF ) no equivale a un carácter válido, y U+FEFF en lugares distintos al inicio del texto transmite el espacio de no separación de ancho cero.

El mismo carácter convertido a UTF-8 se convierte en la secuencia de bytes EF BB BF. El estándar Unicode permite que la BOM "puede servir como firma para texto codificado en UTF-8 donde el conjunto de caracteres no está marcado". ^{[ 75 ]} Algunos desarrolladores de software la han adoptado para otras codificaciones, incluida 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 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 en los patrones posibles en UTF-8 (por ejemplo, no puede haber bytes solitarios con el bit más significativo activado) significa que debería ser posible distinguir UTF-8 de otras codificaciones de caracteres sin depender de la BOM. 

En UTF-32 y UCS-4, una unidad de código de 32 bits sirve como una representación bastante directa del punto de código de cualquier carácter (aunque el orden de bytes, que varía entre plataformas, afecta a cómo se manifiesta la unidad de código como una secuencia de bytes). En las demás codificaciones, cada punto de código puede representarse mediante un número variable de unidades de código. UTF-32 se utiliza ampliamente como representación interna de texto en programas (a diferencia del texto almacenado o transmitido), ya que todos los sistemas operativos Unix que utilizan los compiladores GCC para generar software lo emplean como codificación estándar de " caracteres anchos ". Las versiones recientes del lenguaje de programación Python (a partir de la 2.2) también pueden configurarse para usar UTF-32 como representación de cadenas Unicode, lo que contribuye a la difusión de dicha codificación en software de alto nivel .

Punycode , otra forma de codificación, permite codificar cadenas Unicode en el conjunto limitado de caracteres compatible con el Sistema de Nombres de Dominio (DNS) basado en ASCII . Esta codificación se utiliza como parte de IDNA , un sistema que permite el uso de nombres de dominio internacionalizados en todos los sistemas de escritura compatibles con Unicode. Entre las propuestas anteriores, ahora históricas, se incluyen UTF-5 y UTF-6 .

GB18030 es otra forma de codificación para Unicode, de la Administración de Normalización de China . Es el conjunto de caracteres oficial de la República Popular China (RPC). BOCU-1 y SCSU son esquemas de compresión Unicode. El RFC del Día de los Inocentes de 2005 especificó dos codificaciones UTF de parodia, UTF-9 y UTF-18 .

Unicode se ha convertido en el esquema dominante para el procesamiento y almacenamiento interno de texto. Aunque gran cantidad de texto todavía se almacena en codificaciones antiguas, Unicode se utiliza casi exclusivamente para la creación de nuevos sistemas de procesamiento de información. Los primeros usuarios tendieron a utilizar UCS-2 (el precursor obsoleto de dos bytes de longitud fija de UTF-16) y posteriormente migraron a UTF-16 (el estándar actual de longitud variable), ya que esta era la forma menos disruptiva de añadir compatibilidad con caracteres que no son BMP. El sistema más conocido es Windows NT (y sus sucesores, 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. Se puede instalar compatibilidad parcial con Unicode en Windows 9x mediante la capa de Microsoft para Unicode.

UTF-8 (desarrollado originalmente para Plan 9 ) ^{[ 81 ]} se ha convertido en la principal codificación de almacenamiento en la mayoría de los sistemas operativos tipo Unix (aunque algunas bibliotecas también utilizan otras) porque es un reemplazo relativamente fácil para los conjuntos de caracteres ASCII extendidos tradicionales . UTF-8 es también la codificación Unicode más común utilizada en documentos HTML en la World Wide Web .

Entre los motores de renderizado de texto multilingües que utilizan Unicode se incluyen Uniscribe y DirectWrite para Microsoft Windows, ATSUI y Core Text para macOS, y Pango para GTK+ y el entorno de escritorio GNOME .

Dado que la distribución del teclado no permite combinaciones de teclas sencillas para todos los caracteres, varios sistemas operativos ofrecen métodos de entrada alternativos que permiten acceder a todo el repertorio.

La norma ISO/IEC 14755 ^{[ 82 ]} , que estandariza los métodos para introducir caracteres Unicode a partir de sus puntos de código, especifica varios métodos. Existe el método básico , en el que una secuencia inicial va seguida de la representación hexadecimal del punto de código y la secuencia final . También se especifica un método de entrada por selección de pantalla , en el que los caracteres se muestran en una tabla en pantalla, como en un programa de mapa de caracteres.

Entre las herramientas en línea para encontrar el punto de código de un carácter conocido se encuentran Unicode Lookup ^{[ 83 ]} de Jonathan Hedley y Shapecatcher ^{[ 84 ]} de Benjamin Milde. En Unicode Lookup, se introduce una palabra clave de búsqueda (por ejemplo, "fracciones") y se devuelve una lista de caracteres correspondientes con sus puntos de código. En Shapecatcher, basado en el contexto Shape , se dibuja el carácter en un recuadro y se devuelve una lista de caracteres que se aproximan al dibujo, con sus respectivos puntos de código.

MIME define dos mecanismos distintos para codificar caracteres no ASCII en el correo electrónico, según si estos se encuentran en las cabeceras (como el asunto) o en el cuerpo del mensaje. En ambos casos, se identifica tanto el conjunto de caracteres original como la codificación de transferencia. Para la transmisión de Unicode por correo electrónico, 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 contiene caracteres ASCII . Los detalles de ambos mecanismos se especifican en los estándares MIME y, por lo general, permanecen ocultos para los usuarios de software de correo electrónico.

El IETF ha definido ^{[ 85 ] [ 86 ]} un marco para el correo electrónico internacionalizado utilizando UTF-8, y ha actualizado ^{[ 87 ] [ 88 ] [ 89 ] [ 90 ]} varios protocolos de acuerdo con ese marco.

La adopción de Unicode en el correo electrónico ha sido muy lenta. Algunos textos de Asia Oriental todavía se codifican con sistemas de codificación como ISO-2022 , y algunos dispositivos, como los teléfonos móviles, aún no pueden procesar correctamente los datos Unicode. Sin embargo, la compatibilidad ha ido mejorando. Muchos de los principales proveedores de correo electrónico gratuito, como Yahoo! Mail , Gmail y Outlook.com, ya lo admiten.

Todas las recomendaciones del W3C han utilizado Unicode como conjunto de caracteres para sus documentos desde HTML 4.0. Los navegadores web han sido compatibles con Unicode, especialmente con UTF-8, durante muchos años. Antes existían problemas de visualización derivados principalmente de problemas relacionados con las fuentes ; por ejemplo, las versiones 6 y anteriores de Microsoft Internet Explorer no mostraban muchos puntos de código a menos que se les indicara explícitamente que utilizaran una fuente que los contuviera. ^{[ 91 ]}

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, ^{[ 92 ]} comprenden caracteres de la mayoría de los puntos de código Unicode, con la excepción de:

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

Los caracteres HTML se manifiestan directamente como bytes según la codificación del documento, si esta los admite, o bien los usuarios pueden escribirlos como referencias numéricas de caracteres basadas en el punto de código Unicode del carácter. Por ejemplo, las referencias Δ, Й, ק, م, ๗, あ, 叶, 葉, y 말(o los mismos valores numéricos expresados ​​en hexadecimal, con &#xcomo 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 codificarse con porcentaje .

Unicode no se preocupa en principio por las fuentes en sí , sino que las considera opciones de implementación. ^{[ 93 ]} Cualquier carácter dado puede tener muchos alógrafos , desde las formas más comunes de letras 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 utilizando los puntos de código definidos en el Estándar Unicode . ^{[ 94 ]} El estándar no especifica un número mínimo de caracteres que deba incluir la fuente; algunas fuentes tienen un repertorio bastante pequeño.

Existen numerosas fuentes gratuitas y comerciales basadas en Unicode, ya que TrueType y OpenType son compatibles con Unicode (y el formato Web Open Font Format (WOFF y WOFF2 ) se basa en ellos). Estos formatos de fuente asignan puntos de código Unicode a glifos, pero los archivos de fuente OpenType y TrueType están limitados a 65 535 glifos. Los archivos de colección ofrecen 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 sigue teniendo el límite de 65 535 glifos). Un archivo de colección TrueType normalmente tendría la extensión ".ttc".

Existen miles de fuentes en el mercado, pero menos de una docena —a veces denominadas fuentes "pan-Unicode"— intentan admitir la mayor parte del repertorio de caracteres Unicode. En cambio, las fuentes basadas en Unicode suelen centrarse en admitir solo ASCII básico y sistemas de escritura o conjuntos de caracteres o símbolos específicos. 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 consumir recursos en los entornos informáticos; y los sistemas operativos y las aplicaciones muestran una inteligencia cada vez mayor en lo que respecta a la obtención de información de glifos de archivos de fuentes independientes según sea necesario, es decir, la 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; tal empresa supera el punto de rendimiento decreciente para la mayoría de las tipografías.

Unicode soluciona parcialmente el problema de los saltos de línea que se produce al intentar leer un archivo de texto en diferentes plataformas. Unicode define una gran cantidad de caracteres que las aplicaciones compatibles deben reconocer como terminadores de línea.

En cuanto al salto de línea, Unicode introdujo los separadores de línea U+2028 y U+2029 . Esto representó un intento de proporcionar una solución Unicode para la codificación semántica de párrafos y líneas, con el potencial de reemplazar las diversas soluciones de las distintas plataformas. De esta manera, Unicode ofrece una alternativa a las soluciones históricas dependientes de la plataforma. Sin embargo, pocas soluciones Unicode, si acaso alguna, han adoptado estos separadores de línea y párrafo como los únicos caracteres canónicos de fin de línea. No obstante, un enfoque común para resolver este problema es la normalización del salto de línea. Esto se logra con el sistema de texto Cocoa en macOS y también con las recomendaciones XML y HTML del W3C. En este enfoque, cada posible carácter de salto de línea se convierte internamente a un salto de línea común (cuyo carácter no importa realmente, ya que se trata de una operación interna para la representación). En otras palabras, el sistema de texto puede tratar correctamente el carácter como un salto de línea, independientemente de la codificación real de la entrada.

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. ^{[ 105 ]} Además, los homoglifos también se pueden usar para manipular la salida de los sistemas de procesamiento del lenguaje natural (PLN) . ^{[ 106 ]} La mitigación requiere prohibir estos caracteres, mostrarlos de manera diferente o exigir que se resuelvan al mismo identificador; ^{[ 107 ]} todo esto es complicado debido al enorme y cambiante conjunto de caracteres. ^{[ 108 ] [ 109 ]}

En 2021, dos investigadores, uno de la Universidad de Cambridge y otro de la Universidad de Edimburgo , publicaron un aviso de seguridad en el que afirmaban que las marcas BiDi podían utilizarse para que grandes secciones de código realizaran acciones distintas a las que aparentaban. El problema se denominó « Fuente troyana ». ^{[ 110 ]} En respuesta, los editores de código comenzaron a resaltar las marcas para indicar cambios forzados en la dirección del texto. ^{[ 111 ]}

Las codificaciones UTF-8 y UTF-16 no aceptan todas las secuencias posibles de unidades de código. Las implementaciones varían en su comportamiento al leer una secuencia no válida, lo que ha dado lugar a fallos de seguridad. ^{[ 112 ] [ 113 ]}

Unicode se diseñó para proporcionar una conversión de formato bidireccional , punto por punto, desde y hacia cualquier codificación de caracteres preexistente, de modo que los archivos de texto en conjuntos de caracteres antiguos puedan convertirse a Unicode y luego volver a Unicode para obtener el mismo archivo, sin emplear una interpretación dependiente del contexto. Esto ha dado lugar a arquitecturas heredadas inconsistentes, como la combinación de diacríticos y caracteres precompuestos , que coexisten en Unicode, lo que proporciona más de un método para representar un mismo texto. Esto se observa con mayor claridad en las tres formas de codificación diferentes del Hangul coreano . Desde la versión 3.0, los caracteres precompuestos que pueden representarse mediante una secuencia combinada de caracteres ya existentes ya no pueden añadirse al estándar para preservar la interoperabilidad entre el software que utiliza diferentes versiones de Unicode.

Se deben proporcionar asignaciones inyectivas entre los caracteres de los conjuntos de caracteres heredados existentes y los caracteres de 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, a U+FF5E ～ FULLWIDTH TILDE (en Microsoft Windows ) o U+301C 〜 WAVE DASH (otros proveedores). ^{[ 114 ]}

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 asignaba a 0x5C en JIS X 0201, y existe mucho código heredado con este uso. ^{[ 115 ]} (Esta codificación también reemplaza la tilde '~' 0x7E con el macrón '¯', ahora 0xAF). La separación de estos caracteres existe en ISO 8859-1 , de mucho antes de Unicode.

A las escrituras índicas como el tamil y el devanagari se les asignan solo 128 puntos de código cada una, en consonancia con el estándar ISCII . La representación correcta del texto índico Unicode requiere transformar los caracteres de orden lógico almacenados en orden visual y la formación de ligaduras (también conocidas como conjunciones) a partir de componentes. Algunos académicos locales argumentaron a favor de la asignación de puntos de código Unicode a estas ligaduras, en contra de la práctica de otros sistemas de escritura, aunque Unicode contiene algunas ligaduras árabes y de otros idiomas solo por motivos de compatibilidad con versiones anteriores. ^{[ 116 ] [ 117 ] [ 118 ]} La codificación de nuevas ligaduras 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, ^{[ 119 ]} pero estas fueron rechazadas para su codificación por el comité ISO pertinente ( ISO/IEC JTC 1/SC 2 ). ^{[ 120 ]}

El soporte para el alfabeto tailandés ha sido criticado por su ordenación de caracteres tailandeses. Las vocales เ, แ, โ, ใ, ไ que se escriben a la izquierda de la consonante precedente 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 el tailandés en los teclados. Este problema de ordenación complica ligeramente el proceso de intercalación de Unicode, requiriendo búsquedas en tablas para reordenar los caracteres tailandeses para la intercalación. ^{[ 97 ]} Incluso si Unicode hubiera adoptado la codificación según el orden hablado, seguiría siendo problemático intercalar palabras en el orden del diccionario. Por ejemplo, la palabra แสดง[ sa dɛːŋ ] "perform" comienza con un grupo de consonantes "สด" (con una vocal inherente para la consonante "ส"), la vocal แ-, en orden hablado iría después de la ด, pero en un diccionario, la palabra se coteja como se escribe, con la vocal después de la ส.

Los caracteres con signos diacríticos generalmente se pueden representar como un solo carácter precompuesto o como una secuencia descompuesta de una letra base más uno o más signos que no sean de espaciado. Por ejemplo, ḗ (e precompuesta con macrón y acento agudo arriba) y ē ́ (e seguida del macrón y el acento agudo combinatorios arriba) deberían representarse de forma idéntica, apareciendo ambas como una e con un macrón (◌̄) y un 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. Del mismo modo, los puntos inferiores , necesarios en la romanización de las lenguas índicas , a menudo se colocan incorrectamente. En muchos casos, se pueden usar caracteres Unicode que se corresponden con glifos precompuestos, evitando así el problema, pero cuando no se ha codificado ningún carácter precompuesto, el problema suele resolverse utilizando una fuente Unicode especializada como Charis SIL , que utiliza las tecnologías Graphite , OpenType ('gsub') o AAT para funciones de renderizado avanzadas.

El estándar Unicode ha impuesto reglas destinadas a garantizar la estabilidad. ^{[ 121 ]} Dependiendo de la rigurosidad de una regla, un cambio puede estar prohibido o permitido. Por ejemplo, un "nombre" dado a un punto de código no puede ni podrá cambiar. Pero una propiedad de "escritura" es más flexible, según las propias reglas de Unicode. En la versión 2.0, Unicode cambió muchos "nombres" de puntos de código de la versión 1. Al mismo tiempo, Unicode declaró que, a partir de entonces, un nombre asignado a un punto de código nunca cambiaría. Esto implica que cuando se publican errores, estos no se pueden corregir, incluso si son triviales (como sucedió en un caso con la ortografía BRAKCET en lugar de BRACKET en el nombre de un carácter). En 2006 se publicó por primera vez una lista de anomalías en los nombres de caracteres y, a junio de 2021, había 104 caracteres con problemas identificados, ^{[ 122 ]} por ejemplo:

• U+034F ͏ COMBINANDO UNICIÓN DE GRAFEMAS : No une grafemas. ^{[ 122 ]}
• U+2118 ℘ ESCRITURA MAYÚSCULA P : Esta es una letra minúscula. La mayúscula es U+1D4AB 𝒫 ESCRITURA MATEMÁTICA MAYÚSCULA P. ^{[ 123 ]}
• U+A015 ꀕ SÍLABA YI WU : Esta no es una sílaba Yi, sino una marca de iteración Yi.
• U+FE18 ︘ FORMATO DE PRESENTACIÓN PARA CORCHETE LENTICULAR BLANCO VERTICAL DERECHO : el corchete está mal escrito. ^{[ 124 ]} (Los errores ortográficos se resuelven utilizando alias Unicode ).

Si bien Unicode define el designador (nombre) de escritura como " Phags_Pa ", en los nombres de caracteres de esa escritura se agrega un guion: U+A840 ꡀ PHAGS-PA LETRA KA . ^{[ 125 ] [ 126 ]} Sin embargo, esto no es una anomalía, sino la regla: los guiones se reemplazan por guiones bajos en los designadores de escritura. ^{[ 125 ]}