1. 問題描述

在調用PHP後臺接口發現後臺接口返回的json字符串Gson一直解析不通過:

List<Region> districts = null;
        if (!TextUtils.isEmpty(myString))
        {
            Gson gson = new Gson();
            try
            {
    districts = gson.fromJson(myString, new TypeToken<List<Region>>()
                {}.getType());
            }
            catch (Exception e)
            {
                e.printStackTrace();
            }
        }
 

異常提示的大概內容是：第一行第一列期望對象數組開頭,實際卻是字符串開頭
以上myString 是個json字符串，內容如下：

2. 分析過程

(1) 將以上的json字符串復制到json在線檢查,也是沒通過
(2) json字符串保存在文件,在chrome瀏覽器打開此文件也沒有顯示json排版的格式;
(3) 仔細檢查格式,沒發現什麽問題，根據異常提示的信息，很有可能是第一行第一列有特殊字符存在
(4) 仔細在EditPlus 編輯器查看上面的json字符串，發現 [ 很特別，不是正常的總括號
(5) 如果手動修改成正常的 [ , 復制到JSON在線檢查裏面，json合格，通過！
(6) 修改前的json字符串保存成一個文件，修改後的json字符串保存成一個文件
(7)為了進一步看出是這第一個什麽字符，我改用了UltraEdit編輯器分別打開修改前的文件 和修改後的文件

然後分別 以16進制查看(編輯->16進制函數 -> 16進制編輯)

有特殊字符串的json字符串errorcode_region.txt 文件16進制查看內容如下：

沒有特殊字符，修改後正常的json字符串 new_regions.txt 文件 16進制查看內容如下：

通過比較發現在正常的 [ 符號 多的特殊字符 16進制是 EF BB BF

通過 查看相關資料 它是 BOM (Byte Order Mark，字節序標記)的 UTF-8編碼。就是說此json 字符串 是 帶了 BOM的UTF-8 格式的。

以下是UTF-8 BOM的一些說明，參考 ：UTF-8有BOM和無BOM的區別

UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。

UTF- 8編碼的文件中，BOM占三個字節。如果用記事本把一個文本文件另存為UTF-8編碼方式的話，用UE打開這個文件，切換到十六進制編輯狀態就可以看到開 頭的FFFE了。這是個標識UTF-8編碼文件的好辦法，軟件通過BOM來識別這個文件是否是UTF-8編碼，很多軟件還要求讀入的文件必須帶BOM。可 是，還是有很多軟件不能識別BOM。

在Firefox早期的版本裏，擴展是不能有BOM的，不過Firefox 1.5以後的版本已經開始支持BOM了。現在又發現，PHP也不支持BOM。PHP在設計時就沒有考慮BOM的問題，也就是說他不會忽略UTF-8編碼的文件開頭BOM的那三個字符。

3. 解決辦法

既然知道了問題原因：PHP後臺返回的UTF-8格式的JSON字符串開頭帶了BOM，那解決辦法就是 去掉 這個BOM。

怎樣去掉呢？ 不可能在客戶端去掉，應該是在PHP後臺根據接口名字，找到該接口對應的代碼所在的PHP文件，將此PHP文件保存格式為UTF-8 無BOM 格式。

(1) 用EditPlus 另存為的時候，編碼選擇 UTF-8

如果選擇的是 UTF-8 +BOM, 那就包含了 BOM

註: 用EditPlus 打開帶BOM的文件的時候，會在底部顯示 UF-8+

打開不帶BOM的文件的時候，會在底部顯示 UTF-8

(2) 用UltraEdit 另存為的時候，編碼選擇 UTF-8 無BOM

如果選擇的是 UTF-8 , 那就包含了 BOM

解決PHP服務端返回json字符串有特殊字符的問題