關於windows下程序開發的中文亂碼問題小結
筆者遇到的問題背景：
windows 下使用notepad++6.7 ，ftp連接遠程ubuntu主機，在本地創建遠程主機文件，編輯後上傳出現中文亂碼。
筆者最開始不明白問題出在哪，因為設置了在notepad++中默認使用UTF-8編碼格式進行新建文件，但依舊無效。
筆者一步步探索問題：
- 新建一個文件，寫入純英文html文本後上傳至ubuntu主機，vi ：set fileencoding顯示此時為utf-8編碼
- 上述文件新增幾個中文，保存後上傳至ubuntu主機，這個時候提示fileencoding變成了latin1編碼，相應的中文部分就變成了亂碼
- 網上有很多人說設置一下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。
總結：
- 為了使得兩個系統平臺的文件能夠正常無縫顯示，很大的一個關鍵點是：windows使用UTF-8編碼（無BOM格式）來保存文件或者用UTF-8編碼來保存（別用其他編碼，使用其他編碼保存中文，假設用ANSI保存，想轉為別的碼時，因為本身已經亂碼，再轉很可能也是亂碼）
- 當在文件要上傳至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下程序開發的中文亂碼問題小結