Introducción: Una Cadena JSON Es Más Simple de lo que Parece — Hasta que Aparece una Comilla o un Salto de Línea
Una cadena JSON parece la parte más trivial del formato: algo de texto entre dos comillas dobles. En la práctica, las cadenas son donde más se rompe el JSON escrito a mano. Una comilla suelta dentro del texto, un salto de línea real pegado desde una hoja de cálculo, un tabulador copiado de una terminal o un emoji que una librería codificó mal — cualquiera de estos produce un error del analizador o, peor aún, datos silenciosamente corruptos. Esta guía cubre las reglas completas para cadenas JSON exactamente como las define RFC 8259, el estándar de Internet actual para el formato de intercambio de datos JSON.
RFC 8259 (publicado en diciembre de 2017 y designado STD 90) es breve y preciso sobre las cadenas. Una vez que entiendes su puñado de reglas, escapar cadenas deja de ser adivinanza. Este artículo es el complemento centrado solo en cadenas de nuestra guía sobre sintaxis de objetos JSON RFC 8259, que cubre objetos, claves y miembros. Si además quieres convenciones para construir APIs reales sobre estas primitivas, lee buenas prácticas de JSON para APIs. Para comprobar cualquier ejemplo de aquí, pégalo en nuestro formateador JSON — valida y formatea completamente en tu navegador.
La Forma Básica: Las Cadenas Se Delimitan con Comillas Dobles
Toda cadena JSON empieza y termina con un carácter de comilla doble (", U+0022). Las comillas simples nunca son delimitadores de cadena válidos en JSON, por muy comunes que sean en el código fuente de JavaScript o Python. Este es uno de los errores más frecuentes cuando la gente asume que JSON es "solo literales de objeto de JavaScript" — no lo es. 'hola' es inválido; "hola" es válido.
Entre las comillas de apertura y cierre, una cadena es una secuencia de caracteres Unicode. La mayoría de los caracteres pueden aparecer de forma literal y sin escapar. Sin embargo, tres categorías de caracteres deben escaparse o pueden escaparse opcionalmente:
- La comilla doble (
") debe escaparse, de lo contrario terminaría la cadena antes de tiempo. - La barra invertida (
\\) debe escaparse, porque es el propio carácter que introduce los escapes. - Los caracteres de control en el rango U+0000 a U+001F deben escaparse — un carácter de control literal dentro de una cadena no está permitido.
Todo lo demás — letras, dígitos, puntuación, espacios, caracteres acentuados, ideogramas CJK, emoji — puede escribirse de forma literal siempre que el documento sea UTF-8 válido. No hace falta escapar una é acentuada ni un carácter chino; solo debes escapar las tres categorías anteriores.
Los Escapes de Barra Invertida: Las Secuencias de Dos Caracteres
RFC 8259 define un conjunto fijo de secuencias de escape cortas. Cada una empieza con una barra invertida seguida de exactamente un carácter. Hay exactamente ocho de estos escapes de dos caracteres, más el escape \\u de seis caracteres que se cubre más adelante. El conjunto completo de escapes de dos caracteres es:
\\"— comilla doble (U+0022)\\\\— barra invertida, es decir, la propia barra invertida (U+005C)\\/— barra, es decir, la barra normal hacia delante (U+002F)\\b— retroceso / backspace (U+0008)\\f— avance de página / form feed (U+000C)\\n— salto de línea / line feed (U+000A)\\r— retorno de carro / carriage return (U+000D)\\t— tabulación / tab (U+0009)
Una barra invertida solo puede ir seguida de uno de estos caracteres (", \\, /, b, f, n, r, t) o de una u que introduce un escape Unicode. Cualquier otra secuencia — por ejemplo \\x41, \\a o \\' — no es JSON válido. En particular, \\' (una comilla simple escapada) es inválido en JSON aunque sea común en otros lenguajes, porque la comilla simple nunca necesita escaparse en primer lugar.
El Curioso Caso de la Barra Hacia Delante
El escape de la barra hacia delante, \\/, sorprende a muchos desarrolladores. La barra hacia delante no necesita escaparse — una / literal es un carácter perfectamente válido dentro de una cadena JSON. RFC 8259 simplemente permite que se escape como \\/ como opción. ¿Por qué permitir un escape opcional para un carácter que nunca lo requiere? La razón histórica es la incrustación en HTML: escapar la barra permite escribir la secuencia <\\/script> para que una cadena JSON incrustada dentro de un elemento script de HTML no pueda cerrar accidentalmente ese elemento. Así, "http://example.com" y "http:\\/\\/example.com" son ambos válidos y representan la cadena idéntica. La mayoría de los codificadores dejan la barra sin escapar; algunos, por seguridad en HTML, la escapan.
Caracteres de Control: U+0000 a U+001F Deben Escaparse
Esta es la regla que más problemas causa al copiar y pegar. Cualquier carácter en el rango U+0000 a U+001F — los caracteres de control C0 — no puede aparecer de forma literal dentro de una cadena JSON. Deben escaparse, ya sea usando uno de los escapes cortos con nombre de arriba (para los que lo tienen) o usando un escape \\u.
Los infractores más comunes son caracteres de control invisibles similares a espacios en blanco que se pegan desde otras herramientas:
- Un salto de línea real (line feed, U+000A) pegado desde un campo de texto multilínea debe convertirse en
\\n. Un salto de línea crudo dentro de las comillas es un error de análisis. - Un tabulador real (U+0009), a menudo copiado de hojas de cálculo o de la salida de una terminal, debe convertirse en
\\t. - Un retorno de carro (U+000D), común en texto originado en Windows, debe convertirse en
\\r.
Los caracteres de control que no tienen escape con nombre deben escribirse con la forma Unicode de seis caracteres. Por ejemplo, el carácter NUL (U+0000) se escribe \\u0000, el carácter de escape (U+001B, usado en los códigos de color ANSI de terminal) se escribe \\u001b, y el separador de unidad (U+001F) se escribe \\u001f. No existe un atajo \\0 en JSON — esa es una convención de C y JavaScript, no de JSON. Usa siempre \\u0000 para un carácter nulo.
Fíjate en el límite: la regla cubre de U+0000 a U+001F inclusive. El carácter de espacio U+0020 no es un carácter de control y no necesita escaparse. El carácter DEL (U+007F) no está, quizá sorprendentemente, obligado a escaparse por RFC 8259 — queda por encima del rango de control que la gramática restringe — aunque muchos codificadores lo escapan de todos modos por seguridad.
Escapes Unicode: La Forma \\uXXXX
Cualquier carácter puede representarse mediante un escape Unicode: una barra invertida, una u minúscula y exactamente cuatro dígitos hexadecimales que dan el punto de código del carácter. Por ejemplo, \\u0041 es la letra A (U+0041), y \\u00e9 es é (U+00E9). Los dígitos hexadecimales pueden ser mayúsculas o minúsculas — \\u00E9 y \\u00e9 son equivalentes — pero siempre debe haber exactamente cuatro. \\uE9 (dos dígitos) es inválido; hay que rellenar hasta \\u00e9.
Los escapes Unicode son opcionales para la mayoría de los caracteres. Puedes escribir la letra A de forma literal, o como \\u0041; ambos son válidos e idénticos. Los codificadores que quieren garantizar una salida ASCII pura a menudo escapan de este modo cada carácter no ASCII, por lo que a veces ves "caf\\u00e9" en lugar de "café" en las respuestas de API — ambos decodifican a la misma cadena. Este escapado solo-ASCII es una opción de transporte segura y nunca cambia el significado de los datos.
Pares Suplentes: Caracteres por Encima de U+FFFF
La forma \\u de cuatro dígitos hexadecimales solo puede codificar directamente puntos de código hasta U+FFFF, el tope del Plano Multilingüe Básico. Los caracteres más allá de ese punto — la mayoría de los emoji, muchos alfabetos históricos, símbolos alfanuméricos matemáticos — tienen puntos de código por encima de U+FFFF y no caben en cuatro dígitos hexadecimales. JSON resuelve esto usando pares suplentes UTF-16, exactamente como hace UTF-16 internamente.
Un carácter por encima de U+FFFF se representa como dos escapes \\u consecutivos: un suplente alto en el rango \\uD800 a \\uDBFF, seguido inmediatamente de un suplente bajo en el rango \\uDC00 a \\uDFFF. Juntos, el par codifica un carácter. Por ejemplo, el símbolo musical clave de sol (U+1D11E) se escribe \\uD834\\uDD1E, y el emoji de "cara sonriente" (U+1F600) se escribe \\uD83D\\uDE00.
De esto se derivan dos cosas. Primera, un suplente solitario — un suplente alto no seguido de uno bajo, o un suplente bajo sin un alto que lo preceda — es técnicamente mal formado. RFC 8259 señala que la gramática permite tales caracteres pero advierte que pueden no interoperar; el software robusto trata un suplente sin pareja como una señal de alarma. Segunda, por supuesto, también puedes escribir el emoji de forma literal en un documento UTF-8. "😀" y "\\uD83D\\uDE00" son la misma cadena; la forma escapada solo existe para cuando necesitas una representación ASCII pura.
Errores Comunes al Escapar
Casi todos los errores de cadena JSON caen en uno de unos pocos patrones recurrentes. Reconocerlos ahorra horas de depuración.
1. Una Comilla Sin Escapar Termina la Cadena Antes de Tiempo
Escribir "Ella dijo "hola"" es inválido — la segunda comilla cierra la cadena, y el analizador se atasca luego con el inesperado hola. La solución es escapar las comillas internas: "Ella dijo \\"hola\\"". Este es con diferencia el error de cadena JSON más común.
2. Rutas de Windows y Barras Invertidas Sueltas
Una ruta de Windows como C:\\Users\\Ana escrita ingenuamente como "C:\\Users\\Ana" en una cadena fuente es una trampa: cada \\U y \\A es un escape inválido. En JSON cada barra invertida literal debe duplicarse: la cadena JSON correcta es "C:\\\\Users\\\\Ana". De forma similar, una expresión regular como \\d+ debe escribirse "\\\\d+" dentro de JSON.
3. Pegar Saltos de Línea y Tabuladores Reales
El texto multilínea pegado directamente entre comillas deja saltos de línea y tabuladores literales en la cadena, que son caracteres de control prohibidos. Cada salto de línea real debe convertirse en \\n y cada tabulador real en \\t. Las librerías de serialización lo hacen automáticamente; el problema solo aparece en JSON editado a mano.
4. Usar Comillas Simples como Delimitadores
Las cadenas JSON deben usar comillas dobles. {'name': 'Ana'} no es JSON, aunque sea un literal de objeto de JavaScript válido. Cambia cada delimitador de cadena por una comilla doble.
5. Letras de Escape Incorrectas o Longitud \\u Errónea
Escapes inventados como \\x41, \\0 o \\a no existen en JSON, y un escape \\u con menos de cuatro dígitos hexadecimales (\\u1F) es inválido. Solo los ocho escapes con nombre y la forma \\u de cuatro dígitos son legales, además de los pares suplentes bien formados para los caracteres del plano astral.
6. Doble Codificación
Serializar una cadena JSON ya serializada produce una cadena llena de \\" donde esperabas estructura real, por ejemplo "{\\"name\\":\\"Ana\\"}" — una cadena JSON cuyo contenido resulta ser JSON, no un objeto JSON. Esto suele significar que un valor se pasó por JSON.stringify dos veces. Decodifica una vez e inspecciona si tienes una cadena o un objeto.
Escapar Claves Sigue las Mismas Reglas
El nombre de un miembro de objeto (una clave) es en sí mismo una cadena JSON, así que todas las reglas anteriores aplican de forma idéntica a las claves. Una clave que contenga una comilla, una barra invertida o un carácter de control debe escaparlo, y las claves usan comillas dobles igual que los valores. Para la gramática completa de objetos, miembros y cómo se relacionan las claves con los valores, consulta el artículo complementario sobre sintaxis de objetos JSON RFC 8259. En la práctica, las claves bien diseñadas evitan por completo los caracteres especiales, pero el formato los permite siempre que se escapen correctamente.
Verificar Cadenas con Nuestro Formateador JSON
La forma más rápida de confirmar que una cadena está escapada correctamente es pasarla por un validador que implemente la gramática de RFC 8259. Nuestro formateador y validador JSON analiza tu entrada contra el estándar e informa de la posición exacta de cualquier carácter ilegal — una comilla sin escapar, un carácter de control crudo, un escape \\u mal formado o un par suplente roto. Como se ejecuta completamente en tu navegador, puedes pegar con seguridad cadenas que contengan credenciales, tokens o datos de usuario sin transmitir nada a un servidor.
Cuando necesites imponer contenido de cadena más allá de la mera sintaxis — una longitud mínima, un patrón, un conjunto enumerado de valores permitidos — combina el formateador con nuestras herramientas y un esquema. Para el conjunto más amplio de convenciones que mantienen los payloads JSON consistentes en una API, la guía de buenas prácticas de JSON retoma donde terminan las reglas de cadenas crudas. Domina el conjunto de escapes de aquí — los ocho escapes de barra invertida, la forma \\u, los pares suplentes y la regla de los caracteres de control — y los errores a nivel de cadena que plagan el JSON escrito a mano simplemente dejan de ocurrir.