Herramientas
Guías

Escape / desescape de cadenas JSON

JSON

Escapa y desescapa cadenas JSON — comillas, caracteres de control y \uXXXX.

100 % del lado del cliente Sin backend
Entrada
Salida
En esta página

¿Qué es el escape de cadenas JSON?#

Dentro de un documento JSON, una cadena debe ir entre comillas dobles, y eso crea un problema en cuanto el propio texto contiene una comilla, un salto de línea o una barra invertida. Si las dejaras tal cual, el analizador vería la comilla de cierre demasiado pronto o interpretaría \ como el inicio de un escape que no comprende. Escapar consiste en sustituir esos caracteres por las secuencias breves con barra invertida que define la especificación JSON: \" para una comilla, \\ para una barra invertida, \n para un salto de línea, \t para un tabulador y algunas más. Desescapar es la operación inversa: devolver esas secuencias a los caracteres originales.

Existe un segundo modo, más estricto. Algunos sistemas heredados —transportadores de logs antiguos, bases de datos restrictivas, capas de tránsito que asumen ASCII puro— se atragantan con cualquier byte por encima de 127. Para esos casos, JSON permite escribir cualquier carácter no ASCII como \uXXXX (y los caracteres astrales, como los emoji, como un par suplente UTF-16). El texto sigue siendo JSON válido; simplemente, tras el escape, queda compuesto únicamente por ASCII.

Esta página cubre ambas direcciones y ambos modos: escapar una cadena en bruto hacia un literal de cadena JSON válido, o desescapar un literal de vuelta al texto original, con un conmutador ASCII-only opcional que fuerza cada punto de código no ASCII a la forma \uXXXX.

Cómo usarlo#

  1. Elige la dirección con el conmutador Codificar / Decodificar en la parte superior izquierda de la barra de herramientas. Codificar escapa el texto en bruto hacia un literal JSON; Decodificar desescapa un literal de vuelta al texto.
  2. Escribe o pega en el panel de Entrada a la izquierda.
    • En Codificar, todo el texto se convierte en un único literal de cadena JSON (comillas incluidas).
    • En Decodificar, puedes pegar tanto un literal entre comillas ("a\nb") como solo el cuerpo escapado, sin comillas (a\nb): la herramienta lo envuelve por ti. Un número, booleano u objeto JSON válido se rechaza con «no es una cadena» en lugar de convertirse de forma silenciosa.
  3. Marca Salida solo ASCII (\uXXXX) (modo Codificar) cuando el consumidor final no pueda manejar bytes no ASCII. Los caracteres astrales, como los emoji, se emiten como un par suplente correcto, exactamente igual que haría JSON.stringify.
  4. El resultado aparece en vivo en el panel de Salida. Pulsa Copiar para llevártelo.
  5. Ejemplo inserta una cadena de demostración en varios idiomas; Limpiar vacía ambos paneles.

Características principales#

  • Formas cortas exactas según la especificación. Usa precisamente las secuencias que exige RFC 8259 (\", \\, \b, \f, \n, \r, \t) y \uXXXX para todo lo demás por debajo de 0x20, coincidiendo byte a byte con JSON.stringify.
  • Modo ASCII-only de verdad. Los caracteres no ASCII no se eliminan ni se estropean en silencio: cada uno se emite como \uXXXX, y los caracteres astrales (por encima de U+FFFF) se convierten en un par suplente UTF-16 correcto, no en una unidad de código solitaria y rota que los decodificadores rechazarían.
  • Desescape tolerante. Acepta tanto un literal entre comillas como un cuerpo escapado sin comillas, de modo que incluso fragmentos a medias pegados de una línea de log se decodifican en lugar de lanzar un error.
  • No intenta adivinar. Si la entrada decodificada es JSON válido pero no una cadena (por ejemplo, un número suelto o un array), la herramienta te lo indica en lugar de convertirla a cadena a tus espaldas.

Ejemplo detallado#

Carga Ejemplo en modo Codificar y la entrada es una cadena que combina a propósito comillas, una ruta con barras invertidas, un salto de línea, un símbolo de copyright, un emoji y chino:

He said "hi"
\path\ © 🌍 你好

Sin ASCII-only, el literal escapado conserva los caracteres legibles tal cual y solo escapa lo que debe escaparse:

"He said \"hi\"\n\\path\\ © 🌍 你好"

Ahora marca Salida solo ASCII (\uXXXX) y la misma entrada se convierte en ASCII puro: el símbolo de copyright se pliega a la forma de cuatro caracteres \u00a9, el emoji del globo al par suplente \ud83c\udf0d, y cada carácter chino a su propio punto de código (\u4f60, \u597d):

"He said \"hi\"\n\\path\\ \u00a9 \ud83c\udf0d \u4f60\u597d"

Cambia a Decodificar y pega de vuelta cualquiera de esos dos literales: el texto original —incluidos el emoji y el chino— se restaura intacto.

Preguntas frecuentes#

¿Por qué el emoji se convierte en dos códigos \u en lugar de uno?#

Los caracteres por encima de U+FFFF (emoji, extensiones raras de CJK, algunos símbolos matemáticos) no caben en una sola unidad de código de 16 bits, así que UTF-16 los representa como un par suplente: un suplente alto seguido de uno bajo. El emoji del globo 🌍 (U+1F30D) se convierte en \ud83c\udf0d. Emitir un único \u produciría un JSON inválido que los decodificadores estrictos rechazan; esta herramienta emite el par exactamente igual que JSON.stringify, de modo que el resultado hace el viaje de ida y vuelta sin pérdidas.

Decodificar dice «La entrada no es una cadena JSON». ¿Qué he pegado?#

Has pegado algo que es JSON válido pero no una cadena: normalmente un número suelto (42), un booleano (true) o un objeto/array. La herramienta se niega a convertirlo a cadena porque eso ocultaría un error real (casi con seguridad querías pegar el valor de la cadena, no el documento entero). Envuelve tu texto entre comillas e inténtalo de nuevo.

¿Gestiona caracteres de control como un tabulador literal o un timbre?#

Sí. Un tabulador literal en la entrada se convierte en \t, un retroceso en \b, un avance de formulario en \f, un retorno de carro en \r; cualquier otro código de control por debajo de U+0020 (incluido el timbre, 0x07) se convierte en un código estilo \u0007. Esto importa porque los caracteres de control en bruto son ilegales dentro de las cadenas JSON y algunos analizadores los rechazan directamente.

¿Es la salida ASCII-only «más segura»?#

Solo para un tipo concreto de seguridad: sobrevivir a una capa de tránsito que destroza o rechaza bytes no ASCII. No es una medida de seguridad: los datos siguen siendo totalmente reversibles, simplemente están expresados en un alfabeto más restrictivo. Úsala cuando un consumidor exija ASCII; déjala desactivada en caso contrario, ya que la forma legible es mucho más fácil de depurar.