背景

程序員一提到編碼應該都不陌生，像gbk、utf-8、ascii等這些編碼更是經常在用，但時不時也會出個亂碼問題，解決這個問題的方法大部分都是先google和baidu一下，最后可能在某個犄角旮旯里找到一點信息，然后就機械的按部就班的模仿下來,結果問題可能真就迎刃而解了,然后就草草了事,下回遇到相似的問題,可能又是重復上面的過程。很少有人有耐心去花精力弄明白這寫問題的根本原因，以及解決這些問題的原理是什么。這篇文章就是通過一個實際案例,試著去講清楚什么是編碼,亂碼又是怎么產生的,以及如何解決。該案例是從lua_cjson.c這個庫開始的,對這個庫不熟悉也沒關系,也不需要熟悉它,我們只是借用它來說明亂碼問題,只需要跟著文章的思路走就可以。

前段時間同事在作一個新項目的時候用到了lua_cjson.c這個庫(以下簡稱cjson)，將json串轉換成LUA本地的數據結構,但是在使用的過程中出現了中文亂碼問題，奇怪的是只有那么幾個字是亂碼，這其中就包括”朶”字，其他字一切正常。經了解json串用的是GBK編碼，那問題就來了，為什么用gbk編碼會出現這個問題，原因是什么？又應該怎么解決這個問題？

要解釋清楚這個問題，首先我們來看看json串都有哪些要求。

JSON規范

json全稱JavaScript Object Notion是結構化數據序列化的一個文本，可以描述四種基本類型(strings,numbers,booleans and null)和兩種結構類型(objects and arrays)。

RFC4627中有這樣一段話

A string is a sequence of zero or more Unicode characters.

字符串有零個或多個unicode字符序列組成.

在這里稍微解釋下什么是unicode字符。我們都知道ascii字符有字母、數字等,但是他收錄的字只有一百多個。比如漢字就不是ascii字符，但是unicode收錄了漢字,所以漢字可以是unicode字符。這里要說明的是unicode字符其實就是一些符號。

現在另一個問題出來了，在json文本中應該怎么表示這些字符。

在規范的Encoding片段是這樣說的

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8。

JSON文本SHALL把unicode字符編碼。默認使用utf-8編碼。

我們看到在這里用到了SHALL[RFC2119]這個關鍵字，也就是說字符必須被編碼后才能作為JSON串使用。而且默認使用utf-8編碼。

如何判斷使用的是那種unicode編碼呢?

Since the first two characters of a JSON text will always be ASCII characters[RFC0020],

it is possible to determine whether an octet stream is UTF-8、UTF-16(BE or LE), or

UTF-32(BE or LE)by looking at the pattern of nulls in the first four octets.

由于json文本的前兩個字符(注意這里說的是字符,不是字節)一定是ASCII字符,因此可以從一個字節

流的前四個字節(注意是字節)中判斷出該字節流是UTF-8、UTF-16(BE or LE)、or UTF-32(BE or LE)編碼。

00 00 00 xx UTF-32BE? (u32編碼大端)

xx 00 00 00 UTF-32LE? (u32編碼小端)

00 xx 00 xx UTF-16BE? (u16編碼大端)

xx 00 xx 00 UTF-16LE? (u16編碼小端)

xx xx xx xx UTF-8 ? (utf-8編碼)

ps:

u32用32位的4字節整數表示一個字符；

u16用16位的2字節整數表示一個字符,如果2字節表示不了,就用連續兩個16位的2字節整

數表示，所以就會出現u16編碼中有4個字節表示一個字符的情況，和u32的四字節不一

樣的是,該字符在u16中的前兩個字節和后兩個字節之間不會有字序的問題。

utf-8用多個8位的1字節序列來表示一個字符,所以沒有字序的問題.

截止到現在我們沒有看到任何關于可以使用GBK編碼的信息,難道json文本就不能用gbk編碼嗎,如果真的不能用的話，那為什么cjson不是把所有的gbk編碼解釋稱亂碼,而是只有某幾個字是亂碼.

在規范中對json解析器有這樣一段描述:

A JSON parser transforms a JSON text into another representation.

A JSON parser MUST accept all texts that conform to the JSON grammar.

A JSON parser MAY accept non-JSON forms or extensions.

json解析器可以將一個json文本轉換成其他表示方式。

json解析器MUST接受所有符合json語法的文本.

json解析器MAY接受非json形式或擴展的文本.

亂碼的原因

從規范對對解析器的描述可以看到,規范并沒有要求解析器必須對文本的編碼方式做校驗,而且解析器也可以有選擇的去接受非json形式的文本。

