linu中顯示中文亂碼的問題

linux中顯示中文亂碼的問題/seuxiaoqi/article/details/5577195分類:linux2010-05-1109:154586人閱讀評論（0）收藏舉報由于在windows下默認是gb編碼，而我的vim默認是utf-8（gedit默認也是utf-8）,所以打開會成亂碼。修改了一下配置文件，使vi支持gb編碼就好了。$vi~/.vimrclet&termencoding=&encodingsetfileencodings=utf-8,gbk$:wq再次打開vi,顯示就正常了。如果你需要在linux下面用到windows下的文件，拷貝上去后經(jīng)常發(fā)現(xiàn)中文顯示亂碼。。原因是Windows中默認的文件格式是GBK（gb2312）,而Linux一般都是UTF-8。比較繁瑣的方法是在windows下用程序把內(nèi)容轉(zhuǎn)換為utf-8編碼格式的,但是相當麻煩，而且遇到一個文件轉(zhuǎn)一回。下面介紹一下，在Linux中如何一勞永逸的解決這個問題,查看文件的編碼及如何進行對文件進行編碼轉(zhuǎn)換。查看文件編碼在Linux中查看文件編碼可以通過以下幾種方式:在Vim中可以直接查看文件編碼:setfileencoding即可顯示文件編碼格式。文件編碼轉(zhuǎn)換如果你只是想查看其它編碼格式的文件或者想解決用Vim查看文件亂碼的問題,那么你可以在~/.vimrc（在/etc目錄下面）文件中添加以下內(nèi)容：setencoding=utf-8fileencodings=ucs-bom,utf-8,cp936其中encoding是vim的默認顯示編碼格式，fileencodings是vim打開文件時檢測的編碼格式,存在這種類型的編碼即轉(zhuǎn)換為utf-8編碼。這樣，就可以讓vim自動識別文件編碼（可以自動識別UTF-8或者GBK編碼的文件）,其實就是依照fileencodings提供的編碼列表嘗試,如果沒有找到合適的編碼，就用latin-1（ASCII）編碼打開。在Vim中直接進行轉(zhuǎn)換文件編碼，比如將一個文件轉(zhuǎn)換成utf-8格式（不好用）:setfileencoding=utf-83.iconv轉(zhuǎn)換，iconv的命令格式如下：（未用）iconv-fencoding-tencodinginputfile比如將一個UTF-8編碼的文件轉(zhuǎn)換成GBK編碼iconv-fGBK-tUTF-8file1-ofile2文件名編碼轉(zhuǎn)換:從Linux往windows拷貝文件或者從windows往Linux拷貝文件，有時會出現(xiàn)中文文件名亂碼的情況，出現(xiàn)這種問題的原因是因為，windows的文件名中文編碼默認為GBK,而Linux中默認文件名編碼為UTF&由于編碼不一致，所以導致了文件名亂碼的問題，解決這個問題需要對文件名進行轉(zhuǎn)碼。在Linux中專門提供了一種工具convmv進行文件名編碼的轉(zhuǎn)換，可以將文件名從GBK轉(zhuǎn)換成UTF-8編碼,或者從UTF-8轉(zhuǎn)換到GBK。首先看一下你的系統(tǒng)上是否安裝了convmv,如果沒安裝的話用在http://www.j3e.de/linux/convmv/convmv-1.14.tar.gz下載，然后在windows下面解壓縮用winscp上傳真?zhèn)€目錄，之后進入此目錄執(zhí)行makeinstall命令，之后用convmv命令測試是否安裝成功，若顯示一些命令提示則表示成功了。安裝。下面看一下convmv的具體用法：convmv-f源編碼-t新編碼［選項］文件名常用參數(shù)：-r遞歸處理子文件夾--notest真正進行操作，請注意在默認情況下是不對文件進行真實操作的，而只是試驗。--list顯示所有支持的編碼--unescap可以做一下轉(zhuǎn)義，比如把%20變成空格比如我們有一個utf8編碼的文件名，轉(zhuǎn)換成GBK編碼，命令如下：convmv-fUTF-8-tGBK--notestutf8編碼的文件名這樣轉(zhuǎn)換以后〃utf8編碼的文件名〃會被轉(zhuǎn)換成GBK編碼（只是文件名編碼的轉(zhuǎn)換，文件內(nèi)容不會發(fā)生變化）vim編碼方式的設置和所有的流行文本編輯器一樣，Vim可以很好的編輯各種字符編碼的文件，這當然包括UCS-2、UTF-8等流行的Unicode編碼方式。然而不幸的是，和很多來自Linux世界的軟件一樣，這需要你自己動手設置。Vim有四個跟字符編碼方式有關的選項，encoding、fileencoding、fileencodings、termencoding（這些選項可能的取值請參考Vim在線幫助:helpencoding-names），它們的意義如下：*encoding:Vim內(nèi)部使用的字符編碼方式，包括Vim的buffer（緩沖區(qū)）、菜單文本、消息文本等。默認是根據(jù)你的locale選擇.用戶手冊上建議只在.vimrc中改變它的值，事實上似乎也只有在.vimrc中改變它的值才有意義。你可以用另外一種編碼來編輯和保存文件，如你的vim的encoding為utf-&所編輯的文件采用cp936編碼,vim會自動將讀入的文件轉(zhuǎn)成utf-8（vim的能讀懂的方式），而當你寫入文件時，又會自動轉(zhuǎn)回成cp936（文件的保存編碼）.*fileencoding:Vim中當前編輯的文件的字符編碼方式，Vim保存文件時也會將文件保存為這種字符編碼方式（不管是否新文件都如此）。*fileencodings:Vim自動探測fileencoding的順序列表，啟動時會按照它所列出的字符編碼方式逐一探測即將打開的文件的字符編碼方式，并且將fileencoding設置為最終探測到的字符編碼方式。因此最好將Unicode編碼方式放到這個列表的最前面，將拉丁語系編碼方式latin1放到最后面。*termencoding:Vim所工作的終端（或者Windows的Console窗口）的字符編碼方式。如果vim所在的term與vim編碼相同，則無需設置。如其不然，你可以用vim的termencoding選項將自動轉(zhuǎn)換成term的編碼.這個選項在Windows下對我們常用的GUI模式的gVim無效，而對Console模式的Vim而言就是Windows控制臺的代碼頁，并且通常我們不需要改變它。好了，解釋完了這一堆容易讓新手犯糊涂的參數(shù)，我們來看看Vim的多字符編碼方式支持是如何工作的。Vim啟動，根據(jù).vimrc中設置的encoding的值來設置buffer、菜單文本、消息文的字符編碼方式。讀取需要編輯的文件，根據(jù)fileencodings中列出的字符編碼方式逐一探測該文件編碼方式。并設置fileencoding為探測到的，看起來是正確的（注1）字符編碼方式。對比fileencoding和encoding的值，若不同則調(diào)用iconv將文件內(nèi)容轉(zhuǎn)換為encoding所描述的字符編碼方式，并且把轉(zhuǎn)換后的內(nèi)容放到為此文件開辟的buffer里，此時我們就可以開始編輯這個文件了。注意，完成這一步動作需要調(diào)用外部的iconv.dll（注2），你需要保證這個文件存在于$VIMRUNTIME或者其他列在PATH環(huán)境變量中的目錄里。編輯完成后保存文件時，再次對比fileencoding和encoding的值。若不同，再次調(diào)用iconv將即將保存的buffer中的文本轉(zhuǎn)換為fileencoding所描述的字符編碼方式，并保存到指定的文件中。同樣，這需要調(diào)用iconv.dll由于Unicode能夠包含幾乎所有的語言的字符，而且Unicode的UTF-8編碼方式又是非常具有性價比的編碼方式（空間消耗比UCS-2?。?，因此建議encoding的值設置為utf-8。這么做的另一個理由是encoding設置為utf-8時，Vim自動探測文件的編碼方式會更準確（或許這個理由才是主要的;）。我們在中文Windows里編輯的文件，為了兼顧與其他軟件的兼容性，文件編碼還是設置為GB2312/GBK比較合適，因此fileencoding建議設置為chinese（chinese是個別名，在Unix里表示gb2312，在Windows里表示cp936，也就是GBK的代碼頁）。vim中編輯不同編碼的文件時需要注意的一些地方此文講解的是vim編輯多字節(jié)編碼文檔（中文）所要了解的一些基礎知識，注意其沒有涉及gvim，純指字符終端下的vim。vim編碼方面的基礎知識:1，存在3個變量：encoding 該選項使用于緩沖的文本（你正在編輯的文件），寄存器，Vim腳本文件等等。你可以把‘encoding'選項當作是對Vim內(nèi)部運行機制的設定。fileencoding 該選項是vim寫入文件時采用的編碼類型。termencoding 該選項代表輸出到客戶終端（Term）采用的編碼類型。2，此3個變量的默認值：encoding 與系統(tǒng)當前l(fā)ocale相同，所以編輯文件的時候要考慮當前l(fā)ocale，否則要設置的東西就比較多了。fileencodingvim打開文件時自動辨認其編碼，fileencoding就為辨認的值。為空則保存文件時采用encoding的編碼，如果沒有修改encoding，那值就是系統(tǒng)當前l(fā)ocale了。termencoding 默認空值，也就是輸出到終端不進行編碼轉(zhuǎn)換。由此可見，編輯不同編碼文件需要注意的地方不僅僅是這3個變量，還有系統(tǒng)當前l(fā)ocale和、文件本身編碼以及自動編碼識別、客戶運行vim的終端所使用的編碼類型3個關鍵點，這3個關鍵點影響著3個變量的設定。如果有人問：為什么我用vim打開中文文檔的時候出現(xiàn)亂碼？答案是不確定的，原因上面已經(jīng)講了，不搞清楚這3個關鍵點和這3個變量的設定值，出現(xiàn)亂碼是正常的，倒是不出現(xiàn)亂碼那反倒是湊巧的。再來看一下常見情況下這三個關鍵點的值以及在這種情況下這3個變量的值：1，locale 目前大部分Linux系統(tǒng)已經(jīng)將utf-8作為默認locale了，不過也有可能不是，例如有些系統(tǒng)使用中文localezh_CN.GB18030。在locale為utf-8的情況下，啟動vim后encoding將會設置為utf-8,這是兼容性最好的方式，因為內(nèi)部處理使用utf-8的話，無論外部存儲編碼為何都可以進行無缺損轉(zhuǎn)換。locale決定了vim內(nèi)部處理數(shù)據(jù)的編碼，也就是encoding。2，文件的編碼以及自動編碼識別—-這方面牽扯到各種編碼的規(guī)則，就不一一細講了。但需要明白的是，文件編碼類型并不是保存在文件內(nèi)的，也就是說沒有任何描述性的字段來記錄文檔是何種編碼類型的。因此我們在編輯文檔的時候，要么必須知道這文檔保存時是以什么編碼保存的，要么通過另外的一些手段來斷定編碼類型，這另外的手段，就是通過某些編碼的碼表特征來斷定，例如每個字符占用的字節(jié)數(shù)，每個字符的ascii值是否都大于某個字段來斷定這個文件屬于何種編碼。這種方式vim也使用了，這就是vim的自動編碼識別機制了。但這種機制由于編碼各式各樣，不可能每種編碼都有顯著的特征來辨別，所以是不可能100%準確的。對于我們GB2312編碼，由于其中文是使用了2個acsii值高于127的字符組成漢字字符的，因此不可能把gb2312編碼的文件與latin1編碼區(qū)分開來，因此自動識別編碼的機制對于gb2312是不成功的，它只會將文件辨識為latinl編碼。此問題同樣出現(xiàn)在gbk，big5上等。因此我們在編輯此類文檔時，需要手工設定encoding和fileencoding。如果文檔編碼為utf-8時，一般vim都能自動識別正確的編碼?？蛻暨\行vim的終端所使用的編碼類型一-同第二條一樣，這也是一個比較難以斷定的關鍵點。第二個關鍵點決定著從文件讀取內(nèi)容和寫入內(nèi)容到文件時使用的編碼，而此關鍵點則決定vim輸出內(nèi)容到終端時使用的編碼，如果此編碼類型和終端認為它收到的數(shù)據(jù)的編碼類型不同，則又會產(chǎn)生亂碼問題。在linux本地X環(huán)境下，一般終端都認為其接收的數(shù)據(jù)的編碼類型和系統(tǒng)locale類型相符，因此不需關心此方面是否存在問題。但如果牽涉到遠程終端，例如ssh登錄服務器，則問題就有可能出現(xiàn)了。例如從1臺locale為GB2310的系統(tǒng)（稱作客戶機）ssh到locale為utf-8的系統(tǒng)（稱作服務器）并開啟vim編輯文檔，在不加任何改動的情況下，服務器返回的數(shù)據(jù)為utf-8的，但客戶機認為服務器返回的數(shù)據(jù)是gb2312的，按照gb2312來解釋數(shù)據(jù)，則肯定就是亂碼了，這時就需要設置termencoding為gb2312來解決這個問題。此問題更多出現(xiàn)在我們的windowsdesktop機遠程ssh登錄服務器的情況下，這里牽扯到不同系統(tǒng)的編碼轉(zhuǎn)換問題。所以又與windows本身以及ssh客戶端有很大相關性。在windows下存在兩種編碼類型的軟件，一種是本身就為unicode編碼方式編寫的軟件，一種是ansi軟件，也就是程序處理數(shù)據(jù)直接采用字節(jié)流，不關心編碼。前一種程序可以在任何語言的windows上正確顯示多國語言，而后一種則編寫在何種語言的系統(tǒng)上則只能在何種語言的系統(tǒng)上顯示正確的文字。對于這兩種類型的程序，我們需要區(qū)別對待。以ssh客戶端為例，我們使用的putty是Unicode軟件，而secureCRT則是ansi軟件。對于前者，我們要正確處理中文，只要保證vim輸出到終端的編碼為utf-8即可，就是termencoding二utf-8。但對于后者，一方面我們要確認我們的windows系統(tǒng)默認代碼頁為cp936（中文windows默認值），另一方面要確認vim設置的termencoding二cp936。最后來看看處理中文文檔最典型的幾種情況和設置方式：1，系統(tǒng)locale是utf-8（很多l(xiāng)inux系統(tǒng)默認的locale形式），編輯的文檔是GB2312或GBK形式的（Windows記事本默認保存形式，大部分編輯器也默認保存為這個形式，所以最常見），終端類型utf-8（也就是假定客戶端是putty類的unicode軟件）則vim打開文檔后，encoding=utf-8（locale決定的，，fileencoding=latin1（自動編碼判斷機制不準導致的），termencoding二空（默認無需轉(zhuǎn)換term編碼，，顯示文件為亂碼。解決方案1：首先要修正fileencoding為cp936或者euc-cn（二者一樣的，只不過叫法不同），注意修正的方法不是:setfileencoding二cp936，這只是將文件保存為cp936，正確的方法是重新以cp936的編碼方式加載文件為：edit++enc=cp936，可以簡寫為：e++enc二cp936。解決方案2：臨時改變vim運行的locale環(huán)境，方法是以LANG=zh_CNvimabc.txt的方式來啟動vim，則此時encoding二euc-cn（locale決定的），fileencoding二空（此locale下文件編碼自動判別功能不啟用，所以fileencoding為文件本身編碼方式不變，也就是euc-cn），termencoding二空（默認值，為空則等于encoding）此時還是亂碼的，因為我們的ssh終端認為接受的數(shù)據(jù)為utf-8,但vim發(fā)送數(shù)據(jù)為euc-cn，所以還是不對。此時再用命令：settermencoding二utf-8將終端數(shù)據(jù)輸出為utf-8，則顯示正常。2，情況與1基本相同，只是使用的ssh軟件為secureCRT類ansi類軟件。vim打開文檔后，encoding二utf-8（locale決定的），fileencoding=latinl（自動編碼判斷機制不準導致的），termencoding二空（默認無需轉(zhuǎn)換term編碼），顯示文件為亂碼。解決方案1：首先要保證運行secureCRT的windows機器的默認代碼頁為CP936，這一點中文windows已經(jīng)是默認設置了。其他的與上面方案1相同，只是要增加一步，：settermencoding=cp936解決方案2：與上面方案2類似，不過最后一步修改termencoding省略即可，在此情況下需要的修改最少，只要以locale為zh_CN開啟vim，則encoding二euc-cn,fileencoding和termencoding都為空即為encoding的值，是最理想的一種情況?？梢娎斫膺@3個關鍵點和3個參數(shù)的意義，對于編碼問題有很大助力，以后就可以隨心所欲的處理文檔了，同時不僅僅是應用于vim，在其他需要編碼轉(zhuǎn)換的環(huán)境里，都可以應用類似的思路來處理問題解決問題。最后推薦一款功能強大的windows下的ssh客戶端 xshell，它具有類似secureCRT一樣的多tab的ssh窗口的能力，但最為方便的是這款工具還有改變Term編碼的功能，這樣我們就可以不用頻繁調(diào)整termencoding，只需在ssh軟件里切換編碼即可，這是我用過的最為方便的ssh工具。它是商業(yè)軟件，但非注冊用戶使用沒有任何限制，只是30天試用期超出后會每次啟動都提示注冊，對于功能沒有絲毫影響。1、ibus輸入法Ubuntu系統(tǒng)安裝后已經(jīng)自帶了ibus輸入法，在英語環(huán)境下默認不啟動。配置ibus自動啟動可以在ubuntu系統(tǒng)菜單上選擇SystemPreferences StartupApplications，在該窗口中增加一個程序：Name：ibus-daemonCommand：ibus-daemon-d-x-ribus默認提供的中文輸入法比較弱智，需要額外安裝ibus-pinyin，命令如下：sudoapt-getinstallibus-pinyin這時，還需要將ibus-pinyin輸入法啟動。在ubuntu系統(tǒng)菜單上選擇System---Preferences IBusPreferences,在InputMethod頁中的“Selectaninputmethod"下拉框中選擇增加Chinese-Pinyin,就是圖標中有個一個大大的“拼”字的那一個，然后點擊Add按鈕，最后通過Up按鈕將該輸入法移動到最上面。系統(tǒng)重啟后，通過Ctrl+空格即可調(diào)出ibus輸入法。ibus輸入法總體來說不錯，但是在我的環(huán)境下發(fā)現(xiàn)無法在部分Java程序中調(diào)出來，例如Netbeans、OpenProj。2、fcitx輸入法由于ibus的缺陷，所以我嘗試了fcitx,使用下來也非常不錯，而且可以在Java程序中正常使用，只是在這種情況下光標跟隨有些問題，輸入界面會停留在屏幕最下端，但是可以接受，比起ibus不能使用要好多了。安裝fcitx：sudoapt-getinstallfcitx啟動fcitx：im-switch-sfcitx注銷后重新登錄，fcitx就會生效。如果需要切換回ibus，可以運行im-switch-sibus，然后注銷，重新登錄。fcitx同樣可以通過Ctrl+空格調(diào)出，這時會發(fā)現(xiàn)fcitx顯示的中文是方框，因此需要修改fcitx的配置。Fcitx的配置文件在~/.fcitx/config，該文件為GBK編碼，在Ubuntu下顯示不正常，可以通過如下方式操作：cd~/.fcitxiconv-fgbk-tutf8config>config.tmp編輯config.tmp文件：顯示字體（中）=WenQuanYiMicroHei顯示字體大小=10使用粗體=0保存退出，然后運行命令：iconv-futf8-tgbkconfig.tmp>config注銷后重新登錄，fcitx顯示正常。3、網(wǎng)頁上Flash中的中文顯示為方框的解決辦法編輯/etc/fonts/conf.d/49-sansserif.conf文件，作如下修改:<editname="family"mode="append_last"><string>WenQuanYiMicroHei</string></edit>4、 Java程序部分中文顯示為方框的解決辦法在$JAVA_HOME/jre/lib/fonts目錄下建立fallback目錄，將中文字體文件復制（或link）到fallback目錄。sudomkdir$JAVA_HOME/jre/lib/fonts/fallbacksudoln/usr/share/fonts/truetype/wqy/wqy-microhei.ttc$JAVA_HOME/jre/lib/fonts/fallback/5、 轉(zhuǎn)換文件內(nèi)容編碼Windows下生成的純文本文件，其中文編碼為GBK,在Ubuntu下顯示為亂碼，可以使用iconv命令進行轉(zhuǎn)換：iconv-fgbk-tutf8source_file>target_file6、 轉(zhuǎn)換文件名編碼Windows下壓縮的zip文件，在Ubuntu下解開時，中文文件名會顯示亂碼，可以用convmv解決。安裝convmv：sudoapt-getinstallconvmv轉(zhuǎn)換文件或目錄：convmv-fgbk-tutf8-r--notest*7、 解壓zip文件亂碼在Ubuntu下使用unzip解壓Widnows環(huán)境下生成的zip文件，會發(fā)生文件名或者目錄名亂碼現(xiàn)象，解決辦法是使用7-zip和convmv。安裝7-zip和convmv：sudoapt-getinstallconvmvp7zip-full解壓zip文件：LANG=C7zezip_fileconvmv-fgbk-tutf8-r--notest*8、 解壓rar文件亂碼在ubuntu下解壓Windows環(huán)境下生成的rar文件，同樣會碰到中文亂碼問題，例如使用7z來解壓。解決辦法是使用unrar來解壓。安裝unrar：sudoapt-getinstallunrar9、PDF中文亂碼PDF文件中的中文顯示出亂碼的情況下，可以安裝poppler-data來解決：sudoapt-getinstallpoppler-data1.在新立得里安裝xpdf-chinese-simplified下載安裝poppler-data-0.1者過程如下：下載poppler-data-0.1.tar.gz（也可以到官方下載，這是我隨便搜的一個）解壓放置到/opt文件夾下面。打開終端進入該目錄：cd/opt/poppler-data-0.1運行命令：sudomakeinstalldatadir=/usr/share可以了，中文亂碼問題部分解決了，但可能有方框的問題，請看下文Ubuntu10.04中PDF文檔出現(xiàn)方框在終端輸入sudogedit/etc/fonts/conf.d/69-language-selector-zh-cn.conf修改69—language—selector—zh—cn.conf文件如下：<fontconfig><matchtarget="pattern"><testqual="any"name="family"><string>serif</string></test><editname="family"mode="prepend"binding="strong"><string>DejaVuSerif</string><string>ARPLUMingCN</string><string>ARPLUKaiCN</string><string>ARPLZenKaiUni</string><string>ARPLShanHeiSunUni</string><string>BitstreamVeraSerif</string><string>WenQuanYiBitmapSong</string></edit></match><matchtarget="pattern"><testqual="any"name="family"><string>sans—serif</string></test><editname="family"mode="prepend"binding="strong"><string>WenQuanYiBitmapSong</string><string>ARPLUMingCN</string><string>ARPLUKaiCN</string><string>ARPLZenKaiUni</string><string>WenQuanYiZenHei</string><stri