其实词典也可以是百科，知识库之类的，基本没有共同点，但是某一类词典可以定一个标准。比如外语到汉语的词典结构都差不多。
现在的年轻人不太了解计算机的发展历史,如果词典格式设计比较早,一般都是多文件格式,如果是较新的格式,一般都是单文件格式.
比如stardict/mdx/dsl等都是早期格式, 是可以运行在只有几十M内存的PDA上的(除掉系统占用的,可用内存经常只有10M)
总之,是早期PDA/PC的内存太少, CPU性能也不行,网速较慢而且不稳定等原因催生了mdx/stardict非常"抠门"的设计。
（上面还有人吐槽mdx对词条的排序，这确实是一个问题，但是在当时（世纪交替点）unicode/UTF-8还没有一统江湖的时代， MDX 被设计为一个“面向字节”的格式，而不是一个“面向语言学”的格式就理所当然了，并不能说明其作者没有学过除英语以外的其他语言，老产品不完美，但是我们能多尊重一下老前辈就更完美了。）
能提出这个问题的人肯定没有听过"猫"拨号上网的美妙声音, 也没有用过只有几十M内存的PDA/PC, 相信也没有在DOS时代研究和调整一个晚上的autoexec.bat/config.sys就是为了节省几K的低端内存(640KB以内)只是让仙剑奇侠传等游戏能启动.
直接合并的话只有 ZIP 的存档模式可以，压缩过的都不行，而且 ZIP 文件大小有限制，虽然可以扩展，但兼容问题很多，不可控因素太多了。
你说的空间大小问题，出两个版本，一版带发音一版不带发音，不就解决了，能有什么区别？你看论坛上一堆问题不就是多文件导致的，现在只是对早期设计的复盘，我觉得没什么好避讳的。
有没有可能设计一个更优的词典格式呢
设计容易，推广困难，大多数人的需求已经满足了，改进不多的话，没什么动力切换的。
个人觉得是分开好,mdd文件太大的时候,只需要改动mdx的话,会方便很多.
如果需要完整的单独文件的话,用epub就可以了,也可以有目录,可以查询,可以做标注.
EPUB 无法用于词典查询。比如以 A 开头的所有单词，有可能会存储在同一个 HTML 文件里，词典软件没有办法处理这种文件。
是的，原来的设计说不上是什么错误，只能说是一种历史局限性。如果有必须新设计一个电子词典的话，格式等当然可以更优化。只是在ai渐行的状态下，估计很少有人再有兴趣设计新的词典格式了，电子词典被ai代替是必然。
被代替正是因为 MDX 不好用，无法配合 AI 使用。如果词条是结构化的数据，比如 JSON，会被开发者玩出花来，可扩展性会非常强。
pdf、docx、epub复杂多了，没搞ai的程序员在乎mdx词典罢了。mdx不过就是压缩了的txt或者html，ai没理由看不懂，json不过是适合个性化调整。训练ai的程序员也没那么在乎pdf信息完整保留，最后都是转换后丢失信息的markdown或者更不完整的json甚至txt喂给ai。
不如说一切知识媒介载体都可以被ai解答取代。词典格式而言，mdx在中国使用者不是绝对多吗，完全没被任何格式取代。
何以见得，词典读取程序和内存管理写起来多麻烦。要么产生临时文件多，那就和分开没区别，要么在内存里文件句柄和指针创建和存放了特别多，费事。现在词典软件我见过不少样式表、js脚本、字体、图片、视频都直接放着不打包的。程序员不都是往这省事设计吗？
HTML 只是展示层，AI 真正需要的是结构化的语义数据。训练模型的人很少，大多数开发者是在使用模型，而使用模型最依赖的就是 JSON 这样的语义层结构化数据。
多文件确实省事，但以前的开发过程也比较草莽，现在的开发先写文件抽象层，文件是一个还是多个或者是远程都没区别，从开发这边看都一个样。
这几天继续看论坛里的提问，越来越明显地发现，许多问题都源自 MDict 的多文件结构：文件之间缺乏强关联，也没有显式的约束描述，导致用户在导入词典时经常遗漏资源文件。系统层面也加剧了这个问题，Android 允许应用扫描目录并自动关联文件，而 iOS 完全禁止目录扫描，同时 iOS 的文件导入大多是单文件触发，这进一步放大了多文件设计的缺陷。