为什么要自己写程序呢，因为现有的多多少少有bug，不能正确处理link，在mdx中，link到另一个词条是@@@LINK=，mdx可以有多个词条名一样的词条，比如，一条是主内容，一条link，比如tired可以是主内容，link到tire，一并读取tire，tire又可以除了主内容还link到tyre，tyre又……总之读取时不要死循环了，现有的要么不能return全link的要么干脆主条目都不返回。其次就是遇到bug了也比较好定位，实现些新的功能也更简单https://forum.freemdict.com/t/topic/42473/8
用python写的，过程比较曲折，资料东拼西凑，连带着问ai，总算能跑了，速度不是很快，能继续优化，不过够用了，至少查词没有明显的延迟，代码稍后公布
目前尚未实现的：compact，lzo压缩，流式处理
2026-2-5 更新：
修了修bug，规范了些，新增：获取所有词条名
readmdx20260205.zip (7.5 KB)
测试用的词典文件：
目前还不是很完善，鲁棒性较差，compact还没实现，只支持2.0
readmdx20260123.zip (6.1 KB)
不要server的话把import flask ……那行和结尾那几行删了，不然会报错，貌似因为ripemd128.py，vscode打个字得卡几秒，先打开个别的文件夹解决
咋还有big5……官方builder里也没这个选项啊，坑也忒多了吧……
很多繁体词典用的 big5。
LINK 是小问题，很容易解决。如果有循环 LINK 的情况，可以把链接用对应的文本替代，这样就没问题了。
不是程序员，循环的处理有什么大麻烦吗？迭代@@@LINK时，遇到值是之前的键就跳过执行，应该不会很难吧？
脱节在哪里？需要两个条目互相参见的时候，弄个A词条和B词条相互@@@LINK就很方便也有需要。
互相引用没问题，我说的是脱节是指写代码的人对 MDict 词典和词典的制作不了解，所以我一直建议大家不要再支持 MDict 了，搞新的词典格式才是正解。
哪个玩意写的能整big5的builder，各种逆向 兼容 还不够，还整点新的，真是嫌屎山不够大，我做个UTF-32的mdx不就炸了吗
看到程序员破防就想起了自己的有些时刻 就连句式都一样 真的很搞笑 
（仅调侃，没有嘲笑的意思）
这个循环处理确实不难，但有些细节稍不注意就会掉坑里，比如实际@@@LINK=apple结尾还有个换行符，没去掉两边那些没意义的字符的就啥也找不到；网页有#part2这种操作可打开后自动滚动到某位置，像link个apple#part2也许是指向apple词条的某个位置，也可能词条名就是带#的，官方builder里虽然没提link能这么干，但都能整出big5的mdx了，谁知道做词典的会咋整
所以现有其它格式能不能作为替代？比如json或者sqlite。做轮子也是费劲的，搞搞通用格式转换感觉还比较好推广使用，开发难度可能也低些（非IT行业，只是直觉）
你的直觉是对的，搞开放的通用的才是正解，词典不小，JSON怕是不行，SQLite，是个设备就能跑，分块压缩存进数据库，读取也不难搞，这mdx去这找逆向去那找资料找不着的再推测推测，一言难尽
建议新格式放弃 HTML，专注结构化的 JSON，只做高质量的精品词典，让加载更快、界面更稳、功能更可控，以更现代的体验与 MDict 形成差异化的竞争，在品质与体验方面建立上位优势。（存储用 SQlite 或者自己设计都行。
结构化的 JSON，不管是想实现全文搜索，还是义项，词源，例句，引文，近反义词单独搜索都太简单了，还可以方便 ANKI 制卡，如果再搭配上大模型直接把词典的能力上限提升到新维度，各方面都可以压制 MDict 这种 HTML 词典。
结构化json有很多问题，xml是可以标签和文本混合的，json不行，还有样式问题，其实那个牛津初阶原始数据就是结构化json，非常混乱，比html麻烦的多。我最近在研究epwing，感觉新格式要设计应该也是电子书加索引的模式，应该是类似epub的结构加上可分资源包和索引的模式。
The problem is not that HTML vs JSON. Clearly, HTML wins due to its widespread popularity as a markup language. Online dictionaries appear as HTMLs.
The real issue is how to organize the HTMLs and its metadata (indexing/CSS/JS) efficiently. That is how to design a format whose structure is convenient/transparent/efficient to generate (by makers) and to parse (by dictionary apps).
存储方面，Parquet 感觉也是个不错的现成方案。配合 DuckDB 可以直接跑 SQL，不用手写解析代码。
它内部按 Row Group 分块，支持 Zstd/Brotli 压缩。检索时 DuckDB 能利用 Metadata 里的统计信息自动跳过无关的块，IO 开销很小，算是在高压缩率和查询速度之间比较好的平衡了。
DuckDB and ZSTD are the beasts in the modern era of big data. I love them both.