Compteur d'octets par encodage

Mesurez le nombre d'octets que votre texte occupe en UTF-8, Shift_JIS, EUC-JP, UTF-16 et JIS (ISO-2022-JP). Utile pour vérifier les limites de colonnes de base de données et les plafonds de formulaires anciens.

Dernière mise à jour : 2026-09-20

Le nombre de caractères et le nombre d'octets sont deux choses distinctes

Que dix caractères occupent trente octets est chose courante dès qu'un texte non latin entre en jeu. **Le nombre d'octets d'une même chaîne change avec l'encodage :** en UTF-8 un caractère japonais occupe trois octets et un émoji quatre, tandis qu'en Shift_JIS un caractère japonais tient en deux. Cet outil montre d'un seul coup à combien d'octets revient votre saisie sous cinq procédés à la fois, à savoir UTF-8, Shift_JIS, EUC-JP, UTF-16 et ISO-2022-JP.

**Le nombre d'unités de code UTF-16 affiché à côté est précisément la valeur que renvoie `.length` en JavaScript.** Voilà l'écueil le plus souvent manqué, car les émojis et certains caractères se représentent par une paire de substitution formée de deux unités, si bien que **ce qu'une personne compte pour un caractère, `.length` le compte pour deux.** C'est pourquoi une limite de longueur posée avec `.length` écarte plus tôt que prévu une saisie contenant des émojis. Du côté de la base de données, il en va de même : qu'un `VARCHAR(255)` compte des octets ou des caractères dépend du produit et de son réglage, de sorte qu'avoir les deux nombres sous les yeux vous garde d'un jugement erroné.

Comment s'en servir

Saisissez votre texte Le décompte se met à jour dès le collage. Les retours à la ligne sont parfaitement admis.
Comparez le nombre de caractères et celui d'octets **Un seul caractère peut néanmoins faire trois octets en UTF-8.**
Lisez la ligne de l'encodage qui vous concerne Regardez le procédé qu'emploient réellement votre stockage ou votre destination.
Vérifiez le nombre d'unités UTF-16 **Si votre limite est appliquée par `.length` en JavaScript, c'est ce nombre qui décide du résultat.**

Astuces pour en tirer le meilleur parti

En UTF-8, les caractères alphanumériques demi-chasse occupent 1 octet chacun, tandis que les caractères japonais (hiragana, katakana, kanji) occupent le plus souvent 3 octets chacun. Un même nombre de caractères peut donc correspondre à des tailles en octets très différentes entre un texte anglais et un texte japonais.
Les systèmes anciens qui appliquent des limites basées sur les octets à des colonnes comme VARCHAR(255) atteignent leur plafond bien plus vite avec du texte japonais qu'avec un texte anglais de même longueur en caractères.
La plupart des émojis sont représentés par une paire de substitution de deux unités de code, occupant 4 octets aussi bien en UTF-8 qu'en UTF-16, ce qui explique pourquoi les compteurs de caractères des réseaux sociaux atteignent parfois leur limite plus tôt que prévu.
Si vous connaissez déjà un nombre d'octets et souhaitez le convertir en Ko, Mo ou autres unités, utilisez notre outil complémentaire « Convertisseur d'unités d'octets » : il effectue le calcul inverse, du texte vers le nombre d'octets.

Dans quels cas s'en servir

Pour éviter un débordement de colonne

**Là où le stockage se limite en octets, le texte japonais n'entre qu'au tiers de ce que l'on croirait.** Vous pouvez le vérifier avant d'insérer.

Pour concevoir la limite de saisie d'un formulaire

Il fournit la matière pour décider si le plafond se pose en caractères ou en octets.

Pour dialoguer avec un système ancien

Dans les fichiers à largeur fixe et les échanges en Shift_JIS, le nombre d'octets est la position de la colonne.

Pour éprouver le traitement des émojis

**Vous pouvez confirmer qu'une chaîne comportant des paires de substitution reçoit bien la longueur que vous visez.**

Vocabulaire des encodages de caractères

UTF-8: Un procédé représentant les caractères du monde sur un à quatre octets de longueur variable. **En règle générale, l'ASCII en prend un, le japonais trois et un émoji quatre.**
Shift_JIS: Un procédé pour le japonais où **un caractère japonais tient en deux octets.** Il demeure en usage dans les anciens systèmes et les fichiers à largeur fixe.
EUC-JP: Un procédé japonais longtemps employé sur les systèmes UNIX. Un caractère japonais y occupe d'ordinaire deux octets.
UTF-16: Un procédé représentant les caractères par unités de seize bits. **Les chaînes de JavaScript se comptent dans ces unités.**
Paire de substitution: Le dispositif par lequel **un caractère trop grand pour une unité UTF-16 s'exprime en une paire de deux.** Les émojis et certains caractères relèvent de ce cas.
ISO-2022-JP: Un procédé commutant les jeux de caractères par séquences d'échappement, longtemps employé dans le courrier japonais. On l'appelle aussi simplement JIS.

