Decodificatore Unicode

Questo strumento supporta \uXXXX (BMP), \UXXXXXXXX (Unicode completo), &#DDDD; (entità HTML decimale), &#xHHHH; (entità HTML esadecimale) e U+XXXX (notazione punto di codice) per la decodifica.

UTF-8 codifica ogni punto di codice Unicode utilizzando da 1 a 4 byte. I caratteri ASCII (da U+0000 a U+007F) usano 1 byte, i caratteri latini e altri comuni usano 2 byte, la maggior parte dei caratteri CJK usa 3 byte e le emoji e i caratteri rari usano 4 byte.

\uXXXX usa 4 cifre esadecimali e può rappresentare caratteri nel Piano Multilingue Base (da U+0000 a U+FFFF). \UXXXXXXXX usa 8 cifre esadecimali e può rappresentare qualsiasi carattere Unicode inclusi quelli oltre il BMP.

Sono segni di mojibake: byte UTF-8 decodificati come Windows-1252/Latin-1. «Ã©» indica che i due byte UTF-8 di «é» (0xC3 0xA9) sono stati mostrati come caratteri separati. Usa la modalità Correggi. «ï¿½» è U+FFFD: quei byte sono persi per sempre.

UTF-8 codifica i caratteri in 1–4 byte ed è compatibile ASCII: è lo standard del web, di JSON e delle API. UTF-16 usa 2 o 4 byte (coppie surrogate oltre U+FFFF) ed è usato internamente da JavaScript, Java e Windows. Per i testi web UTF-8 è più compatto e sicuro.

Un punto di codice è un numero assegnato a un carattere nello standard Unicode (U+00E9 per la e accentata); un'unità di codice è l'unità di archiviazione usata da una codifica. Le unità di codice UTF-8 sono byte a 8 bit - U+00E9 ne occupa due - mentre le unità di codice UTF-16 sono a 16 bit e i caratteri oltre U+FFFF ne richiedono due (una coppia surrogata). Le stringhe JavaScript sono UTF-16, quindi 'hello'.length è 5 ma il .length di un'emoji è 2.

Lo stesso carattere visibile può avere più sequenze di byte: la e accentata come un singolo carattere precomposto (NFC) oppure come e più un accento combinante (NFD). NFC compone, NFD decompone e NFKC/NFKD riportano inoltre i caratteri di compatibilità alla forma base (forme full-width, legature). Confrontare o calcolare l'hash dell'input utente senza normalizzare prima è una classica causa di account duplicati e ricerche non andate a buon fine - legatura fi contro f+i.

Il byte order mark è U+FEFF codificato all'inizio di uno stream (EF BB BF in UTF-8) per segnalare la codifica. Gli editor di solito lo nascondono, ma a valle diventa un primo carattere invisibile: un'intestazione CSV acquisisce una chiave fantasma, il parsing JSON fallisce per via del token indesiderato e le sessioni PHP lo emettono prima degli header. UTF-8 non ha bisogno di un BOM poiché non presenta ambiguità nell'ordine dei byte - salva senza.