寫這篇文章的緣由是我使用 reqeusts 庫請求接口的時候, 直接使用請求參數里的 json 字段發送數據, 但是服務器無法識別我發送的數據, 排查了好久才知道 requests 內部是使用 json.dumps 將字符串轉成 json 的, 而 json.dumps 默認情況下會將 非ASCII 字符轉義, 也就是我發送數據中的中文被轉義了, 所以服務器無法識別. 這篇文章雖然是 json.dumps 問題的總結, 但也會涉及到 字符編碼 問題, 所以就簡單先說一下 字符編碼.
Python 中的字符編碼
在 Python3 中, 字符 在內存中是使用 Unicode 存儲的, 常規的字符使用 兩個字節 表示, 一些很生僻的字符就需要 四個字節. 默認使用 Unicode 存儲是什么意思呢, 那就是例子來解釋一下, 在 Python Shell 中輸入以下字符串 '/u4e2d/u6587', 觀察其輸出:
In [51]: '/u4e2d/u6587'Out[51]: '中文'
輸出的為 中文 兩個字. 其實 /u4e2d 和 /u6587 分別表示 中 和 文 的 Unicode 編碼(術語稱為 碼點)的 十六進制 表示, 在 Python3 中以 /u 開頭的字符串被解析為 Unicode 字符, 然后通過其十六進制 碼點 解析出具體的字符, 所以 中文 的內存表示即為 /u4e2d/u6587.
獲取字符 Unicode 碼點
標準庫提供了 ord 函數輸出一個字符的 Unicode 碼點, 使用 chr 函數將 碼點 轉換成 字符, 下面是示例:
In [54]: ord('中')Out[54]: 20013In [56]: chr(20013)Out[56]: '中'
輸出的 碼點 是使用 十進制 表示的, 可以使用以下代碼將整數格式化成十六進制字符串:
'{0:04x}'.format(20013)
使用 json.dumps
有了前面的鋪墊, 就可以來說說 json.dumps 了. 下面以一個例子展開:
In [121]: json.dumps('中文', ensure_ascii=True)Out[121]: '"http://u4e2d//u6587"'In [122]: json.dumps('中文', ensure_ascii=False)Out[122]: '"中文"'
可以看到, 在 ensure_ascii 為 True 的情況下, 中文 被編碼成了 Unicode 碼, 為 False 才能正常顯示, 但是這跟 ASCII 有什么關系呢? 來看一下官方文檔 對這個參數的解釋:
如果 ensure_ascii 是 true (即默認值),輸出保證將所有輸入的非 ASCII 字符轉義。如果 ensure_ascii 是 false,這些字符會原樣輸出。
現在稍微明白了, 在 ensure_ascii 為 True 的情況下, 如果字符串中存在 非ASCII 字符就將其轉義, 根據結果可以知道這個字符被轉義為 Unicode 碼并格式化成了一個字符串, 注意 "http://u4e2d//u6587" 與 "/u4e2d//u6587" 是不同的, 前者是長度為 12 的字符串, 后者會被 Python 直接解析為 中文, 長度為 2. 這也就是我一開始出現的問題, 直接將轉義的字符串在網絡上傳輸可能會無法被識別. 比如 中文 被轉義成 //u4e2d//u6587, 而服務器如果不知道它是被轉義過的字符串, 那它就是一個長度為 12 的普通字符串, 肯定會識別出錯. 而將 ensure_ascii 設為 False 就不會進行轉義, 使用原始字符.
識別轉義字符
如果服務器收到數據后發現是被轉化過的, 那怎么識別呢? 其實被轉義字符串與使用 unicode_escape 對字符串進行編碼再使用 utf-8 進行解碼的結果一致, 代碼如下:
In [129]: msgOut[129]: '中文'In [130]: msg.encode('unicode_escape').decode('utf-8')Out[130]: '//u4e2d//u6587'
所以識別只要反過來使用 utf-8 編碼再使用 unicode_escape 解碼就可以了.
|
新聞熱點
疑難解答