相同的压缩密码,会不会因为计算机编码技术以及 unicode 代码点的变更,导致未来解不开压缩包?

2023-10-12 14:19:13 +08:00
 bler

unicode 给世界上所有的语言字符编号,编码方式决定了二进制的序列,hash 函数通过二进制生成散列值, 那么哪天操作系统不采用这种编码方式了,编码出的二进制序列不同,那么散列值也不一样了,那不就解不开压缩报了?

比如中文”我“,使用 utf8 和 GBK 编码出的二进制序列是不一样的,压缩软件是如何判定输入的字符的编码方式的, 是使用操作系统的编码方式吗

不知道描述的对不对,有对编码熟悉的大佬说说吗

3029 次点击
所在节点    程序员
35 条回复
bler
2023-10-12 16:37:24 +08:00
谢谢各位老哥的解答,涨姿势了
fydpfg
2023-10-12 17:30:12 +08:00
TLDR:压缩文件的规范应该写明密码的编码方式,不然确实可能会有问题。

@mcfog 题主的提问其实完全没有任何问题,题主是在问非 ASCII 的密码本身的编码方式会不会影响解压缩,而不是被压缩的文件的编码方式会不会影响解压缩。

我刚刚用 7-zip 试了一下,7z 格式使用中文密码,在中文 Windows 上压缩,可以正常在 Linux 上解压缩。而 zip 格式不允许非 ASCII 字符作为密码。

题主这个问题的答案其实很简单,压缩文件的格式规范里面规定密码的编码方式就行了,比如规定非 ASCII 密码按 UTF-8 来处理就行。我猜测 7z 格式应该就是规定了一种密码的编码方式(简单搜索了一下没搜到,没去读代码验证)。

