linux和windows雙系統互拷檔案亂碼問題

2021-06-12 16:51:13 字數 3891 閱讀 1947

如果你需要在linux下面用到windows下的檔案,拷貝上去後經常發現中文顯示亂碼。

原因是windows中預設的檔案格式是gbk(gb2312),而linux一般都是utf-8。比較繁瑣的方法是在windows下用程式把內容轉換為utf-8編碼格式的,但是相當麻煩,而且遇到乙個檔案轉一回。

下面介紹一下,在linux中如何一勞永逸的解決這個問題,檢視檔案的編碼及如何進行對檔案進行編碼轉換。

檢視檔案編碼

在linux中檢視檔案編碼可以通過以下幾種方式:

1、在vim

中可以直接檢視檔案編碼

:set fileencoding

即可顯示檔案編碼格式。

檔案編碼轉換

1、如果你只是想檢視其它編碼格式的檔案或者想解決用vim檢視檔案亂碼的問題,那麼你可以在~/.vimrc(在/etc目錄下面) 檔案中新增以下內容:

:set encoding=utf-8 fileencodings=ucs-bom,utf-8,cp936

其中encoding是vim的預設顯示編碼格式,fileencodings是vim開啟檔案時檢測的編碼格式,存在這種型別的編碼即轉換為utf-8編碼。

這樣,就可以讓vim自動識別檔案編碼(可以自動識別utf-8或者gbk編碼的檔案),其實就是依照fileencodings提供的編碼列表嘗試,如果沒有找到合適的編碼,就用latin-1(ascii)編碼開啟。

2、在vim中直接進行轉換檔案編碼,比如將乙個檔案轉換成utf-8格式(不好用)

:set fileencoding=utf-8

3、iconv 轉換,iconv的命令格式如下:(未用)

iconv -f encoding -t encoding inputfile

比如將乙個utf-8 編碼的檔案轉換成gbk編碼

iconv -f gbk -t utf-8 file1 -o file2

檔名編碼轉換: 從

linux

往 windows拷貝檔案或者從windows往linux拷貝檔案,有時會出現中文檔名亂碼的情況,出現這種問題的原因是因為,windows的檔名中文編碼預設為gbk,而linux中預設檔名編碼為utf8,由於編碼不一致,所以導致了檔名亂碼的問題,解決這個問題需要對檔名進行轉碼。

在linux中專門提供了一種工具convmv進行檔名編碼的轉換,可以將檔名從gbk轉換成utf-8編碼,或者從utf-8轉換到gbk。

首先看一下你的系統上是否安裝了convmv,如果沒安裝的話用在

下面看一下convmv的具體用法:

convmv -f 源編碼 -t 新編碼 [選項] 檔名

常用引數:

-r 遞迴處理子資料夾

--notest 真正進行操作,請注意在預設情況下是不對檔案進行真實操作的,而只是試驗。

--list 顯示所有支援的編碼

--unescap 可以做一下轉義,比如把%20變成空格

比如我們有乙個utf8編碼的檔名,轉換成gbk編碼,命令如下:

convmv -f utf-8 -t gbk --notest utf8編碼的檔名

這樣轉換以後"utf8編碼的檔名"會被轉換成gbk編碼(只是檔名編碼的轉換,檔案內容不會發生變化)。

vim 編碼方式的設定

和所有的流行文字編輯器一樣,vim 可以很好的編輯各種字元編碼的檔案,這當然包括ucs-2、utf-8 等流行的 unicode 編碼方式。然而不幸的是,和很多來自 linux 世界的軟體一樣,這需要你自己動手設定。

* encoding: vim 內部使用的字元編碼方式,包括 vim 的 buffer (緩衝區)、選單文字、訊息文字等。預設是根據你的locale選擇.使用者手冊上建議只在 .vimrc 中改變它的值,事實上似乎也只有在.vimrc 中改變它的值才有意義。你可以用另外一種編碼來編輯和儲存檔案,如你的vim的encoding為utf-8,所編輯的檔案採用cp936編碼,vim會自動將讀入的檔案轉成utf-8(vim的能讀懂的方式),而當你寫入檔案時,又會自動轉回成cp936(檔案的儲存編碼).

