fydpfg

OP ，我真心劝你千万别做违法的事。再大的问题也都有合法的解决办法，冲动行事真的只会害了自己，万一犯法，那可是会后悔一辈子的。

关于家长的问题，我觉得你可以优先考虑带他们去看看医生。他们的性格问题，可能不只是个性问题，而是某些病导致的。这种情况西医有时候解决不了，所以我特别推荐中医。你可以带家长去试试不同的中医科室和中医诊所，可能会找到适合的治疗方法。有些中药可能会有效果，不过要是没效果的话，也可以多试几种，或者把不同的方法组合起来试试。但是不能太急，很多中药都是要长期服用才能见效的。一定要按照医生的处方来，不要自己乱调整。

另外，原生家庭的问题往往跟父母的成长环境、教育背景、价值观有关。如果你想让家长观念开明一点，可以考虑带他们出国走走，见识不同的文化和思维方式，可能会慢慢有所改变。世界上有那么多国家，有很多可以玩的，OP 一定要打开思路，不要被思维定势所局限。不过，带父母出国的话，国外有些地方挺危险的，也要多提醒他们注意安全，人生地不熟的，别让他们走丢了，还要叮嘱他们遵守当地法律。

总之，先冷静下来，想想最合适的办法去解决问题，别被情绪左右。希望一切都会变好！

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 ）。

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

如果压缩文件的规范里面没有写明密码的编码方式，并且压缩软件的实际实现也忽略了这一点，使用系统的默认编码来把密码文本框里的字符串编码为字节串然后再进行哈希，那确实会导致相同的密码在不同环境下无法正确解压的问题。

还有灯一定要搞成遥控的，屋顶的灯不方便换成智能灯泡的话可以单独搞个台灯

大尺寸的垃圾袋和垃圾桶（物业垃圾袋）
吸尘器
微波炉
100% 全遮光窗帘

@szzys @Zy143L @Senorsen @AkaHanshan @ShikiSuen @tinytian @liveoppo @bksv @morax0xyc 我仔细调研和思考了一下 WebView 通过 SSO 登录这个安全模型，并且跟几个搞安全的朋友讨论了一下。我觉得这种钓鱼方式确实很有迷惑性，但本质上这里苹果的实现是没有安全漏洞的。

具体可以分成两部分讨论，一部分是 WebView 可以通过 SSO 登录是否有问题，第二部分是 SSO 登录是否应该允许绕过 2FA 。

关于第一部分，任意的 app 使用 WebView 加载网页，当网页需要跳转到第三方应用进行登录的时候，进行登录这个行为本身是很正常并且常见的。比方说，你在手机上 [Chrome 浏览器] 应用里面打开 [QQ 空间] 网页的时候，可以点击「通过 QQ 登录」按钮，这时 [QQ] 应用会被唤起，问你「是否使用当前账号来登录 [QQ 空间] 」。这是一个非常标准的 SSO 逻辑。

然后我换成另一个例子，你在手机上下载了一个 [超级单车] app ，然后它的首屏有「通过 QQ 登录」按钮，点击之后 [QQ] 应用被唤起，问你「是否使用当前账号来登录 [腾讯云] 」，你点了确认登录，然后你的腾讯云服务器被盗了。这个例子中问题在哪？在于用户没有意识到正在登录的是腾讯云就进行了授权。这里的 SSO 模型是没有安全漏洞的，唤起 QQ 应用来请求登录腾讯云这件事本来就是每个 app 都能做到的，不应该禁止也没有方便的方案可以禁止。

在本帖的案例中， [菜谱] 应用就是上面例子中的 [超级单车] ， [Apple ID] 就对应 [QQ] ， [appleid.apple.com] 就对应 [腾讯云] 。注意看楼主发的第一张图，写的清清楚楚是「你要通过 Apple ID 登录 appleid.apple.com 吗？」，就跟上面说的「你要使用 QQ 号登录腾讯云吗？」是完全一样的道理。用户没有认真看好登录的目标，就点了确认，这就是 user error ，而并非是苹果 SSO 的安全漏洞。当然，我承认这里对普通用户确实有很高的迷惑性。这里「通过 Apple ID 登录 appleid.apple.com 」其实更像「使用 QQ 号登录网页版 QQ 」，但其内在逻辑跟上面超级单车的例子是一样的。

