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 esas 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 muestran. Por ejemplo, Unicode define el punto de código U+006E (la minúscula latina "n") seguido de U+0303 (la tilde combinada "◌̃") como canónicamente equivalente al punto de código único U+00F1 (la minúscula letra " ñ " del alfabeto español ). Por lo tanto, esas secuencias deben mostrarse de la misma manera, deben ser tratadas de la misma manera por aplicaciones como alfabetización de nombres o búsqueda , y pueden sustituirse entre sí. De manera similar, cada bloque de sílaba Hangul que está codificado como un solo carácter puede codificarse de manera equivalente como una combinación de un jamo conjunto inicial, una vocal conjunto jamo y, si corresponde, un jamo conjunto 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 "ff") se define como compatible, pero no canónicamente equivalente, con la secuencia U+0066 U+0066 (dos letras latinas "f"). Las secuencias compatibles pueden tratarse de la misma manera en algunas aplicaciones (como clasificación e 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 contrario 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 equivalentes se reduzcan 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 otra completamente descompuesta (donde los puntos individuales se dividen en varios).
Por compatibilidad u otras razones, Unicode a veces asigna dos puntos de código diferentes a entidades que son esencialmente el mismo carácter. Por ejemplo, el carácter "Å" se puede codificar como U+00C5 (nombre estándar "LETRA A MAYÚSCULA LATINA CON ANILLO ARRIBA", una letra del alfabeto en sueco y en varios otros idiomas ) o como U+212B ("SIGNO DE 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" de voltio ) no tienen un punto de código separado para cada uso. En general, los puntos de código de caracteres verdaderamente idénticos (que se pueden representar de la misma manera en fuentes Unicode) 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 verse 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 usan por sí solos, sino que están destinados a modificarse o combinarse con un carácter base anterior. Ejemplos de estos caracteres combinados son la tilde combinada 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 del carácter es el proceso opuesto.
En general, los caracteres precompuestos se definen como canónicamente equivalentes a la secuencia de su letra base y la combinación posterior de signos diacríticos, en cualquier orden que puedan aparecer.
Algunas escrituras utilizan regularmente múltiples marcas de combinación que, en general, no interactúan tipográficamente y no tienen caracteres precompuestos para las combinaciones. Los pares de marcas que no interactúan se pueden almacenar en cualquier orden. Estas secuencias alternativas son en general canónicamente equivalentes. Las reglas que definen su secuenciación 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 sólo 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 el original (como los dígitos en posiciones de subíndice o superíndice , o los dígitos encerrados en un círculo (como "①") heredados de algunas fuentes japonesas). Dicha secuencia se considera compatible con la secuencia de caracteres originales (individuales y no modificados), en 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 interpretació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 diferentes reglas, algunas de las cuales generan muchas 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 conducir a las mismas dificultades que otros.
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 característica, los usuarios que busquen una secuencia de puntos de código particular no podrán encontrar otros glifos visualmente indistinguibles que tengan una representación de puntos 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 se 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 la forma compuesta como la descompuesta imponen un orden canónico en la secuencia de puntos del 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 los 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 , por ejemplo, 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. Lo mismo ocurre cuando se busca la letra latina I (U+0049) en el número romano precompuesto Ⅸ (U+2168). De manera similar, el superíndice ⁵ (U+2075) se transforma en 5 (U+0035) mediante el mapeo de compatibilidad.
Sin embargo, transformar superíndices en equivalentes básicos puede no ser apropiado para software de texto enriquecido , porque la información de 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 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 se encuentra en una de estas formas normalizadas no se modificará si el mismo algoritmo la procesa nuevamente.
Las formas normales no están cerradas bajo concatenación de cadenas . [3] Para cadenas Unicode defectuosas que comienzan con una vocal Hangul o un jamo conjunto final , la concatenación puede romper la composición.
Sin embargo, no son inyectivos (asignan diferentes glifos y secuencias originales a la misma secuencia normalizada) y, por lo tanto, tampoco son biyectivos (no se pueden restaurar). Por ejemplo, las distintas cadenas Unicode "U+212B" (el signo de 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ílaba Hangul) que será reemplazado por otro bajo la normalización se puede identificar en las tablas Unicode por tener un campo de compatibilidad no vacío pero carecer de una etiqueta de compatibilidad.
El ordenamiento canónico se ocupa principalmente del ordenamiento de una secuencia de caracteres combinados. Para los ejemplos de esta sección asumimos que estos caracteres son signos diacríticos , aunque en general algunos signos diacríticos no son caracteres combinables y algunos caracteres combinados no son signos 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 tengan un valor de clase de combinación distinto de cero debe ordenarse por el valor de clase de combinación utilizando un algoritmo de clasificación estable . Se requiere una clasificación estable porque se supone que la combinación de caracteres con el mismo valor de clase interactúa tipográficamente, por lo que los dos órdenes posibles no se consideran equivalentes.
Por ejemplo, el carácter U+1EBF (ế), usado en vietnamita , tiene un acento tanto agudo como 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 combinadas para los dos acentos son 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 combinación de caracteres.
Cuando dos aplicaciones comparten datos Unicode, pero los normalizan de manera diferente, pueden producirse errores y pérdida de datos. En un caso específico, OS X normalizó los nombres de archivos Unicode enviados desde el software Samba para compartir archivos e impresoras. Samba no reconoció los nombres de archivo alterados como equivalentes al original, lo que provocó la pérdida de datos. [4] [5] Resolver un problema de este tipo no es trivial, ya que la normalización no es invertible sin pérdidas.