前段时间，遇到朋友的求助，说以前运行的好好的系统现在出问题了，而且看不懂报错到底是什么意思。
我仔细看看报错信息，应该是MySQL数据库报出来的，大意是说：collation不兼容，一个是 utf8mb4_0900_ai_ci，另一个是utf8mb4_general_ci。
utf8mb4_general_ci这玩意儿我见过，是针对utf8mb4编码的collation，但是utf8mb4_0900_ai_ci是啥，我也没见过。
于是我问他，这玩意儿从哪里出来的？
他说：“我也不知道，我完全没见过啊。再说，我数据库编码已经是utf8mb4了，怎么还会有这么多名堂？”
看他着急又不知所措的样子，我便花了点时间来研究，还真学到点新知识。而且我也发现，有许多程序员天真的以为“用了UTF8就等于做了国际化了，不用再担心编码问题”。看来，这个话题还真值得多讲讲。
首先从utf8mb4_0900_ai_ci这个诡异的名字说起。
Unicode编码的诞生，是为了解决之前各国的计算机文字编码自成一体的问题。不同国家采用不同的编码，自己用还算正常，但是跨文化交流必然会出问题，更无法解决“在同一篇文档里又要显示中文又要显示韩文还要显示日文”之类的问题。
有了Unicode，地球上所有的文字都有独一无二的编码（Code Point，也就是为它分配的码值，或者说“逻辑代号”），前述问题就解决了。
但是Unicode（有个相关的名字是UCS，Universal Coded Character Set，二者基本等价）只确定了码值，或者说，只分配了逻辑代号。至于这些逻辑代号在实际使用中如何存储，如何传输，那是另一个问题。而UTF-8，就是解决存储和传输等问题的“实际方案”。
实际上，UTF的全名是Unicode Transformation Format，也就是“Unicode变换格式”。这里的“变换”，基本可以类比为：要告诉别人明天早上九点来开会，到底是发邮件呢，还是打电话呢，还是写纸条呢，还是直接去敲门打招呼呢？。
所以，Unicode的变换格式不只UTF-8一种，还有UTF-16、UTF-32等等。UTF-8使用比较普遍，因为它是变长编码，如果只传输ASCII字符，则每个字符只需要一个字节。因此，如果数据中包含大量的ASCII字符，那么UTF-8可以节省很多存储空间。
老一点的程序员大概都知道UTF-8，在MySQL中写作utf8，没有横线。如果要用MySQL存储多种语言的字符，那么把字符集（character set）设定为utf8是合适的选择。注意，MySQL中必须指定utf8，而不是Unicode。因为Unicode只是逻辑规范，utf8才是具体存储和传输的格式。
那么，utf8mb4_0900_ai_ci什么意思呢？
我们分部分来看这个名字，先从开头看起。
utf8mb4，这个名字许多人大概熟悉。如今🖨️🛒♥️☎️🌹之类的emoji表情已经大量使用，但MySQL之前的的字符集（character set）是utf8（更准确的名字是utf8mb3，一个字符最多使用3个字节来存储），只能存储编码值从0x000到0xFFFF之间的字符。
然而，emoji表情字符的码值超过了0xFFFF，按照UTF-8规范，存储时需要用4个字节。正因为如此，MySQL才提供了utf8mb4的字符集。如果把数据库表的字符集设定为utf8mb4，就可以正常存储包含表情字符的文本了。
中间的0900，它对应的是Unicode 9.0的规范。要知道，Unicode规范是在不断更新的，每次更新既包括扩充，也包括修正。比如6.0版新加入了222个中日韩统一表义字符（CJK Unified Ideographs），7.0版加入了俄国货币卢布的符号等等。
如果支持新的Unicode规范，就可以直接享受好处，像对待普通字符那样对待这些新字符，当然是好事。
以前的MySQL虽然也会跟随Unicode的更新，但速度太慢了。MySQL 5.7的第一个发行版MySQL 5.7.1是2013年4月23日面世的，它包含的最新的Unicode规范是Unicode 5.2，发布于2009年10月。即便是2020年1月13日发布的MySQL 5.7.29，仍然是这样。
然而Unicode规范早已升级了很多版，即便是9.0版本，也发布于2016年6月，过去了好多年了。到目前为止，最新的版本已经到了12.1，发布于2019年5月。所以从5.2更新到9.0，看起来是一大进步，其实也只是补课而已。
Unicode在不断更新，来源：维基百科
最后两部分_ai_ci，ai表示accent insensitivity，也就是“不区分音调”，而ci表示case insensitivity，也就是“不区分大小写”。
所以，utf8mb4_0900_ai_ci到底是个什么东西呢？其实，它是个collation。
说起“字符集”，许多人想当然认为，给每个字符分配了一个编码，并且能存储、能传输，这就够了。其实这当然不够，我们不但需要给每个字符分配编码，让它们能存储、能传输，还需要定义一套关系来组织它们，找到它们之间的联系。这套关系的定义，就是collation。
collation定义了哪个字符和哪个字符是“等价”的。所以如果指定“不区分大小写”，那么a和A，e和E就是等价的，这样查找时就会方便很多。但这还不够，世界上的文字很多，所以才会有“不区分音调”的要求，这时候e、ē、é、ě、è就是等价的，那么假设我们要进行拼音查找，只要按e去找就可以全部列出来，很方便。甚至，它们也和ê、ë也是等价的，这样就更方便了。
collation也定义了字符的排序规则，如果按照“字符顺序（而不是简单的‘字母顺序’）”来排序，哪个字符应当排在哪个字符前面。所以，尽管“啊”、“副”、“德”三个字的拼音开头分别为A、F、D，但直接选定collation为utf8mb4，它们并不会按照“啊”、“德”、“副”的顺序排序，而是会排成“副”、“啊”、“德”。如果你希望把中文字符按照拼音（英文字母）来排序，指定使用gb18030_chinese_ci作为collation就可以了。
当然，要补充的是，collation依赖于字符集（character set），所以把gb18030_chinese_ci作为collation，就要求字符集是gb18030，而不能是utf8mb4。
这也很好理解，字符集定义了可以使用的字符，对应的collation定义了字符之间的关系。如果collation不依赖于字符集，那么很可能出现“有些字符没有关系定义，不知如何判断等价和顺序”的问题。
到这里，那位朋友的疑惑就解开了。MySQL 8.0之后，默认collation不再像之前版本一样是utf8mb4_general_ci，而是统一更新成了utf8mb4_0900_ai_ci。
不幸的是，这位朋友的系统是一路升级上来的，所以之前建的各种数据表，它们的collation仍然是utf8mb4_general_ci（这个名字够自负，这个例子也提醒我们，不要低估技术的发展，不要把话说得太满），而新建的表是utf8mb4_0900_ai_ci。如果，恰好遇到包含字符串相等或者大小比较的联表查询语句，而关联的表又使用了不同的collation，MySQL就无法决策到底应当使用哪个，就会报错。
既然如此，解决办法也很简单，用alter table table_name collate utf8mb4_0900_ai_ci显式统一所有表的collation，问题就解决了。
我们可以多想想，把character set和collation分开，到底有什么好处？其实好处很多。如果把字符看作个人，character set就相当于验明正身，给每个字符发张身份证，而collation相当于告诉大家，排队的时候谁在前谁在后。collation有多套，就相当于可以灵活按身高、体重、年龄、出身地等等因素来排序，却完全不会受到身份证号的干扰。
实际上，MySQL 8.0中的collation也确实有多套。从utf8mb4_0900_ai_ci这个名字就可以看出来，起码还有utf8mb4_0900_as_ci，也就是“区分音调”的collation，此时e、ē、é、ě、è就不再是等价的。另外还有utf8mb4_0900_as_cs，此时e和E也不等价了。只要在查询时指定不同的collation，就可以享受这些好处，十分方便。
这个问题本来不麻烦，为什么会难住人呢？原因不复杂，你去看关于MySQL和Unicode的中文资料，绝大部分都是告诉你，utf8或者utf8mb4就可以解决问题了。因此，不少程序员完全意识不到还有collation这种东西。
所以，这些程序员理解的“字符集”就只有一堆孤零零的字符，根本没想到还需要定义字符之间的等价和排序关系。而这恰恰是最可惜的，因为他们完全错过了“举一反三”的启发，许多类似问题也就缺乏解决思路。要知道，哪怕你做的不是国际化的业务，也可以从collation中受益的。
我们都知道，电商系统的订单处理是一个流程，其中涉及许多状态，比如“已下单，未支付”、“已支付”、“已确认”、“已拣货”、“已发货”等等。
有程序员看到这个需求，想当然就按照先后顺序，用1、2、3、4、5来表示对应状态，确实简单不会出错，也方便先后对比，比如要查找所有“已确认”之前的订单，就查查“已确认”的状态码是4，那么找状态码<4的订单就可以。
然后，有一天，忽然要在两个状态之间加入某个中间状态，比如“已确认”之后需要新的风险评估，通过了才可以去拣货，怎么办？总不可能在3和4之间加一个3.5吧？因为这个数据字段本来就是整数型啊。
所以“有经验”一点的程序员会改改，一开始就不按照1、2、3、4、5这样来分配状态码，而是按100、200、300、400、500，留足空隙，这样就避免了3.5的尴尬，直接给“风控系统已通过”分配350就可以了。
但这仍然不够。如果业务忽然要求既有顺序要变，比如之前“已确认”在前，“风控系统已通过”在后，现在要求“风控系统已通过”在前，“已确认”在后，该怎么办？350总不可能大于400呀。
如果你了解了collation就会发现，这是同样的问题。数据的标识和数据的有序性应当隔离开来。标识是一套规范，有序性是另一套规范，两者可以随意组合。你看，Unicode字符的排序可以按照字符的编码值来，也可以按照其它规范来——加载不同collation就是了嘛。
所以，“已下单，未支付”的代码就可以是OUPD，“已支付“的代码就可以是PDED，“已确认”的代码就可以是CFMD…… 它们只用来做唯一标识，没有任何其它意义。然后在外面定义一套顺序规则，比如OUPD < PDED < CFMD，然后提供一个查询接口，做任何比较的时候都查询这个接口就好——实际上许多语言可以自定义compare函数来做排序，道理就在这里。万一将来要改业务流程，比如加入新状态，或者更改状态的先后顺序，也只需要做一点点更改，规则查询接口保持不变，其它地方更是保持原封不动。
最后我想补充的是，即便你有非常多的软件开发经验，但如果要做“国际化”的业务，仍然会面对许多想不到的问题——e、ē、é、ě、è、ê、ë的等价问题就是一例。这类问题，不亲自经历是很难想象的。
From Life Sailor, post MySQL升级8.0的新故障，utf8mb4_0900_ai_ci是啥？
家长应当和儿童，尤其是低龄儿童谈论“空气动力学”吗？ 我的答案曾经是非常肯定的：不应当。不要说儿童，就是成年人也不见得理解这些抽象的概念，与儿童谈论这些名词，只会让人望而生畏。身为父母，我们应当做的是，以孩子能理解的、感兴趣的方式谈论相关的具体问题，但绝对不要提这些大词。 不过世界的奇妙就在于，父母对教育并没有绝对的权威，总是需要根据实际情况来修正自己的观点。在“空气动力学”的问题上，我就吃到了教训。 那是一个下午，家里小朋友在iPad上看完他最喜欢的Blippi（这个节目我之前介绍过，对80后父母来说，Blippi可以理解为“带你见识各种新鲜玩意的董浩叔叔”），忽然抬起头来问我：“爸爸，你知道什么是aerodynamics吗？” “什么？你问我知不知道什么是aerodynamics？”我的下巴都要掉下来了。“空气动力学”这种词还是上中学时，身为军迷的我们在《航空知识》上知道的。再往后英语好一些，能看原版科普视频了，才知道“空气动力学”的原文就是aerodynamics。可是，我家这个还没上小学的家伙，竟然就能真诚地瞪大眼睛，一本正经地问我“知不知道什么是aerodynamics”。 (more…)
我本来是不应该认识孟老师的。 2001年，我在寝室夜谈里第一次听到孟老师的名字。当时有同学说“公共选修课的《法学概论》讲得真好，那个老师叫孟繁超”，开始我不怎么在意，慢慢才发现这么说的人还不少。那个年月网上的资料正丰富，出版管制也不那么严格，刚进大学不久的我正自由自在地看得过瘾，心想“大学里的法学概论讲再好，能讲些什么，还不是教科书上老一套”，所以这种课，不听也罢。 但生活就在这么奇妙。那年冬天，有天中午我吃过饭正准备午睡，忽然有人敲门问“计算机系有位叫余晟的同学在这里吗？” 大中午的谁会来找我？我正好奇这个问题，门一推开就有同学喊“孟老师，孟老师来了”。 那是我第一次见到孟老师，中年人，国字脸，身材高大，打扮很精神，披在身后的深色大衣让我一下子想起电影里的斗篷。他笑眯眯地说“你是余晟？听同学说你搞电脑很厉害，我家的电脑坏了，想请你去看看。” (more…)
中国人大概都对历史有一些特别的偏好。对我们普通人来说，历史首先是文化的象征，一个人“懂历史”，基本等于这个人“有文化”；历史也是民族自豪感的来源，哪怕考古上仍然存在争议，但是“五千年文明”的说法是普通人都耳熟能详的。 不过等我长大之后才发现，这种偏好大概还有更深层次的原因，那就是历史看起来有种道德的意味，因为我们从小就熟悉“以史为鉴”的智慧，也熟悉各种“历史的选择”：每当我们对现实感到失望、困惑的时候，我们经常去历史——而不是先贤的智慧中——中寻找解答。找到曾经发生的类似的故事，就可以预言未来的结局。 于是乎，失望也好、困惑也罢，总归会有光明的未来，历史总会给我们支撑的信念。 我曾经很相信，熟谙历史是种智慧，而且是深层次的智慧。但是看得越多、经历得越多，我就越觉得，这很难称之为“智慧”。 为什么？ (more…)
“无人出租车要来了”。以百度“萝卜快跑”为代表的无人出租车，眼看就要在国内多个城市成规模运营。 熟悉IT的人都知道，IT的独特优势就在于“大规模扩展时边际成本极低”。在软件时代，微软开发的Windows，多卖一份的成本只是多刻录一张光盘而已。在无人驾驶时代，从10辆车到10万辆车的成本，也遵循同样的规律。换句话说，一旦模式“跑通”了，就可以迅速大规模铺开。无人出租车的大规模应用，也是“指日可待”了。 只不过，新技术这一次似乎没有那么激动人心，反而引起了很多争议——无人驾驶出租车大规模推广，会不会影响广大出租车、网约车车主的收入甚至生计？如果是，这样的技术进步，真的是我们所需要、所期待的吗？对于这个问题，不同的人有相差迥异的答案。 按照我的观察，许多人对此是相当乐观的。理由在于，“技术的每一次飞跃发展，虽然有阵痛，最终都创造了更多的新岗位”。既如此，无人出租车短期“看似”抢了许多人的饭碗，但也只是短期的“阵痛”而已。看看历史，纺织机的发明，蒸汽机的改良，汽车的诞生，无不证明了“阵痛说”的正确性。 坦白说，这种观点我是怀疑的。 (more…)
因为小朋友放暑假，近期带小朋友回国待了几个礼拜。最深的感受就是标题所说的：松弛一点，愉快一点。 我第一次突出意识到这点，是在上海下飞机乘地铁。当时我们乘的直梯就要关门，远远看见有个年轻小伙子跑过来，我连忙按住开门按钮，并招呼他”别着急，慢慢来“，等他进了轿厢才关门。本来我以为大家起码会打个招呼，露个笑脸，因为我已经习惯如此，但完全出乎我意料的是，他进来之后对我们完全视若不见，自顾自掏出手机，盯着看得入迷。 我继而发现，不管是在电梯里，站台上，还是车厢里，虽然四下里都是广播”请扶好站稳，抓好扶手，不要看手机“，但是似乎人人都盯着自己的手机。年轻人在打手机游戏，年纪大一点的在滑各种小视频，还有不少人在聊天软件里打字如飞……对着屏幕的表情都很生动，可是一旦抬起头来，似乎马上又换了个人。 后来又有一次，我乘地铁的时候，因为比较拥挤，一个小伙子倒退时踩了我一脚，他大概意识到了，很快把脚挪开，脸上闪过一丝不安，马上又恢复正常，我也没有计较。不幸的是，过了十来分钟，他又踩了我一脚，同样是先有一点不安，很快又恢复正常。 这次我忍不了了，于是我开口告诉他：“小伙子，你已经踩了我两脚了。” (more…)
前几天，国内朋友发来一条消息，原来是乌克兰F-16坠落，飞行员丧生的新闻。我本来以为他要讨论此事的真假和原委，他真正的问题却完全出乎我的意料： 新闻里说，飞行员叫阿列克谢·“月鱼”·梅斯，对应原文是Alexei “Moonfish” Mes，为什么会有人把“月鱼”写在自己的名字里，而且还打引号。 之前看新闻，乌克兰还有一个著名的飞行员叫安德烈·“果汁”·皮尔希科夫（Andrii “Juice” Pishchykov），怎么“果汁”也是正式的名字？ 未必Moonfish和Juice之类，还有什么特别的含义吗？…… 这堆问题看的我有点想笑，因为自己以前也很苦恼外国人的名字，只有在国外长期生活，才逐渐搞清楚这其中的名堂。所以，除了解答朋友的问题，我也把自己的解释写下来，搞清楚两个最不容易理解的点，就不会对外国人名有那么多问题了。 (more…)
View Comments
感觉用状态码做例子不是很好。在我看来，状态码设计是一个破坏MECE的问题，导致的不协调。
讲的很生动有趣，解决了我的疑惑，顺便还提到了状态码的排序，感谢作者٩(ˊᗜˋ*)و