現在我們再來看看cjson解析器是如何做的，在cjson開頭的注釋中說了這么一句話:

Invalid UTF-8 characters are not detected and will be passed untouched。

If required, UTF-8 error checking should be done outside this library。

發現無效的UTF-8編碼會直接放過,如果有必要對UTF-8編碼的檢查應該在該庫的之外。

說的很清楚,對非utf8編碼直接放過，不做任何檢查,所以用gbk編碼不符合規范,但又可以被解析的答案就出來了。那”朶”等這些字的亂碼問題又是怎么回事? 我們現在看看cjson對規范中的另外兩個編碼utf16、utf32是如何做的，然后再說亂碼問題.

在cjson解析方法的開始處是這么做的:

/* Detect Unicode other than UTF-8(see RFC 4627, Sec 3)

*

* CJSON can support any simple data type, hence only the first

* character is guaranteed to be ASCII (at worst:'"'). This is

* still enough to detect whether the wrong encoding is in use.

*/

if (json_len >=2 && (!json.data[0] || !json.data[1]))

luaL_error(1,"JSON parser does not support UTF-16 or UTF-32");

前面我們說過一個json串的前兩個字符一定是ascii字符,也就是說一個json串至少也的有兩個字節.所以這段代碼首先判斷json串的長度是不是大于等2,然后根據串的前兩個字節的值,是否有零來判斷該文本是否是非utf-8編碼。結果已經看到了，人家不支持規范上說的u16和u32編碼.

現在我們就來看看”朶”這個子是如何變成亂碼的，經過對cjson源碼的分析得知,cjson在處理字節流的時候當遇見’\’反斜杠時會猜測后一個字節應該是要被轉義的字符,比如\b、\r之類的字符,如果是就放行,如果不是,cjson就認為這不是一個正確的json格式,就會把這個字節給干掉,所以本來用兩個字節表示的漢子就硬生生的給掰彎了。

那”朶”字跟’\’反斜杠又有什么關系? 查詢這兩字符在編碼中的表示得出:

“朶” 0x965C

“\” 0x5C

這樣我們就看到”朶”字的低位字節和”\”字符相同,都是0x5C,如果這時候”朶”字后邊不是b、r之類的可以被轉移ascii字符,cjson就會把這個字節和緊跟其后的一個字節抹掉,所以亂碼就產生了。

那我們應該怎么解決這個問題,讓cjson可以順利的支持gbk編碼呢,首先我們看看gbk編碼是怎么回事,為什么會出現低位字節和ascii沖突的問題.

GB_編碼系列

先來了解一下GB系列的編碼范圍問題:

GB2312(1980)共收錄7445個字符，6763個漢字和682個其他字符。

每個漢字及符號用兩個字節表示,為了跟ascii兼容,處理程序使用EUC存儲方法。

漢字的編碼范圍

高字節: 0xB0 – 0xF7,

低字節: 0xA1 – 0xFE,

占用72*94=6768,0xD7FA – 0xD7FE未使用。

GBK共收錄21886個字符,采用一字節和雙字節編碼。

單字節表示范圍

8位: 0x0 – 0x7F

雙字節表示范圍

高字節: 0x81 – 0xFE

低字節: 0x40 – 0x7E、0x80 – 0xFE

GB18030收錄70244個漢字,采用1、2、4字節編碼。

單字節范圍

8位: 0x0 – 0x7F

雙字節范圍

高字節: 0x81 – 0xFE

低字節: 0x40 – 0xFE

四字節范圍

第一字節:0x81 – 0xFE

第二字節:0x30 – 0x39

第三字節:0x81 – 0xFE

第四字節:0x30 – 0x39

由于GB類的編碼都是向下兼容的，這里就有一個問題，因為GB2312的兩個字節的高位都是1,符合這個條件的碼位只有128*128=16384個。GBK和GB18030都大于這個數,所以為了兼容,我們從上面的編碼范圍看到,這兩個編碼都用到了低位字節的最高位可以為0的情況。

最終得出的結論就是,在GBK編碼中只要該字符是兩個字節表示,并且低位字節是0x5C的字符都會被cjson弄成亂碼.

解決方案:

1) 不要使用gbk編碼,將你的字符串轉換成utf-8編碼.

2) 對cjson源碼稍微做個改動,就是在每個字節到來之前先判斷該字節是否大于127,如果大于則將該字節個隨后的一個字節放過,否則交給cjson去處理。

總結

以上是生活随笔為你收集整理的json mysql乱码问题_JSON数据乱码问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。