jBin: un formato binario con esquema propio que recorta cargas JSON un 80%
El proyecto, publicado en GitHub, sustituye el texto repetitivo de JSON por etiquetas de tipo, varints y un esquema que evita repetir la estructura en cada valor.
jBin es un formato binario que va acompañado de su propio lenguaje de esquema, publicado en GitHub, y que según quien lo ha escrito reduce el tamaño de las cargas útiles JSON un 80%. La premisa de partida: buena parte de un JSON es repetición —nombres de campo, comillas, llaves— y todo eso se puede tirar si emisor y receptor conocen de antemano qué forma tiene el dato.
Cómo se codifica
El ejemplo que usa el texto es el de siempre: "hello world" cabe en ASCII con un byte por carácter, pero un 104 se lleva tres bytes ('1', '0', '4') si se escribe como texto. Para no pagar ese sobrecoste hay que marcar el tipo, y ahí empieza el diseño. El primer byte de cada valor lleva una etiqueta que dice qué es; si el valor es una cadena, hace falta además saber cuántos bytes ocupa, así que aparece un campo de longitud.
El truco para que la cabecera no crezca sin control es un bit de continuación en el byte más significativo. Si está a 1, hay otro byte de cabecera detrás; si está a 0, la cabecera termina y empieza el dato. Es el mismo mecanismo de los varint para números que no caben en siete bits: el 128 necesita dos bytes, uno con los siete bits bajos y otro con lo que sobra. El propio autor reconoce el parentesco con protobuf.
La segunda pieza es el esquema. Si la estructura se describe una sola vez —un entero, un puntero a char, una lista de diez enteros, como en el struct de C del ejemplo—, el decodificador ya sabe qué tipo toca en cada posición y las etiquetas dejan de repetirse valor a valor. Queda solo decidir cómo se mide cada cosa: varint para enteros y booleanos, f32 y f64 con anchura fija, y un tipo delimitado para las cadenas, donde hay que conocer la longitud antes de empezar a leer. Como solo hay cuatro codificaciones, caben en dos bits, y a cada campo se le asigna un número para poder direccionarlo.
Qué falta para tomárselo en serio
El 80% es la cifra de su autor, no de un tercero, y en el repositorio de jBin no hay comparativas contra MessagePack, CBOR o el propio protobuf. En un formato de serialización eso es justo lo que decide: no cuánto ahorra en un ejemplo de una línea, sino cómo se comporta con cargas reales, qué ocurre cuando el esquema evoluciona entre versiones y qué rendimiento da en lenguajes que no son C. Tampoco se detalla la licencia. Con lo que hay, jBin se lee como lo que es: un ejercicio de diseño de formatos bastante entretenido y una excusa para entender por qué un varint ahorra bytes.
