關於windows下程式開發的中文亂碼問題小結

標籤：檢查   傳輸   無效   內容   color   解析   中文   not   文章   

筆者遇到的問題背景：

windows 下使用notepad++6.7 ，ftp串連遠程ubuntu主機，在本地建立遠程主機檔案，編輯後上傳出現中文亂碼。

 

筆者最開始不明白問題出在哪，因為設定了在notepad++中預設使用UTF-8編碼格式進行建立檔案，但依舊無效。

筆者一步步探索問題：

1. 建立一個檔案，寫入純英文html文本後上傳至ubuntu主機，vi ：set fileencoding顯示此時為utf-8編碼
2. 上述檔案新增幾個中文，儲存後上傳至ubuntu主機，這個時候提示fileencoding變成了latin1編碼，相應的中文部分就變成了亂碼
3. 網上有很多人說設定一下meta標籤，就是最常見的charset=utf-8這個屬性，我也進行了嘗試，宣告失敗，沒有解決亂碼問題。

我覺得問題出現了，一個檔案，沒寫中文前是utf-8編碼，寫入檔案後是latin1編碼，這就是問題的關鍵。

一頓百度之後發現，在notepad++，選項卡中有一個“格式(M)”，其中有很多選項：其中主要有兩個大塊：以XXX格式編碼，轉為XXX格式編碼，這就是解決問題的關鍵所在。

 

結合筆者以前遇到過一些關於中文亂碼，讓很多網友頭疼不已的問題，需要明白的道理總結如下：

內容涉及windows作業系統，linux作業系統以及瀏覽器的解析三個部分。

第一、要明白該問題是windows上預設的字元編碼與Linux上的字元編碼不同導致的，一般前者是ANSI，後者是UTF-8；

在不同平台上文本顯示的亂碼問題是因為作業系統之間預設的字元編碼不同造成的，上面的例子，純英文文本，ANSI編碼和UTF-8編碼可以說是等價的，沒有問題。

但是涉及到中文編碼時，ANSI是不支援的，或者說與UTF-8的編碼是不同的。一份ANSI編碼的文本送給Linux，它用UTF-8格式來解開，結果是解除一對亂碼。

另外，windows和linux同樣使用UTF-8對文本進行編碼時，略有區別，這就是有BOM和無BOM的區別（具體參看其他文章），Linux無BOM。

　　總結：

1. 為了使得兩個系統平台的檔案能夠正常無縫顯示，很大的一個關鍵點是：windows使用UTF-8編碼（無BOM格式）來儲存檔案或者用UTF-8編碼來儲存（別用其他編碼，使用其他編碼儲存中文，假設用ANSI儲存，想轉為別的碼時，因為本身已經亂碼，再轉很可能也是亂碼）
2. 當在檔案要上傳至Linux主機上時，要做一次檢查，將檔案轉成UTF-8（無BOM）再傳上去，確保完全沒問題。

 

第二、meta標籤，就是最常見的charset=utf-8這個屬性的問題

這個問題造成的亂碼，其實來自於文字檔本身的編碼和瀏覽器解析時使用的編碼不同而導致的，這與第一點造成的亂碼不是同一個概念。

• 舉例1：訪問一個UTF-8格式的網頁文本，該文本沒有指定<meta charset=utf-8>，很可能遇到瀏覽器預設以GBK編碼對網頁進行解析。結果：以GBK解碼一份以UTF-8編碼的文本，亂碼。
• 舉例2：訪問一個一個UTF-8格式的網頁文本，該文本指定<meta charset=utf-8>，很可能遇到瀏覽器預設以GBK編碼對網頁進行解析，此時遇到meta，懂得要以utf-8來解析它。結果：以UTF-8正確解析了一份以UTF-8編碼的文本，沒問題。
• Ps:例子2也可能還是對中文解析出亂碼。這是為什嗎？那是因為，服務端的那份UTF-8編碼的檔案，在有中文的地方，本身就已經是亂碼！原因是什嗎？是的，這種情況下，就可以將兩個中文亂碼的原因聯絡起來了。在windows上編寫完代碼上傳至服務端主機時，就已經因為兩個系統的編碼矛盾而致使中文亂碼了，當瀏覽器發起訪問時，不管解析使用的編碼是否正確，錯誤的編碼再怎麼解析，都是錯的，這就是問題的由來。

 

總結：不同的系統之間傳輸檔案，注意編碼要使用正確的，確保檔案本身沒有錯；用戶端訪問時，用meta告知瀏覽器檔案的編碼，確保解析檔案沒有錯，有這兩步，一般不會都能解決中文亂碼問題！

 

關於windows下程式開發的中文亂碼問題小結