2017-02-18 13 views
0

これは、LinuxおよびWindowsの文字のデフォルトエンコーディングについては、よくある問題だと思います。しかし、私はインターネットを検索した後、私はそれを自動的に修正する簡単な方法がないので、それを行うスクリプトを書くつもりです。ここでWindowsファイル名がLinuxで壊れた文字で表示される

はシナリオです:

私は、Windowsシステム上でいくつかのファイル、英語以外の名前(特に私の場合、中国)とのいくつかを作成しました。そして私はそれらを7-zipを使ってzipファイルに圧縮しました。その後、zipファイルをLinuxにダウンロードし、Linuxシステム(Ubuntu 16.04 LTS)(デフォルトのアーカイブプログラム)でファイルを解凍しました。私が推測したように、英語以外のファイル名はすべて壊れた文字として表示されます!最初は私はconvmvで簡単にできるはずだと思ったが、...

私はconvmvを試して、 "Skipping、already utf8"と言った。何も変わっていない。

そして、私はPythonを使ってツールを書いて、汚れた仕事をすることにしました。何らかのテストの後、元のファイル名を破損したファイル名に関連付けることができません。(内容をハッシュしない限り)

ここは例です。後にpythonで「GBK」でエンコードされたIセットアップWindows上のファイル名をリストするには、Webサーバ、および1つのファイルには、

u'j\u63a5\u53e3\u6587\u6863' 

として表示されていると私は私のLinuxシステム上のファイル名を照会することができます。私は上に示した名前で直接ファイルを作成することができ、その名前は正しいです。また、unicode gbk文字列をutf8エンコーディングにエンコードしてファイルを作成することもできます。その名前も正しいです。 (したがって、私は同じ名前なので、同時にそれらを行うことはできません)。今度は、前に抽出したファイル名を読みます。これは同じファイルでなければなりません。 UTF8でそれをデコード

、それはu'jの\ u255cの\ u2559のようなものです... ':としてではなく、ファイル名が完全に異なっています。 gbkでデコードするとUnicodeDecodeError例外が発生し、utf8でデコードしてからgbkでエンコードしようとしましたが、結果はまだまだです。

要約すると、元のファイル名がLinuxシステムに抽出された後、デコードまたはエンコードすることによって元のファイル名を検査することはできません。私が実際にプログラムを仕事にさせたいのであれば、おそらくいくつかのエンコーディングオプションを使ってアーカイブをやり直すか、スクリプトを使って行くだけですが(md5やsha1のような)ファイル内容ハッシュを使って元のファイルWindows上の名前。

上記の2つのシステム間でファイルの内容を比較する以外にも、Pythonスクリプトから元の名前を推測する機会はありますか?一般的なエンコーディングと少しの実験では

+1

他の質問の重複:http://stackoverflow.com/questions/9974779/using-unicode-characters-for-file-names-inside-a-zip-archive – selbie

+0

インターネットで「zipファイルとunicodeファイル名」を検索します。あなたはこれを最初に打つわけではありません。 – selbie

+1

「unicode gbk」 –

答えて

1

、私はあなたのmojibakeを逆転することができました:

bad = 'j\xe2\x95\x9c\xe2\x95\x99\xe2\x94\x90\xe2\x94\x8c\xe2\x95\xac\xe2\x94\x80\xe2\x95\xa1\xe2\x95\xa1' 
>>> good = bad.decode('utf8').encode('cp437').decode('gbk') 
>>> good 
u'j\u63a5\u53e3\u6587\u6863'  # u'j接口文档' 

gbk - 一般的な中国のWindowsエンコーディング
cp437 - 一般的な米国のWindows OEMコンソールエンコーディング
utf8 - 一般的なLinuxのエンコーディング

+0

うわー、これは素晴らしいです!私はcp936を試したときにcp437について考えたことはありません。ありがとうございました! – Qianqian

関連する問題