Comptage d'octets en ligne, gratuit

Comment ça marche

1. Tapez ou collez du texte : Tapez ou collez n'importe quel texte dans le champ de saisie.
2. Consultez le nombre d'octets : L'outil affiche instantanément le nombre d'octets en UTF-8, UTF-16, ASCII et dans d'autres encodages, côte à côte.
3. Vérifiez les limites : Comparez le nombre d'octets aux limites courantes (SMS : 160 caractères, en-têtes HTTP : 8 Ko, champs de base de données, etc.) pour vérifier si votre contenu rentre.

Pourquoi utiliser un compteur d'octets ?

Le nombre de caractères et le nombre d'octets ne sont pas la même chose. Un seul émoji peut peser 4 octets en UTF-8. Les caractères chinois et arabes occupent 2 à 3 octets chacun. De nombreux systèmes imposent des limites en octets, et non en caractères, c'est notamment le cas des champs VARCHAR MySQL, des valeurs Redis, des en-têtes HTTP, des messages SMS, et des noms d'objets de stockage cloud. Le compteur d'octets révèle la taille réelle en octets de votre texte dans chaque encodage, pour que vous restiez dans les contraintes de votre système.

Fonctionnalités

• Plusieurs tailles d'encodage : Affiche le nombre d'octets pour UTF-8, UTF-16 LE/BE, UTF-32 et Latin-1.
• Détail des caractères : Compte séparément le total de caractères, les points de code Unicode et les caractères multi-octets.
• Préréglages de limites courantes : Comparez avec les limites de SMS (160), tweet (280), méta-description (160), VARCHAR MySQL, et plus.
• Mises à jour en direct : Le nombre d'octets se met à jour en temps réel à mesure que vous tapez.
• Comparaison d'encodages : Identifiez l'encodage le plus compact pour votre texte.

Questions fréquentes

Pourquoi mon nombre d'octets est-il plus grand que mon nombre de caractères ?

De nombreux caractères occupent plus d'un octet en UTF-8. Les caractères ASCII (A-Z, 0-9, ponctuation) font 1 octet chacun. Les caractères latins étendus (lettres accentuées) font 2 octets. Les caractères chinois, japonais, coréens et arabes font généralement 3 octets. Les émojis font habituellement 4 octets.

Quel encodage utilisent la plupart des systèmes web ?

UTF-8 est l'encodage dominant pour le contenu web, les API, le JSON et les bases de données. MySQL et PostgreSQL utilisent UTF-8 par défaut. Lorsque vous vérifiez des limites d'octets, utilisez la colonne UTF-8, sauf indication contraire de votre système.

Pourquoi les messages SMS ont-ils une limite de 160 caractères ?

Les SMS traditionnels utilisent l'encodage GSM 7 bits, qui autorise 160 caractères par segment. Dès que vous incluez un caractère non GSM (comme un guillemet typographique, un émoji ou une lettre non latine), le message passe à l'encodage UCS-2, ce qui réduit la limite à 70 caractères par segment.

Qu'est-ce qu'un octet, vraiment ?

Un octet, c'est 8 bits, soit 256 valeurs distinctes. Dans un texte, ces 256 valeurs sont associées à des caractères par le biais d'un encodage, une règle qui dit « cette séquence d'octets équivaut à ce caractère ». La même suite d'octets peut signifier des textes complètement différents selon l'encodage : l'octet 0xE9 vaut « é » en Latin-1, mais c'est le début d'une séquence de 3 octets en UTF-8, ou une partie d'une unité de code UTF-16. L'encodage, c'est toute l'histoire.