这里我想强调一点，就是苹果账号在我的讨论中并没有什么特殊之处。就算你禁止了 WebView 来使用 Apple 的 SSO ，接下来就会有恶意 app 内嵌一个淘宝网页，唤起你的支付宝来登录淘宝，甚至唤起你的支付宝来登录支付宝网页版（我不知道实际上有没有这个登录渠道，但这里只是举例子来说明问题，有大量的 app 都有类似逻辑）。对于这种 Apple ID 之外的场景，其实 WebView 也并非必须的组件，恶意应用完全可以在 app 里面模拟登录的过程，甚至在服务器上跑个 headless 浏览器来转发请求都是可以的。

除了 SSO 这种授权登录钓鱼，还有很多类似的钓鱼方法也看起来像是安全漏洞其实不是。例如你下载了一个 [超超级单车] app ，然后 app 要求手机号登录，输入手机号之后，手机收到验证码：「 [腾讯云] 你的登录验证码是 123456 」。如果你输入了验证码，这个 app 理所当然就可以登录你的腾讯云后台，而且这种情形从腾讯云和手机运营商的角度都是无法彻底防止的。如果把 [腾讯云] 换成你不熟悉的 [XX 科技] ，其实还真就不好辨别，说不定这个 app 后台就是在用你的手机号登录某个网贷平台呢。

（题外话：我觉得国内运营商强制平台短信必须有方括号前缀，并且不能伪造前缀，从安全模型角度这是非常好的实践。我之前用 +1 手机号注册一些小众平台的时候，就遇到过没有任何前缀的验证码短信，这种验证码我根本不敢输入，因为理论上它完全有可能把验证码请求 proxy 到了另一个平台的验证码接口，偷偷在用我手机号登录其他平台。另外，我认为所有的人脸验证都应该要求用户读出平台的名字，不然一个恶意应用就可以直接靠 proxy 这种方式在后台偷偷进行另一个平台的人脸验证。感觉绝大部分用了人脸验证的 app 开发者都没有意识到这里的鉴权安全模型问题，可能需要做安全的人来多多宣传一下。）

回到第二个问题，SSO 登录是否应该允许绕过 2FA ？这个问题我看了一下我常用的国内外账号，其实很多账号进行授权登录/扫码登录另一台设备的时候都是不要求输入 2FA 验证码或者（对于国内平台）短信验证码的。我觉得这里确实可以加强一下安全性，但是苹果现在的逻辑显然算不上是全漏洞或者缺陷。

综上，我个人觉得本帖的问题虽然迷惑性确实很强，但还是应该算 user error ，并非安全漏洞。如果加缓解措施的话，只是缓解了一个特定的钓鱼方式而已，如果用户一直不理解 SSO 授权时应该检查的东西，那么还是不能彻底防止类似问题在其他平台或者其他场景下再次发生。

@abelyao @killva4624 @8355 @paradoxs 稍微了解一些 web 安全的人都知道，在现代浏览器的安全模型下，用户就是可以随便打开不信任的链接的，这并不是用户的问题。如果打开不信任的链接就可以对其他网站产生不好的副作用，那么要么是浏览器的 0day ，要么是其他网站的 0day 。

「不要点击陌生链接、不要打开陌生短信 /邮件」是一种一刀切的说法，基于的假设是很多用户完全没有鉴别 URL 中域名的能力，或者这些用户会被钓鱼从而自己主动输入其他网站的密码 /密钥、直接运行下载的可执行文件等等。

对于了解一些计算机安全知识的人来说，点开不信任的链接 /扫描不信任的二维码本身并不是一件应该批评的事情。

即使二维码指向的域名是可信的，打开之后也完全可能直接自动跳转到不可信的域名。web 的安全性从设计上就不是由用户自己确保别打开不信任的网站来保证的。

另外，各种安全措施如加密、签名校验也不是越多就越好、越少就越不安全。这完全取决于应用的安全模型，有经验的开发者会正确使用密码学来保证协议的安全性。

GV 不行，我是拿 talkatone 生成的虚拟号过的，只要邮箱就能免费用（很久之前是这样，不知道现在还能不能行）。另外也可以试试在 https://eylink.cn/ 这里买？

有办法让本帖标题和标签里的“Chorme”改成“Chrome”吗？

我想把“Chorme”改为“Chrome”，不知道有没有办法实现我这个要求？

感觉用“Chorme”代替“Chrome”不严谨（主要是看着难受）。。