@PeekabooCAT 泡酒喝还行，也喝不了多少。我不知道在哪看到的说黄芪会都偷“肾气"补身体，不知道是不是真的，结合我吃药效果，吃完确实有种红光满面，有点精气外泄的现象，现在用黄芪都会少用了

@jarson 这是经方，网上是能找到比例的，我都是各种药买一袋，大多是 250g ，按照比例自己称重配的，自己买来配有个好处是自己可以根据自己的感受做适当的加减,前提是你对药效有一定了解。

买药的话是抖音去找的，找那种会拍实地去当地收药材的主播，我自己买的很杂，找了好几家，药效都差强人意，很明显的感觉是吃完身体“没反应”，“没反应”的具体表现就是，如生地黄这个药，你如果本身肠胃不好，或者剂量过多，吃完就会拉肚子窜西，这是我真实经历过的，假药的话，吃完就会没反应。

总结来讲，就我自己的经历而言，中医是一门很靠经验的一门学科，对药和医生都有很高的要求。药物配伍不好，不起效果，药材本身质量差或者是假药，也会影响最终效果，但是中药在我身上确实是起作用了。

@totoroLeon 两个月没好那基本就没对症，防己黄芪汤喝完过一会儿，你身体就会有一种热感，体内有湿的，喝完感觉身体会轻不少，不是体重上的，是感觉上的。

不知道你多大了，年龄大了，各个脏器基本都或多或少有毛病，需要有专门懂这些的人帮你调理，搭配锻炼和好的作息，效果会很显著。其实你也可以研究一下中医养生相关方面的东西，我现在看待我身体的异常我都会结合脏器进行分析，比如身体很重，走路不轻松，我会买一些健脾的药，比如眼睛干涩，我会买一些疏肝补血的药，效果确实是有了，花了我近一年的时间，前前后后买药的钱差不多有 4 ，5 千了，收获还是有的。

我看评论区好多建议你切啥的，如果你这病从小就有，那可以考虑切，因为先天有缺是很难治的，反正治好也难，不如切了，让你看起来像正常人，但是切之前最好调研一下，切了后会不会有后遗症，比如切包皮这件事，以前都听别人说切了会降低敏感度，防止细菌滋生，防细菌是真的，降低敏感是假的，切了后龟头会裸露出来，没有包皮包裹住的那种温热，这种温热恰恰是为了让你适应阴道的那种温热湿润感的，对你反而有利，切了之后长时间没做那事，你会很不适应

还有一种是脾虚也会，喝防己黄芪汤，这个还能能治头皮屑，对我有效果，不知道别人喝有没有

大概率肾阴虚，多锻炼就行，有段时间纵欲太凶，手心，和心口都在冒汗

以后有新功能放后端吧，目前国内还处于发展阶段，好多东西都只能从欧美国家盗版东西来用，国家为了寻求发展是会默认这种行为的，所以在版权方面不会监管太严，太严之后国内根本没法发展。目前阶段的著作权法，除非你是个大企业，有那资金去收集论证别人侵权，不然个人作者维权很难，就跟农民工讨薪一样。

@bler 我更新一下我的回答，”pipeline 的类变量在两个爬虫中会共用“，这是错误的，虽然两个爬虫在同一进程中，但是两个爬虫类变量是隔离的

我大概明白楼主是啥意思，楼主应该是想问，main1.go 和 main2.go 独立运行，会不会被 go 语言分配到同一个进程之中。我被 python 的 scrapy 框架坑过，scrapy crawl 命令运行爬虫的时候，scrapy crawl spider1 和 scrapy crawl spider2 是运行在同一个进程之下的，pipeline 的类变量在两个爬虫中会共用，估计楼主应该是遇到类似的问题了

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

标题应该改为：
”使用非 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