Minifier du JSON

Une espace entre deux jetons ne signifie rien et une espace à l’intérieur d’une chaîne est une donnée. Un minificateur qui retire chaque espace qu’il trouve transformera un nom, une adresse ou une phrase stockée comme valeur en autre chose, et le résultat restera du JSON valide — donc rien en aval ne proteste, et la corruption est découverte bien plus tard par une personne qui la lit.

Celui-ci analyse le document et l’imprime sans indentation, ce qui rend cette erreur impossible par construction. C’est aussi pourquoi il refuse une entrée qui ne s’analyse pas : il n’existe pas de compréhension partielle sur laquelle se rabattre.

Du JSON formaté est typiquement fait de vingt à quarante pour cent d’espaces, donc le nombre affiché ici a l’air impressionnant. Sur un réseau, il ne l’est le plus souvent pas, parce que les réponses sont compressées et que gzip est extrêmement bon sur des suites d’espaces — l’écart compressé entre un document formaté et le même minifié est souvent inférieur à cinq pour cent.

Là où cela compte, c’est partout où la compression n’intervient pas : une valeur dans une variable d’environnement, une colonne de base, une ligne de journal, un champ avec une limite de longueur stricte, un QR code. Ce sont les raisons d’être de cette page, et dans chacune c’est le nombre d’octets bruts qui contraint.

Un compte de caractères est ce qu’un champ de texte vous donne et c’est la mauvaise mesure. Le JSON voyage en UTF-8, où un caractère ASCII prend un octet, une lettre accentuée ou cyrillique deux, la plupart des caractères CJK trois et un emoji quatre. Un document de mille caractères japonais fait environ trois mille octets.

Toutes les vraies limites — une taille d’en-tête, une largeur de colonne, une taille de message sur une file — sont en octets. Mesurer en caractères donne un document qui tient d’après votre compte et qui est refusé d’après le leur, ce qui est un échec déroutant précisément parce que le nombre que vous aviez vérifié était bon.

Faites-le pour tout ce qui est stocké ou transmis là où la compression est absente et la taille bornée. Faites-le pour une charge que vous allez coller dans un champ de formulaire, une variable d’intégration continue ou un secret Kubernetes. Faites-le pour un document qui doit tenir sur une ligne parce que quelque chose en aval lit ligne par ligne.

Ne le faites pas sur un fichier qui vit dans un dépôt. Une configuration minifiée est une configuration que personne ne peut relire : chaque modification touche l’unique ligne dont elle est faite, donc le diff montre le fichier entier et le relecteur ne voit rien. Les octets économisés ne pèsent rien à côté, et l’étape de build qui minifierait à la sortie existe déjà.

Pas grand-chose, et c’est l’intérêt de savoir où se trouve le plancher. Du JSON minifié dépense encore des octets en guillemets autour de chaque clé, en noms de clés répétés dans chaque élément d’un tableau, et en ponctuation entre eux. Pour une liste de mille objets ayant les quatre mêmes champs, les noms de champs constituent l’essentiel du fichier.

Si minifier ne suffit pas, les étapes suivantes sont structurelles plutôt que cosmétiques : des noms de clés plus courts, un tableau de tableaux avec les noms de champs énoncés une fois, ou un format qui n’est pas du JSON. C’est une décision sur l’interface et non sur les espaces, et il vaut la peine de reconnaître dans laquelle des deux on se trouve.

Chaque caractère accentué pèse deux octets en UTF-8 au lieu d’un. Un document rempli de libellés français — `libellé`, `réf`, `société`, `été` — pèse donc sensiblement plus que le même document en anglais, à contenu égal, et l’écart se voit sur les gros tableaux de données.

La conséquence pratique concerne les limites de champ. Un contenu qui tenait dans une colonne de 255 caractères peut dépasser une limite exprimée en 255 octets, et la différence est exactement le nombre d’accents. Le compte affiché ici est en octets pour cette raison, et c’est aussi pourquoi il ne coïncide pas avec ce que compte votre éditeur.

Elle ne raccourcit aucune valeur, ne supprime aucune clé et ne change aucun nombre au-delà de leur réécriture sous forme exacte la plus courte. `1.50` devient `1.5` et `1e2` devient `100`, ce qui économise quelques octets et ne change rien à la donnée.

Elle ne supprime pas non plus les clés dont la valeur est nulle, contrairement à ce que certains outils appellent aussi minification. Cette distinction compte : retirer une clé `null` change ce que l’API réceptrice comprend, puisqu’absente et nulle sont souvent deux états différents. Ici, seule la mise en forme disparaît.

Trier reste possible sur une seule ligne, et cela sert au même usage qu’ailleurs : rendre deux documents comparables. Un document minifié et trié est une empreinte stable du contenu, indépendante de l’ordre dans lequel un système a sérialisé ses champs.

C’est d’ailleurs la façon habituelle de calculer une somme de contrôle sur une structure de données : minifier, trier, puis hacher. Sans le tri, deux systèmes qui décrivent le même objet produisent deux empreintes différentes, et la comparaison ne veut plus rien dire.

Beaucoup d’éditeurs ralentissent nettement sur une ligne de plusieurs centaines de kilooctets, parce que leur coloration syntaxique et leur retour à la ligne travaillent par ligne. Un fichier minifié volumineux peut donc être parfaitement valide et pénible à ouvrir.

C’est un argument de plus pour ne minifier qu’à la sortie. Gardez la version lisible pour le travail humain, produisez la version d’une ligne pour la machine, et ne confondez pas les deux dans un même fichier versionné — l’un des deux usages en souffre toujours.