一个后端服务容器中解压zip包,释放出带文件名带中文的文件,中文显示被?代替,初步推断是服务基础镜像系统字符集出现问题。
进入容器中端界面,手动创建带中文的文件,果不其然,中文显示被?代替了!
进入容器 查看字符集
# docker exec -it /bin/bash
# locale
# locale -a
从输出可以看到,系统使用的是POSIX字符集,POSIX字符集是不支持中文的,而UTF-8是支持中文的 只要把系统中的环境 LANG 改为”UTF-8”格式即可解决问题。
在容器中临时测试
# export LANG="en_US.UTF-8"
手动touch一个带中文的文件,显示正常。
永久设置需在Dockerfile中设置环境字符集环境变量
ENV LANG="en_US.UTF-8"
创建文件的的文件名中文显示问题解决了,程序解压zip包,释放出带文件名带中文的文件名显示乱码问题依然存在。
查阅知道得知,原zip格式并没有指定编码格式,Windows下生成的zip文件中的编码是GBK/GB2312等,因此,导致这些zip文件在Linux下解压时出现乱码问题,因为Linux下的默认编码是UTF-8。
zip这种档案格式1993年出现以来,直到 6.3版才支持Unicode(UTF-8)文件名。虽然zip标准里说在此之前只支持IBM CP437编码,但如果那样的话,在zip档案中只能出现拉丁字母和少量的其它字符。事实上,各种zip软件在创建档案时使用当前系统的字符集来编码文件名,这样的档案文件在使用同样字符集的系统里可被正常解压,但在别的系统里解压就容易出现文件名乱码问题。
如果能在创建zip文件的时候明确要求软件使用Unicode文件名,就能保证支持zip 6.3标准的软件总能正确地解码档案中的文件名。在我找到的资料里,7-zip从开始支持Unicode文件名,并提供了3种模式,其中-mcu选项会让7-zip在遇到非ASCII字符时便启用UTF-8文件名编码,其命令行使用方法如下:
# 7z a -mcu X.zip FILE_NAME
7zFM的“创建压缩包”对话框左下角有一个名叫“参数”的文本框,在里面可以填写创建压缩包时想要使用的参数,但必须省略“-m”,也就是说,如需指定“-mcu”,则要在该文本框里填写“cu”。
一般来说, 解决方式:
第一条命令用于解压缩,而LANG=C表示以US-ASCII这样的编码输出文件名,如果没有这个语言设置,它同样会输出乱码,只不过是UTF8格式的乱码(convmv会忽略这样的乱码)。
第二条命令是将GBK编码的文件名转化为UTF8编码,-r表示递归访问目录,即对当前目录中所有文件进行转换。
不管Windows还是linux,都可以压缩成7z格式,因为这种压缩有自己的编码,不会乱,但是使用7zip,需要引入新的软件包,我们一般选择指定解压字符编码。
参考
在zip文件中使用Unicode文件名
https://via.hypothes.is/http://coinfaces.me/posts/unicode-filename-in-zip-archive
解决linux下zip文件解压乱码
https://via.hypothes.is///04/25/%E8%A7%A3%E5%86%B3linux%E4%B8%8Bzip%E6%96%87%E4%BB%B6%E8%A7%A3%E5%8E%8B%E4%B9%B1%E7%A0%81
Linux 下 zip 文件解压乱码解决方案
https://via.hypothes.is//p/72bb8d2ed4df
如何看待 Bandizip 将推出新的付费版本,原免费版将添加广告?
https://via.hypothes.is//question/350595457