Por qué el chino se convierte en \u4e2d\u6587
En resumen: Un escape \u4e2d\u6587 es Unicode legal, no un fallo de codificación. El mojibake real tiene otro aspecto, y distinguirlos decide qué hay que corregir de verdad.
En resumen: trata la salida \uXXXX como escape legal, confirma que hace round-trip por JSON.parse, y desactiva la serialización en ASCII puro como ensure_ascii=False cuando quieras chino legible; mantén el escape solo para transportes que no pueden llevar caracteres no ASCII.
Porque se escapó, no porque se dañó.
JSON.parse('"\\u4e2d\\u6587"') // "中文"
\u4e2d es 中 y \u6587 es 文. Son secuencias de escape legales; cualquier analizador las restaura. No hay nada roto: simplemente es ilegible en logs, diffs y capturas de paquetes.
Quién hace el escape
| Herramienta | Valor predeterminado | Interruptor |
|---|---|---|
json.dumps de Python |
Escapa (ensure_ascii=True) |
ensure_ascii=False |
JSON.stringify de JavaScript |
Sin escape | — |
| Jackson de Java | Sin escape | Opcional |
json_encode de PHP |
Sin escape desde 5.4 | — |
encoding/json de Go |
Sin escape | — |
Python es de lejos la fuente más común. El valor predeterminado tiene una razón: la salida en ASCII puro sobrevive a cualquier transporte. El coste es que cada carácter no ASCII pasa a ocupar seis caracteres.
Escape frente a mojibake
Escape: \u4e2d\u6587, coincide con \uXXXX. Causado por los ajustes del serializador.
Mojibake: 测试, 涓枃. Causado por escribir bytes UTF-8 y leerlos como Latin-1 o GBK.
Prueba rápida: pega el texto en la consola del navegador como JSON.parse('"…"'). Si vuelve legible, era escape. Si falla o sigue corrupto, es un desajuste de codificación, y la corrección consiste en alinear las codificaciones, no en tocar el serializador.
Desactivarlo
json.dumps(data, ensure_ascii=False)
Después verifica aguas abajo: algunos sistemas heredados dependen realmente del transporte solo ASCII, en particular las pasarelas de SMS y los relés de correo antiguos.
Cuándo el escape es la elección correcta
- Transportes hostiles a los caracteres no ASCII (cabeceras HTTP heredadas, algunas pasarelas de SMS)
- JSON anidado dentro de otra cadena JSON, donde el escape reduce los conflictos de comillas
- Pipelines de logs que truncan por bytes y partirían un carácter multibyte
Fuera de esos casos, prefiere la legibilidad y desactívalo.
FAQ
¿Por qué Python escapa el chino de forma predeterminada?
Porque ensure_ascii=True es el valor predeterminado, lo que garantiza una salida en ASCII puro que sobrevive a cualquier transporte. El coste es que cada carácter no ASCII pasa a ocupar seis caracteres.
¿Debería desactivar ensure_ascii?
Desactívalo cuando la legibilidad importa. Después verifica aguas abajo: las cabeceras HTTP heredadas, algunas pasarelas de SMS y los pipelines de logs que truncan por bytes pueden seguir dependiendo de contenido solo ASCII.
¿Qué ocurre si el transporte no puede llevar caracteres no ASCII?
Mantén el escape. Cuando JSON se incrusta dentro de otra cadena JSON, o viaja por un canal hostil a los caracteres no ASCII, el escape evita conflictos de comillas y impide que los caracteres multibyte se partan.