Longueur d'une chaîne : caractères, octets et graphèmes

Il existe trois réponses courantes à « quelle est la longueur de cette chaîne », et elles mesurent des choses différentes. Les octets mesurent le stockage : combien d'unités de 8 bits le texte occupe dans un encodage donné. Les points de code mesurent les valeurs Unicode : combien d'entrées numérotées le texte utilise. Les graphèmes mesurent la perception : combien de caractères un lecteur humain voit.

Prenez le mot café. Un lecteur voit 4 graphèmes. Sous sa forme composée il fait 4 points de code, mais en UTF-8 il occupe 5 octets, car le é exige 2 octets. Prenez un drapeau en emoji : 1 graphème pour l'utilisateur, 2 points de code en coulisses, 8 octets en UTF-8, et 4 unités de code UTF-16. Même chaîne, quatre nombres.

Deux faits expliquent presque tous les bugs liés à la longueur. D'abord, les compteurs naïfs choisissent une unité et prétendent qu'elle vaut pour les trois — le .length de JavaScript compte les unités UTF-16, le strlen du C compte les octets, et aucun n'est « la » longueur. Ensuite, les limites choisissent leur propre unité — une colonne de base de données compte les caractères, un payload d'API compte les octets, un SMS compte les symboles encodés — et le bug est toujours un décalage entre le compteur et la limite.

Le reste de cet article couvre les trois unités en détail, pourquoi les emoji et les accents cassent les compteurs naïfs, les maths UTF-8 vs UTF-16, les limites pratiques qui rejettent réellement votre texte, quand valider par caractères et quand par octets, et ce qui change avec l'arabe et le texte bidirectionnel. Si vous avez juste besoin des chiffres, l' outil de longueur de chaîne affiche caractères, mots et octets côte à côte. Il fait partie de l'ensemble plus large des string tools aux côtés du compteur de mots.

Caractères, octets et graphèmes — avec exemples

Appliquées aux mêmes chaînes, voici ce que chaque unité rapporte et quel outil ou limite l'utilise :

Le motif : le texte ASCII fait s'accorder tous les compteurs, ce qui explique pourquoi les différences se cachent jusqu'à l'arrivée du texte réel — accents, emoji, écritures non latines. Testez votre compteur avec café 😀 et vous saurez aussitôt quelle unité il rapporte.

Pourquoi les emoji et les accents cassent les compteurs naïfs

Deux mécanismes causent presque toutes les surprises. Le premier est celui des caractères multi-octets : en UTF-8, les lettres ASCII prennent 1 octet, les lettres latines accentuées 2, la plupart des écritures non latines 2 à 3, et les emoji 4. Tout compteur qui rapporte des octets grandit donc plus vite que le texte visible dès que vous quittez l'anglais simple.

Le second est celui des séquences combinantes : des caractères construits à partir de plusieurs points de code qui s'affichent comme un seul glyphe. Un é peut être un point de code précomposé ou la lettre e plus un accent combinant — identiques à l'écran, comptes différents. Les emoji sont pires : les drapeaux sont des paires d'indicateurs régionaux, et les familles sont des chaînes entières jointes par des jointures sans chasse. Un seul « caractère » visible peut faire huit points de code.

• Le .length de JavaScript compte les unités de code UTF-16. Tout ce qui est hors du plan multilingue de base — presque tous les emoji — compte pour 2. Utilisez Array.from(str).length pour les points de code ou Intl.Segmenter pour les graphèmes.
• Le len() de Python compte les points de code. Mieux, mais toujours pas les graphèmes : un drapeau rapporte 2, une famille avec jointures 7+.
• La normalisation change le compte. Les formes NFC (composée) et NFD (décomposée) du même mot ont des nombres de points de code différents. Deux bases qui stockent le même nom dans des formes différentes divergent sur sa longueur.

La solution n'est pas un meilleur nombre unique — c'est le bon nombre pour le bon usage, ce qui explique pourquoi l' outil de longueur de chaîne affiche ensemble caractères, mots et octets UTF-8 au lieu de prétendre que l'un d'eux est « la » longueur.

Les maths des octets UTF-8 vs UTF-16

Les encodages de stockage transforment les mêmes points de code en nombres d'octets différents. UTF-8 utilise 1 octet pour l'ASCII, 2 pour le latin accentué, le grec, le cyrillique, l'hébreu et l'arabe, 3 pour la plupart des écritures asiatiques, et 4 pour les emoji. UTF-16 utilise 2 octets pour tout le plan multilingue de base et 4 octets (une paire de substitution) pour tout ce qui est en dehors.

