计划分三期完成：
-
探讨制作词典时碰到的实际问题：
- 各路制作工具的优劣对比，特别是writemdict.py的发展历史，及面对闭源mdx的尴尬处境
- 各平台客户端goldendict, mdict, 欧路，对mdx的兼容性问题和差异
- 讨论实际解决方案
-
探讨周边工具：
- 在线查词
- 数据标注，统一样式
- 实时编辑修订的可能性
- 可订制的导入导出，如导出词头，导入anki
-
新世代的诞生，参与推动下世代词典制作工具的诞生进程。
9 个赞
如果不考虑出新格式的话，这些问题就只能对症（各异的 mdx）下药。。。个人感觉还是数据差异性太大，导致软件的处理差异。
这是一个浩大的工程，我早已立项，无奈时间和水平都不够。这个项目我已搁置了。这个能解决
而
这个统一样式就需要人工的力量了，需要熟悉 CSS 的人来洗排版。
2 个赞
支持集思广益讨论。
关于统一样式这一点，我曾经也想把常用字典的外观统一起来（当然改css是上手难度低花费时间长的做法），随着对词典认识的加深，现在已经放弃这个强迫症了。原因：
一是各家大词典的编撰理念不同，词条内容独具特色，如牛津高阶的Which Word? / word finder / Homophones / See also / Vocabulary Building / More Like This / British/American等等等等栏目，导致其HTML标签的数量繁杂差异很大，很多标签是独有的。
二是样式多样化不是坏事。用多了之后，查阅词条一眼即可辨别是来自于哪一部词典，这个词典的特色长处是什么、这些地方需要特别多加关注。所以说，有区分度后查阅效率可能会更高。
当然，原始网站的css排版往往很难看，这时候选择你看得顺眼的网友改版css、在其基础上做微调是最省时间的。希望能把自己的时间用在刀刃上。
最后转引之前的回帖供参考。
并不是说不需要改进mdx不透明的打包方式，也就是说可以设计一种新的开源打包方式：
1、继续采用Web技术（HTML+CSS+JavaScript），最好跟现有mdx打包前的源文本一样，把规范表述清楚全面。因为各大词典上线网页是这个结构，app数据底层也是，这大大方便了电子词典的爬虫转换制作，而且也降低了一般人修改完善词典的门槛。
2、提供新的、开源方便的打包解包工具。
3、新的打包格式需要goldendict等软件支持。
4、要能解决mdx现有的痛点以吸引用户。比如，可以方便导出某词条内容（源文本及相关js & css）、方便修改某词条内容的编辑功能（错别字）、方便手动增加词条间跳转功能（也是一种编辑），等等。
2 个赞
要实现对单个mdx词条的校对修改，
可否基于mdict-utils 将mdx解开为源txt文本（一个词条一个txt，可增加单个词条的txt），这样修改或增加词条只要打开相应txt。编译mdx时，可选择合并所有词条再编译、或者仅编译当前词条的源txt。如果不满意当前词条，返回相应txt 修改即可。
貌似主要的功能都有现成模块，麻烦在于GUI 界面设计。
实时编辑词典的需求很怀疑，HTML本身就不方便普通人编辑，容易打乱词条HTML的结构和层次，不适合分享，也不利于其他词典作者的二次加工提取数据重新制作，还是报错反馈让作者统一修改更好。
mdx 的解包，很多开源工具都做的很好，但打包都有排序黑盒的问题，部份词条stripkey后的排序结果和 mdxbuilder 的并不一致（skywind3000 和 lgmcw 有讨论过类似问题），如果词典软件依赖 mdx 本体里的索引去搜索词条，结果也会不一样，这点 gd 做的最好，重建了索引。
这点非常认同，统一样式很困难。
3 个赞
主要是有些词典想边看边改错，还想顺手加上跳转链接。目前来来回回的全编译有点麻烦。
在mdx里词头key和释义(record)是分开储存的，mdx前半段是key，后面段是所有record。但是key并不是唯一的，mdx允许同一个key出现多次，但是出现一次必须要有record对应。但是python的dictionary就不是如此，key是唯一的，对应唯一的content。我为了应付key重复的情况，把content定义成一个list，这样如果有多个对应的record，会把他们按顺序存入content list里。mdict软件对于每个词条的排序很讲究的，稍微排不好你就查不全dot，DoT，DOT这些样子的单词。
因为我需要自定义排序，而且原厂的mdxbuilder的会强行乱排序，mdxbuilder肯定是不能用了，所以我用writemdict来生成mdx文件。writemdict是开源的python代码，可以转mdx。原版的writemdict python代码，并不支持一key对多record的操作，你只能合并多出来的的释义在一条释义里，但这样弄的话，同时有释义和跳转的词就会失效，并且实际使用时会代码会漏显示出来在屁股后面挂一个@@@LINK这种。所以我动手改了writemdict的python代码，让他可以读我这种稍高级的content是个list的dictionary。这个改动可以顺利生成mdx文件。
然而关键的问题来了，在mdx二进制文件里的header里有一个字段表明了词头的数量。这个字段在writemdict原版里在代码很开始的部分被很随意地直接写作dictionary的key数量，这个在原版里确实没有任何问题，但是在我这儿就并不适用了，因为词条数是content里面record之和，而不是key数量。转出来的文件，goldendict并不读取这个字段，所以不报错，所以在goldendict里面没有任何问题。而安卓MDict读取mdx校验发现和实际不一致，有的版本直接闪退，闪退。ios MDict有的版本不闪退但不可以查后面的词，仅仅是后面的词查不到。导致报错的具体原因是有些词头(key)对应多个解释(Record)。但是python字典解构必须是一一对应，所以一个key下面对应一个数组，数组里每一条包含这多个Record。
相较于writemdict原版我主要改了两个地方：1. 在原版代码里，以前一个字典的key只能对应唯一个value。而MDict完全支持多个相同词头对应多个意思。所以我改了一下生成mdx的python代码，让他不只take一个record，而是用一个for loop 遍历take所有的record，让一个字典的key可以对应多个value。2. 修改排序算法。原版是用的默认python排序，输出的文件在MDict简直不能查，GD勉强能查。
不知道后面哪一步和我这个代码改动不合拍，结果就这样了。
- GoldenDict 默认读取全部词条，然后存储在自己的缓冲区中，查询在缓冲区中进行，可以对全部词条搜索
- MDict 严重依赖于词典自身排序，根据排序规则查找词条所在扇区块，然后再找到词条。如果排序不符合他的规则，即使有这个词条，但不能找到正确的扇区块，也不能定位词条
- ecdic 更怪，他也依赖于词典自身排序，基本规则与 MDict 相同，但遇到特殊字符时，如 空格 减号 等，有时能查出，有时不能。闭源的软件，没办法…
词序排列的问题可参看这里
4 个赞
用开源的 python 实现打包 mdx，在欧路上问题特别多，writemdict 本身的代码问题好解决，但 stripkey 的黑盒问题解决不了，preview 最初也实现了 mdx 的打包，后面就是因为这个原因去掉了，词典作者们要正式发版，推荐还是用 mdxbuilder3.0。
重复 key 乱序问题，倒是没想过，第一次看到。
jonah_w：好像默认是strip key的，这貌似会导致像’s -'s 之类的词条在打包后可能无法查询 链接
不知道作者后来解决没有。
如果继续拘泥在 MDX 这个格式上的话，就会补丁摞补丁，不同软件有不同实现和渲染方式，最后谁也搞不懂谁。
闭源不谈，MDX 也不是一种好的词典格式，只是历史沉淀太过深厚，改变不了而已。
1 个赞
显然mdx 格式并不完美，但为什么它能流行这么广、持续这么长时间？这甚至超过了原作者的设计，因为他开发的格式4.0都 没能这么成功。
在我看来，技术门槛不高，能吸引新鲜血液的广泛、不断加入是最重要的原因。当然，问题是，现在某些方面需要统一的规范，但又不能一下子限制太多，建议慢慢来。
2 个赞
有没有想法, 一起弄个新工具
1 个赞
这就是所谓的「技术债」吧。
1 个赞
有什么办法能把自己这些年保存的好多个 .mhtml的文件 做成一个词典库 来查看么？
提取词头作为索引;
搜索某个词;然后截取这一段,
然后调用浏览器内核显示出来;
大概就是把网页的标题 做为单词 保存的网页内容 作为这个单词的解释页 请问有没有具体的工具或者教程 推荐一下？
会不会编程语言?
刚开始学习python 还没太入门 有什么专用的库么？
那就用别人弄好的吧,