对一个全新的 MDX 词典制作工具来说，词典制作者们最关心的问题就是生成的词典和欧路，MDict 等软件是否适配。词典制作工具应该是为他们服务的。如果不想考虑欧路之类的商业软件，建议专心新格式。
3 个赞
相当于造生态啦，开头都是很难的。
1 个赞
老铁表述的很清楚啦 - 首先实现自己的需求，一步一步来，至于将来能不能助力繁荣欧路和MDict商业软件，应该是在实现自己目标的久远后再考虑吧 - 或者就不需要考虑的啦
总之，支持楼主啦
恩, 你说的很有道理, 是应该适配这些词典软件的, 这里我理解的适配主要就是 MDX 的创建能够让欧陆和 mdict 解析, 对于这一部分我会根据当前已有资料做最大努力的兼容性处理(需要有朋友帮忙测试), 至于更深层次的兼容, 这个比较难, 需要花费时间区逆向他们的新格式, 然而对于这一部分, 我是没有打算的, 未来可能也没有打算, 如果有人做了这部分的工作, 我很乐意将他们的逆向结果实现, 做到更深已层次的兼容, 如果没有人继续这部分工作, 我这边恐怕没那么大的精力.
此外, 我也是希望能够慢慢将 MDX 生态过度到一种新的简单而实用的词典格式上来, 生态是一个很大的问题, 和 @LostTemple 的看法一致, 至于后续能不能助力闭源软件, 则是另外一个问题.
2 个赞
不需要靠新格式，浪费时间。
词头排序是索引再考虑怎么解决？
mdx作者是不是打算更新格式？
1 个赞
这两年看过太多人把时间浪费在 mdx 这个闭源格式上了。之前其实已经有两个 rust 作者开发过类似工具了（或者只是解析，忘记了），而基于 writemdict 的衍生版本，则至少见过五个以上。
mdx 的生成就交给官方工具。你支持下 mdx 的解析就够了，或者再提供转换工具，迁移到你的新格式上，可能是新词典软件比较好的开荒方式。
2 个赞
mdx只是个后缀名，从词典内容上来说，4.0以前差不多已经算是开源的了。只是个别细节上各大词典软件、打包解包工具的处理不一样，实际上每个软件衍生出了各自的mdx规范，这对现在mdx的生态并没有大的影响，反而是影响力名列前茅。当然少数情况下会出现小坑，例如last_idol解决的GoldenDict上不支持某些类型png的问题。
新格式的好处是统一公开透明，但要让各大词典软件支持新格式不是一件易事，实质上是构建一种新的生态。假使今天mdict官方公布了统一的mdx规范，各大词典软件的调整跟进也需要一个过程。
之前也有一堆帖子提出要搞新格式，都是不了了之了。可看看mdx设计优点的一些讨论。
我的建议是在GPL框架的前提下，尽可能保留mdx这个黑箱衍生出的各个版本mdx的共同部分。最好是把编译出来的词典文件改一下后缀为mdx，在GoldenDict上基本上（不要求百分百）就能用。
3 个赞
还有一点，编译前的utf文本也要尽可能跟当前的mdx一致。
mdx流行的一个重要原因是其技术门槛低，HTML+css就可以，调试也方便，有利于我这样的众多小白参与词典制作。
2 个赞
endnote大所言极是（所有回复中这是我个人最认可的建议）：千万别做或别着急着做生态。
但凡枚举一下pdawiki和本站过往的那些个上来就提生态或计划搞生态的个体作品，无不都有头无尾 - 过程也就是活跃一下论坛氛围而已啦。
你看GoldenDict没有自己的生态吧，但是很多人在用。
其实GoldenDict也有自己的格式 - 那就是它的 “index 文件格式，这个格式是活的 - 每种词典格式都可以有自己的私有定义在里面，这个格式的目的就是为了给各种格式的词典文件做索引 - 它并不刻意的要求一定要转换词典格式，只提供索引机制（实际上索引里放上转换好的词典内容也并不不可）”。 — 引自群内GD讨论内容
GoldenDict从设计之初应该就没有让其它词典软件兼容它的格式这样的目标，GoldenDict（包括其移动版本）能活到或流行到现在，其高明之处是在设计上，并非营造生态啦。楼主的初步设想，与GoldenDict的索引机制是极其相似的，至于词典内容是否转换为自定义格式 - 个人认为可有可无吧，初步设想中的索引机制（词典软件的基石）设计完善是重中之重 - 无论什么查询方式（现在基于sql），查询什么内容，无不基于索引的。
pdawiki上不乏（这里应该也有）“欧路MDict这样的商业软件的拥泵 - 其目的是很明确的，怎么让自家的词典壳子（app）能够越来越丰满 - 它自己当然并不分发词典，只卖个壳子（可以认为个体开源词典app或GoldenDict是免费壳子），这个丰满的过程大抵是不停的吸个体用户或词典制作者或所谓社区用户的血” — 引自群内讨论
这些狡猾的商业公司并不直接参与营造生态啦 - 毕竟盗版是不合法的。
我说这么多，估摸着已经引起好多人的不适啦 - 有些时候，社区就如商业公司的托儿所一般，校长、教职、心理按摩师等角色一应俱全。
最终还是一句概括一下吧：
楼主已经有了目标 - 先实现自己的需求，按照自己的初衷去做这个工具就行啦。
3 个赞
支持多格式是很艰难的工作，GoldenDict 已经做到极致了。
同意。
2 个赞
时至今日，2021年，他做的并不好。
1 个赞
人走茶凉，世态常情嘛，哈哈哈哈
不太现实的想法。
- 当前编译出来的 mdx 经过网友测试(但是只测试了一个), 已经能在 goldendict 上使用了, 预计问题不大
- 将编译后的词典文件名后缀修改为 mdx, 这个实现很简单.
- 编译前的源文件格式目前我没有做任何检测, 但是编译后的 mdx 格式统一为 utf-8 编码
3 个赞
endnote应该是说新格式
并且，GD 能直接按照读取 现有 MDICT 的 MDX 方式来读取这个意思吧。还是我理解错啦。
2 个赞
Goldendict 的实现我没有具体看, 但是目前我的实现就是按照现有已公开的代码实现 MDX 的解析和创建的.
2 个赞
是这意思，之前有人提出json方案之类的，那就是不太一样的格式了。
其实每个词典软件本身都是一个有独特之处的规范（即便有官方标准也不可能或没必要面面俱到），楼主的实现也不例外。只不过如果有个大家都认可的统一标准，各种工具编译出来的mdx就不会有太多的兼容性问题。目前的mdx各家在盲人摸象，但没有大的问题，类似于Linux内核之前的各种类Unix系统和utilities。
如果能总结整理出一个完整公开的词典规范，那倒也是一件耗费精力的好事。
2 个赞
不知道的我理解对不对，我的想法是这样的：
mdx格式目前不是有许多逆向工程嘛，意思就是相当mdx格式内部结构的大部分已经被公开出来了，这些公开的部分，都是支持当前大部分客户端GD、MDict、欧路等的。
既然如此，那就基于这些公开部分，就像 endnote 所说，初期先取它们的交集成新的mdx格式，新mdx在当前则是同样支持GD、深蓝等客户端的，同时做个自己的像mdxbuilder般的打包工具；
后期可以不断优化、完善此格式，如有新特性可以去修改维护开源软件GD使其支持，有精力还可开发相应的开源客户端，尽管新格式的优化，但都向下兼容最初的格式，以保证同样支持那些非开源客户端如深蓝（深蓝也很久没更新了）
随着新格式用户群不断地扩大，用新打包工具的词典制作者越来越多，这样就慢慢脱离了原闭源工具mdxbuilder，走向开源。
一句话来说，就是好好做个mdx的开源分支，青出于蓝而胜于蓝。
1 个赞
既然我们都在创新了，为什么要基于 MDX 呢。。假设我们加了一些 全文索引到MDX 内，欧路 GD 肯定不会支持的呀，除非我们贡献代码，然而都要自己贡献代码了，为什么还要继续 MDX 呢。。
我不要从一个闭源东西开发。
2 个赞
是的。如果目标是构建一个完全开源的词典规范，那也要一步步来。既然事实证明mdx有诸多优点，就没必要标新立异另起炉灶。可参照Linux的发展史。步子太大了，容易扯着蛋。
所以，先在GPL框架的前提下，从最大公约数出发，尽可能与现有生态对接上。如果有版权问题而不兼容的部分，单独提供工具转换。这样子新编译出来的文件后缀不叫mdx也可以（让用户自己去改不难），慢慢的这个生态有可能会成长起来，因为新问题新需求会吸引新用户转过来。
但这些让用户过来的新问题新需求目前还不知道（或者说目前mdx生态圈能大致满足用户需求），只能最大限度地兼容mdx，所以现阶段不用着急去设计构建全新不同的生态。
我支持喜欢开源，尊敬开源contributor。但我也理解商业软件作者，毕竟大家都要先顾好生活。商业软件的长处优点，也是值得学习借鉴的。，
1 个赞