Compter les caractères

Quatre chiffres, parce que « caractère » a quatre sens

Prenez l'emoji d'une famille, ou un pouce levé avec une couleur de peau. Une personne voit un caractère. Il est construit à partir de plusieurs points de code reliés par des liaisons invisibles : une expression régulière en voit donc sept. JavaScript stocke le texte en unités de 16 bits, et tout ce qui sort de la plage de base en occupe deux : il en annonce donc onze. Encodé en UTF-8 pour une colonne de base de données, il occupe vingt-cinq octets. Aucun de ces chiffres n'est faux et aucun n'est la réponse — le bon dépend entièrement de ce qui impose la limite.

La question pratique est donc : qui a fixé la limite ? Une colonne de base de données déclarée en VARCHAR compte les octets dans la plupart des moteurs, c'est pourquoi un champ qui accepte 255 caractères anglais en refuse beaucoup moins en japonais. Un SMS fait 160 caractères dans son propre alphabet à sept bits, et tombe à 70 par message dès qu'un seul caractère en sort — un guillemet courbe ou un emoji peut transformer un message en trois. Un validateur de formulaire en JavaScript compte presque toujours les unités UTF-16, c'est pourquoi un champ qui annonce 280 caractères peut refuser une chaîne apparemment plus courte, remplie d'emoji.

Le compte de ce que voit un lecteur est le plus difficile, et il est obtenu grâce à la segmentation de texte du navigateur lui-même — le même mécanisme qui décide où va votre curseur quand vous appuyez sur la flèche gauche. C'est la bonne définition d'« un caractère » pour tout ce qu'une personne perçoit, et elle gère les cas qui piègent les comptages plus simples : une lettre accentuée écrite comme une lettre de base suivie d'un signe combinant compte pour un, et les groupes de caractères en hindi et en thaï sont comptés comme le ferait un lecteur de ces écritures.

Pour de la prose anglaise ordinaire, les quatre chiffres sont identiques, c'est pourquoi le problème reste invisible jusqu'au jour où il ne l'est plus. Ils divergent sur les emoji, les caractères accentués et combinants, les écritures non latines et les symboles mathématiques — et ce sont exactement les saisies qui font qu'un champ est tronqué en silence dans une base de données trois mois après sa création.

Si vous cherchez autre chose

Dans le code, utilisez une fonction qui compte ce dont vous avez besoin plutôt que la longueur par défaut. Intl.Segmenter en JavaScript compte ce que voit un lecteur ; les chaînes Python 3 comptent les points de code et len(s.encode("utf-8")) compte les octets ; PHP propose mb_strlen face à strlen précisément pour cette distinction. Dans la plupart des langages, la valeur par défaut est celle qui arrangeait le langage, et c'est rarement celle que votre limite désigne.

Quand c'est un champ de base de données qui impose la contrainte, la solution durable se trouve en amont. Déclarer une colonne en utf8mb4 dans MySQL, ou en text dans PostgreSQL, supprime toute une catégorie de bugs de troncature — l'ancien utf8 de MySQL est notoirement limité à trois octets par caractère et ne peut pas stocker le moindre emoji. Compter soigneusement dans le formulaire n'est qu'un palliatif pour une colonne qui aurait dû être déclarée autrement.