TOON ↔ JSON

Funciones

• Las dos direcciones, JSON → TOON y TOON → JSON, o se fija una a mano
• Tres delimitadores: coma, tabulador (el más compacto) y barra vertical
• ⚠️ Una comparación del recuento de caracteres con el porcentaje de cambio; un número negativo significa que TOON es más corto
• ⚠️ Dice claramente que son caracteres y no tokens, y por qué el recuento de tokens no se puede dar
• ⚠️ El lado JSON se mide compacto, para que el sangrado no engañe a la comparación
• Admite pares clave-valor, objetos anidados, arrays y arrays tabulares
• ⚠️ Al fallar, nombra las dos cosas que de verdad fallan: una tabla cuyo número de filas no cuadra con el declarado y una comilla sin cerrar
• ⚠️ Avisa de que «ha producido salida» no es «lo ha leído bien»: el decodificador de TOON es bastante indulgente
• Todo ocurre en tu navegador

Cómo se usa

1. Pega JSON o TOON; la dirección se detecta sola
2. Cambia el delimitador si hay muchas tablas: el tabulador ahorra más caracteres
3. Mira el resultado y la comparación de caracteres; si vas a dárselo a un modelo, la línea que importa es la del porcentaje

Preguntas frecuentes

¿Por qué das caracteres y no tokens?

Porque no se puede contar con exactitud, y un número equivocado dicho con seguridad es peor que ninguno. El recuento de tokens depende del tokenizador: el cl100k y el o200k de GPT, el de Claude y las distintas implementaciones BPE abiertas parten de formas distintas, y el texto no latino, el código y el JSON divergen aún más entre ellas. Hacerlo bien exige incluir un tokenizador de 1–2 MB en la página, y aun así solo daría la respuesta de un tokenizador mientras se leería como general. Así que esto da lo que se puede contar exactamente: caracteres. El recuento de caracteres se correlaciona mucho con el de tokens (lo que TOON quita son sobre todo claves repetidas y llaves), pero «un 40% menos de caracteres» no es «un 40% menos de tokens».

¿Dónde ahorra TOON de verdad?

En dos sitios. En las claves repetidas: para un conjunto de objetos con la misma forma, JSON escribe `"id"`, `"name"` y `"role"` en cada uno, mientras que TOON las escribe una vez en la cabecera y las filas son puro dato. Y en las llaves y las comillas: `{}`, `[]` y `""` suman mucho en un array grande. Así que cuanto más regular es el dato, más ahorra: una tabla de decenas de filas con los mismos campos puede reducir el tamaño a la mitad, mientras que un objeto con tres claves y sin arrays mide igual o incluso más.

¿Por qué una tabla lleva un `[2]`?

Eso es el número de filas, y TOON lo usa para confirmar que la tabla está completa. No es decoración: el decodificador lo compara con las filas que ha leído de verdad y da un error cuando no cuadran («Expected 3 tabular rows, but got 1»). Es fácil olvidarlo al editar TOON a mano: borras una fila sin actualizar el número y la siguiente lectura falla. Es una de las pocas cosas que el decodificador rechaza de verdad.

¿Qué significa que «haya salida» no es «haberlo leído bien»?

Que el decodificador de TOON es bastante indulgente. En las pruebas da error por exactamente dos cosas: una tabla cuyo número de filas no cuadra con el declarado, y una comilla sin cerrar. Más allá de eso, una línea sin ningún sentido se lee como una cadena y obtienes un resultado «correcto» cuyo contenido no es el que creías. Así que al pegar TOON de otro sitio, échale un ojo al JSON resultante en vez de limitarte a comprobar si dio error.

¿Cuándo conviene usar TOON?

Cuando metes datos estructurados en un prompt. Es más corto que JSON y, como las tablas se alinean fila a fila, también se lee bien para un modelo. No para: mover datos entre máquinas (ese es el terreno de JSON, donde todos los lenguajes tienen un analizador estable), nada que necesite una especificación estricta (TOON es joven; la implementación de referencia es la especificación) ni archivos de configuración que la gente edita a mano (el recuento `[N]` se olvida fácil y nada te avisará).