mdxbuilder4.0能接受“[asterisk]-”開頭的headword，例如“[asterisk]-oŋ”；可是“-”開頭的，例如“-東”，大多數沒問題，但有些不work，看跟哪個漢字搭配，奇怪。
赶紧扔掉这个4.0，因为很多软件不支持也不能解包
推荐zzzsleep的mdict-utils mdict 打包解包工具。
pip install mdict-utils
pip install mdict-utils 比 mdxbuilder 3.0 RC1 好嗎？
1 个赞
mdict-utils配合代码可以自动化打包。
mdxbuilder必须手动打包。
1 个赞
终于搞定了。
简单总结一下：如果制作mdd，且需要给欧路词典使用，并作为独立发音库；那么文件名最好不要包括各种半角符号，最好也不要以半角字符开头并包含全角字符；否则不知道会发生什么状况。
以上结论基于这几天近百次打包的尝试 
—————
更新下昨天的实验结果：
和某个文件的内容应该无关，和一系列的“碰巧”的文件名有关。相同的其他文件，仅重命名某一个文件，欧路就可以正常识别；“异常”文件保持异常名称，放入另一组原来正常的文件中，打包出来欧路也可以识别。我估计是生成的mdd中的索引恰好触发了欧路的某个“bug”，也可能是欧路故意设置的内部检测机制，兼容性差
————
刚刚在打包回的贴，发现打完还是有问题。等我先定位一下问题先，以下答复先作废哈。初步怀疑可能是我打包的文件太多了，总文件数超过30万，根目录下超过20万。仅删除掉大量文件后，用mdict-utils打出来的包是ok的。也可能是欧路的bug。
这两天刚遇到的坑，结合欧路词典说一下：
mdxbuilder(rc1)打包出来的mdd有问题，ios版无法识别为独立语音库，pc版"好像"都无法正常使用其中的语音。但是pc版mdict都使用正常。
mdict-utils打出来的mdd可以在pc版欧路被识别为独立语音库，正常发音。
1 个赞
具体版本多少？
1 个赞
别用mdxbuilder4.0rc1，用3.0
1 个赞
就是3.0的，应该是官方最后一个3.0系列的版本。否则欧路里也用不了，目前只是独立发音库有问题，词典里的发音没问题。
1 个赞
程序bug。上面讨论过。
MDX Builder 不是开源软件，没法修补bug。所以才推荐mdict-utils mdict 打包解包工具。
mdict-utils 1.0.8.3
这个是刚发布的最新版？？
1 个赞
GitHub上
像是一个人。但官方安装渠道是
pip install mdict-utils
1 个赞
又发现一个类似的、不支持的符号 #，例如：“22.2.2 用#填充的单元格” 这个就无法作为keyword。
要命的是，英文问号可以用中文问号替换解决，但#就不好找可用的替代符号了。
补充一个使用mdx/mdd的注意事项
当存在多个MDD文件时，如果希望只使用其中一部分的mdd，则应该保证所有mdd的命名序号是连续的：即如需要重命名为.mdd、.1.mdd、.2.mdd、3.mdd…
当然，前面的文件名应该与mdx保持一致
算是个人感觉吧，折腾词典的原始数据的时候，在纯文本编辑器界面的话，如果对自己的正则表达式特别有自信，或者对需要处理的字典数据的文件格式特别清晰的话，该用正则用正则，即快还省事儿，但如果上面两样都不存在，建议还是少用正则，尤其是在数据清洗整理完毕后，进入脚本需要敲代码的时候，尽量少用正则，正则这玩意儿，影响范围太大，而且，差一点小细节啥的，污染的是整个数据源。而且，一些你不希望改动的效果，在正则里，坑都埋得特别深。如果仅仅是拿来看的，有点数据误差最多算闹眼睛，拿来背的话，还是老老实实在代码里写逻辑，起码自己能控制住自己该干啥干啥。正则这玩意儿，短小精悍，但处理逻辑能力不强。反正我自己是在文本编辑器里，使用正则处理点儿数据清洗的，在写代码生成数据规范文件的时候，轻易不用正则。尤其爬到beautifulsoup的时候，范围能准确的界定到某个标签的话，没必要用正则，直接自己老老实实的写处理逻辑。以上纯粹是个人习惯和个人观点吧。
正则是把双刃剑，效率奇高，但如果不小心，很容易大片大片的误删数据，新手不建议用正则
我感觉也是，一般我是在文本编辑器环境里，用正则，该干啥干啥的，所见即所得，但正则，逻辑控制上不是强项，而且跟逻辑控制有关的语法太晦涩，可读性和维护性差，而且还牵一发动全身，一般，折腾到代码这块，需要更精细的控制逻辑处理的时候，我是忍住的，能不用正则，尽量不用正则。简单的替换功能，直接在文本编辑器里就折腾明白正则了，需要更具体的控制逻辑分支的时候，都是代码的事儿，这都不是应该施展正则的地方。
1 个赞
mdict-utils是如何排序的？我想按照源文件的排序生成mdx，mdict-utils能实现吗？
这种事儿，感觉，无论是js，css，还是config.ini,哪怕乃至整个mdd，都缺乏一套严谨的类似包管理的机制，命名空间污染的段子，在不同字典编撰者之间，特别容易发生。建议要么论坛有个严格的规范来约束，在字典的编辑发布阶段，尽量杜绝这种事儿，要么就是干脆在软件工具层面，做好package management的事儿。我自己根据论坛的字典数据，提取出来折腾个背单词的小工具，就发觉，collins的css，js啥的和 longman 的css，js啥的，单独整合到一个界面显示的话，尽是这类命名空间的事儿。目前的解决办法，要么自己手动规范命名空间，要么借助啥第三方工具，规范命名。