Mengapa Cina bertukar menjadi \u4e2d\u6587
Inti pati: Escape \u4e2d\u6587 ialah Unicode yang sah, bukan kegagalan pengekodan. Mojibake sebenar kelihatan berbeza, dan membezakan kedua-duanya menentukan apa yang sebenarnya perlu anda betulkan.
Pokoknya: anggap output \uXXXX sebagai escape yang sah, sahkan ia berputar balik melalui JSON.parse, dan matikan pensirian ASCII tulen seperti ensure_ascii=False apabila anda mahu Cina yang boleh dibaca; kekalkan escape hanya untuk pengangkutan yang tidak boleh membawa bukan ASCII.
Kerana ia di-escape, bukan dirosakkan.
JSON.parse('"\\u4e2d\\u6587"') // "中文"
\u4e2d ialah 中 dan \u6587 ialah 文. Ini ialah jujukan escape yang sah; mana-mana penghurai memulihkannya. Tiada apa yang rosak — ia hanya tidak boleh dibaca dalam log, perbezaan dan tangkapan paket.
Siapa yang melakukan escape
| Alat | Lalai | Suis |
|---|---|---|
Python json.dumps |
Meng-escape (ensure_ascii=True) |
ensure_ascii=False |
JavaScript JSON.stringify |
Tiada escape | — |
| Java Jackson | Tiada escape | Pilihan |
PHP json_encode |
Tiada escape sejak 5.4 | — |
Go encoding/json |
Tiada escape | — |
Python jauh lebih biasa sebagai sumber. Lalai itu wujud atas sebab: output ASCII tulen bertahan dalam mana-mana pengangkutan. Kosnya ialah setiap aksara bukan ASCII menjadi enam aksara.
Escape berbanding mojibake
Escape: \u4e2d\u6587, sepadan dengan \uXXXX. Disebabkan oleh tetapan pensirian.
Mojibake: 测试, 涓枃. Disebabkan oleh menulis bait UTF-8 dan membacanya sebagai Latin-1 atau GBK.
Ujian pantas: tampal teks ke dalam konsol pelayar sebagai JSON.parse('"…"'). Jika ia kembali boleh dibaca, ia adalah escape. Jika ia gagal atau kekal bergelut, ia ialah ketidaksepadanan pengekodan — dan pembetulannya ialah menyelaraskan pengekodan, bukan menyentuh pensirian.
Mematikannya
json.dumps(data, ensure_ascii=False)
Kemudian sahkan hiliran: sesetengah sistem warisan benar-benar bergantung pada pengangkutan ASCII sahaja, terutamanya gerbang SMS dan geganti mel lama.
Bila escape ialah pilihan yang betul
- Pengangkutan yang bermusuhan dengan bukan ASCII (pengepala HTTP warisan, sesetengah gerbang SMS)
- JSON yang bersarang di dalam rentetan JSON lain, di mana escape mengurangkan konflik petikan
- Saluran log yang memotong mengikut bait dan akan memecahkan aksara berbilang bait
Jika tidak, utamakan kebolehbacaan dan matikannya.
Soalan Lazim
Mengapa Python meng-escape Cina secara lalai?
Kerana ensure_ascii=True ialah lalai, yang menjamin output ASCII tulen yang bertahan dalam mana-mana pengangkutan. Kosnya ialah setiap aksara bukan ASCII menjadi enam aksara.
Patutkah saya mematikan ensure_ascii?
Matikannya apabila kebolehbacaan penting. Kemudian sahkan hiliran — pengepala HTTP warisan, sesetengah gerbang SMS dan saluran log yang memotong mengikut bait mungkin masih bergantung pada kandungan ASCII sahaja.
Apa yang berlaku jika pengangkutan tidak boleh membawa bukan ASCII?
Kekalkan escape. Apabila JSON dibenamkan di dalam rentetan JSON lain, atau bergerak melalui saluran yang bermusuhan dengan bukan ASCII, escape mengelakkan konflik petikan dan menghalang aksara berbilang bait daripada dipecahkan.