CodeKitHubEn quoi consiste cet outil ?
Pour un texte ASCII pur (lettres anglaises, chiffres, ponctuation de base), le nombre de caractères et le nombre d'octets sont identiques — chaque caractère occupe exactement un octet en UTF-8. Dès que le texte inclut des lettres accentuées, des caractères chinois/japonais/coréens, du cyrillique, de l'arabe, des emoji, ou la plupart des autres caractères non-ASCII, ce n'est plus vrai : un seul caractère peut occuper 2, 3 ou 4 octets en UTF-8, et 2 ou 4 octets en UTF-16.
Cela compte chaque fois qu'un système a une limite en octets plutôt qu'en caractères — les SMS, la taille des colonnes de base de données, les limites de charge utile d'API, et certaines plateformes sociales mesurent tous en octets, pas en caractères, donc le même texte peut dépasser silencieusement une limite selon la langue ou les symboles qu'il contient.
Pourquoi l'utiliser ?
- Un champ de bio façon Twitter/X vous limite en octets, pas en caractères, et votre nom contient un emoji — tapez-le ici pour voir le vrai coût en octets avant que le formulaire ne le tronque silencieusement.
- La colonne de votre base de données est définie en VARCHAR(255) en octets en interne, et un titre de produit en japonais ou en arabe qui « paraît court » se fait sans cesse rejeter — collez-le ici pour voir pourquoi il utilise en réalité trois fois plus d'octets qu'un titre en alphabet latin.
- Vous estimez combien de segments SMS un message marketing multilingue va utiliser — les opérateurs facturant et découpant par taille en octets, vérifier le nombre d'octets UTF-8/UTF-16 ici évite de deviner et de se retrouver avec une facture plus salée que prévu.
- Une API renvoie une cryptique erreur « payload trop volumineux » sur un champ JSON avec un validateur strict de longueur en octets, alors que la chaîne semblait correcte dans votre éditeur — ceci montre exactement combien d'octets cette chaîne coûte réellement.
- Vous comparez pourquoi la même phrase coûte plus de stockage dans une langue que dans une autre — tapez chaque version et observez le nombre d'octets UTF-8 grimper pour du texte CJK ou arabe par rapport à la version en ASCII pur.
- Vous devez vérifier si un emoji dans un nom d'utilisateur est compté comme un ou deux caractères par une règle de validation tatillonne — cet outil le compte comme une personne le verrait, donc vous pouvez savoir si l'autre système se trompe.
Mode d'emploi
- Tapez ou collez du texte dans le champ.
- Lisez le nombre de caractères, le nombre d'octets UTF-8, et le nombre d'octets UTF-16 en dessous — ils se mettent à jour pendant que vous tapez.
Exemple
Entrée
Hello, 世界! 🌍Résultat
12 caractères, 19 octets UTF-8, 26 octets UTF-16La partie ASCII (« Hello, » et « ! ») occupe 1 octet par caractère en UTF-8. Chaque caractère chinois occupe 3 octets, et l'emoji occupe 4 octets — c'est pourquoi les nombres d'octets sont nettement plus élevés que le nombre de caractères.
Utilisations courantes
- Vérifier si une description de produit multilingue tiendra dans une colonne de base de données définie par une longueur en octets plutôt qu'en caractères.
- Estimer l'utilisation des segments SMS, car les SMS sont facturés et divisés par taille en octets, et le texte non-latin utilise une limite par segment différente.
- Vérifier qu'une charge utile d'API ou un champ de formulaire reste sous une limite de taille en octets avant de la soumettre.
- Comprendre pourquoi une chaîne qui « semble courte » est rejetée par un système avec une vérification de longueur basée sur les octets.
Taille en octets UTF-8 par type de caractère
Le tableau ci-dessous montre le coût typique en octets UTF-8 par catégorie de caractère — utile pour estimer le poids réel d'un texte multilingue avant de le coller en entier.
| Type de caractère | Exemple | Octets UTF-8 | Octets UTF-16 |
|---|---|---|---|
| Lettre/chiffre ASCII | A, 7 | 1 | 2 |
| Latin accentué (é, ñ, ü) | é | 2 | 2 |
| Cyrillique / grec / hébreu / arabe | д, α, א | 2 | 2 |
| CJK (chinois, japonais, coréen) | 世 | 3 | 2 |
| La plupart des emoji (hors BMP) | 🌍 | 4 | 4 |
Foire aux questions
Pourquoi le nombre de caractères et le nombre d'octets ne correspondent-ils pas ?
Le texte Unicode est stocké sous forme d'octets, et le nombre d'octets dont chaque caractère a besoin dépend de l'encodage et du caractère lui-même. En UTF-8, les caractères ASCII occupent 1 octet, la plupart des lettres latines accentuées et cyrilliques/grecques/hébraïques/arabes occupent 2 octets, la plupart des caractères CJK occupent 3 octets, et les emoji occupent généralement 4 octets. Le nombre de caractères compte simplement les symboles, sans se soucier de la façon dont ils sont stockés.
Quel nombre d'octets dois-je utiliser pour un champ limité en octets ?
Utilisez l'encodage que le système utilise réellement pour stocker ou transmettre le texte — la plupart des API web modernes, bases de données, et fichiers utilisent UTF-8, donc le nombre d'octets UTF-8 est généralement le bon. Certains systèmes plus anciens (comme la gestion interne des chaînes Windows/Java) utilisent UTF-16.
Cela compte-t-il correctement les emoji ?
Oui. De nombreux emoji sont stockés en interne comme une paire d'unités de code « substituts » UTF-16, que les méthodes de comptage naïves comptent comme 2 caractères. Cet outil compte correctement les points de code Unicode, donc un emoji est compté comme 1 caractère, correspondant à ce qu'une personne voit réellement.
Est-ce la même chose que l'outil Compteur de mots ?
Non — le Compteur de mots se concentre sur le nombre de mots et de phrases pour l'écriture. Cet outil concerne spécifiquement la taille en octets par rapport au nombre de caractères, ce qui compte pour les limites techniques plutôt que pour les exigences de nombre de mots.
Mon texte est-il envoyé quelque part ?
Non. Le comptage se fait localement dans votre navigateur en utilisant l'encodeur de texte intégré de JavaScript ; rien n'est envoyé à un serveur.
Pourquoi le même caractère occupe-t-il un nombre d'octets différent en UTF-8 et en UTF-16 ?
Les deux encodages utilisent des règles totalement différentes pour associer les points de code aux octets. UTF-8 utilise 1 à 4 octets selon le caractère, optimisé pour que l'ASCII reste sur 1 octet. UTF-16 utilise 2 octets pour la plupart des caractères et seulement 4 octets pour ceux situés hors du plan multilingue de base (comme la plupart des emoji) — un caractère chinois occupe donc 3 octets en UTF-8 mais seulement 2 en UTF-16, tandis qu'un emoji occupe 4 octets dans les deux cas.
Un emoji avec ton de peau ou de famille (composé de plusieurs caractères joints) est-il compté correctement ?
L'outil compte les points de code Unicode, donc un emoji composé construit à partir de plusieurs points de code joints par un joigneur de largeur nulle (comme un emoji de famille) est compté comme plusieurs caractères, pas un seul — reflétant la façon dont le texte est réellement encodé, même s'il s'affiche comme un seul glyphe.
Quelle est la différence entre le nombre d'octets UTF-8 et le nombre de caractères pour un texte français sans accents ?
Pour un texte utilisant uniquement des lettres ASCII, des chiffres, des espaces et une ponctuation de base, ils sont identiques — chaque caractère occupe exactement 1 octet en UTF-8. L'écart n'apparaît qu'une fois des lettres accentuées (é, à, ç, ù), symboles ou écritures non latines ajoutés.
Puis-je utiliser cet outil pour vérifier exactement les limites de caractères de Twitter/X ou des SMS ?
Cet outil donne le nombre brut de caractères et d'octets, qui est la base sur laquelle ces limites sont construites, mais les plateformes appliquent parfois leurs propres règles de pondération (certaines comptent par exemple certains emoji ou URL comme un nombre fixe de caractères, quelle que soit leur longueur réelle) — vérifiez les règles spécifiques de la plateforme pour les cas limites, et utilisez cet outil pour comprendre le coût en octets sous-jacent.