Solución:
Todo lo que nunca quiso saber sobre la normalización Unicode
Normalización canónica
Unicode incluye varias formas de codificar algunos caracteres, sobre todo los acentuados. La normalización canónica cambia los puntos de código a una forma de codificación canónica. Los puntos de código resultantes deben parecer idénticos a los originales, salvo que existan errores en las fuentes o en el motor de renderizado.
Cuándo usar
Debido a que los resultados parecen idénticos, siempre es seguro aplicar la normalización canónica a una cadena antes de almacenarla o mostrarla, siempre que pueda tolerar que el resultado no sea bit por bit idéntico a la entrada.
La normalización canónica viene en 2 formas: NFD y NFC. Los dos son equivalentes en el sentido de que uno puede convertir entre estas dos formas sin pérdida. Comparar dos cadenas bajo NFC siempre dará el mismo resultado que compararlas bajo NFD.
NFD
NFD tiene los personajes completamente expandidos. Esta es la forma de normalización más rápida de calcular, pero da como resultado más puntos de código (es decir, utiliza más espacio).
Si solo desea comparar dos cadenas que aún no están normalizadas, esta es la forma de normalización preferida a menos que sepa que necesita la normalización de compatibilidad.
NFC
NFC recombina puntos de código cuando es posible después de ejecutar el algoritmo NFD. Esto lleva un poco más de tiempo, pero resulta en cadenas más cortas.
Normalización de compatibilidad
Unicode también incluye muchos caracteres que realmente no pertenecen, pero que se usaron en conjuntos de caracteres heredados. Unicode los agregó para permitir que el texto en esos conjuntos de caracteres se procese como Unicode y luego se vuelva a convertir sin pérdida.
La normalización de compatibilidad los convierte en la secuencia correspondiente de caracteres “reales” y también realiza la normalización canónica. Los resultados de la normalización de compatibilidad pueden no parecer idénticos a los originales.
Los caracteres que incluyen información de formato se reemplazan por otros que no. Por ejemplo el personaje ⁹ se convierte en 9. Otros no implican diferencias de formato. Por ejemplo, el carácter de número romano Ⅸ se convierte a las letras regulares IX.
Obviamente, una vez realizada esta transformación, ya no es posible volver a convertir sin pérdidas al juego de caracteres original.
Cuándo usar
El Consorcio Unicode sugiere pensar en la normalización de compatibilidad como un ToUpperCase transformar. Es algo que puede ser útil en algunas circunstancias, pero no debe aplicarlo de cualquier manera.
Un caso de uso excelente sería un motor de búsqueda, ya que probablemente desee buscar 9 para igualar ⁹.
Una cosa que probablemente no debería hacer es mostrar el resultado de aplicar la normalización de compatibilidad al usuario.
NFKC / NFKD
La forma de normalización de compatibilidad viene en dos formas NFKD y NFKC. Tienen la misma relación que entre NFD y C.
Cualquier cadena en NFKC está intrínsecamente también en NFC, y lo mismo para NFKD y NFD. Por lo tanto NFKD(x)=NFD(NFKC(x)), y NFKC(x)=NFC(NFKD(x))etc.
Conclusión
En caso de duda, opte por la normalización canónica. Elija NFC o NFD según la compensación de espacio / velocidad aplicable, o según lo que requiera algo con lo que esté interactuando.
Algunos caracteres, por ejemplo, una letra con acento (digamos, é) se puede representar de dos formas: un único punto de código U+00E9 o la letra simple seguida de un acento combinado U+0065 U+0301. La normalización ordinaria elegirá uno de estos para representarlo siempre (el punto de código único para NFC, la forma de combinación para NFD).
Para los caracteres que podrían estar representados por múltiples secuencias de caracteres base y marcas de combinación (por ejemplo, “s, punto abajo, punto arriba” versus poner un punto arriba y luego un punto abajo o usando un carácter base que ya tiene uno de los puntos), NFD también elija uno de estos (a continuación, va primero, como sucede)
Las descomposiciones de compatibilidad incluyen una serie de caracteres que “realmente no deberían” ser caracteres, pero lo son porque se utilizaron en codificaciones heredadas. La normalización ordinaria no unificará estos (para preservar la integridad del viaje de ida y vuelta; esto no es un problema para los formularios de combinación porque no hay codificación heredada [except a handful of vietnamese encodings] utilizado ambos), pero la normalización de compatibilidad lo hará. Piense como el signo de kilogramo “kg” que aparece en algunas codificaciones de Asia Oriental (o el alfabeto y katakana de ancho medio / ancho completo), o la ligadura “fi” en MacRoman.
Consulte http://unicode.org/reports/tr15/ para obtener más detalles.
Las formas normales (de Unicode, no de bases de datos) tratan principalmente (¿exclusivamente?) Con caracteres que tienen marcas diacríticas. Unicode proporciona algunos caracteres con marcas diacríticas “incorporadas”, como U + 00C0, “Latin Capital A with Grave”. Se puede crear el mismo carácter a partir de una “A mayúscula latina” (U + 0041) con un “Acento grave combinado” (U + 0300). Eso significa que aunque las dos secuencias produzcan el mismo carácter resultante, un byte por byte la comparación mostrará que son completamente diferentes.
La normalización es un intento de lidiar con eso. La normalización asegura (o al menos intenta hacerlo) que todos los caracteres están codificados de la misma manera, ya sea usando una marca diacrítica de combinación separada donde sea necesario, o todos usando un solo punto de código siempre que sea posible. Desde el punto de vista de la comparación, no importa mucho cuál elijas, prácticamente cualquier cadena normalizada se comparará correctamente con otra cadena normalizada.
En este caso, “compatibilidad” significa compatibilidad con el código que asume que un punto de código es igual a un carácter. Si tiene un código como ese, probablemente desee utilizar la forma normal de compatibilidad. Aunque nunca lo he visto expresado directamente, los nombres de las formas normales implican que el consorcio Unicode considera preferible usar marcas diacríticas combinadas separadas. Esto requiere más inteligencia para contar los caracteres reales en una cadena (así como cosas como romper una cadena de manera inteligente), pero es más versátil.
Si está haciendo un uso completo de la UCI, es probable que desee utilizar la forma normal canónica. Si está tratando de escribir un código por su cuenta que (por ejemplo) asume que un punto de código es igual a un carácter, entonces probablemente desee la forma normal de compatibilidad que lo haga realidad con la mayor frecuencia posible.