Conséquence pratique : une description produit en français fait à peu près la même taille dans les deux encodages, un catalogue arabe aussi, mais une bio sociale pleine d'emoji est plus grande en UTF-8 (4 octets par emoji) que ce que le .length de JavaScript suggère (2 unités par emoji).

Pour les développeurs, les conversions sont des one-liners : new TextEncoder().encode(str).length donne les octets UTF-8 dans le navigateur, len(s.encode("utf-8")) en Python, et Buffer.byteLength(str, "utf8") en Node.js. Quand une API documente un plafond en octets, c'est ce nombre qu'il faut vérifier — pas celui du compteur de caractères du champ.

Les limites qui rejettent réellement votre texte

La longueur ne compte que parce que quelque chose l'impose. Les quatre limites qui mordent le plus souvent :

• Colonnes de base de données. Une limite VARCHAR(255) est généralement en caractères, mais les types limités en octets et les vieilles colonnes MySQL utf8 (3 octets) rejettent entièrement les emoji à 4 octets. L'erreur apparaît à l'envoi, longtemps après que l'utilisateur a passé la validation frontend.
• Segmentation SMS. 160 caractères GSM-7 par segment, ou 70 en UCS-2 dès qu'un caractère hors alphabet apparaît — puis 153/67 par segment concaténé après le premier. Un seul emoji peut transformer un message d'1 segment en 3.
• Plafonds de champs d'API. Beaucoup d'API plafonnent les champs en octets (limites de payload) tout en les documentant en caractères. Un champ documenté comme « 32 caractères » peut rejeter 32 emoji parce qu'ils dépassent le budget d'octets sous-jacent.
• Validation de formulaires. Le maxlength du frontend compte les unités UTF-16 dans la plupart des navigateurs — il est donc d'accord avec le .length de JavaScript mais pas avec le backend, la base de données, ni les yeux de l'utilisateur.

La règle : découvrez quelle unité la couche qui impose la limite compte, et validez dans cette unité. Quand la doc est silencieuse, testez avec des emoji — ils séparent les compteurs de caractères des compteurs d'octets plus vite que n'importe quelle documentation.

Quand valider par caractères, quand par octets

Validez par graphèmes ou points de code quand la limite concerne le contenu humain : noms d'affichage, bios, titres, commentaires, méta-descriptions. L'utilisateur pense en caractères visibles, le compteur devrait aussi.

Validez par octets quand la limite concerne le transport ou le stockage : plafonds de payload de requêtes, colonnes de base de données limitées en octets, limites de taille de webhooks, longueur d'URL encodée. Ici la longueur visible n'a aucune importance — ce qui compte, c'est ce qui traverse le fil.

Et validez toujours des deux côtés dans la même unité. Un frontend qui compte les graphèmes pendant que le backend compte les octets est la forme la plus courante de ce bug, et il n'apparaît qu'avec une entrée non ASCII — exactement celle qui manque probablement à votre suite de tests.

Texte arabe et caractères bidirectionnels

L'arabe ajoute deux subtilités. D'abord, les diacritiques (harakat) : le même mot visible peut être stocké avec ou sans marques de voyelles, et sous forme précomposée ou décomposée, donc deux chaînes « identiques » rapportent des longueurs différentes. Normaliser en NFC avant de compter supprime la plupart des désaccords.

Ensuite, la directionalité : un texte mixte arabe et latin contient des caractères de contrôle bidirectionnels invisibles qui affectent l'ordre d'affichage. Ils sont invisibles à l'écran mais comptent dans toutes les unités — octets, points de code, longueur UTF-16, toutes. Un titre produit copié qui « semble » faire 30 caractères peut en faire 34 à cause de deux marques cachées.

L'écriture arabe elle-même n'a pas de majuscules/minuscules, donc les convertisseurs de casse y sont inopérants — mais les compteurs de longueur la traitent comme toute autre écriture non ASCII : 2 octets par lettre en UTF-8, 1 unité UTF-16 par lettre. Un texte arabe collé qui échoue à une limite échoue généralement sur les octets, pas sur la longueur visible.

Comptez sans devinettes

Quelle que soit la limite à vérifier, le comptage lui-même devrait être à un seul collage :

• Un compteur de longueur de chaîne gratuit affichant caractères, mots et octets UTF-8 côte à côte.
• Fonctionne entièrement dans votre navigateur — rien de ce que vous collez n'est téléversé.
• Se combine avec le compteur de mots quand vous avez aussi besoin des mots et du temps de lecture.
• Fait partie de l'ensemble plus large des string tools : compteur de mots, convertisseur de casse, encodeur d'URL et encodeur Base64.

Questions fréquentes