#2 @qaz741wsd859 入站出站都生效。主要针对出站，入站还在测试中。

#3 @NewYear 不是，这个不是协议。和是否有公网/开放端口没有关系。可以通俗的理解为：在正常的 TCP 传输中加一点 HTTP 特征，骗过限速。

FakeHTTP 只处理已有的 TCP 报文，自身不提供服务。

不关机，似乎说的大多数是 MacBook 。并且 MacBook 插电源和不插电源差距也挺大的。
插电源的话，合盖还能 ping 通，还能 ssh 进去。跑什么命令都没问题。
不插电源，过一段时间就掉线了，ssh 也不行。应该是进入了更深层次的睡眠。

Mac Mini 应该是一直插电的，可能就没有那种体验了(?)

@xiangyuecn #20
你确实发现了一个令很多人困惑的地方：SQL 中的“相等”，其实是概念上的等价，不是完全的相同。

排序规则（ collation ），规定了 order by 的顺序，也规定了哪些字符串是“相等”的，等号运算会返回真，group by 会被分到一组。
如果对排序规则了解不深，我推荐阅读一些相关的资料，这样奇奇怪怪的问题就能迎刃而解了。

以 MySQL 为例吧，设置 set collation_connection=utf8mb4_general_ci;
select 'abc' = 'ABC'; -- 你会发现它们是相等的，结果为 1 。
select hex('abc') = hex('ABC'); -- 你会发现结果为 0 ，不等。

select 'abc' = 'abc '; -- 相等
select length('abc') = length('abc '); -- 不等

其实也没什么问题。因为“排序规则”规定了它们等价。但是它们又不是同一个东西，所以套一层函数就不等了。
当然你也可以选一个 NO PAD 的规则，让它们自身不等。

set collation_connection=utf8mb4_0900_ai_ci;
select 'abc' = 'abc '; -- 不等
select length('abc') = length('abc '); -- 不等

这些都是可以配置的，并且不同数据库上的默认配置可能有所不同。

希望对你有所帮助。

@lance6716 #18 优秀 d(^_^o)

@sapphire #89
不是应用，我在做一个基础的跨平台库，尽力兼顾简洁、性能、准确性。调库直接转换应该是省事，但是我不想搞得太臃肿（比如在 OpenWRT 路由器下面也能运行？）
其实支持中文只是我的一个想法，当初程序只支持 ASCII 。后来我发现引入 UTF-8 代价很小，大多数代码都没问题。在后来我引入了 Windows 支持，就遇到了 GBK 。它对原先 ASCII 的代码兼容不好。然后我就吐槽了。

@HTravel #82 那肯定是不敢，不然我也不会发帖了。所以回到标题：大家快点统一 UTF-8 ，少一层转换，大家都省事。
对于 Windows ，应该把 ANSI API 的 UTF-8 支持好。事实上 POSIX 的大多 API 就是微软所谓的 ANSI API 。
Unicode API 的想法是好，但是最后 UTF-16 还是变成了变长编码（代理对），实在是又吃了亏。（路线走错了）

@HTravel #80
是简化后的代码，因为这个不是重点。整块太长了，再加上异常处理流程等等，我估计大伙都不愿意看。

入参是被 realpath()标准化后的路径，不存在这种了。

@lepig #5
如果是全新的业务，那么用默认的排序规则 utf8mb4_0900_ai_ci ，或者它的哥们（大小写敏感/不敏感）都是 OK 的。
这里考虑到一些已有的老库，比如它们的排序规则已经定在 utf8mb4_bin 了，那么除非重新进行完整的测试，那最好还是别动它，一般还按原来的用。

@wuyiccc #6
因为其实问题不在这（虽然有一定逻辑关系在里面），问题在于查询优化。

可以看一下 my_like_range_mb() 的实现，它的注释里面有：

> "a" is the smallest possible string for NO PAD.
> "a\0\0..." is the smallest possible string for PAD SPACE.
> "a\xff\xff..." is the biggest possible string.

其实 MySQL 是意识到这个问题的。但是后面的 if 条件是 (cs->state & MY_CS_BINSORT) || cs->pad_attribute == NO_PAD
单独把 MY_CS_BINSORT 加入判断，我觉得这个是没有理由的，且造成了 bug 。我的 patch 就是把它去掉了，测试用例可以通过。

@wqtacc #2 你说的对，但是不能否认 utf8mb4_bin 它确实有 bug 。其实不止这一个有问题，可以试试 gbk_bin 、gb18030_bin 等，也是一样的。

@Nasei #3 字符集排序规则行为是不能改变。但是如果改变 like 转化为范围查询的内部逻辑呢？那就是可行的了。其实是能修的。

接力： https://riskbird.com/#/?inviteCode=D7B1FFAE25D9F7B7

