La equivalencia Unicode es la especificación del estándar de codificación de caracteres Unicode de que algunas secuencias de puntos de código representan esencialmente el mismo carácter. Esta característica se introdujo en el estándar para permitir la compatibilidad con conjuntos de caracteres estándar preexistentes , que a menudo incluían caracteres similares o idénticos.
Unicode proporciona dos de estas nociones, equivalencia canónica y compatibilidad. Se supone que las secuencias de puntos de código que se definen como canónicamente equivalentes tienen la misma apariencia y significado cuando se imprimen o se muestran. Por ejemplo, el punto de código U+006E n LETRA N MINÚSCULA LATINA seguida de U+0303 ◌̃ TILDE COMBINADA se define por Unicode como canónicamente equivalente al punto de código único U+00F1 ñ LETRA N MINÚSCULA LATINA CON TILDE del alfabeto español ). Por lo tanto, esas secuencias se deben mostrar de la misma manera, se deben tratar de la misma manera por aplicaciones como la alfabetización de nombres o la búsqueda , y se pueden sustituir entre sí. De manera similar, cada bloque de sílaba Hangul que se codifica como un solo carácter se puede codificar de manera equivalente como una combinación de un jamo de unión inicial, un jamo de unión vocálica y, si corresponde, un jamo de unión final.
Se supone que las secuencias que se definen como compatibles tienen apariencias posiblemente distintas, pero el mismo significado en algunos contextos. Así, por ejemplo, el punto de código U+FB00 (la ligadura tipográfica "f") se define como compatible (pero no canónicamente equivalente) con la secuencia U+0066 U+0066 (dos letras "f" latinas). Las secuencias compatibles pueden tratarse de la misma manera en algunas aplicaciones (como la ordenación y la indexación ), pero no en otras; y pueden sustituirse entre sí en algunas situaciones, pero no en otras. Las secuencias que son canónicamente equivalentes también son compatibles, pero lo opuesto no es necesariamente cierto.
El estándar también define un procedimiento de normalización de texto , llamado normalización Unicode , que reemplaza secuencias equivalentes de caracteres de modo que dos textos cualesquiera que sean equivalentes se reducirán a la misma secuencia de puntos de código, llamada forma de normalización o forma normal del texto original. Para cada una de las dos nociones de equivalencia, Unicode define dos formas normales, una completamente compuesta (donde múltiples puntos de código se reemplazan por puntos únicos siempre que sea posible) y una completamente descompuesta (donde los puntos únicos se dividen en múltiples).
Por razones de compatibilidad u otras, Unicode a veces asigna dos puntos de código diferentes a entidades que son esencialmente el mismo carácter. Por ejemplo, la letra "A con un anillo diacrítico encima" se codifica como U+00C5 Å LETRA A MAYÚSCULA LATINA CON ANILLO ENCIMA (una letra del alfabeto en sueco y en varios otros idiomas ) o como U+212B Å SIGNO ANGSTROM . Sin embargo, el símbolo de angstrom se define como esa letra sueca, y la mayoría de los demás símbolos que son letras (como ⟨V⟩ para voltio ) no tienen un punto de código separado para cada uso. En general, los puntos de código de caracteres verdaderamente idénticos se definen como canónicamente equivalentes.
Para mantener la coherencia con algunos estándares más antiguos, Unicode proporciona puntos de código únicos para muchos caracteres que podrían considerarse como formas modificadas de otros caracteres (como U+00F1 para "ñ" o U+00C5 para "Å") o como combinaciones de dos o más caracteres (como U+FB00 para la ligadura "ff" o U+0132 para la letra holandesa " IJ ").
Para mantener la coherencia con otros estándares y lograr una mayor flexibilidad, Unicode también proporciona códigos para muchos elementos que no se utilizan por sí solos, sino que están pensados para modificar o combinar con un carácter base precedente. Algunos ejemplos de estos caracteres combinatorios son la tilde combinatoria y el diacrítico japonés dakuten ("◌゛", U+3099).
En el contexto de Unicode, la composición de caracteres es el proceso de reemplazar los puntos de código de una letra base seguido de uno o más caracteres combinados en un solo carácter precompuesto ; y la descomposición de caracteres es el proceso opuesto.
En general, los caracteres precompuestos se definen como canónicamente equivalentes a la secuencia de su letra base y las marcas diacríticas combinadas posteriores, en cualquier orden en que aparezcan.
Algunas escrituras utilizan con regularidad múltiples marcas de combinación que, en general, no interactúan tipográficamente y no tienen caracteres precompuestos para las combinaciones. Se pueden almacenar pares de estas marcas que no interactúan en cualquier orden. Estas secuencias alternativas son, en general, canónicamente equivalentes. Las reglas que definen su secuencia en la forma canónica también definen si se considera que interactúan.
Unicode proporciona puntos de código para algunos caracteres o grupos de caracteres que se modifican solo por razones estéticas (como las ligaduras , los caracteres katakana de ancho medio o las letras latinas de ancho completo para su uso en textos japoneses), o para agregar nueva semántica sin perder la original (como los dígitos en posiciones de subíndice o superíndice , o los dígitos en círculo (como "①") heredados de algunas fuentes japonesas). Tal secuencia se considera compatible con la secuencia de caracteres originales (individuales y sin modificar), para el beneficio de aplicaciones donde la apariencia y la semántica agregada no son relevantes. Sin embargo, las dos secuencias no se declaran canónicamente equivalentes, ya que la distinción tiene algún valor semántico y afecta la representación del texto.
UTF-8 y UTF-16 (y también algunas otras codificaciones Unicode) no permiten todas las secuencias posibles de unidades de código . Diferentes programas convertirán secuencias no válidas en caracteres Unicode utilizando distintas reglas, algunas de las cuales son muy susceptibles a pérdidas (por ejemplo, convertir todas las secuencias no válidas en el mismo carácter). Esto puede considerarse una forma de normalización y puede generar las mismas dificultades que otras.
Un software de procesamiento de texto que implemente la función de búsqueda y comparación de cadenas Unicode debe tener en cuenta la presencia de puntos de código equivalentes. En ausencia de esta función, los usuarios que busquen una secuencia de puntos de código en particular no podrán encontrar otros glifos visualmente indistinguibles que tengan una representación de punto de código diferente, pero canónicamente equivalente.
Unicode proporciona algoritmos de normalización estándar que producen una secuencia de puntos de código única (normal) para todas las secuencias que son equivalentes; los criterios de equivalencia pueden ser canónicos (NF) o de compatibilidad (NFK). Dado que uno puede elegir arbitrariamente el elemento representativo de una clase de equivalencia , son posibles múltiples formas canónicas para cada criterio de equivalencia. Unicode proporciona dos formas normales que son semánticamente significativas para cada uno de los dos criterios de compatibilidad: las formas compuestas NFC y NFKC, y las formas descompuestas NFD y NFKD. Tanto las formas compuestas como las descompuestas imponen un orden canónico en la secuencia de puntos de código, que es necesario para que las formas normales sean únicas.
Para comparar o buscar cadenas Unicode, el software puede utilizar formas compuestas o descompuestas; esta elección no importa siempre que sea la misma para todas las cadenas involucradas en una búsqueda, comparación, etc. Por otro lado, la elección de criterios de equivalencia puede afectar los resultados de la búsqueda. Por ejemplo, algunas ligaduras tipográficas como U+FB03 ( ffi ), números romanos como U+2168 ( Ⅸ ) e incluso subíndices y superíndices , p. ej. U+2075 ( ⁵ ) tienen sus propios puntos de código Unicode. La normalización canónica (NF) no afecta a ninguno de estos, pero la normalización de compatibilidad (NFK) descompondrá la ligadura ffi en las letras constituyentes, por lo que una búsqueda de U+0066 ( f ) como subcadena tendría éxito en una normalización NFKC de U+FB03 pero no en la normalización NFC de U+FB03. De la misma manera, cuando se busca la letra latina I (U+0049) en el número romano precompuesto Ⅸ (U+2168), el superíndice ⁵ (U+2075) se transforma en 5 (U+0035) mediante el mapeo de compatibilidad.
Sin embargo, la transformación de superíndices en equivalentes de línea base puede no ser adecuada para el software de texto enriquecido , porque la información del superíndice se pierde en el proceso. Para permitir esta distinción, la base de datos de caracteres Unicode contiene etiquetas de formato de compatibilidad que proporcionan detalles adicionales sobre la transformación de compatibilidad. [1] En el caso de las ligaduras tipográficas, esta etiqueta es simplemente <compat>, mientras que para el superíndice es <super>. Los estándares de texto enriquecido como HTML tienen en cuenta las etiquetas de compatibilidad. Por ejemplo, HTML utiliza su propio marcado para colocar un U+0035 en una posición de superíndice. [2]
Las cuatro formas de normalización Unicode y los algoritmos (transformaciones) para obtenerlas se enumeran en la siguiente tabla.
Todos estos algoritmos son transformaciones idempotentes , lo que significa que una cadena que ya está en una de estas formas normalizadas no se modificará si se procesa nuevamente con el mismo algoritmo.
Las formas normales no se cierran bajo la concatenación de cadenas . [3] Para las cadenas Unicode defectuosas que comienzan con una vocal Hangul o terminan con jamo , la concatenación puede romper la composición.
Sin embargo, no son inyectivas (asignan diferentes glifos y secuencias originales a la misma secuencia normalizada) y, por lo tanto, tampoco biyectivas (no se pueden restaurar). Por ejemplo, las cadenas Unicode distintas "U+212B" (el signo angstrom "Å") y "U+00C5" (la letra sueca "Å") se expanden mediante NFD (o NFKD) en la secuencia "U+0041 U+030A" (letra latina "A" y anillo combinado encima de "°") que luego se reduce mediante NFC (o NFKC) a "U+00C5" (la letra sueca "Å").
Un solo carácter (que no sea un bloque de sílabas Hangul) que será reemplazado por otro durante la normalización puede identificarse en las tablas Unicode por tener un campo de compatibilidad no vacío pero carecer de una etiqueta de compatibilidad.
El orden canónico se ocupa principalmente del ordenamiento de una secuencia de caracteres combinables. Para los ejemplos de esta sección, asumimos que estos caracteres son diacríticos , aunque en general algunos diacríticos no son caracteres combinables y algunos caracteres combinables no son diacríticos.
Unicode asigna a cada carácter una clase de combinación , que se identifica mediante un valor numérico. Los caracteres que no se combinan tienen el número de clase 0, mientras que los caracteres que se combinan tienen un valor de clase de combinación positivo. Para obtener el orden canónico, cada subcadena de caracteres que tenga un valor de clase de combinación distinto de cero debe ordenarse por el valor de clase de combinación utilizando un algoritmo de ordenación estable . Se requiere una ordenación estable porque se supone que los caracteres que se combinan con el mismo valor de clase interactúan tipográficamente, por lo que los dos órdenes posibles no se consideran equivalentes.
Por ejemplo, el carácter U+1EBF (ế), utilizado en vietnamita , tiene acento agudo y circunflejo. Su descomposición canónica es la secuencia de tres caracteres U+0065 (e) U+0302 (acento circunflejo) U+0301 (acento agudo). Las clases de combinación para los dos acentos son ambas 230, por lo que U+1EBF no es equivalente a U+0065 U+0301 U+0302.
Dado que no todas las secuencias de combinación tienen un equivalente precompuesto (la última en el ejemplo anterior solo se puede reducir a U+00E9 U+0302), incluso la forma normal NFC se ve afectada por el comportamiento de los caracteres de combinación.
Cuando dos aplicaciones comparten datos Unicode, pero los normalizan de forma diferente, pueden producirse errores y pérdida de datos. En un caso específico, OS X normalizó los nombres de archivo Unicode enviados desde el software de intercambio de archivos e impresoras Netatalk y Samba . Netatalk y Samba no reconocieron los nombres de archivo modificados como equivalentes al original, lo que provocó la pérdida de datos. [4] [5] Resolver este problema no es trivial, ya que la normalización no es invertible sin pérdida.