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