Quand vous sauvegardez du texte sur disque, l'envoyez sur le réseau ou le stockez en base de données, ce qui est réellement conservé, ce sont des octets, pas des caractères. Le nombre de caractères qu'affiche votre éditeur est calculé à l'affichage, après décodage des octets. Si vous vous trompez d'encodage d'un côté ou de l'autre, vous obtenez du mojibake : un texte décodé avec le mauvais encodage devient du charabia (le classique é au lieu de é quand des octets Windows-1252 sont lus comme de l'UTF-8).

Le comptage d'octets, c'est ce que mesurent toutes les limites concrètes : colonnes de bases de données, tampons d'en-têtes HTTP, charges utiles SMS, clés d'objets de stockage cloud, indépendamment de ce que le texte « semble » être. Ce compteur indique la taille en octets dans les quatre encodages qui vous intéresseront le plus probablement : UTF-8 (le standard moderne), UTF-16 (le format interne de Windows, Java, JavaScript), ASCII (uniquement valide pour le texte latin anglais) et Latin-1 (un repli d'un octet hérité). Le nombre de caractères à côté est donné à titre de référence.

UTF-8 : l'histoire

UTF-8 a été esquissé par Ken Thompson et Rob Pike aux Bell Labs dans la nuit du 2 septembre 1992, prétendument sur un set de table dans un diner du New Jersey, après que l'équipe Plan 9 eut besoin d'un encodage à longueur variable compatible ASCII pour Unicode. Le design porte trois propriétés que presque rien d'autre n'a en même temps : le texte ASCII est aussi de l'UTF-8 valide (1 octet par caractère, octets identiques), l'encodage est auto-synchronisant (les bits de poids fort de n'importe quel octet vous disent s'il démarre un nouveau caractère ou continue un caractère existant), et il n'y a pas d'ambiguïté d'ordre des octets. Ces trois propriétés expliquent ensemble pourquoi UTF-8 a évincé tous les encodages concurrents sur le web.

Il a d'abord été standardisé en RFC 2044 en octobre 1996, révisé en RFC 2279 en janvier 1998, et remplacé par l'actuel RFC 3629 (novembre 2003), qui a plafonné UTF-8 à 4 octets par caractère pour correspondre au plafond final des points de code Unicode à U+10FFFF. W3Techs suit l'usage des encodages sur le web public en continu depuis 2010 ; UTF-8 est passé de 56 % des sites web en 2011 à environ 98 % en 2026. La spécification HTML5 impose UTF-8 pour le nouveau contenu ; HTTP/2 et HTTP/3 envoient leurs en-têtes en UTF-8 via HPACK / QPACK ; RFC 8259 impose UTF-8 pour l'échange JSON entre systèmes. S'il faut choisir un seul encodage pour tout, la réponse depuis 15 ans est UTF-8 et la réponse pour les 15 prochaines années sera la même.

UTF-8 est à longueur variable, de 1 à 4 octets par caractère :

Conséquence pratique : un texte anglais en UTF-8 fait en moyenne ~1 octet par caractère ; le chinois ~3 octets ; un message riche en emoji peut atteindre 4 octets par caractère visible, et les emoji combinés (séquences ZWJ familles) atteignent facilement 20 à 30 octets pour ce qui ressemble à un seul caractère.

UTF-16 et le piège des paires de substitution

UTF-16 a été l'encodage de choix pour Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET et Cocoa NSString de Mac OS X. Il utilise 2 octets pour chaque caractère du plan multilingue de base (U+0000 – U+FFFF), et des paires de substitution pour tout ce qui est au-delà : une substitution haute (D800–DBFF) plus une substitution basse (DC00–DFFF), soit 4 octets au total. UTF-16 a besoin d'une marque d'ordre des octets (BOM) sur disque pour distinguer le gros-boutiste (UTF-16BE, FE FF) du petit-boutiste (UTF-16LE, FF FE) ; Windows utilise le petit-boutiste par défaut.

Le piège : en JavaScript, "😀".length === 2. MDN le dit explicitement : la propriété length « contient la longueur de la chaîne en unités de code UTF-16 ». C'est pourquoi un seul emoji comme 😄 indique une longueur de 2 (il vit dans le plan supplémentaire et nécessite une paire de substitution), et la séquence ZWJ famille 👨‍👩‍👧‍👦 indique une longueur de 11 (quatre emoji de 2 unités de code plus trois jointures de largeur nulle). Le même emoji famille à un caractère vaut 11 en JavaScript, 5 en Python 3 et 1 en Swift, selon le modèle de chaîne de chaque langage. Pour des comptages de caractères visibles corrects en JavaScript, utilisez Intl.Segmenter avec la granularité grapheme (tous les navigateurs evergreen depuis 2021).

ASCII, Latin-1 et le bazar pré-Unicode

ASCII (American Standard Code for Information Interchange) a été standardisé en ASA X3.4-1963, révisé en X3.4-1968, puis à nouveau en ANSI X3.4-1986. Un code 7 bits, 128 caractères : 95 imprimables plus 33 de contrôle. Les 33 caractères de contrôle incluent des héritages du télétype comme BEL, BS, CR, LF, DEL, et quelques-uns qui survivent dans les protocoles modernes (NUL, TAB, LF, CR, ESC). ASCII fonctionne toujours comme un sous-ensemble strict d'UTF-8, ce qui explique pourquoi « du texte ASCII pur » est aussi du UTF-8 valide et pourquoi la migration vers UTF-8 a été indolore pour les systèmes purement anglophones.

Latin-1 / ISO-8859-1 (1987) était une extension à 256 caractères sur un seul octet qui ajoutait les lettres accentuées d'Europe de l'Ouest, les symboles monétaires et la ponctuation courante. C'était l'encodage de fait du contenu web occidental de 1995 jusqu'à ce qu'UTF-8 le supplante vers 2008. Windows-1252 est le sur-ensemble Microsoft de Latin-1, ajoutant les « guillemets courbes », les tirets cadratins et le symbole euro dans la plage de contrôle C1 (0x80-0x9F) ; quand des fichiers CSV sont échangés par email entre Mac et Windows, c'est l'origine du classique mojibake é quand un côté lit des octets Windows-1252 comme de l'UTF-8.

Le piège « utf8 » de MySQL

MySQL traîne une verrue de jeu de caractères notoire depuis la version 4.1 : l'alias utf8 n'est pas réellement UTF-8. C'est un sous-ensemble plafonné à 3 octets qui ne peut pas représenter les caractères au-dessus de U+FFFF, ce qui signifie qu'il ne peut pas stocker d'emoji ni de caractères du plan supplémentaire. Insérer « 🎉 » dans une colonne utf8 produit « ? » ou une erreur selon sql_mode. La solution est utf8mb4, ajouté dans MySQL 5.5.3 (mars 2010) ; MySQL 8.0 (avril 2018) en a fait le nouveau défaut. Mais les schémas créés avant 8.0 utilisent souvent encore la version 3 octets par défaut. Si vous voyez des emoji disparaître silencieusement depuis l'entrée utilisateur, c'est presque toujours la cause. PostgreSQL n'a pas de piège équivalent, il accepte le vrai UTF-8 nativement.

SMS, GSM-7 et la charge utile de 160 octets

La limite des 160 caractères SMS remonte à un calcul de Friedhelm Hillebrand en 1985, ingénieur au Groupe de travail GSM qui se serait assis à sa machine à écrire, aurait tapé des phrases aléatoires, et compté que « la plupart des messages peuvent s'exprimer en 160 caractères ou moins ». Les 160 ont ensuite été dérivés à rebours pour tenir dans une charge utile de 140 octets en utilisant un alphabet 7 bits (140 × 8 ÷ 7 = 160). Les détails de l'encodage sont formalisés dans 3GPP TS 23.038 (à l'origine GSM 03.38), et ils régissent encore la facturation SMS aujourd'hui.

En octets : un SMS unique fait 140 octets sur la liaison. Avec GSM-7, cela donne 160 caractères ; avec UCS-2 (un encodage à largeur fixe de 2 octets utilisé pour tout ce qui sort de l'alphabet GSM-7) cela donne 70. Les messages multi-segments perdent 7 caractères GSM-7 ou 3 caractères UCS-2 par segment au profit d'un en-tête de données utilisateur (User Data Header) utilisé pour le réassemblage, donc les longs messages plafonnent à 153 caractères GSM-7 par segment ou 67 caractères UCS-2 par segment. Un seul guillemet courbe, tiret cadratin ou emoji rétrograde tout le message en UCS-2 et divise par deux la limite par segment. Le « Smart Encoding » de Twilio remplace automatiquement les guillemets courbes par des guillemets droits pour maintenir les campagnes marketing dans l'encodage le moins cher.

Où les limites en octets mordent vraiment

Trois catégories où les limites en octets (et pas en caractères) vous attrapent :

En-têtes de requête HTTP. Pas de maximum dans la spec formelle, chaque serveur en impose un. LimitRequestFieldSize d'Apache vaut 8 Ko par en-tête par défaut ; large_client_header_buffers de Nginx vaut 4 × 8 Ko par défaut ; IIS vaut 16 Ko ; l'AWS Application Load Balancer accepte 16 Ko par en-tête et 60 Ko au total ; Cloudflare autorise 32 Ko. Les JWT avec des claims gonflés dépassent régulièrement le défaut Apache de 8 Ko, ce qui est le mode d'échec en production le plus courant pour l'authentification par jeton.

Clés d'objets de stockage cloud. S3 et GCS plafonnent tous deux les clés d'objet à 1024 octets UTF-8. Azure Blob Storage plafonne les noms de blob à 1024 caractères (UTF-16 interne). Pour S3, un nom de fichier riche en CJK (3 octets par caractère) plafonne à ~341 caractères ; un nom riche en emoji (4 octets par caractère) à ~256, bien avant ce que le développeur attend.

Limites de ligne et d'index de bases de données. MySQL InnoDB a une taille de ligne de 65 535 octets et une limite de préfixe de clé d'index de 3072 octets sur le format de ligne DYNAMIC (767 sur l'ancien COMPACT). Une colonne VARCHAR(255) utf8mb4 a besoin de 1020 octets (255 × 4) d'espace d'index, OK sur DYNAMIC, cassé sur COMPACT. Les documents BSON MongoDB plafonnent à 16 Mo. Les éléments DynamoDB plafonnent à 400 Ko (en incluant les noms d'attributs). Les valeurs Redis plafonnent à 512 Mo.

Cas d'usage courants

• Validation de champs de base de données, confirmer qu'un nom soumis par l'utilisateur tient avant INSERT, surtout quand la colonne est VARCHAR(255) utf8mb4 et que l'entrée est en CJK.
• Texte de marketing SMS, confirmer que le message reste en GSM-7 (~1 octet par caractère visible dans la charge utile) au lieu de basculer accidentellement en UCS-2 à cause d'un guillemet courbe.
• Budget de charge utile d'API, confirmer qu'un corps JSON tient sous une limite connue (DynamoDB 400 Ko, charge utile AWS Lambda 6 Mo synchrone, 256 Ko asynchrone).
• Clés d'objets cloud, confirmer qu'une clé S3 / GCS reste sous 1024 octets après transcodage non-ASCII.
• Divulgation emoji, voir exactement combien de « poids » un emoji ou une séquence ZWJ famille ajoute à une chaîne.
• Choix d'encodage, comparer les tailles en octets UTF-8 vs UTF-16 ; pour un contenu majoritairement CJK, UTF-16 peut être plus compact (2 octets par caractère CJK vs 3 en UTF-8).

Erreurs courantes

1. Faire confiance à .length en JavaScript pour la taille en octets. .length renvoie des unités de code UTF-16, pas des octets et pas des caractères. Pour des octets UTF-8, utilisez new TextEncoder().encode(text).length ; pour des caractères visibles, utilisez Intl.Segmenter.
2. Supposer que MySQL utf8 est vraiment UTF-8. C'est un sous-ensemble 3 octets qui élimine silencieusement les emoji. Utilisez toujours utf8mb4 (et utf8mb4_unicode_ci pour la collation) sur toute colonne qui touche au texte soumis par l'utilisateur.
3. Supposer qu'un emoji vaut un octet. Un seul emoji fait 4 octets en UTF-8, 4 octets en UTF-16 (paire de substitution). Une séquence ZWJ famille peut dépasser 30 octets pour ce qui ressemble à un seul caractère.
4. Compter un BOM UTF-8 comme du contenu. Le BOM UTF-8 de trois octets EF BB BF au début d'un fichier est une métadonnée, pas du texte. La plupart des outils CLI (awk, head, sed) le traitent comme une partie du premier champ, ce qui est à l'origine de nombreux bugs « pourquoi mon premier nom de colonne a-t-il un caractère bizarre ».
5. Rapporter un compte d'« octets ASCII » pour du texte non-ASCII. ASCII ne peut pas représenter les caractères au-delà de U+007F. Ce compteur avertit quand l'entrée contient du non-ASCII pour que vous sachiez que la colonne ASCII n'a pas de sens.

Autres questions fréquemment posées

Pourquoi un emoji fait-il 4 octets alors que les caractères texte n'en font qu'un ?

UTF-8 utilise 1 octet pour l'ASCII (U+0000 à U+007F), 2 octets pour le latin étendu / grec / cyrillique / arabe / hébreu (U+0080 à U+07FF), 3 octets pour la plupart des scripts CJK et indiens (U+0800 à U+FFFF), et 4 octets pour les emoji et caractères du plan supplémentaire (U+10000 à U+10FFFF). Un emoji typique comme 😀 (U+1F600) est dans le plan supplémentaire et coûte 4 octets. Les emoji combinés (par exemple la famille 👨‍👩‍👧‍👦) sont construits à partir de plusieurs emoji de base collés ensemble par des jointures de largeur nulle ; chaque emoji de base fait 4 octets, chaque jointure fait 3 octets, donc une famille de 4 prend 4×4 + 3×3 = 25 octets pour ce qui ressemble à un caractère.

Que signifie réellement MySQL utf8 ?

Dans MySQL, l'alias de jeu de caractères utf8 est un sous-ensemble plafonné à 3 octets du vrai UTF-8. Il peut encoder tous les caractères du plan multilingue de base d'Unicode mais ne peut pas stocker d'emoji ni de caractère au-dessus de U+FFFF. Le vrai UTF-8 4 octets dans MySQL s'appelle utf8mb4, disponible depuis MySQL 5.5.3 (mars 2010), défaut depuis MySQL 8.0 (avril 2018). Si vous pouvez modifier le schéma, utilisez toujours utf8mb4 avec la collation utf8mb4_0900_ai_ci (ou utf8mb4_unicode_ci sur les serveurs plus anciens).

Ce compteur inclut-il une marque d'ordre des octets UTF-8 ?

Non. La marque d'ordre des octets UTF-8, ce sont les trois octets EF BB BF qu'Excel sur Windows exige au début d'un fichier pour détecter l'UTF-8. Le compteur mesure les octets du texte que vous collez ; si votre texte commence par un BOM, ces trois octets sont comptés comme du contenu. Si vous voulez savoir si les octets de votre fichier atteindront une limite, ne collez que le corps du fichier, pas le BOM.

Pourquoi mon texte chinois affiche-t-il 3 octets par caractère en UTF-8 ?

Presque tous les idéogrammes CJK sont dans la plage Unicode U+4E00 à U+9FFF (le bloc CJK Unified Ideographs), qu'UTF-8 encode sur 3 octets chacun. Une phrase chinoise de 100 caractères fait donc 300 octets UTF-8. En UTF-16, le même texte fait 200 octets (2 octets par caractère), donc UTF-16 est plus compact pour un contenu majoritairement CJK. UTF-8 l'emporte pour un contenu mixte latin-et-CJK parce que les caractères latins coûtent 1 octet chacun au lieu de 2.

Mon texte est-il téléversé quelque part ?

Non. Le compteur d'octets fonctionne entièrement dans votre navigateur. Les comptes d'octets UTF-8 viennent de l'API standard TextEncoder (tous les navigateurs modernes la supportent), les comptes UTF-16 et Latin-1 viennent de simples boucles. Il n'y a pas de requête réseau, pas d'appel serveur, pas de journalisation. Une fois la page chargée, l'outil fonctionne hors ligne. Sûr pour inspecter des jetons d'API, des données internes ou tout ce que vous ne colleriez pas dans un compteur de texte tiers.