例如，你输入了 admin，楼主的程序会先计算 admin 的 md5

ee = 21232f297a57a5a743894a0e4a801fc3

然后接下来的每一行，就是从 ee 中截取一部分 ，我们以倒数第二行为例：

eee = 21232f297a57a5a743894a0e4a801fc （截掉了末尾一位）
c3284d0f94606de1fd2af172aba15bf3


对这个截取出来的字符串再做一次 md5

aa = 0bec65c106b31f939d884627c52360d5

然后，这就是倒数第二行的内容了，其它各行类似。

@bitdust #1
恩，我翻资料的时候就发现，国内关于这类『老古董』的资料非常的少。
而许多国外网站有着详细的整理，还有许多人在努力维持着这些老古董的运行。

了解这些编码的发展历史，有助于了解当时的人们遇到的问题和解决的思路，也是蛮有趣的。

@limbo0 #14
UTF-8 总是第一个字节在前的，也可以换个角度来理解为：UTF-8 总是 大端序


前缀编码的主要好处应该是可以无视传输过程中出现的局部错误吧，和字节序关联不是很大。

关于 『 8 字节 Emoji 』，这里需要做一点修正，由于这类 Emoji 事实上也是『组合』出来的，并不是严格意义上的单个字符。（但是中间都没有 U+200D 这个连字符）

我了解到的这类 Emoji 主要分两种：
1 、Emoji flag sequence
也就是国旗这一类，比如我举例的中国国旗🇨🇳，其实是由字母🇨和🇳组成的。
相应的列表可以在这里找到： https://en.wikipedia.org/wiki/Regional_Indicator_Symbol#Emoji_flag_sequences

2 、Emoji 控制符
最典型的就是 Emoji 的肤色控制 ，Apple 在 iOS 8.3 引入的多种肤色 Emoji，其实就是 『表情』+『肤色』拼接在一起组成的。比如 👦🏿 其实就是 👦+ 🏿。
https://i.loli.net/2020/03/29/qjWAexMNQwrcpbG.png

在不支持这个特性的系统上看，就会看到一个默认肤色的表情+色块。（使用 Android 手机的朋友应该会经常看到）

除此之外，还有键帽序列、VS-15/16 等控制符也可以实现类似的控制功能，他们都会导致 8 字节 Emoji 的出现。


BTW：U+200D 其实也是控制符，不过这家伙出场至少就是 11 字节了。

🤓 楼主的这篇文章倒是提醒了我，之前写的关于更冷门的博多码的文章也分享了一下 /t/657280

感谢楼主分享，补充几个点。

UTF-8 是如何避免字节序问题的 ？
字节序问题本质上是对于 『跨字节』数据结构（例如 4 字节的 int ）的存储顺序差异。
UTF-8 虽然是『多字节』编码，但是内部每个字节是互相独立表示的，从字节序角度来看，可以当作单字节看待，自然也就不存在『跨字节』的问题。


UTF-8 能被大量推广，和自身的变长编码属性也有很大关联。
UTF-8 对于 ASCII 字符只需要 1 字节，但是对于 CJK 字符，都需要至少 3 字节。
而 GB-2312 虽然字符集偏小，但是对于常用汉字的表示只需要 2 字节。
在 ASCII 字符集为主的互联网世界，这样是更省空间的，但是从某种角度来说，其实 CJK 字符集的使用着是做出了牺牲的。

Emoji 并不是一定 4 字节，比如说我们看一下中国国旗 🇨🇳，就是 8 字节的：
https://i.loli.net/2020/03/29/JEgZYmiORQ6hPdH.png


Emoji 还存在 U+200D 这种『骚操作』，这个零宽连字符可以将多个 Emoji 连在一起，造出新的 Emoji：
https://i.loli.net/2020/03/29/J4K5dZMg2DqRp9O.png

比如这个一家三口 ，👨‍👩‍👦其实就是 『男』+『女』+『小男孩』

@NonClockworkChen #3
我又看了下，发现我们遇到的问题好像不太一样，我是以字母为单位重复，你这个直接是以词为单位重复了。

你的情况："apple" -> "appleapple"
我的情况："apple" -> "aappppllee"

另，我的蓝牙键盘（ IKBC ）在电池电量低的时候，会出现类似卡键的情况，
效果类似："apple" -> "aaaappppppppplllllllllllllllle"

补图：
https://i.loli.net/2020/03/28/DLHXI72AFtzg3id.png

前几天我的输入法出 bug 的时候遇到了这个问题，重启解决。

这个博客主题…… 吓我一跳……

@est
=。= 人家明明补充说明了：满足一堆条件的情况下，才可能会实现这种高难度结果

@leo108 #35
显然我是在瞎扯的，我也讲了 『既然对方不想好好沟通，那么就一起剑走偏锋』。
不太可行的原因，主要是因为按照我扯的原则，这 3000 仍然是要楼主出的。

但是确实也有可能会有效，主要因为公司需要对固定资产入账报税，而电脑类资产可能会做 3~5 年的折旧计划，也就说机器的账面价值确实会逐步降低，但是是否能低过市场价确实不好说。

补充一下上面视频的国内源：
https://www.bilibili.com/video/av31038567/

不属于正版，但不侵犯版权。

比如 LTT 的节目中，用于评测的测试机，上面的 Windows 都没激活，Linus 还专门做了一期视频来解释：
https://www.youtube.com/watch?v=M3bezYerYxQ

强行区分的话，个人这样理解：

Documents -> 用之前最好看一下
Help Center -> 出问题的时候看
Knowledge Base -> 无聊的时候看

我也遇到了多次要一直弹的情况，我一直以为是 Setapp 的原因，但是这两天发现 TextMate 也出现类似情况了，不知道和楼主的原因是否类似。

卖掉，换了 24 寸 4K 开 200% ，和 32 寸 2K 开 100%

@woncode #2
嗯，很多人就是因为不了解 Client Side Session，才对 Session-ID 产生了误解。


关于 JWT，主要还是因为很多人会直接将 JWT 和 Session 拿来做对比，所以我希望能明确这两个东西不是『同类型』的，不同维度并不是想说毫无关联，只是代表类型差异。

他们之间的关系应该是这样：
Session 是虚拟概念，Client Side Session 是它的一种实现思路，而 JWT 可以作为 Client Side Session 的安全容器。

需要注意的是，JWT 仅仅是因为自身特性决定了 『可以』作为安全容器，这就好些 Cookies 『可以』用来存储 Session-ID 一样，只是可选项，非双向绑定，所以我觉得 JWT 和 Session 间还是有不小的距离的。

另外单纯从 JWT 的定义来讲，它的能力也不止于此，完全可以应用于其它情况，参考 RFC：
https://tools.ietf.org/html/rfc7519
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters.


当然，这些都是形式，也不需要太过于纠结，了解本质就好~~