@docx 主要是这种问题，我感觉的确有灌水的嫌疑。

@aabbcc112233 站长已经多次明确强调，不允许发布 AI 生成内容，而且也不是第一次说明了。

你的 SaaS 设计的时候没有考虑私有化部署吗？我们的都是允许私有化部署的，只要客户提供私有化部署的全部资源，这样部署完毕后，整个软件就和我们一点关系也没有。运维也要他们自己负责，一般也无法及时升级。

@bler 但这种粗暴的解决方案有时候也存在问题。因为某些系统，甚至不携带非 ASCII 的码表，也无法显示非 ASCII 编码的字符，这就是另外一个话题了，这些都是历史遗留问题。

@bler 压缩软件会在内部使用一个固定的 encoding 模式获取到的密码的 byte[]表示，这个表示在 Encoding 指定值不变的情况下是不会有什么变化的。
另外就是 zip 这种压缩编码存在缺陷，的确会又解析错误。例如你在 GB2312 chcp 下压缩一个文件夹，然后在 UTF8 chcp 的另外一个计算机上解码，文件夹就会乱码。因为 zip 这个格式规范并没有存储压缩时候的文件名的字符串编码格式，导致它总是按照操作系统当前的编码来处理字节序列，这回导致文件名这种东西，使用 gb2312 byte 字节存储，却使用 UTF-8 解码，这个时候你就会看到解码后的文件名称错误。这个纯粹是因为 zip 这种文件格式存在缺陷。这种情况你就只能显示的告诉解压软件不要使用操作系统默认编码来解压文件，而是使用你手动指定的编码格式。
软件应该避免依赖操作系统的默认编码格式。否则你的软件很可能无法正常在各个不同国家的系统上运行。

@bler 另外存在一个叫做码表或者 Encoding 的东西，它可以将不同 Encoding 编码的字节序列做相互转换，例如将一个 byte[] /utf-8 转换为 byte[] utf-16, 字符串内部都使用 byte[]序列表示。获取到一个字节序列后，如果你不知道它究竟是什么编码方案，甚至不知道它不是字符序列，就只能靠探测了。例如 VSCode 默认就会一个探测功能，可以猜测一个文件使用了什么 Encodeing 模式，但是这个探测并不是总是靠谱。

@bler 另外就是，操作系统本身是由内核+驱动+一堆周边软件构成的。操作系统内核部分的确也有自己的字符串编码模式，但这个和你普通的应用程序没关系，你们也不同共享内存，除非涉及到内核调用和封送。这个时候你就需要关心操作系统内部字符串的格式了。或者你调用一些系统组件，这个时候返回给你的字节序列你必须按照操作系统的编码模式转换为你本地编程语言的字符串使用的编码格式，不知道我这样解释，你理解没有。

@bler 你理解错了，操作系统没有编码一说。字符串对操作系统来说是透明的字节序列。操作系统并不关心字节序列到底是什么编码方案，关心编码模式的是应用程序（ Application)，应用程序自己必须要知道你使用的字符串到底使用的什么编码，否则就无法解析。各个编程语言内置的 string 类型使用的编码都可以是不同的。例如 Python 用的 utf-8, c#/javascript 用的 UTF16 。因此这个属于应用程序需要关心了。例如你是要 C#将一个文件是要 UTF-16 写入文件，在 python 中是要 utf8 去加载这个文件，就会乱码，这个时候 python 加载这个文件必须显示告诉加载方法应该文件是要的是 UTF16 编码，这个时候 python 会将文件是要 utf-16 加载后转码为 utf-8, 从而才能在 python 中正常的处理这个字符串。

1. Unicode 字符集： 每个字符对应的码点不会变化（只会添加新的 Code)
2. UTF-8/16/32: 是存储方案（编码方案），也不会变化，只会添加对新的 Unicode 字符集版本的支持。
3. 压缩软件没有办法知道用的什么格式，要不再元数据携带，要不最终用户告诉它使用的什么编码，要不靠猜测，要不靠诱探。

PS: 各个编码方案通过编码表是可以相互转换的，但是很多转换是不可行的，例如 ASCII 的字符集就很小，没法包容 UTF-8 的所有有效字符集。

配速 5 到 6, 控制步频，长期跑让后降心率，一次性跑 10-15km ，不要急着提升配速。至少能在心率稳定跑完半马再考虑提升配速的问题。

@haython 你要的是可信环境，而目前除了专门的硬件，手机这种东西，包括微信的客户端都不是可信环境，因此要做到你想要的功能是不现实的。只能提高破解者的门槛，如果利益足够，最终肯定还是防不住的，过度加强会导致成本上升，正常用户体验也会受限。电脑上播放的 DRM 加密视频就是一个典型的例子。

Jwt 主要用来给资源授权的，生命周期很短。几乎不做权限回收控制。如果想要做有状态的会话凭证，又不想维护服务器状态，理论上就是矛盾的。

@codehz 我觉得为了限制这种滥用， 应该将除了 CPU 以外的所有计算机资源都视为受限的，不允许这些辣鸡 APP 随意调用，强奸用户，硬件拥有者应该能够禁止 APP 对任何硬件的访问权限。至少需要给用户一个兜底选择，例如从操作系统层面，直接禁止任何 APP 调用摄像头，麦克风，扬声器。

@kumoilain 我感觉我需要的是彻底禁止一个 APP 使用使用扬声器。或者针对当个软件的音频条件功能。感觉扬声器也应该和摄像头一样，使用需要申请权限。

@ODESZA 百度贴吧，一开就会自动暂停播放声音。

另外同源策略是一大堆策略，不只是 javascript 发起的请求受到同源策略限制，浏览器上几乎所有跨站点的操作都受到同源策略限制，没有同源策略，浏览器这个代理基本上就废掉了。任何时候浏览器都只能允许打开一个单一的站点，而且关闭后还需要清空所有信息才能确保安全。

如果没有 Same-origin policy ，就需要彻底禁用掉 JavaScript, 甚至禁用掉 JavaScript 也不能解决一些致命的安全缺陷。
不使用同源策略，各个网站之间完全可以替代用户做任何事情，在未经过用户的同意下。
同源策略主要是解决帮助浏览器的最终用户消除信任问题，确保针对服务器的请求是服务器自主提供+用户主动提供，而非其它网站的恶意操作。

我的民生银行 APP 开代理都不能用，直接闪退。更别说 root 了。

@redtech 如果不打游戏，这个 5K 是个不错的选择。打游戏是真不行，黑场不行，延迟太高。