¿JSON permite comentarios?

No. La especificación oficial de JSON (RFC 8259) no contempla comentarios de ningún tipo. Algunos parsers permisivos los toleran, pero cualquier consumidor estricto fallará al leerlos. Si necesitas anotar un fichero, usa un campo dedicado ("_comment": "…") o cambia el formato a YAML.

¿Por qué YAML falla por indentación?

Porque YAML usa la sangría como sintaxis significativa: dos espacios sí, cuatro espacios sí, mezclados no. Tabs y espacios juntos también rompen. La mayoría de los errores crípticos de YAML ("could not find expected ':'", "mapping values are not allowed here") vienen de un cambio sutil en el ancho de indentación o de un tab oculto. Configurar el editor para mostrar caracteres invisibles ayuda mucho.

¿Se pierden números grandes al convertir JSON?

Sí, si el parser usa coma flotante de doble precisión (IEEE 754) — como hace JavaScript por defecto. El límite seguro es 2^53 − 1 = 9 007 199 254 740 991. Cualquier entero más grande se redondea silenciosamente. La forma robusta es serializar el campo como string ("id": "9007199254740993") o usar un parser con soporte explícito de BigInt.

¿YAML y JSON representan los mismos tipos?

Casi, pero no exactamente. YAML 1.2 está diseñado para ser un superconjunto de JSON, así que cualquier JSON válido también lo es como YAML 1.2. Sin embargo, YAML 1.1 (todavía muy usado) tiene coerción automática de booleanos (yes/no/on/off), referencias anchor/alias y tipos extendidos. Convertir YAML 1.1 a JSON puede transformar strings en booleanos sin avisar; conviene siempre validar el resultado.

¿Mis datos se envían a un servidor?

No. Las herramientas del hub JSON y YAML de ToolsOps se ejecutan enteramente en tu navegador. No subimos tu input a ningún servidor, no lo almacenamos y no lo enviamos a terceros. Es una garantía arquitectónica, no una promesa: el código no incluye llamadas remotas con tu contenido.

Buenas prácticas con JSON y YAML

Cuándo elegir JSON o YAML, errores frecuentes en cada uno, números grandes, anchors YAML, validación previa al deploy y por qué importa el procesamiento client-side.

Qué problema resuelve JSON

JSON nació como un subset de JavaScript pensado para que máquinas y humanos intercambiaran datos estructurados sin ambigüedad. Su gramática es deliberadamente pequeña: objetos, arrays, strings, números, booleanos y null. Esa simplicidad es su mayor virtud: cualquier lenguaje serio tiene un parser estricto, y el formato no deja margen de interpretación. APIs HTTP, almacenamiento estructurado y comunicación entre servicios viven cómodos en JSON precisamente por eso.

La contrapartida es la rigidez: sin comentarios, sin trailing commas, sin referencias internas. Para humanos que editan un fichero a mano, JSON puede ser incómodo. Para máquinas, es ideal.

Qué problema resuelve YAML

YAML asume que el usuario es humano. Permite comentarios con #, agrupa por indentación en lugar de por llaves, soporta strings sin comillas en muchos casos y añade referencias anchor/alias para reutilizar fragmentos dentro del mismo documento. Por eso domina configuraciones largas que se editan a mano: Kubernetes, GitHub Actions, docker-compose, Ansible.

La contrapartida es la flexibilidad: la misma flexibilidad que hace YAML cómodo también permite errores sutiles. La conversión automática de booleanos en YAML 1.1, los anchors compartidos entre rama y rama, o el cambio silencioso de tipos al mezclar comillas son fuentes habituales de bugs en producción.

Cuándo elegir JSON o YAML

Hay una heurística que funciona en el 90 % de los casos: si el fichero lo consumirá una máquina sin que un humano lo edite habitualmente, JSON. Si lo editará un humano (un developer, un DevOps, un operador), YAML.

Payloads HTTP de API: JSON.
Configuración Kubernetes / Compose / Actions: YAML.
Resultados de tests / coverage / logs estructurados: JSON.
Documentos legibles con anotaciones inline: YAML.
Almacenamiento clave-valor en Redis/etc.: JSON serializado.

Errores frecuentes en JSON

Trailing comma: parsers estrictos rechazan {"a": 1,}.
Comentarios: // o /* */ rompen el parseo.
Claves sin comillas: {a: 1} no es JSON, es JavaScript.
Comillas simples: JSON solo acepta comillas dobles.
Claves duplicadas: el parser conserva la última y descarta la primera sin avisar.
NaN / Infinity: tampoco son JSON válido. Hay que serializar como string o como null y documentar el contrato.

Errores frecuentes en YAML

Indentación inconsistente: dos espacios en una sección y cuatro en otra rompe el documento.
Tabs mezclados con espacios: nunca usar tabs en YAML.
Booleanos implícitos (YAML 1.1): yes, no, on, off, y, n se convierten en booleanos sin avisar.
Valores que parecen versiones: 1.0 se interpreta como número float. Cita el valor: "1.0".
Strings con dos puntos: `host: foo:bar` puede romper el parseo; usa comillas.
Listas vacías mal escritas: una clave seguida de nada en lugar de [] o {} puede interpretarse como null.

