我看了一下回复，发现很多人没有理解我的意思，我重新整理一下描述。

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

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

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

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

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

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

@fydpfg 这个老哥牛皮，他是真能从官方文档中找到答案

谢谢各位老哥的解答，涨姿势了

@thinkershare 你说的这个场景我遇到过，之前有 hook 过 app ，遇到 java 的字节流数据，打印出来是一个整数数组，这个时候需要知道它的编码方式才能将他转成可阅读的文本，字节流数据你不知道编码方式，你就不知道是三个字节表示一个字符还是 2 个字节表示一个字符

@thinkershare 谢谢老哥了，我理解你的意思，我就是好奇字符的编码对应用程序的影响，应用程序是如何应对多语言多编码环境的

总结一下：
这个问题是我在设置压缩包密码时，是否应该用非 ascii 字符引出的，我担心如果未来中文出现新的文字，unicode 码点和字符的映射会发生变化。
一般来讲 ascii 字符 基本不会变化了，英文字母就那几个，中文的可变性太强了，新增文字就意味着新增码点。但是想想 unicode 委员会应该不会范这种低级错误，有点杞人忧天了。但是也不是没有收获，又加深了对编码的理解

@thinkershare 老哥你的 1 ，2 解答了我对码点和编码的疑惑，但是第三点我很好奇，假设操作系统是 GBK 编码环境，然后软件能拿到操作系统的编码方式，输入到密码框中的数据是 GBK 编码的二进制数据，然后压缩软件把他转化成 utf8 的二进制编码值，然后再散列比对解压缩密码，这种编码的转化过程可能存在吗

@mcfog 大佬详细说说，就是不懂才问

参考一下各位老哥的回复以及看的一些文章总结一下：

1 、打洞相关的原理
https://www.h3c.com/cn/d_201206/922130_30005_0.htm

2 、nat 不同模式的一些区别（会影响打洞的情况）：
https://myth.cx/p/qbittorrent-nat-tcp-hole-punching/

3 、我在其他论坛里发现 比特彗星 已经实现了 udp 打洞的场景，据说开发组里有国人，
qBittorrent 不行，毕竟美国佬人手好几个 ip ，不太理解 nat 套好几层这种神奇场景。

4 、tracker 是提供 peer 信息的，并不作为服务器做数据转发，
之前想当然了，美国佬人手几个 ip ，直接就能通过 ip+port 下载数据了，没有这种复杂数据中转场景。

@nothingistrue 谢谢老哥了，已经有点搞明白这个了， @smilekung 这个老哥说的对，我描述的场景其实就是 udp 打洞的场景，这篇文章 https://www.h3c.com/cn/d_201206/922130_30005_0.htm 还介绍了 tcp 打洞的场景，还有很多关于 nat 方面的东西

找个一个讲的比较好的文章，感兴趣的可以看看： https://www.h3c.com/cn/d_201206/922130_30005_0.htm

@xiaozecn 谢谢，我的主要目的还是想知道，在 a,b 两个用户处于内网（ nat ）网络环境下，有没有方案实现不依托于公网服务器交换数据，公网服务器只交换两者的地址，然后两者自己进行数据交互，这样能不占用公网的带宽流量。所以我才有上面的一个设想场景，a 内网发送请求，tracker(或者是其他中转服务器）完成对 b 的网络交互通知，然后 b 发送数据给 a ，而不是 b 把数据给 tracker(或者是其他中转服务器），然后再发送给 a

能哪位大佬能出个 a,b 两个内网用户交互种子资源的网络拓扑图吗，主要是数据的流向，怎样流动的，我想知道各方的带宽占用情况，这个 p2p 到底是怎么个数据流向，尤其是国内这种都处于内网的情况下

@titanium98118 那我们下载的数据从哪来的，总得要有一个公网做 a 和 b 数据转发吧， 那同样要占用这个公网服务器的带宽了，这个公网服务器是由谁提供的呢

@nothingistrue 我知道 udp 不需要回复确认，但是 a,b 都处于内网之中，b 向 a 无法直接发送数据啊。还有 a,b 用户通过公网建立 tcp 连接，b 向 a 发送数据不一样要占公网服务器的带宽吗。

谢谢各位大佬

@DonaldVVV 好的，谢谢，这买贵的机器风险太高了，一不注意几百块就被白嫖了😂

@wxxxcxx 好的谢谢

@haimall 好的谢谢

@DonaldVVV 能说说怎么交易的吗，在那个平台交易的，怎样保证交易双方不跑路