用PHP如何检测一个ZIP包内的文件是在何种编码的系统下创建的
事情起源于在WIN下创建的zip放到linux下解压时,中文路径和文件名会出现乱码,于是动手写了个脚本转换zip内文件名的代码。但是,如果是在日语、韩语或者繁体字WIN系统下建立的zip,由于不知道原始编码格式,导致无法转码。
怎么解。。。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
LZ 的 id 看着眼熟 ... 这么多年了还在问这个等级的问题 ... 你也不容易啊你 ...
代码就是这样了 ... 根据文件名来判断系统 ...
简体中文的 windows 会返回 EUC-CN ... 繁体中文我猜测应该是 EUC-TW 或者 BIG5 ...
Linux 和 MacOS 都是 UTF-8 ... 纯英文的文件就别捣乱了 ...
应该是有编码问题,举例说明:mac下的压缩,如果文件是中文名,到win下面解压的时候全部是乱码。所以在mac下面压缩的时候,都尽量只用英文文件名。
11年的时候,有人提过类似问题:http://bbs.csdn.net/topics/370123319 ,文中的解决方案是说:查看http://www.pkware.com/documents/cases...,并搜索“Info-ZIP Unicode Path Extra Field”
搜索完这段内容:
希望有用。
@Ven 就是文件名的编码吧,稍微改了下楼上的代码,我的系统是linux,所以要把非UTF-8的重新编码为UTF-8
正确答案见@Sunyanzi 的回答,这里再补充一些。
由于Windows系统的历史原因,部分压缩软件生成的zip包,在用mb_detect_encoding()检查文件名的编码时,会得到类似“CP936”这样的结果。我当时在这里被搞晕了,以为函数没能正确检测到编码。实际上CP936是微软自己的一套标准,基本上等于GBK。
而关于其他的“CP***”的编码对应关系,或许可以参看这篇文章:Windows代码页
ZIP格式,似乎文件名没有编码这一说。
至于你说的解压缩出现乱码,这是解压缩软件的问题……