2016-03-08 33 views
0

我有一個字符編碼,這可能在一定程度上有問題的運行一些老的網站。但是,儘管如此,他們仍然運行良好,我還沒有努力改變它。然而,從昨天晚上突然出現的編碼問題在這些頁面上顯現出來(這意味着所有有問題的字符始終都顯示正常,現在被「?」 - 符號替代)。我測試了最新版本的IE,FF和Chrome。爲什麼網站編碼的顯示更改爲「過夜」?

正如我已經在HTML或其他網站的資源沒有改變我很好奇什麼引發了顯示我的網站的變化?

更多信息這也許可以幫助:

- 我使用的共享虛擬主機爲這些網站。雖然我沒有找到一個通知,告訴的話,目前我考慮一些改變,這樣或許是一個可能的原因主控器,雖然我不知道什麼樣的變化會導致上述效果。

- 上述變化只發生在網上的版本,但不是在我的本地版本(在不同的可配置的網絡服務器上運行)也有同樣的網頁代碼(所以地方看起來還是「精」的方式之前)。但是,當我經常訪問現場和本地版本時,我無法將現有的差異歸結爲緩存問題。

- 網站顯示的文本在保存爲ANSI格式的「.php」文件中的HTML/PHP代碼中被硬編碼。我只是爲了更好地理解問題所在而告訴這個問題(儘管我並不尋求提示如何解決我的編碼問題......)。定義部分開始,如下所示:在黑暗中

<!DOCTYPE html> 
<html> 
<head> 
<title>some title</title> 
<meta charset="iso-8859-1"> 
+0

* 「我有一個字符編碼運行一些老網站」 * - 嗯,嗯,是的,每一個* *的網站 「編碼」 ... – deceze

+0

」運行...這可能在某種程度上是有問題的「:-) – Wooz

+1

您的網站運行編碼的事實值得懷疑? ; O) – deceze

回答

1

刺:你的共享主機已經更新了他們的服務器/配置,現在您的網頁使用默認的HTTP服務Content-Type頭宣告網頁的編碼方式是UTF-8 。由於您顯然沒有自己設置更具體的標題,瀏覽器現在會誤解頁面內容。

配置Web服務器以設置正確的Content-Type標題(可能在.htaccess文件中有一些指令,請詢問您的主機),或者在PHP中使用header()調用。

Handling Unicode Front To Back In A Web AppUTF-8 all the way through

+0

嗯,這可能是一個很好的提示,即使我想是我的供應商的有點霸道把它帶到他們身上來定義我的編碼。我需要檢查之前,我可以說,如果這是原因。但我認爲,如果這是由供應商設置的內容類型將覆蓋我的 ?! – Wooz

+0

是的,HTTP標頭優先於HTML元素。您應該始終確保您的HTTP標頭正確表示文檔的編碼;依靠meta元素永遠不是一個好主意。 – deceze

+0

嗯,看來你是對的,至少如果我正確讀取應答頭:「連接:保持活躍;內容編碼:gzip;內容長度:4905;的Content-Type:text/html的;字符集= UTF-8 ;日期星期二,2016年3月8日14點34分23秒格林尼治標準時間;服務器Apache的,因人而異的Accept-Encoding」 - 你spontanously知道什麼是‘因人而異接受編碼’代表什麼嗎?對於以前設置的「charset = UTF-8」有沒有什麼不同?如果你不知道我可以在晚些時候自己谷歌它當然。 – Wooz

相關問題