除了密码,其实文件名也有这个问题,我之前研究过。对于 7z 压缩包,压缩和解压缩的时候按照标准会统一按 UTF-16-LE 来处理(参见 https://py7zr.readthedocs.io/en/latest/archive_format.html#filename ),所以不会有问题。而 zip 格式根本没规定编码,这样不同默认编码的环境创建出来的压缩包就会不兼容,所以 zip 格式经常有文件名乱码问题。对于 rar 格式,文件名是 UTF-8 编码(参见 https://www.rarlab.com/technote.htm )。

而对于被压缩的文件,文件本身就是一串字节,压缩的过程跟编码方式无关,所以不会有任何问题。

如果压缩文件的规范里面没有写明密码的编码方式,并且压缩软件的实际实现也忽略了这一点,使用系统的默认编码来把密码文本框里的字符串编码为字节串然后再进行哈希,那确实会导致相同的密码在不同环境下无法正确解压的问题。
nothingistrue
2023-10-12 17:39:14 +08:00
程序员区出现这帖子,是耻辱。
huaxxy94
2023-10-12 18:43:39 +08:00
@nothingistrue #23 怎么耻辱了,我觉得这类问题不论对错都可以探讨探讨,千年虫事件不就是当时程序员觉得不可能吗。
mcfog
2023-10-12 19:07:57 +08:00
@fydpfg 我读了好几遍才大致猜到 OP 的意思,你也可以看下上面的兄弟有多少是没有发现 OP 在讨论“压缩密码使用非 ASCII 的编码问题”,而不是“压缩包内文本文件的编码”或者“压缩包内文件名的编码”的
zjp
2023-10-12 19:26:02 +08:00
@lambdaq unicode 也不是编码的统称,它只定义了字符的码点
vcn8yjOogEL
2023-10-12 19:33:18 +08:00
这种东西肯定会向后兼容的
liveoppo
2023-10-12 20:08:55 +08:00
推荐 20 楼和 25 楼

密码就不应该有 ASCII 之外的其他格式
smallyu
2023-10-12 20:48:03 +08:00
借楼,请教一下,rar 是不是有不同的压缩模式,在密码一样的情况下,用 windows 压缩,会不会 mac 的 unarchived 软件解压不开
mikewang
2023-10-12 20:55:46 +08:00
可以这样类比:

现在我们都用十进制。我记下一个数 114514 。
数百年后,人类升级,新人类使用十六进制。

那么,我记下的数会被当作十六进制解读,理解为十进制的 1131796 ,从而增大为 9.88 多倍吗?

这是个兼容性问题,升级时肯定是要解决的嘛。
nothingistrue
2023-10-13 09:13:23 +08:00
@huaxxy94 #23 千年虫事件的原因,是 1960 年代的程序规则——6 位数表示日期,随着时间的演变到了 2000 年不再适合了。程序员社区,能出现你这种连千年虫事件的浅显原因都不知道的人,那也是耻辱。你这种回复还能收到感谢,那更是耻辱。
bler
2023-10-13 09:46:34 +08:00
我看了一下回复,发现很多人没有理解我的意思,我重新整理一下描述。

标题应该改为:
”使用非 ascii 字符设置压缩包密码,在未来会不会解不开压缩包,提示解压缩密码不正确“

这个问题本质上是一个编码问题,要理解为什么是编码问题,需要知道解压缩时,
压缩软件是如何比对用户输入的密码的,如此就引出了用户设置的压缩包密码是以”什么形式“
存储在压缩包中的,既然存储了,那么就能读取,对于 7-zip 这类开源软件,是可以找到它的压
缩逻辑的,那么就可以知道密码在二进制文本的哪个位置。

那么问题来了,你都能读取了,我设置密码意义在哪,这里就引出了”信息摘要算法“,
也可以说是”hash 算法”,将文本“映射”为一串不可逆推出原始文本的一串字符,这样就保证了
密码的安全性,别人无法从压缩包中提取出你设置的压缩密码。

为什么说这是一个编码问题,这是由于 hash 算法在做 hash 运算的时候,会将你设置的密码文本
转化成二进制,然后再做 hash ,文本字符转二进制,这里就引出了编码问题。

ascii 字符集在我看来基本就那样了,不太可能会变动,但是 unicode 字符集就不太一样了,
就拿中文来讲,未来可能就会多一个字,多一个字就意味着 unicode 需要将他纳入,
新的码点就会产生,我之前担心的是新的码点的产生会不会更改以前码点的值,比如 U+4444 变成 U+4441,
加入使用 utf8 编码,对应的二进制值就会发生变化,从而影响 hash 值,导致无法解开压缩包,提示压缩
密码错误,这个纯属我胡思乱想。

还有一种顾虑是操作系统编码环境的改变对解开压缩包的影响,比如中国用户 windows 操作系统
很多的默认编码是 gbk (我的是,使用 [Console]::OutputEncoding 查看),对于一个中文字符,
utf8 使用三个字节,而 gbk 使用两个字节,这就导致同一个中文字符,二进制结果是不一样的,那么 hash
值也会不一样,这就意味着操作系统编码环境改变,如果压缩软件不统一对字符的编码,就会导致
在不同的系统中解不开压缩包。

@fydpfg 这个老哥牛皮,他是真能从官方文档中找到答案
huaxxy94
2023-10-13 10:26:33 +08:00
@nothingistrue #31 难道不是一个意思?当时的程序员没有想到 2000 年这种跨世纪的情况,有的程序甚至连闰年 29 日都没识别,这就是程序员为了省存储或者考虑不周的失误,咋还被你说成演变了。
xubingok
2023-10-13 11:38:20 +08:00
我就是来看看有多少人没明白题主的意思...

"压缩密码","解不开压缩包",这些关键字看不懂吗?硬是扯到压缩文件编码方式也是厉害.

至于答案嘛:不影响.
cyrivlclth
2023-10-13 15:22:28 +08:00
明白 lz 的意思,我以前用中文当 qq 密码,后来版本更新登陆不上去了,然后找回密码依旧不改,用 alt+小键盘的方式输入中文字,然后后来换了个平台,被坑了,因为只记得编码不记得具体是什么字了,再后来就再也不用这种奇怪的密码。
肯定是有影响的,假设文明清零重新开始,那么要复原非 ascii 的难度肯定更大。所以对于不太重要的文件且密码奇葩,估计是真没办法输入密码了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/981315

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX