Décodeur Unicode

Cet outil prend en charge \uXXXX (BMP), \UXXXXXXXX (Unicode complet), &#DDDD; (entité HTML décimale), &#xHHHH; (entité HTML hexadécimale) et U+XXXX (notation de point de code) pour le décodage.

UTF-8 encode chaque point de code Unicode en utilisant 1 à 4 octets. Les caractères ASCII (U+0000 à U+007F) utilisent 1 octet, les caractères latins et courants utilisent 2 octets, la plupart des caractères CJC utilisent 3 octets, et les emoji et caractères rares utilisent 4 octets.

\uXXXX utilise 4 chiffres hexadécimaux et peut représenter les caractères du plan multilingue de base (U+0000 à U+FFFF). \UXXXXXXXX utilise 8 chiffres hexadécimaux et peut représenter n'importe quel caractère Unicode, y compris ceux au-delà du BMP.

Ce sont des signes de mojibake : des octets UTF-8 décodés comme du Windows-1252/Latin-1. « é » signifie que les deux octets UTF-8 de « é » (0xC3 0xA9) ont été affichés comme deux caractères séparés. Utilisez le mode Réparer. « � » est U+FFFD : ces octets sont définitivement perdus.

UTF-8 encode les caractères sur 1 à 4 octets et est compatible ASCII : c'est le standard du web, de JSON et des API. UTF-16 utilise 2 ou 4 octets (paires de substitution au-delà de U+FFFF) et sert de représentation interne à JavaScript, Java et Windows. Pour le web, UTF-8 est plus compact et plus sûr.

Un point de code est un numéro attribué à un caractère dans la norme Unicode (U+00E9 pour le e accent aigu) ; une unité de code est l'unité de stockage qu'utilise un encodage. Les unités de code UTF-8 sont des octets de 8 bits - U+00E9 en occupe deux - tandis que les unités de code UTF-16 sont sur 16 bits, et les caractères au-delà de U+FFFF en nécessitent deux (une paire de substitution). Les chaînes JavaScript sont en UTF-16, donc 'hello'.length vaut 5 mais le .length d'un émoji vaut 2.

Un même caractère visible peut avoir plusieurs séquences d'octets : le e accent aigu comme un seul caractère précomposé (NFC) ou e plus un accent combinant (NFD). NFC compose, NFD décompose, et NFKC/NFKD réduisent en outre les caractères de compatibilité (formes pleine largeur, ligatures). Comparer ou hacher une saisie utilisateur sans normaliser au préalable est une source classique de comptes en double et d'échecs de recherche - ligature fi vs f+i.

Le marqueur d'ordre des octets (BOM) est U+FEFF encodé au début d'un flux (EF BB BF en UTF-8) pour signaler l'encodage. Les éditeurs de texte le masquent généralement, mais en aval il devient un premier caractère invisible : un en-tête CSV gagne une clé fantôme, l'analyse JSON échoue sur ce jeton parasite, et les sessions PHP l'émettent avant les en-têtes. UTF-8 n'a pas besoin de BOM puisqu'il ne présente aucune ambiguïté d'ordre des octets - enregistrez sans BOM.