一个后端服务容器中解压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
