2011-09-22 58 views
3

我正在使用JSON和cURL在兩臺服務器之間實現通信。問題在於,有時候會有BOM(字節順序標記),在JSON回覆中的開頭括號之前附加。我已經設法修剪它併成功解析了JSON字符串,但考慮到JSON是由我自己的代碼生成的,我不知道該BOM來自哪裏。我使用json_encode()生成回覆和標題()+回聲來打印它,只要我不能告訴,json_decode()不會產生任何物料清單。相應的.php文件以UTF-8編碼,並且沒有BOM(根據Notepad ++)。除了cURL之外,我還嘗試使用Chrome和Python(urllib2)執行請求。儘管Chrome根本沒有註冊任何物料清單,但python經常無法解析傳入的JSON。BOM在JSON回覆中隨機出現

那麼,有沒有在使用echo一些細微之處,不知何故會產生這樣的結果?我應該從哪裏開始尋找問題的根源以及可能的解決方案?

+0

您的JSON是否包含任何多字節字符?如果你沒有明確地提出BOM,那麼我可以想到的唯一原因就是如果PHP由於某種原因確定有必要在其中存在......此外,出於興趣,什麼是相關的PHP版本? – DaveRandom

+0

不,JSON回覆根本不包含多字節字符。我正在使用PHP 5.3.8 – Xifax

+0

你是否在回聲之前將JSON轉儲到文件中? – DaveRandom

回答

1

我有同樣的問題。我從PHP輸出json,並在頁面頂部包含其他類文件。這些文件不會輸出任何內容,但是當它們被包含時,我得到的字節順序標記與我包含文件一樣多。所以如果我有4個包含,我的JSON開始時也有4個BOM。

我確定包括沒有打印任何數據,並有PHP的標籤之外沒有雜散回車。我嘗試了諸如「application-json」等標題,但沒有成功。

最後,我簡單地在記事本++中打開每個PHP文件,進入「編碼」並將其從UTF-8更改爲ANSI,然後保存。這就是讓它工作並返回有效的json所需的一切。我根本沒有更改PHP的代碼。

這個解決方案仍然感覺不夠理想。由於我們不從這些包含的文件輸出任何內容,因此不應該有任何影響。

+1

這就是PHP解釋器的工作原理。任何不在'<?php'和'?>'內的內容都會逐字輸出。 BOM正好在文件的開頭(3個第一個字節),所以在'<?php'之前。這就是它出現的原因,儘管在這樣的文件中沒有其他輸出。請記住,您始終可以使用PHP在您的源文件中查找BOM並將其刪除;) – Mchl

+0

只需關閉PHP結束標記即可。這也可以防止「標題已發送」的問題。 – taco

+0

使用「沒有BOM的UTF-8」可以爲您提供更多更好的服務。你不希望你的源代碼被編碼在一個不起眼的ANSI代碼頁中,只是爲了刪除BOM。 –