乙個BOM頭引發的血案!!!

2021-07-30 21:47:15 字數 2691 閱讀 6563

今天在公司做專案的時候,伺服器一直報500錯誤,檢查**以後**沒有任何問題,糾結了很長時間,最後出在了**裡面有了bom頭導致了專案不能執行,特此記錄一下,以免大家跟我犯同樣的錯誤。

事情的起源是一段很普通的**:

[php]view plain

copy

print

?<?php   

session_start();  

$_session

['test'

] = 

'test'

;  $_session

['name'

] = 

'name'

;  $data

= serialize(

$_session

);  

...更多後續**  

?>  

沒有問題,很簡單的一段設定session的**。

但是執行後卻報錯:

cannot send session cache limiter - headers already sent (output started at...) on line ...

報錯資訊很明顯,就是在session_start()之前有了輸出,導致後面的header傳送失敗。

因為很多情況下<?php   標籤之前空格也會被當做header傳送出去的,所以先檢查這個。

仔細檢查一下,沒有空格,沒有echo ,沒有print等導致輸出的問題,那麼到底是什麼問題呢?

應該有很多人都想到了,bom頭。

對,這裡就是bom頭搞的鬼。

那麼什麼是bom頭呢?

[plain]view plain

copy

print

?bom: byte order mark  

就是乙個位元組順序標籤,類似乙個標記,又叫簽名,   

bom簽名的意思就是告訴編輯器當前檔案採用何種編碼,方便編輯器識別,但是bom雖然在編輯器中不顯示,但是會產生輸出,就像多了乙個空行。  

一般的編碼集中並不會出現bom頭,unicode編碼集中會出現。  

常見的bom頭是:【摘錄自:  

utf-8    ║ ef bb bf   

utf-16le ║ ff fe (小尾)  

utf-16be ║ fe ff (大尾)  

utf-32le ║ ff fe 00 00   

utf-32be ║ 00 00 fe ff  

為什麼bom頭會產生亂碼?  

【摘錄自:  

有bom頭的儲存或者位元組流,它一定是unicode字符集編碼。到底屬於那一種(utf-8還是utf-16或是utf-32),通過頭可以判斷出來。  

由於已經說過utf-16,utf-32不指定bom頭,解析程式預設就認為是ansi編碼,出現亂碼。而utf-8指定或者不指定程式都可判斷知道對於的字符集編碼。  

問題就出在這裡,可能有的應用程式(ie6瀏覽器),它就認為如果utf-8編碼,就不需要指定bom頭,它可以自己判斷,相反指定了bom頭,它還會出現問題  

(因為它把頭當utf-8解析出現亂碼了)。這裡不截圖了,cnblogs裡面談這個比較多,目前ie6會出現問題。其它ie7+,firefox,chrome不會出現,會忽略掉bom頭。  

統一解決辦法是:存為utf-8編碼是,不需要加入bom頭,其它utf-16,utf-32加入。  

知道了這個,解決方案就很明顯了:把utf-8的bom頭去掉即可。

方式就是檔案編碼格式選擇utf-8無bom。

另摘錄乙個網上找來的去除bom頭的**:

[php]view plain

copy

print

?<?php   

if(isset(

$_get

['dir'

]))else

$auto

= 1;  

checkdir($basedir

);  

function

checkdir(

$basedir

)else

}  }  closedir

($dh

);  

}  }  

function

checkbom (

$filename

) else

}  elsereturn ("bom not found."

);  

}  function

rewrite (

$filename

,$data

)   

?>  

另外乙個常見的bom頭的地方時xml檔案。解析失敗的話,有很大一部分原因是這個。

error on line 1 of document  : content is not allowed in prolog. nested exception: content is not allowed in prolog.

此時只要去掉bom頭就行了。

解決的辦法

用notepad++

裡面的那個編碼 轉為無bom即可。。

希望可以幫到大家

乙個memset引發的血案

前幾天做了一道bst題,提交了幾次都是wa,今天抽空拿了出來仔細瞧瞧總算被我發現禍頭根源.總結原因還在於自己對memset不太了解,以前用對估計也是瞎貓撞見死耗子 memset的介紹 void memset void buffer,int ch,size t count buffer 指向某段記憶體...

乙個分號引發的「血案」

再多的表情也無法詮釋我現在的心情!a b for matrices 這是很水的一道題,然而卻整整折騰了我2個多小時。從晚上6點多開始,花了沒幾分鐘就把 敲好了,可是資料一測,竟然不對,然後就開始找問題,找了很久,我竟然都還沒看出問題在哪,越找心裡越不爽,這麼做明明對的呀,一執行怎麼就錯了呢?一直到了...

乙個strlen引發的血案

部分測試 原來是這樣的 int decryptrelation aesdecryptfromfiletobytes const std string in file path,unsigned char out data,const char aes encrypt key,int in data ...