事情起源于在WIN下創(chuàng)建的zip放到linux下解壓時(shí)，中文路徑和文件名會(huì)出現(xiàn)亂碼，于是動(dòng)手寫了個(gè)腳本轉(zhuǎn)換zip內(nèi)文件名的代碼。但是，如果是在日語、韓語或者繁體字WIN系統(tǒng)下建立的zip，由于不知道原始編碼格式，導(dǎo)致無法轉(zhuǎn)碼。

怎么解。。。

回復(fù)內(nèi)容：

事情起源于在WIN下創(chuàng)建的zip放到linux下解壓時(shí)，中文路徑和文件名會(huì)出現(xiàn)亂碼，于是動(dòng)手寫了個(gè)腳本轉(zhuǎn)換zip內(nèi)文件名的代碼。但是，如果是在日語、韓語或者繁體字WIN系統(tǒng)下建立的zip，由于不知道原始編碼格式，導(dǎo)致無法轉(zhuǎn)碼。

怎么解。。。

LZ 的 id 看著眼熟 ... 這么多年了還在問這個(gè)等級(jí)的問題 ... 你也不容易啊你 ...open( '/path/to/your.zip' );

/* can not open ..? are you kidding me ..? */

if ( true !== $res )

throw new Exception( 'Can Not Open Zip File / ' . $res );

/* default value of file encoding ... */

$encoding = 'EMTPY';

/* controller ... change this if mb_detect_encoding return wrong answer ... */

$controller = null;

/* get file list ... */

for ( $i = 0; $i < $zip->numFiles; ++ $i ) {

/* get file encoding ... */

$encoding = mb_detect_encoding( $zip->getNameIndex( $i ), $controller );

/* we do not need english named files ... */

if ( 'ASCII' !== $encoding ) break;

}

/* clean table ... */

$zip->close();

/* simply output ... */

echo $encoding;

代碼就是這樣了 ... 根據(jù)文件名來判斷系統(tǒng) ...

簡(jiǎn)體中文的 windows 會(huì)返回 EUC-CN ... 繁體中文我猜測(cè)應(yīng)該是 EUC-TW 或者 BIG5 ...

Linux 和 MacOS 都是 UTF-8 ... 純英文的文件就別搗亂了 ...

應(yīng)該是有編碼問題，舉例說明：mac下的壓縮，如果文件是中文名，到win下面解壓的時(shí)候全部是亂碼。所以在mac下面壓縮的時(shí)候，都盡量只用英文文件名。

11年的時(shí)候，有人提過類似問題：http://bbs.csdn.net/topics/370123319 ，文中的解決方案是說：查看http://www.pkware.com/documents/cases...，并搜索“Info-ZIP Unicode Path Extra Field”

搜索完這段內(nèi)容：4.6 Third Party Mappings

------------------------

4.6.1 Third party mappings commonly used are:

0x07c8 Macintosh

0x2605 ZipIt Macintosh

0x2705 ZipIt Macintosh 1.3.5+

0x2805 ZipIt Macintosh 1.3.5+

0x334d Info-ZIP Macintosh

0x4341 Acorn/SparkFS

0x4453 Windows NT security descriptor (binary ACL)

0x4704 VM/CMS

0x470f MVS

0x4b46 FWKCS MD5 (see below)

0x4c41 OS/2 access control list (text ACL)

0x4d49 Info-ZIP OpenVMS

0x4f4c Xceed original location extra field

0x5356 AOS/VS (ACL)

0x5455 extended timestamp

0x554e Xceed unicode extra field

0x5855 Info-ZIP UNIX (original, also OS/2, NT, etc)

0x6375 Info-ZIP Unicode Comment Extra Field

0x6542 BeOS/BeBox

0x7075 Info-ZIP Unicode Path Extra Field

0x756e ASi UNIX

0x7855 Info-ZIP UNIX (new)

0xa220 Microsoft Open Packaging Growth Hint

0xfd4a SMS/QDOS

希望有用。

@Ven 就是文件名的編碼吧，稍微改了下樓上的代碼，我的系統(tǒng)是linux，所以要把非UTF-8的重新編碼為UTF-8open($zipfile_name);

if(true !== $res)

throw new Exception('Can Not Open Zip File '.$res);

$encoding = "UTF-8";

$controller = array("ASCII","UTF-8", "GB2312", "GBK", "BIG5");

for($i = 0; $i < $zip->numFiles; ++ $i){

$entry = $zip->getNameIndex($i);

$encoding = mb_detect_encoding($entry, $controller);

if( "UTF-8" !== $encoding)

$entry = iconv($encoding, "UTF-8", $entry);

echo $entry." ---> ".$encoding.chr(10);

}

$zip->close();

}

detect_encoding($argv[1]);

?>

正確答案見@Sunyanzi 的回答，這里再補(bǔ)充一些。

由于Windows系統(tǒng)的歷史原因，部分壓縮軟件生成的zip包，在用mb_detect_encoding()檢查文件名的編碼時(shí)，會(huì)得到類似“CP936”這樣的結(jié)果。我當(dāng)時(shí)在這里被搞暈了，以為函數(shù)沒能正確檢測(cè)到編碼。實(shí)際上CP936是微軟自己的一套標(biāo)準(zhǔn)，基本上等于GBK。

而關(guān)于其他的“CP***”的編碼對(duì)應(yīng)關(guān)系，或許可以參看這篇文章：Windows代碼頁

ZIP格式，似乎文件名沒有編碼這一說。

至于你說的解壓縮出現(xiàn)亂碼，這是解壓縮軟件的問題……

本文原創(chuàng)發(fā)布php中文網(wǎng)，轉(zhuǎn)載請(qǐng)注明出處，感謝您的尊重！

總結(jié)

以上是生活随笔為你收集整理的php zip 编码,encoding - 用PHP如何检测一个ZIP包内的文件是在何种编码的系统下创建的...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。