Compteur d'octets UTF-8 | Repérer l'écart entre VARCHAR et String.length sur un seul écran

Collez un texte et obtenez simultanément le nombre d'octets UTF-8, les points de code Unicode (vrais caractères), les unités de code UTF-16 (ce que renvoie string.length en JavaScript) et le nombre de lignes. Un détail réparti en 4 catégories (ASCII, Latin étendu, BMP CJK, emoji et plans supplémentaires) montre précisément quels caractères font gonfler votre budget de stockage.

💡 À propos de cet outil

Si vous avez déjà vu une insertion MySQL refusée par ERROR 1406: Data too long for column, constaté qu'un JWT contenant un emoji pèse presque le double, ou découvert dans la console que '😀'.length === 2, vous avez heurté l'écart entre points de code Unicode, octets UTF-8 et unités UTF-16.

UTF-8 est un encodage à longueur variable défini par le RFC 3629 : ASCII tient sur 1 octet, le Latin étendu (é, à, ç, œ), le grec et le cyrillique sur 2, le bloc CJK du BMP sur 3, et tout ce qui se trouve au-dessus de U+FFFF — emoji, idéogrammes supplémentaires, symboles mathématiques — sur 4 octets. Les chaînes JavaScript sont en interne en UTF-16, donc tout caractère hors BMP apparaît comme une paire de substitution (surrogate pair) et compte pour 2 dans length. Conséquence : les bases de données comptent en octets, les API JS raisonnent en unités UTF-16 et nous, humains, comptons en graphèmes. Les trois mesures divergent dès qu'un emoji ou un caractère exotique entre en jeu.

Cet outil affiche les quatre métriques en parallèle et range chaque caractère dans l'un des quatre seaux d'octets UTF-8, pour répondre à des questions concrètes : « Pourquoi un texte français pèse-t-il plus qu'un texte anglais équivalent ? », « Combien d'emoji rentrent dans une clé Redis de 4 Ko ? », « Mon display_name tient-il dans ce NVARCHAR(50) ? ».

🧐 Questions fréquentes

Q. VARCHAR(255), c'est 255 caractères ou 255 octets ? A. Depuis MySQL 5.0.3, c'est 255 caractères, mais la limite de taille de ligne est calculée en octets (65 535 par ligne). Avec utf8mb4, un VARCHAR(N) est traité comme pouvant occuper jusqu'à N × 4 octets pour le calcul d'index et de ligne, donc une seule colonne VARCHAR(16383) suffit à atteindre la limite. Utilisez le champ « Octets UTF-8 » de cet outil pour dimensionner vos colonnes avec des données réelles.

Q. Pourquoi '😀'.length renvoie 2 en JavaScript ? A. String.prototype.length renvoie le nombre d'unités de code UTF-16. U+1F600 se trouve hors du BMP, il est donc encodé par la paire de substitution 😀. Pour compter les caractères réels, utilisez [...chaîne].length, Array.from(chaîne).length ou le champ « Caractères » de cet outil, qui parcourt les points de code avec for..of.

Q. Quelle différence entre utf8 et utf8mb4 dans MySQL ? A. Le jeu de caractères historique utf8 stocke au maximum 3 octets par caractère et remplace silencieusement tout caractère de 4 octets (emoji, plusieurs idéogrammes supplémentaires, symboles mathématiques) par ?. utf8mb4 est l'UTF-8 complet selon le RFC 3629. Pour tout nouveau schéma, choisissez systématiquement utf8mb4 : si le seau « 4 octets » de cet outil contient ne serait-ce qu'une valeur, le jeu de caractères historique aurait corrompu vos données.

Q. Caractères vs unités UTF-16 : quand l'écart compte-t-il ? A. Dès qu'une API fait confiance à string.length : les key React, un substring naïf, les validateurs de longueur de mot de passe, la limite Twitter avant 2017. Les graphèmes (👨‍👩‍👧‍👦 = un seul caractère perçu) diffèrent aussi des points de code ; utilisez Intl.Segmenter quand vous avez besoin d'un comptage orienté utilisateur final.

Q. Comment sont comptés les sauts de ligne ? A. LF (\n), CRLF (\r\n) et CR (\r) sont tous traités comme un séparateur de ligne unique. Une entrée vide vaut 0 ligne, toute entrée non vide vaut au moins 1. À noter : CRLF occupe quand même 2 octets et 2 unités UTF-16 même s'il ne compte que pour un séparateur.

📚 Le saviez-vous

• L'héritage de l'ISO-8859-1: Avant la généralisation d'UTF-8 vers 2010, la plupart des systèmes francophones tournaient sur ISO-8859-1 (Latin-1), où chaque caractère, y compris les accentués, occupait exactement 1 octet. La migration vers UTF-8 a fait passer un fichier .txt français moyen d'environ 1,1 octet par caractère à 1,2 octet par caractère — un surcoût modeste qui a rendu possibles les emoji et le grec dans le même fichier. Collez un texte français ici, comparez « Caractères » et « Octets UTF-8 » : l'écart correspond exactement au nombre d'accents.
• Le œ et le Œ rangés à part: Les ligatures œ (U+0153) et Œ (U+0152) ne sont pas dans le bloc Latin-1 ISO-8859-1 ; elles ont été ajoutées dans Windows-1252 puis reprises par Unicode dans le Latin-A étendu. En UTF-8 elles pèsent chacune 2 octets et expliquent pourquoi de vieux logiciels mal configurés transformaient « cœur » en « cur » ou « c?ur ». Un texte avec « bœuf » et « sœur » fait monter le seau « 2 octets » de cet outil.
• Tweets français vs japonais: Twitter / X a maintenu la limite à 280 caractères pour le français et 140 pour le japonais. Mais en UTF-8 transport, un tweet français de 280 caractères pèse en moyenne 320 octets, alors qu'un tweet japonais de 140 caractères en pèse 420. La densité d'information par octet est plus élevée en japonais (CJK 3 octets), ce qui justifie économiquement la différence de quota.