笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
批量文件 GBK 转 UTF-8，iconv 中途报错停住怎么办
同事从 Windows 那边拷过来三百多个 CSV 和字幕文件，我用 vim 打开全是乱码，一猜就是 GBK 编码。批量转 UTF-8 的时候 iconv 转到一半就报错停下来，折腾了一下午，把过程记下来。
先看单个文件确认编码。file 命令能猜一个大概：
file -bi 数据.csv
输出里的 charset 字段如果是 iso-8859-1 或者 unknown，基本可以判断是中文 Windows 的老编码，常见是 GBK 或者 GB2312，也可能直接是 GB18030。iso-8859-1 这种误判很常见，因为 GBK 的字节落在 Latin-1 的范围内，file 就瞎猜了。
转换单文件：
iconv -f GBK -t UTF-8 数据.csv > 数据_utf8.csv
- -f 是源编码，-t 是目标编码，输出重定向到新文件。批量处理就是套个循环：
for f in *.csv; do
iconv -f GBK -t UTF-8 "$f" > "$f.new" && mv "$f.new" "$f"
done
问题来了：跑到某个文件的时候 iconv 直接罢工，报错长这样：
iconv: illegal input sequence at position 84521
意思是这个文件在偏移 84521 的位置遇到了 GBK 里不存在的字节序列。原因通常是这批文件的来历比较杂：大部分是 GBK，但个别人用别的工具存过、混进了 UTF-8 片段，或者里面有几个字是 GBK 覆盖不到的冷门字符，还有可能是某几个文件其实是 BIG5 或者 UTF-16。iconv 对非法序列是零容忍，碰到就停，不会跳过继续。
最简单的绕法是用 -c 让 iconv 把非法序列丢弃，硬着头皮转完：
iconv -f GBK -t UTF-8 -c 数据.csv > 数据_utf8.csv
-c 的意思是遇到非法输入就忽略。代价是那几个转不了的字会被直接丢掉，文件里会缺字。对字幕、报表这种丢了几个生僻字影响不大的场景，先 -c 转完能用；要是文件内容很重要，缺字不能忍，就得换思路。
另一个更稳的源编码选择是 GB18030。它是 GBK 的超集，冷门字、少数民族文字都覆盖，能转的字符范围比 GBK 大，很多 GBK 转不过去的字用 GB18030 就能过：
iconv -f GB18030 -t UTF-8 数据.csv > 数据_utf8.csv
我后来就是把 -f 从 GBK 换成 GB18030，绝大多数报错的字都正常转过来了，剩下的漏网之鱼再用 -c 兜底。还有一个容易忽略的方向：有些文件其实早就是 UTF-8 了，你拿 -f GBK 硬转，等于把好好的 UTF-8 字节流按 GBK 解读再转一遍，二次破坏，越转越乱。所以批量转之前先抽几个文件用 file 和肉眼确认，别一个编码套所有。
实在搞不定是哪种编码，可以用 Python 的 chardet 猜，虽然不保证准，但比瞎试强：
python3 -c "
import chardet, sys
data = open(sys.argv[1], 'rb').read(20000)
print(chardet.detect(data))
" 数据.csv
chardet 会输出猜的编码和置信度。它只读前两万个字节猜，文件很长、开头又是纯 ASCII 的话可能猜歪，但多数情况下能给出个方向。还有个小工具叫 enca，也是干这个的，有些发行版包名叫 enca，有些叫 enconv。
要是文件确实混着多种编码，最稳的其实是写个 Python 脚本按字节硬解，解不动的用 errors='replace' 占位，至少不会半路崩：
for path in ['数据1.csv', '数据2.csv']:
raw = open(path, 'rb').read()
text = raw.decode('gb18030', errors='replace')
open(path, 'w', encoding='utf-8').write(text)
errors='replace' 会把解不出来的字节替换成 Unicode 替换符，不会像 iconv 那样直接抛异常中断整个循环。对海量文件、只想全部转完再慢慢挑缺字的情况，这个脚本比 shell 里一个个 iconv 省心。
还有一类坑是文件名本身就是 GBK 编码的。内容转好了，文件名还是乱码，ls 出来一串问号。转文件名不能用 iconv，得用专门处理文件名的工具，Linux 上有个 convmv 可以干这个：
convmv -f GBK -t UTF-8 --notest *.csv
--notest 才是真改，去掉的话只预览不改名。我现在处理这类批量编码问题，固定顺序是：先 file 抽样确认，再单文件试转，能用 GB18030 就不碰 GBK，个别文件混编用 Python 硬解加 replace，弄完内容再单独处理文件名。别一上来就整个目录无脑 iconv，等转完发现全错位再回头就麻烦了。