文件系统中元数据的隐患——字符串

        文件系统避不开目录管理，目录管理离不开文件名和文件路径。文件名和路径直指字符串和层级结构。每一个问题都挺麻烦的。这里我们浅谈一下字符串的问题。

字符

        ASCII算是一个很小很经典的字符集了，也体现了很多精髓。大致分为字符分类，如可显示字符和不可显示字符（控制字符和专有字符等），有大小写转换（大小写间差值固定），1字节编码。其他字符集如 Unicode可以对等着考虑，需要更多字节，能表示更多字符还可扩展，编码规则复杂，引起的问题也更诡异。这部分可以了解下 go 的 utf8包、unicode 相关材料。

        相对于文件系统，需要考虑文件名的字符类别，元数据流的编码方式和字符集转化情况。很多对象存储的命名都只限于ASCII的可显示字符，是很明智的举动，减少了很多麻烦事。

字符集

        如果你觉得文件名不就是一个 string 嘛，那可能还在小白阶段。每个类型后面的存储原理、编码解码、字节转换，以及多类型相互转换和展示、编码转码、大小写转换，每个拎起来都能写一大篇，这里我们只说关键的点。

        持久化字符集选择：一般用 mysql 的建表都会有CHARSET属性，可以设置为utf8(等同于utf8mb3)和utf8mb4。可以简单理解为每个字符最多用多少字节表示，字符所用字节数在首字节有固定前缀标识。业务需要聚焦自己的字符串信息圈定的是哪些字符集，字符集哪些字符的编码，以及业务链路中（直至持久化），字符编码的方式变化。每一步都尤其重要，否则，将被卷入各种各种的乱码和丢信息的漩涡里。

        综上，其实还需要聊一些编码和解码的东西，但是每一个东西都很大。和业务的直接关系很小，但是本质都血肉关联。待我好好整理一番，后续连更看看以一种怎样的方式呈现。欢迎大家相互交流！