Questions fréquentes

La longueur en caractères compte le nombre de caractères visibles dans une chaîne, tandis que la longueur en octets indique le nombre d'octets nécessaires pour stocker ou transmettre cette chaîne en tant que donnée informatique. Pour un texte ASCII pur, les deux valeurs coïncident, mais pour un texte contenant des caractères multi-octets comme le japonais, la longueur en octets peut être plusieurs fois supérieure à la longueur en caractères.

UTF-8 utilise un encodage à longueur variable de 1 à 4 octets par caractère, et la plupart des caractères japonais (hiragana, katakana, kanji courants) occupent 3 octets. Shift_JIS, en revanche, encode la plupart des caractères japonais sur 2 octets, si bien qu'un même texte japonais occupe généralement plus de place en UTF-8 qu'en Shift_JIS.

Cela dépend du moteur de base de données et des paramètres du jeu de caractères de la colonne. Le VARCHAR(n) de MySQL est généralement limité à « n caractères », mais il existe aussi des limites internes distinctes basées sur les octets (comme la longueur maximale de clé indexable), ce qui explique qu'un texte contenant des émojis puisse parfois provoquer des erreurs. Consultez la documentation spécifique de votre SGBD pour connaître le comportement exact.

Les caractères alphanumériques et symboles demi-chasse n'occupent qu'1 octet en UTF-8, Shift_JIS et EUC-JP, tandis que les caractères pleine chasse (hiragana, katakana, kanji, symboles pleine chasse) occupent de 2 à 3 octets selon l'encodage. Une chaîne de 10 caractères peut ne peser que 10 octets si elle est entièrement en demi-chasse, ou 20 à 30 octets si elle est entièrement en pleine chasse.

Cet outil prend une chaîne de texte en entrée et calcule sa longueur en octets pour chaque encodage. L'outil « Convertisseur d'unités d'octets », lui, prend un nombre d'octets déjà connu (par exemple 1 500 000 octets) et le convertit en unités comme Ko, Mo ou Go. Utilisez cet outil pour aller du « texte au nombre d'octets », et l'autre outil pour aller du « nombre d'octets à d'autres unités ».

Anecdote — Le lien méconnu entre les limites de caractères des réseaux sociaux et le nombre d'octets

Les anciennes versions du jeu de caractères « utf8 » de MySQL avaient une limitation surprenante : elles ne pouvaient en réalité pas stocker les émojis Unicode (caractères supplémentaires à partir de U+10000). UTF-8 est lui-même un encodage à longueur variable prenant en charge jusqu'à 4 octets par caractère, mais le « utf8 » de MySQL était historiquement plafonné à 3 octets par caractère, provoquant des erreurs d'insertion dès qu'un texte contenant des émojis était enregistré. La migration vers « utf8mb4 », qui prend correctement en charge la plage complète de 4 octets, est aujourd'hui la solution recommandée : un exemple bien connu montrant pourquoi comprendre la relation entre encodage des caractères et nombre d'octets compte réellement en pratique.

À l'époque où Twitter (aujourd'hui X) imposait sa fameuse limite de 140 caractères, un débat de longue date opposait les langues sur la question de l'équité : les utilisateurs japonais pouvaient exprimer une idée assez complète en 140 caractères, tandis que les utilisateurs anglophones parvenaient à peine à écrire 20 à 30 mots dans la même limite. Cela s'explique par le fait qu'un seul caractère kanji japonais peut transmettre bien plus d'information qu'une seule lettre anglaise. Twitter a fini par introduire un système de comptage pondéré, où des langues comme le japonais comptaient « 1 caractère = 1 point », tandis que certains caractères d'autres langues comptaient « 2 octets = 1 point », dans le but d'équilibrer les choses entre les langues.

Les SMS sur téléphone mobile présentent une particularité similaire. Un SMS encodé au standard GSM autorise jusqu'à 160 caractères par message, mais dès qu'il contient ne serait-ce qu'un seul caractère hors du jeu de caractères GSM 7 bits — comme un émoji ou un caractère japonais —, l'encodage bascule vers UCS-2 (à peu près équivalent à UTF-16), et la limite chute brutalement à seulement 70 caractères. Le fait qu'un seul caractère japonais puisse réduire de plus de moitié la longueur disponible d'un message illustre parfaitement, en situation réelle, la relation entre encodage des caractères et nombre d'octets que cet outil est conçu pour mesurer.

Voir toutes les anecdotes