@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 在不引入第三方库下就能这么找，是不是挺省事？；）

应该和我一样，之前有发帖：/t/1118730

@hronro 使用 WebRTC 的话 是可以 UDP 的

@ysc3839 #14
不应该，可以重新执行一下：
~/.vscode-server/code-latest --patch-now

上面会显示被修改的文件。比对一下就知道了。

也可以确认下 VSCode 客户端和服务端的版本号是否匹配：
~/.vscode-server/code-latest --version

不同版本的 server 路径不一样。

@yanqiyu 这不就是 NFS 嘛，D-state 还 kill 不掉（悲）

@est #29 其实这不是解压软件的问题，而是 OS 抛出错误后，应用继续往上抛了而已。我来解释一下实现重试的难点。

假设应用通过 fopen()打开文件，fread()到一半出错了，这个时候如果重新 fopen()，会面临一个版本问题：我重新读的文件还是原来那个吗？有没有被修改过？这些应用都不能判断。

虽然这些是 corner case ，不过一旦遇到都是 bug ，可能造成数据丢失。最保险的做法就是将错误原样抛出去，fail-fast 思想。

这个应当是 OS 层面的责任，比如 macOS 在 SMB 连接断开时，应用尝试 read()并不会立即失败，而是阻塞住直到连接恢复（或者超时几分钟后失败），通过 SMB 协议确保读到的文件没有发生改变。我不太熟悉 Windows 上的机制，不过可以确定这个在应用层是没法处理的。

这种情况网不行也没什么好办法啊，网络会中断就先解决网络问题。

或者 NAS 和电脑之间套一层 WireGuard ，物理链路中断时，WireGuard 并不会断，等恢复就好了。

要么就 NAS 电脑网线直连，配静态 ip 传输。

要么就把电脑硬盘拆下来，塞 NAS 里内部传输。

@tt0411 #9 是的，我这里就是简化了所有步骤：

- 将 patchelf 做成了 libpatchelf 静态编译进去 (libpatchelf/libpatchelf.h)
- 自带编译好的 glibc 和 libstdc++
- 修改了 glibc ，将系统目录改为当前目录，这样改 .interp 就行了，不用再改 rpath 。事实上这么做也更安全。(patches/glibc.patch)

然后加上了额外的功能，就是自动处理插件。官方的方案只能让 server 能用，实测很多 native 插件还是不行的。

做的就是一个开箱即用，不用配参数。