笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
emoji 存成??，join 报 Illegal mix of collations
备忘一下今晚这个坑，不算新，但每次遇到都得重新翻一遍，干脆完整记下来。
现象有两个。一个是接口在存用户昵称，昵称带 emoji，比如那个笑脸，UTF-8 编码是 F0 9F 98 80 四个字节，入库之后变成两个问号 ??。另一个是凌晨一张报表 join 突然报错：
Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_unicode_ci,IMPLICIT) for operation '='
第一反应以为是字段不是 utf8mb4，查了表结构，列是 utf8mb4 没错，但直接 insert 还是报：
Incorrect string value: '\xF0\x9F\x98\x80' for column 'nickname' at row 1
这才想起来字符集要三层对齐：库表字段、连接层、显示层。表字段是 utf8mb4 只解决一半，连接串那层没配的话，客户端发过去的字符串在入口就被按别的字符集解码再编码，emoji 的四个字节在转换里被丢掉，等到了 MySQL 已经是坏的了。我们 Java 用的 JDBC，URL 上没带 characterEncoding=utf8，驱动走默认，改完连接串、重启应用，新写入的才正常。老数据里已经变成 ?? 的那些只能单独写脚本清洗，好在量不大。
collation 那个 join 更隐蔽。两张表都是 utf8mb4，但一张建表默认是 utf8mb4_general_ci，另一张被同事建表时指定成 utf8mb4_unicode_ci。MySQL 里做等值 join 时，两边 collation 不一致，优化器直接抛上面那个 Illegal mix 的错误；就算有的场景不报错，这种字符串比较也走不了索引——排序规则不同，索引里的字节序跟比较规则对不上，等于白建。
当时报表 SQL join 了四张表，报错字段是个渠道编码 channel_code，varchar(32)。修法两个方向：要么统一表的 collation，要么 SQL 里临时对齐。生产上我选了统一，顺便把整张表的列都刷一遍：
ALTER TABLE t_user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE t_order CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CONVERT TO 会把表里所有 char/varchar/text 列连字符集带排序规则一起转，最省事。注意表大的话它走的是拷表流程，会在某段时间内堵写，低峰跑。急着救报表就在 join 条件后手动指 COLLATE utf8mb4_unicode_ci，一条 SQL 的事。
顺带对比了下 general_ci 和 unicode_ci 的差异：general_ci 按简化规则比较，快一点，但有些西文大小写和重音的处理不符合通用排序习惯；unicode_ci 更接近标准排序，稍微慢一点点。真到 8.0，默认排序规则已经换成 utf8mb4_0900_ai_ci，跟 5.7 时代那两套又不完全是一回事，跨版本迁移时如果表没跟着转，最典型的就是两库看着都是 utf8mb4，实际排序规则各写各的，联表一查就翻车。当时统一 collation 那张 3000 万行的表，CONVERT 低峰跑了十几分钟，期间读不受影响，写会卡在拷表那一段，所以这种动作我都约在半夜做。报表里临时 COLLATE 那条只用来救火，第二天确认线上全统一完就撤了，免得每张报表都挂着 COLLATE 后缀，看多了容易漏改。老数据里那些已经变成 ?? 的昵称，我是写脚本按 emoji 的 Unicode 范围在备注列里翻原始记录，能捞回多少算多少，先补了用户反馈最多的几十个表情，剩下的列了个清单丢给运营定优先级。
顺带把更早踩的 utf8mb4 的坑也并进来。一张老表有 varchar(255) 的唯一索引，5.7 把表从 utf8 转成 utf8mb4 后重建索引，直接报：
Specified key was too long; max key length is 767 bytes
utf8mb4 一个字符最多 4 字节，255 乘 4 是 1020，超了 InnoDB 旧的 767 字节索引上限。5.7 里要开 innodb_large_prefix 同时行格式用 DYNAMIC 才能建 3072 字节的索引，我们当时图省事把唯一索引改成前缀索引（前 191 个字符）才建上。后来 8.0 默认行格式 DYNAMIC、索引上限 3072，就没这限制了。为什么有的表报有的表不报，我当时没细究，应该是建表时 ROW_FORMAT 不一样，先这样记着。
教训收拢成一句话：emoji 存不进去先查三层——库表字段字符集、连接串 charset、终端显示字符集；join 报 Illegal mix of collations 就查参与比较的两列 collation 是否一致；varchar(255) 上 utf8mb4 建唯一索引，先想到 767 字节上限。