Herramientas de desarrollo · JSON formateador y validador
JSON explicación de los escapes de cadena: \n, \uXXXX y caracteres de control
· Cómo funciona
json flujo de trabajo del desarrollador validación
Una nueva línea sin formato dentro de una cadena JSON no es válida, al igual que una pestaña. Esta publicación cubre las ocho secuencias de escape, cómo funcionan los escapes \u y los pares sustitutos, y por qué un párrafo pegado puede invalidar un archivo completo.
El párrafo que rompió la carga útil
El párrafo que rompió la carga útil: al pegar un salto de línea visible en una descripción citada se inserta un carácter de control directamente en la cadena JSON. La primera línea parece completa, pero la cita inicial aún espera contenido de cadena o una cita final. Cuando el analizador llega al avance de línea sin formato, se detiene allí porque las cadenas JSON no pueden abarcar líneas físicas de esa manera. El texto debe contener el escape de dos caracteres `\n` siempre que el valor decodificado necesite una nueva línea.
Las pestañas copiadas de un documento u hoja de cálculo provocan el mismo tipo de error, aunque un editor pueda representarlas como espacios inofensivos. Reemplace una pestaña literal con `\t`, un retorno de carro con `\r` y otros controles prohibidos con sus escapes con nombre o Unicode.
Los ocho escapes JSON permiten
Los ocho escapes que permite JSON: después de una barra invertida, las formas cortas son `"`, `\\`, `\/`, `\b`, `\f`, `\n`, `\r` y `\t`. Representan comillas, barra invertida, barra diagonal, retroceso, avance de página, avance de línea, retorno de carro y tabulación horizontal. Una barra diagonal también puede aparecer sin formato; `\/` existe principalmente por compatibilidad con contextos que alguna vez trataron una secuencia de script de cierre de manera especial.
Ninguna otra letra puede seguir a una barra invertida JSON. Las secuencias familiares de los lenguajes de programación, como `\v`, `\0`, `\x41` o una barra invertida seguida de una nueva línea física, no son válidas aquí. Utilice `\u` seguido de exactamente cuatro dígitos hexadecimales cuando no exista un escape corto. Este pequeño vocabulario fijo mantiene las cadenas JSON portátiles: un consumidor no necesita JavaScript, Python o reglas de escape específicas del shell para determinar los caracteres representados por el texto válido.
Por qué una tabulación literal no es válida pero una é literal está bien
Por qué una tabulación literal no es válida pero una é literal está bien: JSON prohíbe puntos de código sin escape desde U+0000 hasta U+001F dentro de cadenas. Ese rango contiene pestañas, nuevas líneas y otros controles cuyos efectos invisibles pueden alterar el encuadre o la visualización. La letra `é` es U+00E9, muy fuera del rango de control, por lo que UTF-8 JSON puede incluirla directamente entre comillas. Lo mismo ocurre con la mayoría de las escrituras, símbolos y emoji.
Escapar de Unicode ordinario es, por lo tanto, opcional, no un requisito de limpieza. `"café"` y `"caf\u00e9"` decodifican en la misma secuencia de caracteres. El texto directo suele ser más fácil de leer para las personas, mientras que los escapes pueden ayudar a transportar solo ASCII o hacer visible una unidad de código específica. Los personajes de control son diferentes: su escape es obligatorio.
Cómo funcionan los escapes \uXXXX
Cómo funcionan los escapes `\uXXXX`: el `u` debe ir seguido exactamente de cuatro dígitos hexadecimales, utilizando 0–9 o A–F en cualquier caso. `\u00E9` representa la unidad de código UTF-16 para `é` y `\u000A` representa un avance de línea. Menos dígitos, llaves como `\u{1F600}` o una letra no hexadecimal hacen que JSON no sea válido, incluso si otro lenguaje de programación acepta esa notación.
Los caracteres por encima de U+FFFF se representan en esta forma de escape como un par sustituto. El emoji 😀 se puede escribir como `\uD83D\uDE00`: el sustituto alto y bajo se combinan después de analizarlos en un valor escalar Unicode. La gramática JSON puede llevar un escape sustituto no emparejado, pero los codificadores y aplicaciones posteriores pueden rechazarlo o reemplazarlo porque no identifica un carácter Unicode completo.
Ejemplo resuelto: escapar de una ruta de Windows y un fragmento de HTML
Ejemplo resuelto: escapar de una ruta de Windows y un fragmento de HTML; la ruta prevista `C:\Temp\report.txt` necesita que cada barra invertida se duplique en la fuente JSON: `"C:\\Temp\\report.txt"`. Sin duplicar, `\T` es un escape no válido y secuencias como `\r` o `\t` pueden convertirse silenciosamente en caracteres de control en lugar de separadores de ruta. Construya el JSON a partir del valor deseado, sin adivinar qué barras diagonales mostradas ya pertenecen a un idioma externo.
Un fragmento HTML como `<a title="Report">Open</a>` puede mantener los corchetes angulares y la barra diagonal literalmente, pero las comillas del atributo deben convertirse en `\"` dentro de la cadena JSON. Si una nueva línea separa dos etiquetas, codifíquela como `\n`. El miembro JSON resultante se puede validar y analizar nuevamente al texto HTML original.
Donde las fugas se duplican
Donde los escapes se duplican: cada gramática del texto adjunto tiene su propia oportunidad de interpretar las barras invertidas. Un documento JSON que contiene la cadena decodificada `line1\nline2` debe escapar de esa barra invertida, lo que produce `"line1\\nline2"`. Si ese texto JSON se almacena como una cadena JSON, sus comillas y ambas barras invertidas necesitan otra capa de escape. El aparente desorden registra múltiples representaciones, no una forma extendida especial de JSON.
Los shells y los literales del lenguaje de programación agregan sus propias reglas de citas antes de que un analizador JSON vea el argumento. Diagnostique de adentro hacia afuera: escriba primero el valor decodificado exacto, codifíquelo como JSON una vez, luego codifique ese texto JSON completo para el shell circundante o el idioma de origen. En cada límite, inspeccione qué bytes o caracteres recibe realmente el siguiente analizador.
Lo que esto no cubre
Lo que esto no cubre: las entidades HTML como `"` y la codificación porcentual de URL como `%20` son transformaciones separadas para contextos sintácticos separados. Un analizador JSON no decodifica ninguna de las formas. La cadena `"""` contiene seis caracteres literales después del análisis, no una comilla, y `"%20"` contiene un signo de porcentaje seguido de dos dígitos, no un espacio. Aplique esas codificaciones solo cuando los datos crucen HTML o un componente URL.
Esta discusión tampoco reemplaza la codificación de salida. El JSON válido recibido de una fuente que no es de confianza aún puede contener HTML, texto tipo script o secuencias de control de terminal como datos de cadena normales. La aplicación que luego procesa o ejecuta un comando debe manejar ese destino de forma segura. JSON escapar protege la estructura JSON; no es una desinfección universal.
Conclusión: escapa de lo que la gramática prohíbe, nada más
Conclusión: escape de lo que la gramática prohíbe, nada más: las comillas dobles, las barras invertidas y los puntos de código debajo de U+0020 necesitan atención dentro de las cadenas JSON. El Unicode ordinario puede seguir siendo legible, mientras que `\uXXXX` proporciona una alternativa exacta de cuatro dígitos y los pares sustitutos representan caracteres superiores a U+FFFF. Un diagnóstico en una posición aparentemente en blanco a menudo identifica una nueva línea literal, tabulación u otro carácter de control que debe reemplazarse con su escape textual.
Cuente las capas de codificación en lugar de contar las barras diagonales. Comience desde el valor que debe recibir la aplicación, codifíquelo una vez para JSON y solo luego cite el documento resultante para cualquier shell externo, archivo fuente o segunda cadena JSON. Valide el texto presentado al analizador JSON y, cuando sea importante, inspeccione la cadena decodificada posteriormente.