@shimanooo #70 UTF-8 保证 `0x5c` 就是 `\`。正是我想说明的地方。
可以看图：
https://i.imgur.com/ioirsYp.png

0 开头只有 0yyyzzzz 的形式，是单字节。多字节都是 1 开头的。虽然多字节浪费了一些空间，但是处理起来高效呀。

@datou #50
是需要支持的，有认证，但可以有配置使用其他字符集。对于信创看来，UTF-8 （或者准确说 Unicode ）显然不够自主，万一 IRG 卡你脖子不收录新汉字怎么办 https://i.imgur.com/agAJ0Rd.png

@realpg #64
> 问题从来不在编码
我不赞成，编码可以分优劣。

> 而在于你写的代码
在 GBK 的条件下，代码确实是有问题的。

> 你使用了一个非跨平台的各自平台编译器 你想让程序跨平台能运行 那么默认就是你自己处理各个平台兼容性问题
> 而你处理不好就开始怒喷了
是的，我正在写一个跨平台的 C 库，正在处理这些问题。与其说“处理不好”，倒不如说“很难处理好”。
例如，很多人都说过，不要把 Windows 用户目录设置为中文，因为很多软件会报错。具体地说，我在上面举的 musl execvp() 函数，最终就是用 char * 遍历的。
当一个问题普遍存在时，我们就要思考问题的根源，比如比较 GBK 和 UTF-8 在设计上的优劣。

跨平台的东西也是人写出来的，方便了大家，但是写起来不舒服，请允许我吐槽一下。


@si #65
> GB2312 制定的时候两个字节都是大于 0x80 的，微软搞 GBK 的时候为了塞下更多汉字把 0x40-0x80 也用了。
赞，这么看来 GB2312 倒是完全兼容 ASCII 的。我不认可 GBK 的原因主要就是第二字节侵占了 ASCII 码范围，产生了麻烦。最终 GB18030 还是拓宽到了四字节，当初不如直接加字节来的痛快。

@ysc3839 #44
原样传递是一部分，POSIX 程序还是会处理的字符串的。比如 musl 的 PATH 变量，就是通过 strchrnul() 直接分割冒号的。这个函数只按字节处理。看了一下 glibc 也是一样的。
非 UTF-8 下就有出问题的风险。所以 UTF-8 的设计是很好的，GBK 和 GB18030 就差那么一点（其实我想说明的也就是这个意思）

https://git.musl-libc.org/cgit/musl/tree/src/process/execvp.c

@bbao #13 其实 GB 系列编码不算老吧，GBK 有年代了，但是 GB18030-2022 是新出的，而且属于强制国标，国产化适配必须的。像不少系统原来只支持 UTF-8 ，现在要支持使用 GB18030 ，你说到底算进步还是退步哈哈

@bbao 别啊，我现在工作了，虽然时间不长。或许是看到了我的历史帖子，那是我注册 v 站的十周年纪念，不是说今年（

@geelaw #34 其实 936 是包含了平片假名的，只要没有生僻字勉强还行（
所以我也很好奇其他 posix 程序是怎么移植过来的，毕竟大多数 API 都是 char *，到最后一步再转成 LPCWSTR 么，好像也有问题。

好在 Windows 10 1903 往后可以通过 manifest 指定 code page 为 UTF-8 (65001)了，以后 ANSI API 应该还有发展空间：
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

@geelaw #5
@yk000123 #29

抱歉，其实是因为完整的代码逻辑很长，这里是我随手举的例子，没有完全说明清楚。传入的路径是标准化后的绝对路径（如 realpath() 处理后的字符串），所以不考虑 ./ ../ // 等情况了。移植到 Windows 上是做了 #ifdef _WIN32 处理的, Linux 上不做反斜杠判断。

@geelaw #6
Linux 上确实可以不是 UTF-8 ，正如中文 Windows 上也不一定是 GBK （可以手动改成实验状态的 UTF-8 ），但可以认为已经成为了事实上的标准。绝大多数用户使用默认配置就是这种情况了。

@w568w #12
在 UTF-8 上应该是可靠的（只要不是去数字符数的话）。这里的困境是：我也知道有问题，但是似乎没有办法简单解决。正如需求就是简单的数斜杠，那么真的需要引入一个 Unicode 库吗，其实我自己也是怀疑的（？）
另外 mbtowc()，wc 是 widechar 吧，不是 NULL 空终止。

@minami #22
其实是说我的代码有 BUG 啦，这个代码确实学艺不精，其实我也想知道 *应该* 怎么写，或许你也可以举个例子 hhh 这是很多人都会犯的错误。但在 UTF-8 ，它是允许你这么遍历的。一个是方便我这种懒人，二是让那些欧美地区人写的这类代码也能正常跑在中文上。
比如说 strstr() 找子串，GBK 是用不得的。utf-8 在不引入第三方库下就能这么找，是不是挺省事？；）