Unicode

Unicode è lo standard universale di codifica dei caratteri mantenuto dal Unicode Consortium. Assegna un numero univoco (un “code point”) a ogni carattere in ogni sistema di scrittura che è stato formalmente proposto e accettato — attualmente circa 150.000 caratteri su 161 script, incluse le lingue moderne, i sistemi di scrittura storici, i simboli matematici, la notazione tecnica e le emoji.

I code point sono scritti come U+XXXX (4-6 cifre esadecimali). La lettera A è U+0041; la i senza punto turca è U+0131; l’emoji del razzo è U+1F680.

Unicode stesso non specifica come i code point vengono serializzati in byte — è compito delle codifiche. Le tre principali codifiche:

• UTF-8 — larghezza variabile da 1 a 4 byte per code point. Compatibile con ASCII. La codifica web dominante.
• UTF-16 — 2 o 4 byte per code point. Usato internamente da Java, le stringhe JavaScript e Windows.
• UTF-32 — esattamente 4 byte per code point. Semplice ma dispendioso; raramente usato per l’archiviazione.

Gli strumenti di Convertitive gestiscono Unicode completo dove necessario — il codificatore Base64 gestisce correttamente UTF-8, il contatore di parole conta code point e grafemi, il convertitore maiuscole/minuscole rispetta la maiuscolizzazione specifica del turco (il problema della I con e senza punto).

Code point ≠ carattere ≠ grafema — la distinzione che rompe ogni libreria di stringhe: la lettera “é” può essere rappresentata in due modi in Unicode — come il singolo code point U+00E9 (precomposto) o come U+0065 (e) seguito da U+0301 (accento acuto combinante). Entrambi si renderizzano in modo identico; entrambi contano come “un carattere” per un essere umano; uno è un code point, l’altro è due. Le emoji sono peggio: 👨‍👩‍👧 (famiglia) è una sequenza ZWJ di sette code point ma un solo grafema. I conteggi di lunghezza in JavaScript (str.length) restituiscono unità di codice UTF-16, non grafemi — l’emoji della famiglia ha una lunghezza stringa di 11. Usa Intl.Segmenter (browser moderni, Node 16+) per conteggi accurati dei grafemi.

Forme di normalizzazione Unicode — quando il testo non corrisponde a se stesso: due stringhe visivamente identiche possono avere rappresentazioni byte diverse a causa della suddivisione precomposto-decomposto sopra citata. Lo Standard Unicode definisce quattro forme di normalizzazione (NFC, NFD, NFKC, NFKD) che canonicalizzano questo. NFC (composto) è il predefinito per HTML e la maggior parte dei file system; NFD (decomposto) è il predefinito di macOS HFS+ e il motivo per cui i percorsi di file a volte sembrano identici ma si confrontano come diversi tra sistemi. Le ricerche di uguaglianza di stringhe nei database e le ricerche negli indici di ricerca dovrebbero normalizzare in NFC in scrittura per evitare il bug “la query identica non corrisponde”. Riferimento: The Unicode Standard, Version 15.

Esempio pratico

Prendi la stringa “café”. Due rappresentazioni Unicode ugualmente valide: NFC = U+0063 U+0061 U+0066 U+00E9 (4 code point), NFD = U+0063 U+0061 U+0066 U+0065 U+0301 (5 code point, “e” + accento acuto combinante). Entrambi si renderizzano in modo identico. Considera ora come appare ciascuno in diversi conteggi: in UTF-8 NFC è 5 byte (63 61 66 C3 A9); NFD è 6 byte (63 61 66 65 CC 81). In JavaScript: "café".length = 4 per NFC, 5 per NFD. Confronta l’uguaglianza senza normalizzare: nfc === nfd è false. Esegui entrambi tramite String.prototype.normalize("NFC") prima: diventano identici. Bug risolto. Questa è la causa radice esatta di “ho cercato José e il record esiste ma non viene restituito” nei database che memorizzano nomi inviati dagli utenti da client Mac e Windows misti.

Quando e perché è importante

Ogni applicazione internazionalizzata prima o poi incontra i casi limite di Unicode: nomi utente con segni combinanti, percorsi di file copiati tra macOS (NFD) e Linux (NFC), vietnamita con diacritici sovrapposti, regole di maiuscolizzazione turche (la minuscola di “I” è “ı” non “i” — il “problema della I turca” ha causato veri crash di iOS nel 2018), rendering da destra a sinistra di arabo ed ebraico e sequenze ZWJ di emoji i cui code point componenti evolvono più velocemente degli aggiornamenti del font del tuo telefono. Le regole difensive: normalizza in NFC all’input, usa Intl.Collator per l’ordinamento specifico della locale (non il sort per code point di Array.sort), usa Intl.Segmenter per il troncamento consapevole dei grafemi e lascia che CLDR (il database delle locale di Unicode) guidi il comportamento specifico della locale piuttosto che codificare regole fisse. Riferimento: Unicode Technical Report #15 — Normalization Forms.