Normalizzatore Unicode NFD

La forma di normalizzazione Unicode D, o NFD, riscrive una stringa in modo che ogni carattere precomposto si espanda in un carattere base seguito dai segni combinanti che ne definiscono l'aspetto. Un café con e-acuta precomposta diventa la sequenza di cinque code point c-a-f-e più accento acuto combinante; le sillabe hangul si dividono in jamo; Å diventa A più un anello combinante. Questa capacità riceve un campo di testo, applica l'algoritmo NFD della piattaforma secondo lo Unicode Standard Annex 15 e restituisce la stringa normalizzata insieme a statistiche di lunghezza e a un flag di modifica.

Cosa fa davvero la scomposizione canonica NFD

Unicode memorizza molte lettere accentate in due modi: come un unico code point precomposto, ad esempio U+00E9 per la e minuscola latina con acuto, oppure come la lettera base U+0065 seguita dall'accento acuto combinante U+0301. Entrambe le sequenze appaiono uguali a schermo, ma sono sequenze di byte diverse, rompono l'uguaglianza delle stringhe e possono sorprendere controlli di lunghezza, espressioni regolari e vincoli di unicità nei database.

La Normalization Form D, definita nello Unicode Standard Annex 15, applica la scomposizione canonica: ogni carattere con un mapping di scomposizione canonica viene sostituito da tale mapping e i segni combinanti sono ordinati per classe di combinazione così che sequenze equivalenti diventino identiche. NFD non ricompone in seguito; quel passo di ricomposizione è NFC. NFD non applica nemmeno i mapping di compatibilità, quindi una legatura come fi o una cifra a larghezza piena resta com'è: la scomposizione di compatibilità spetta a NFKD e NFKC.

Le sillabe hangul ricevono una scomposizione algoritmica speciale in jamo iniziale, vocale e finale, ed è per questo che una breve parola coreana può crescere di diverse volte in lunghezza di code point restando lo stesso testo linguistico. Poiché la tabella di mapping e l'ordine dei segni sono fissati dalla versione Unicode del runtime, lo stesso input produce sempre la stessa stringa NFD su un dato motore.

Dove NFD compare nel lavoro di ingegneria reale

Le pipeline di ricerca e autocompletamento spesso rimuovono i diacritici dopo NFD affinché cafe corrisponda a café senza mantenere una tabella di accenti scritta a mano per ogni lingua. I generatori di identificatori e slug scompongono prima e poi eliminano i segni combinanti, producendo chiavi stabili di tipo ASCII da titoli orientati all'utente. Il QA di localizzazione confronta due esportazioni che sembrano uguali a schermo ma falliscono i test di uguaglianza finché entrambi i lati non vengono forzati in NFD.

Ingegneri di font e di shaping ispezionano sequenze scomposte mentre eseguono il debug dell'ancoraggio dei segni e della sostituzione dei glifi. I revisori di sicurezza normalizzano nomi utente ed etichette di dominio prima dei controlli su allow-list affinché lookalike precomposti e scomposti non eludano un filtro che ha elencato una sola forma. I job di migrazione dati convertono corpus legacy densi di NFC in NFD quando un sistema a valle documenta NFD come forma di archiviazione.

I corsi di programmazione insegnano l'encoding mostrando che un carattere visibile può diventare due code point dopo NFD, e una landing dedicata al normalizzatore serve meglio tale intento di ricerca che sepolto sotto convertitori generali di code point Unicode o strumenti Base64. Preferisca uno strumento NFC o NFKC separato quando serve composizione o piegatura di compatibilità; questa pagina si rivolge a chi ha specificamente bisogno della scomposizione canonica Unicode NFD e di una stringa normalizzata deterministica da fidarsi in test e pipeline.