@fragrans23 我没搞过 redis 消息队列，我搞过 kafka 。kafka => python asyncio 内部 pub-sub => websocket

后端实现 pub-sub 多简单的事情。python asyncio 可以闭着眼睛给你写一个，我写过。

其他 node.js ，Java vert.x 我觉得也不是难事。

你在自己的后端做这件事啊。。。

后端有个统一的 pub-sub，需要什么 topic 向 redis 增量订阅，不需要的取消。

前端 websocket 去向你自己的后端 pub-sub 订阅，这里就能直接规定每个 subscriber 需要订阅哪些 topic 了。

这样你的后端项目只要加入口机横向扩展，就能迅速扩大规模。毕竟你的 redis 只要抗住每个入口机一个订阅者就行。

@Citrus 是 sudo rm -rf / --no-preserve-root

你自己都没有把自己的需求搞清楚。

你搞清楚了都不用上来发帖问，自己就写出来了。

首先，操作系统本来就不会对文件名排序。排序是文件浏览器的功能。

所以楼主需要做个文件浏览器。

不是，简单的数据结构和算法是程序员的 **基本素质** 啊。

不然连前端都写出来一坨运行起来都巨慢的代码是什么鬼啊（摔）

在 C++ 里面我就 i=0; j=0 开始原地求和，最后设一下 size，最高效。

@AoEiuV020 你说的很对，C++ 的库安装，在 VS 下就是忒麻烦。

所以我用 linux + cmake + conan.io 。这真的无痛，什么 openssl 、cpp-httplib 、libcurl 都是一键安装，直接运行

估计是因为服务器是谷歌的核心服务器，ip 被墙了。

顺便 golang.org 实测不挂梯子无法访问。

？国内无法流畅访问国外的东西，所以谷歌在 google.cn 这个墙内备案的域名上给一个镜像，这不是很好吗

13L 说得对。 对 @nowheretoseek 楼主无力吐槽的主要原因是，tm 一堆根本就不对头的假设，然后推出了让人摸不着头脑的结论。

我 tm 真不知道楼主在一本正经地纠结什么。
----

都说了 Unicode 本质是字符 <=> 数字，你增加字符不就是在码表中继续加字符么？本来就没有 New Unicode，因为每过几年 Unicode 就会发布新的码表，因为增加修订了什么东西。你可以说每一版都是 New Unicode 。

再说一遍 Unicode 是字符 <=> 数字，tm 根本就没规定是 32 位整数。地球文字只有十万多字符，你 20 亿还不够外星文明用，那就用 64 位整数吧（摔）
----

再说编码。UTF-8 的规则几乎可以无限扩展单字符长度。在大部分程序看来都是直接用库解析这坨二进制，比如 libICU 。或者干脆不理这坨东西到底是什么，因为 UTF-8 的编码方式保证了它具有替换安全性（你把它当成二进制 char[] 替换一个合法的子串，不会产生非法的串）。替换、分割、合并，所有这些普通字符串操作都是安全的。这意味着 regex 也是安全的，以及所有一般的字符串算法都是安全的。这 tm 还能有什么问题？

所以为啥用 UTF-8 替代 GBK 这种字符集？因为 GBK 没有局部替换的安全性。

@nowheretoseek

0. 首先楼主要明白一点：字符编码只是一种把文本变成二进制串再变回来的规范。字符串本质都是二进制串。不同的编码能产生不同的二进制串，但是都是二进制串。

这里吐槽一下，这就是没有在 C/C++ 里面摸爬滚打过的坏处了。char* 数组、'\0' 结束符，有这些基础来解释二进制字符串就很容易理解。不然都是从 Java/C#/Python3 学起的，我 tm 根本不知道怎么解释这个常识。

1. 据我所知，Linux 大部分系统核心功能没考虑啥编码的事情。包括文件系统在内都是直接操作二进制串的。像 ext4 这种文件系统，似乎你可以把任何二进制串当做文件名，甚至是不合法的乱码二进制串（反正它不在意，它只在意这个二进制字符串）。

2. 有些文件系统似乎会考虑编码，比如 APFS，NTFS 。

3. Unicode 只是个字符映射表，它的规范是字符 <=> 数字的映射关系。具体怎么变成二进制串有很多种方法

3.1 UTF-8：一个 Unicode 字符被映射成 1~6 个二进制 8 位数字不等。建议楼主学习一下这个编码方法，因为它可以直接解答楼主的帖子里面的所有问题。理论上这种编码方法可以类推到任何长度的可变长字符，比如 1~100 个二进制 8 位数字。

3.2 UTF-16：一个 Unicode 字符被映射城 2 个或 4 个二进制 8 位数字。这个方案应该也能直接类推成任意 2K 个字符。建议楼主学习。也可以解决楼主的所有疑问。

3.3 UCS-2：早期最多能表示几万个字符的 Unicode 编码方案，每个字符固定映射城 2 个二进制 8 位数字。在更小的字符集上和 UTF-16 相同。可能很多人第一反应的 Unicode 就是这种编码方案，但是实际上不应该用这个编码处理很多事情，会造成字符截断问题。

3.4 UCS-4：每个字符固定映射城 4 个二进制 8 位数字。对于地球字符而言这已经足够了。Python3 用的是这个编码。

4. 所以楼主的问题实在是无力吐槽，因为 UTF-8/UTF-16 已经满足楼主的问题了。

事实上是大家真的不在乎

嘈点太多以至于无力吐槽