如果要抛弃mdx，重新开发一种新格式的话，沿袭mdx那种词头下塞一坨html片段是不是比较蠢？或者说，如果采用这种传统结构，会带来哪些问题呢？
论坛里关于新格式的构想的帖子我大概都看了，感觉似乎都在推崇某种统一的内容结构（类似odict这种）。但比如说WFG做的那个电脑汉字字典，这本字典不是普通辞典的那种释义下挂一个例证的结构。如果我们先设计好一种统一结构的新格式出来，然后再照葫芦画瓢式地糊一个辞典软件，那遇到这种辞典必然是不容易转换过去的。
没有要指导什么或者吵架的意图，望海涵。
3 个赞
你在凌晨3:30发这个帖子，一定有什么道理。
2 个赞
新入圈的开发者大多数想要使用统一的文本格式，主要是方便二次开发，比如统一调整文本的样式、精确的提取文本内容，提供更好的使用体验，或者在不同应用中交换文本内容，但是要兼容不同版权方的词典内容，只有 HTML 能做到。
是这样的，没可能完整转换。
开发新格式，推荐苹果的方案：XML 的索引和 HTML 的内容混合在一起使用，这里的索引 XML 可以替换成 JSON，词典内容展示使用 HTML，二次开发使用 JSON。
首先，前提如果訂為「如果要抛弃mdx」就錯誤了
好端端的為什麼要拋棄呢?
例如訂個前提為「如果要抛弃汽車，重新開發一種交通工具…」
這個前提就是錯誤的，沒有其拋棄的必要性
換個前提「如果要改進mdx」那就有很多點可以講了
再者，目前世界上較流行的結構格式有6種：
Html、Markdown、Wikitext、LaTeX、BBcode、Asciidoc
全世界的網站99%使用Html格式
無論是通用性與方便性都是這 6 種格式內最好的
選擇已經改版多次且技術成熟的 html 不會愚蠢
自己開發一個沒人懂的新格式在我看來更蠢
mdx格式雖然缺點不少
但以目前辭典生態圈看來
並沒有什麼急著替換格式的急迫性
與其把精力放在辭典格式，不如放在辭典內容更有意義
3 个赞
新格式或者新的词典软件，开发和推广困难的地方就在这里，必然要先抛弃旧词典的用户，被大多数人反对。
大多數人反對?
開發新格式或新軟件沒有人會反對吧
最多是開發出來沒人用
另外有一點你弄錯了
開發新的軟件不一定要拋棄舊用戶
兩件事並非互斥的
可以兼容
開發新的東西很好
但是其優點有沒有足以吸引原用戶替換才是重點
新格式推出後吸引力不足
也不代表大多數人就反對新格式
html优势还是比较大的，最起码一点，随着渲染引擎更新和标准迭代，html几乎有无限的可能性，而词典软件几乎不需要做什么只需要调用或更新渲染引擎就能自动适配。
个人理解，词典软件对html的处理，仅仅包括：（1）超链接的处理，实际上只需要处理特定的属性，譬如href=‘entry://’、href=‘sound://’、src=‘’；（2）多个词条怎么呈现，iframe（如mdict android，dicttango瀑布流）或词条拼接（GoldenDict）或单独渲染+切换（dicttango滑动）。其他方面都交给渲染引擎就行。
Rayman在发布mdx之初，当时的mdx词典普遍样式简单、功能除了个发音相当于没有。但就因为其底子是html，通过对html5标准的运用，才有了诸如ldoce5++这种功能极其丰富的词典，有了百花齐放的排版和功能修改。以我自己修改词典为例，像大英百科2010，当时作者就有抓取离线视频资源，但并没去实现播放，我就在网上查了下发现video标签，然后照葫芦画瓢试了下就成了；再像最近搞的发音瘦身，因为sppex被官方弃用并以opus作为后继，尽管没有谁表示mdx支持opus，但我查了下发现现代浏览器都支持opus，尽管mdict android不支持href='sound://xx.opus’这种私有格式播放，但通过html5标准的audio方式就实现了目标；甚至一些想要的功能、设计，只需要自己去网上（比如w3school，虽然有人吐槽假官方有错误但我觉得还是蛮好用）去搜一下就能解决。可以说，使用html作为词条内容呈现的mdx具备了跟随html标准自动迭代升级的能力。
如果说真要做个新格式，我个人觉得还是得基于html。我觉得可以包括三大块：（1）词头；（2）特殊格式解析区，这块可以标定默认发音、词形变化等，像词性变化目前mdx是通过@@@LINK实现的，可能会出现重复词条；此处也可标定某些词条不可检索，比如目前oaldpe里存在诸如set_1、set_2的内容，或许可以在这一块简单处理标记；（3）内容区，使用html。第二块通过特殊的标签围起来，并且可以为空，这样的话当前的mdx资源只需解包后很简单的正则替换就能重新打包成新格式，不浪费当前的成果。
2 个赞
现实问题是如果新开发的软件或者格式没人用，或者旧有用户使用惯性过大，开发者是没有动力开发新的软件的。现在直接做 AI 词典 x 翻译软件，新用户要多的多，他们对新软件会更宽容更友善，为什么要支持使用 MDX 的用户。
MDX 是不可能改进了，很多词典的作者已经不在了，他们没可能兼容新的软件，新的软件对 MDX 的支持永远也不可能比旧软件做的更好。（这是我长期观察后的结论，对开发者来说，与其浪费时间讨好旧的词典用户，不如开辟新的根据地
1 个赞
什么道理？从无到有开发一个新格式还不是抛弃mdx？
学习了！受教了！
用sqlite怎麼樣？之前看論壇一個用戶說一個詞頭下掛一坨html這種活不是sqlite幹的，應該用nosql。
sqlite 是开源辞典格式的最佳选择，轻量稳定可靠跨全平台，全球有超过 40 亿台设备在使用。nosql 的问题是目前没有类似 sqlite 这样等级的开源库，有些库勉强可以在移动端跑起来，但他们不是为移动端设计的。
不考虑移动端的问题，只是查词头的话什么数据库都可以实现，如果要做义项反查、例句搜索，只有 sqlite 自带全文搜索引擎可以轻松做到。
mdx 是分块压缩，多个词条的内容压缩在一起，压缩率会更高一些，sqlite 直接单个词条压缩在使用上更方便，相比 mdx 的缺点就是体积会大一些。（sqlite 除了这个缺点外剩下的都是优点。
之前用claude糊了个app出来，然后塞了个200w词头的sqlite词库（内容全部是随机英语词）进去，全文检索也没有想象中的快，大概0.8秒-1秒这种速度。
感觉全文检索速度不如xapian？
词头用sqlite，内容用xapian这样行不行？
你有全文索引没？
1 个赞
这个速度有点不对劲，要看代码才知道问题在哪。对给定单个关键字的查找，全文检索的速度其实都差不多的，主要看磁盘的访问速度。（最好再用 claude 优化下代码
内容用 xapian 是可以的，但这样就和 ng 一样了，每次增加新词典都要生成索引，在移动端使用不是很方便。sqlite 自带索引，不需要考虑这一步。xapian 也不是为移动端设计的，移动端全文检索用 lucene 和 sqlite 比较多，论坛里的无限词典就是用的 lucene。
无法确认了，觉得不可行我直接把整个项目文件删了…
维基百科 8.89G / 500万文档 (链接)，用 sqlite 全文检索：
文档总数: 5032105
搜索 ‘the’, 匹配文档数: 4168066 , 耗时: 286.42ms
搜索 ‘griffith observatory’, 匹配文档数: 79 , 耗时: 1.169ms
sqlite-indexer.py.zip (1.4 KB)
PS: 搜索引擎在实际使用中，只会查询前 100 个匹配项，速度上的差别其实不大
对比专业的搜索引擎 (链接)：
2 个赞
有人搞啊，DictTango的自研格式就是基于sqlite，说sqlite跨平台差的，是没对国内软件应用的基本认识。微信，QQ，钉钉的数据库全是基于sqlite用sqlcipher加密，我见过使用sqlite的商业词典软件（包括陆台韩日越英法德西意），有十几个。PC端词典软件更喜欢自研格式（方便自定义压缩和加密和索引方式），IOS和Android都是用sqlite居多。Android用sqlite，很大程度上因为这就是Android原生支持sqlite的api。 使用 SQLite 保存数据 | Android Developers
2 个赞
