Pourquoi le chinois devient \u4e2d\u6587
L’essentiel : Un échappement \u4e2d\u6587 est de l'Unicode légal, pas un échec d'encodage. Le vrai mojibake est différent, et les distinguer décide de ce qu'il faut réellement corriger.
L'essentiel : traitez une sortie \uXXXX comme de l'échappement légal, confirmez qu'elle fait un aller-retour via JSON.parse, et désactivez la sérialisation ASCII pur comme ensure_ascii=False quand vous voulez du chinois lisible ; ne gardez l'échappement que pour les transports qui ne peuvent pas porter du non-ASCII.
Parce qu'il a été échappé, pas endommagé.
JSON.parse('"\\u4e2d\\u6587"') // "中文"
\u4e2d est 中 et \u6587 est 文. Ce sont des séquences d'échappement légales ; tout parseur les restaure. Rien n'est cassé — c'est simplement illisible dans les journaux, les diffs et les captures de paquets.
Qui fait l'échappement
| Outil | Défaut | Interrupteur |
|---|---|---|
Python json.dumps |
Échappe (ensure_ascii=True) |
ensure_ascii=False |
JavaScript JSON.stringify |
Pas d'échappement | — |
| Java Jackson | Pas d'échappement | Facultatif |
PHP json_encode |
Pas d'échappement depuis 5.4 | — |
Go encoding/json |
Pas d'échappement | — |
Python est de loin la source la plus courante. Le défaut existe pour une raison : une sortie ASCII pur survit à tout transport. Le coût est que chaque caractère non-ASCII devient six caractères.
Échappement contre mojibake
Échappement : \u4e2d\u6587, correspondant à \uXXXX. Causé par les réglages du sérialiseur.
Mojibake : 测试, 涓枃. Causé par l'écriture d'octets UTF-8 et leur lecture en Latin-1 ou GBK.
Test rapide : collez le texte dans une console de navigateur comme JSON.parse('"…"'). S'il revient lisible, c'était de l'échappement. S'il échoue ou reste brouillé, c'est une incompatibilité d'encodage — et la correction est d'aligner les encodages, pas de toucher au sérialiseur.
Le désactiver
json.dumps(data, ensure_ascii=False)
Vérifiez ensuite en aval : certains systèmes hérités reposent réellement sur un transport ASCII seulement, notamment les passerelles SMS et les anciens relais de messagerie.
Quand l'échappement est le bon choix
- Les transports hostiles au non-ASCII (en-têtes HTTP hérités, certaines passerelles SMS)
- Le JSON imbriqué dans une autre chaîne JSON, où l'échappement réduit les conflits de guillemets
- Les pipelines de journaux qui tronquent par octets et diviseraient un caractère multi-octets
Sinon, préférez la lisibilité et désactivez-le.
FAQ
Pourquoi Python échappe-t-il le chinois par défaut ?
Parce que ensure_ascii=True est le défaut, ce qui garantit une sortie ASCII pur qui survit à tout transport. Le coût est que chaque caractère non-ASCII devient six caractères.
Faut-il désactiver ensure_ascii ?
Désactivez-le quand la lisibilité compte. Vérifiez ensuite en aval — les en-têtes HTTP hérités, certaines passerelles SMS et les pipelines de journaux qui tronquent par octets peuvent encore dépendre d'un contenu ASCII seulement.
Que se passe-t-il si le transport ne peut pas porter du non-ASCII ?
Gardez l'échappement. Quand du JSON est imbriqué dans une autre chaîne JSON, ou voyage sur un canal hostile au non-ASCII, l'échappement évite les conflits de guillemets et empêche les caractères multi-octets d'être divisés.