# 写了个简单的mdx 2.0 及mdd 2.0 的reader，用于server，能查对tired **URL:** \ **Category:** 技术交流与词典编修\ **Tags:** 词典软件制作\ **Created:** [2026 年1 月 23 日 03:29 UTC](https://forum.freemdict.com/t/topic/42966 "2026-01-23T03:29:09Z")\ **Posts on this page:** 20\ **Page:** 1
作者： ![u3842](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/u/d6d6ee/32.png) [@u3842](https://forum.freemdict.com/u/u3842)\ 发布日期： [2026 年1 月 23 日 03:29 UTC](https://forum.freemdict.com/t/topic/42966/1 "2026-01-23T03:29:09Z")
为什么要自己写程序呢，因为现有的多多少少有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](https://forum.freemdict.com/t/topic/42473/8) 用python写的，过程比较曲折，资料东拼西凑，连带着问ai，总算能跑了，速度不是很快，能继续优化，不过够用了，至少查词没有明显的延迟，代码稍后公布 目前尚未实现的：compact，lzo压缩，流式处理 2026-6-8 更新： 重构，支持网络文件，io优化 [mdxReader.zip](https://forum.freemdict.com/uploads/short-url/dj1HevjxzzyEJoovQOxQB0zxI5o.zip) (12.2 KB) ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 23 日 04:39 UTC](https://forum.freemdict.com/t/topic/42966/2 "2026-01-23T04:39:42Z")
测试用的词典文件： > [@MDX 词典测试文件](https://forum.freemdict.com/t/topic/30462): > > 收集了经常会出错的词典文件，方便开发人员测试词典程序有可能出现的错误，如果有问题的话遍历词条和内容的时候会出现错误。（ compact.mdx 是使用了紧凑 HTML 格式的词典文件，需要自行查看词条是否显示正常。 [basic.zip](https://forum.freemdict.com/uploads/short-url/7Yvf30zyoQD3wrsTclVNHBrr7WG.zip) (1.1 KB) [big5.zip](https://forum.freemdict.com/uploads/short-url/bPy1k1j6fvF8qiYVKAOy9IPULRw.zip) (1.1 KB) [gbk.zip](https://forum.freemdict.com/uploads/short-url/u7KC6M1Z1YIT68Nddax78BwG0sf.zip) (1.1 KB) [halfwidth.zip](https://forum.freemdict.com/uploads/short-url/1s1o3zk3t8FP4IzVawOT8U168N1.zip) (3.4 KB) [utf16.zip](https://forum.freemdict.com/uploads/short-url/scIiSSK8EsNhnTN3JSKC5E4pycC.zip) … ---
作者： ![u3842](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/u/d6d6ee/32.png) [@u3842](https://forum.freemdict.com/u/u3842)\ 发布日期： [2026 年1 月 23 日 09:30 UTC](https://forum.freemdict.com/t/topic/42966/4 "2026-01-23T09:30:32Z")
咋还有big5……官方builder里也没这个选项啊，坑也忒多了吧…… ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 23 日 11:11 UTC](https://forum.freemdict.com/t/topic/42966/5 "2026-01-23T11:11:11Z")
很多繁体词典用的 big5。 ---
作者： ![winn](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/w/9dc877/32.png) [@winn](https://forum.freemdict.com/u/winn)\ 发布日期： [2026 年1 月 23 日 14:34 UTC](https://forum.freemdict.com/t/topic/42966/6 "2026-01-23T14:34:10Z")
LINK 是小问题，很容易解决。如果有循环 LINK 的情况，可以把链接用对应的文本替代，这样就没问题了。 ---
作者： ![amob](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/amob/32/14630_2.png) [@amob](https://forum.freemdict.com/u/amob)\ 发布日期： [2026 年1 月 23 日 14:38 UTC](https://forum.freemdict.com/t/topic/42966/7 "2026-01-23T14:38:09Z")
不是程序员，循环的处理有什么大麻烦吗？迭代@@@LINK时，遇到值是之前的键就跳过执行，应该不会很难吧？ ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 23 日 15:01 UTC](https://forum.freemdict.com/t/topic/42966/8 "2026-01-23T15:01:03Z")
写代码只是基本功，之前很多人不了解有 @LINK 这个东西，或者知道有 @LINK 这个东西，不知道里面会有循环的问题。这种与一线用户场景的脱节，是出现问题的根源。 ---
作者： ![amob](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/amob/32/14630_2.png) [@amob](https://forum.freemdict.com/u/amob)\ 发布日期： [2026 年1 月 23 日 15:38 UTC](https://forum.freemdict.com/t/topic/42966/9 "2026-01-23T15:38:46Z")
脱节在哪里？需要两个条目互相参见的时候，弄个A词条和B词条相互`@@@LINK`就很方便也有需要。 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 23 日 15:51 UTC](https://forum.freemdict.com/t/topic/42966/10 "2026-01-23T15:51:44Z")
互相引用没问题，我说的是脱节是指写代码的人对 MDict 词典和词典的制作不了解，所以我一直建议大家不要再支持 MDict 了，搞新的词典格式才是正解。 ---
作者： ![u3842](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/u/d6d6ee/32.png) [@u3842](https://forum.freemdict.com/u/u3842)\ 发布日期： [2026 年1 月 24 日 00:14 UTC](https://forum.freemdict.com/t/topic/42966/11 "2026-01-24T00:14:49Z")
哪个玩意写的能整big5的builder，各种逆向 兼容 还不够，还整点新的，真是嫌屎山不够大，我做个UTF-32的mdx不就炸了吗 ---
作者： ![hua](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/hua/32/11090_2.png) [@hua](https://forum.freemdict.com/u/hua)\ 发布日期： [2026 年1 月 24 日 00:20 UTC](https://forum.freemdict.com/t/topic/42966/12 "2026-01-24T00:20:55Z")
看到程序员破防就想起了自己的有些时刻 就连句式都一样 真的很搞笑 :goutou: （仅调侃，没有嘲笑的意思） ---
作者： ![u3842](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/u/d6d6ee/32.png) [@u3842](https://forum.freemdict.com/u/u3842)\ 发布日期： [2026 年1 月 24 日 00:44 UTC](https://forum.freemdict.com/t/topic/42966/13 "2026-01-24T00:44:22Z")
这个循环处理确实不难，但有些细节稍不注意就会掉坑里，比如实际@@@LINK=apple结尾还有个换行符，没去掉两边那些没意义的字符的就啥也找不到；网页有#part2这种操作可打开后自动滚动到某位置，像link个apple#part2也许是指向apple词条的某个位置，也可能词条名就是带#的，官方builder里虽然没提link能这么干，但都能整出big5的mdx了，谁知道做词典的会咋整 ---
作者： ![ppxia](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/ppxia/32/58538_2.png) [@ppxia](https://forum.freemdict.com/u/ppxia)\ 发布日期： [2026 年1 月 24 日 06:47 UTC](https://forum.freemdict.com/t/topic/42966/14 "2026-01-24T06:47:48Z")
> [@last\_idol](#): > > 搞新的词典格式才是正解 所以现有其它格式能不能作为替代？比如json或者sqlite。做轮子也是费劲的，搞搞通用格式转换感觉还比较好推广使用，开发难度可能也低些（非IT行业，只是直觉） ---
作者： ![u3842](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/u/d6d6ee/32.png) [@u3842](https://forum.freemdict.com/u/u3842)\ 发布日期： [2026 年1 月 24 日 07:03 UTC](https://forum.freemdict.com/t/topic/42966/15 "2026-01-24T07:03:12Z")
你的直觉是对的，搞开放的通用的才是正解，词典不小，JSON怕是不行，SQLite，是个设备就能跑，分块压缩存进数据库，读取也不难搞，这mdx去这找逆向去那找资料找不着的再推测推测，一言难尽 ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 24 日 07:18 UTC](https://forum.freemdict.com/t/topic/42966/16 "2026-01-24T07:18:04Z")
建议新格式放弃 HTML，专注结构化的 JSON，只做高质量的精品词典，让加载更快、界面更稳、功能更可控，以更现代的体验与 MDict 形成差异化的竞争，在品质与体验方面建立上位优势。（存储用 SQlite 或者自己设计都行。 结构化的 JSON，不管是想实现全文搜索，还是义项，词源，例句，引文，近反义词单独搜索都太简单了，还可以方便 ANKI 制卡，如果再搭配上大模型直接把词典的能力上限提升到新维度，各方面都可以压制 MDict 这种 HTML 词典。 ---
作者： ![wynick27](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/w/958977/32.png) [@wynick27](https://forum.freemdict.com/u/wynick27)\ 发布日期： [2026 年1 月 24 日 08:32 UTC](https://forum.freemdict.com/t/topic/42966/17 "2026-01-24T08:32:36Z")
结构化json有很多问题，xml是可以标签和文本混合的，json不行，还有样式问题，其实那个牛津初阶原始数据就是结构化json，非常混乱，比html麻烦的多。我最近在研究epwing，感觉新格式要设计应该也是电子书加索引的模式，应该是类似epub的结构加上可分资源包和索引的模式。 ---
作者： ![Akira](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/a/ba8739/32.png) [@Akira](https://forum.freemdict.com/u/Akira)\ 发布日期： [2026 年1 月 24 日 10:26 UTC](https://forum.freemdict.com/t/topic/42966/18 "2026-01-24T10:26:29Z")
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). ---
作者： ![wnabc123](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/w/9d8465/32.png) [@wnabc123](https://forum.freemdict.com/u/wnabc123)\ 发布日期： [2026 年1 月 24 日 11:20 UTC](https://forum.freemdict.com/t/topic/42966/19 "2026-01-24T11:20:54Z")
存储方面，Parquet 感觉也是个不错的现成方案。配合 DuckDB 可以直接跑 SQL，不用手写解析代码。 它内部按 Row Group 分块，支持 Zstd/Brotli 压缩。检索时 DuckDB 能利用 Metadata 里的统计信息自动跳过无关的块，IO 开销很小，算是在高压缩率和查询速度之间比较好的平衡了。 ---
作者： ![Akira](https://forumcdn.freemdict.com/letter_avatar_proxy/v4/letter/a/ba8739/32.png) [@Akira](https://forum.freemdict.com/u/Akira)\ 发布日期： [2026 年1 月 24 日 11:58 UTC](https://forum.freemdict.com/t/topic/42966/20 "2026-01-24T11:58:23Z")
> [@wnabc123](#): > > 存储方面，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. ---
作者： ![last\_idol](https://forumcdn.freemdict.com/user_avatar/forum.freemdict.com/last_idol/32/2205_2.png) [@last\_idol](https://forum.freemdict.com/u/last_idol)\ 发布日期： [2026 年1 月 24 日 12:13 UTC](https://forum.freemdict.com/t/topic/42966/21 "2026-01-24T12:13:46Z")
列式存储只适合需要索引的字段，不适合文档直接存储的场景。 [下一页](https://forum.freemdict.com/t/topic/42966.md?page=2)