Présentation

Le projet jBin propose un format binaire capable de réduire la taille d’un document JSON d’environ 80 % en s’appuyant sur un schéma déclaratif. L’idée de base repose sur la suppression des métadonnées textuelles (noms de champs, séparateurs) et sur l’encodage compact des valeurs primitives. Le texte d’origine montre que la simple conversion d’une chaîne "hello world" en ASCII occupe 11 octets, alors que le même contenu, lorsqu’il est stocké avec un en‑tête de type et de longueur, passe à 13 octets, mais que l’ensemble d’un objet structuré gagne en densité grâce à la réutilisation du schéma.

Architecture du format

Le format se compose de trois parties essentielles : un schéma décrivant les champs (type et numéro), un en‑tête de champ codé sur un octet, et le corps de donnée. Le type est limité à quatre valeurs (varint, f32, f64, délimité) et est stocké sur les deux bits de poids faible de l’octet d’en‑tête. Le numéro de champ occupe les six bits supérieurs, ce qui autorise jusqu’à 63 champs distincts sans extension. Pour les valeurs supérieures à 127, le format utilise un varint à 7 bits avec un bit de continuation (MSB) : chaque octet dont le MSB vaut 1 indique qu’un octet supplémentaire suit. Ainsi, le nombre 128 s’écrit 10000001 00000000 (LSB‑first), ce qui correspond à la même technique que les protobuf.

FILE *f = fopen("file.bin", "wb");
unsigned char data[] = "hello world";
fwrite(data, 1, sizeof(data) - 1, f);
fclose(f);

Le schéma permet d’éliminer le champ [TYPE] pour chaque valeur, car le type est implicite dans le numéro de champ. Par exemple, le champ userid (numéro 10) de type varint est encodé en décalant le numéro de deux bits (00101000) puis en appliquant le type 00 (00101000), soit un octet unique.

Implémentation et limites

L’auteur décrit la construction d’un analyseur lexical, d’un AST et d’un générateur de code (codegen) basé sur le pattern Visitor. Le processus de compilation transforme la description du schéma en code C capable de sérialiser et désérialiser les structures. La mise en œuvre du varint repose sur un décodage itératif : lire un octet, extraire les 7 bits de données, concaténer tant que le MSB vaut 1. Cette méthode minimise l’en‑tête pour les petites valeurs mais introduit un surcoût de 1 à 2 octets pour les nombres supérieurs à 127.

Le format ne prévoit pas de mécanisme de versionnage intégré ; toute évolution du schéma nécessite une recompilation du code client. De plus, la limitation à 63 champs (6 bits) impose une contrainte sur les structures très larges, bien que l’on puisse envisager une extension à deux octets d’en‑tête. Enfin, l’absence de compression de flux (par ex. gzip) signifie que les gains proviennent uniquement de la représentation binaire.

Perspectives d’utilisation

Le modèle s’avère adapté aux environnements où la bande passante est limitée et où les structures de données sont connues à l’avance, comme les protocoles IoT ou les échanges inter‑services à haut débit. Comparé à des formats texte, le gain de 80 % observé sur des payloads JSON typiques justifie l’effort de génération de schéma. Toutefois, pour des API publiques où la flexibilité et la lisibilité sont prioritaires, le coût de maintenance du schéma peut dépasser les bénéfices de compaction.