Números grandes y precisión

JSON no tiene tipo entero. Todos los números son IEEE 754 double-precision en la mayoría de parsers, lo que limita los enteros exactos a 2^53 − 1 (9 007 199 254 740 991). Cualquier entero más grande pierde precisión silenciosamente: timestamps de Twitter, IDs de Snowflake, claves primarias de bases relacionales grandes. Si tu sistema usa IDs por encima de ese rango, serializa los campos como string desde el origen. Es la única forma garantizada de preservar precisión a través de parsers.

YAML 1.1 vs 1.2 y trampas con booleanos

YAML 1.2 (2009) corrigió varios problemas de YAML 1.1 (2005), pero muchos parsers en uso todavía siguen la spec de 1.1. La diferencia más peligrosa es la coerción de booleanos: en 1.1, los strings yes, no, on, off, y, n se convierten en booleanos automáticamente; en 1.2, solo true y false. Esto significa que un campo como country: NO (donde NO es el código ISO de Noruega) se convierte silenciosamente en false. La defensa es citar siempre los valores que pueden confundirse: country: "NO".

Anchors y aliases

YAML permite definir un fragmento con &ancla y reusarlo con *ancla. Es útil para reducir duplicación en ficheros largos, pero introduce riesgos: el alias comparte la misma referencia, así que mutar un campo en una rama afecta a todas las demás si el parser no clona en profundidad. Además, los conversores YAML → JSON suelen expandir los anchors, multiplicando el tamaño del fichero. Si tu flujo convierte YAML a JSON antes de almacenarlo, mide el tamaño post-expansión.

Validar antes de desplegar

La regla de oro: cualquier YAML o JSON que vaya a producción se valida antes de que se aplique. En Kubernetes, kubectl apply --dry-run=client lo hace localmente; GitHub Actions tiene act para validar workflows sin push. Para JSON estructurado, un JSON Schema con AJV detecta no solo errores sintácticos sino también incoherencias de tipo y rango. Hacerlo en CI (no en el navegador del operador) previene incidentes silenciosos.

Por qué validar client-side importa

Cuando un developer pega un secreto, una clave API o un token en un validador online, esos bytes pueden quedar en logs, en cachés intermedias o en bases de datos del proveedor. Es una fuga real, no teórica: cualquier servicio que reciba tu input lo procesa en su infraestructura. ToolsOps procesa los inputs íntegramente en tu navegador: el código JavaScript que tu navegador ejecuta es el único que ve los bytes. Para tareas donde lo que pegas es sensible, ese contrato es la diferencia entre validar y filtrar.

Cuando termines de leer, vuelve al hub JSON y YAML para usar el validador o el conversor con la cheat sheet a mano.

Preguntas frecuentes

¿JSON permite comentarios?: No. La especificación oficial de JSON (RFC 8259) no contempla comentarios de ningún tipo. Algunos parsers permisivos los toleran, pero cualquier consumidor estricto fallará al leerlos. Si necesitas anotar un fichero, usa un campo dedicado ("_comment": "…") o cambia el formato a YAML.
¿Por qué YAML falla por indentación?: Porque YAML usa la sangría como sintaxis significativa: dos espacios sí, cuatro espacios sí, mezclados no. Tabs y espacios juntos también rompen. La mayoría de los errores crípticos de YAML ("could not find expected ':'", "mapping values are not allowed here") vienen de un cambio sutil en el ancho de indentación o de un tab oculto. Configurar el editor para mostrar caracteres invisibles ayuda mucho.
¿Se pierden números grandes al convertir JSON?: Sí, si el parser usa coma flotante de doble precisión (IEEE 754) — como hace JavaScript por defecto. El límite seguro es 2^53 − 1 = 9 007 199 254 740 991. Cualquier entero más grande se redondea silenciosamente. La forma robusta es serializar el campo como string ("id": "9007199254740993") o usar un parser con soporte explícito de BigInt.
¿YAML y JSON representan los mismos tipos?: Casi, pero no exactamente. YAML 1.2 está diseñado para ser un superconjunto de JSON, así que cualquier JSON válido también lo es como YAML 1.2. Sin embargo, YAML 1.1 (todavía muy usado) tiene coerción automática de booleanos (yes/no/on/off), referencias anchor/alias y tipos extendidos. Convertir YAML 1.1 a JSON puede transformar strings en booleanos sin avisar; conviene siempre validar el resultado.
¿Mis datos se envían a un servidor?: No. Las herramientas del hub JSON y YAML de ToolsOps se ejecutan enteramente en tu navegador. No subimos tu input a ningún servidor, no lo almacenamos y no lo enviamos a terceros. Es una garantía arquitectónica, no una promesa: el código no incluye llamadas remotas con tu contenido.