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.
Astuces
- 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.
Questions fréquentes
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.