* fileencoding: vim 中當前編輯的檔案的字元編碼方式,vim 儲存檔案時也會將檔案儲存為這種字元編碼方式 (不管是否新檔案都如此)。

* fileencodings: vim自動探測fileencoding的順序列表, 啟動時會按照它所列出的字元編碼方式逐一探測即將開啟的檔案的字元編碼方式,並且將 fileencoding 設定為最終探測到的字元編碼方式。因此最好將unicode 編碼方式放到這個列表的最前面,將拉丁語系編碼方式 latin1 放到最後面。

* termencoding: vim 所工作的終端 (或者 windows 的 console 視窗) 的字元編碼方式。如果vim所在的term與vim編碼相同,則無需設定。如其不然,你可以用vim的termencoding選項將自動轉換成term的編碼.這個選項在 windows 下對我們常用的 gui 模式的 gvim 無效,而對 console 模式的vim 而言就是 windows 控制台的**頁,並且通常我們不需要改變它。

好了,解釋完了這一堆容易讓新手犯糊塗的引數,我們來看看 vim 的多字元編碼方式支援是如何工作的。

1. vim 啟動,根據 .vimrc 中設定的 encoding 的值來設定 buffer、選單文字、訊息文的字元編碼方式。

2. 讀取需要編輯的檔案,根據 fileencodings 中列出的字元編碼方式逐一探測該檔案編碼方式。並設定 fileencoding 為探測到的,看起來是正確的 (注1) 字元編碼方式。

3. 對比 fileencoding 和 encoding 的值,若不同則呼叫 iconv 將檔案內容轉換為encoding 所描述的字元編碼方式,並且把轉換後的內容放到為此檔案開闢的 buffer 裡,此時我們就可以開始編輯這個檔案了。注意,完成這一步動作需要呼叫外部的 iconv.dll,你需要保證這個檔案存在於 $vimruntime 或者其他列在 path 環境變數中的目錄裡。

4. 編輯完成後儲存檔案時,再次對比 fileencoding 和 encoding 的值。若不同,再次呼叫 iconv 將即將儲存的 buffer 中的文字轉換為 fileencoding 所描述的字元編碼方式,並儲存到指定的檔案中。同樣,這需要呼叫 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 的**頁)。

額外的例子:

a)轉換檔案內容編碼

windows下天生的純文字檔案,其中文編碼為gbk,在ubuntu下顯示為亂碼,可以使用iconv命令進行轉換:

iconv -f gbk -t utf8 source_file > target_file

b)解壓zip檔案亂碼

在ubuntu下使用unzip解壓widnows環境下天生的zip檔案,會發生檔名或者目錄名亂碼現象,解決辦法是使用 7-zip和convmv。

安裝7-zip和convmv:

sudo apt-get install convmv p7zip-full

解壓zip檔案:

lang=c 7z e zip_file

convmv -f gbk -t utf8 -r --notest *

c)pdf中文亂碼

pdf檔案中的中文顯示出亂碼的情況下,可以安裝poppler-data來解決:

sudo apt-get install poppler-data

Windows系統與debian系統雙系統安裝

1 資源 2 啟用系統 3 安裝驅動 驅動程式根據硬體在網上錄找,如華碩的驅動可以在其官網找到 華碩官網 4 禁用windows 8.1系統的 快速啟動 功能,為裝debian系統做準備。6 使用軟碟通 ultraiso 燒錄debian安裝映象 開機進入bios將其設定為u盤啟動 不同的電腦進入b...

windows10下安裝ubuntu雙系統

硬體情況 cpu i7 8700k 主機板 z370 顯示卡 gtx 1080ti 硬碟 1,ssd 256g 2,機械硬碟 2t 不過這次兩個系統都裝在了ssd上 用u盤製作uefi啟動盤的過程就不說了,網上的教程很多,而且過程也一樣,使用ultraiso軟體,很簡單。接下來就是安裝過程了 1,選...

如何從Linux遠端訪問Windows系統

1 掛載本地linux系統映象後,切換到映象掛載點檢視系統映象下的檔案 2 找到packages資料夾,進入後安裝三個lib支援軟體包 libao rpm ivh libao 1.1.0 8.el7.i686.rpm libao 1.1.0 8.el7.x86 64.rpm libao devel ...