希望群策群力集中讨论一下，方便新人少走弯路
先抛个砖：
在Windows上，无法创建名为con或者aux的文件夹或者文件，这个问题来源于Windows上的限制。如果最初在抓取数据的时候不知道Windows有这个限制，所以也没有考虑到这个问题，就会导致几百个单词的发音文件路径失效，需要回头返工修复。
2 发音文件 文件名里不要包含 - 字符，软件（起码goldendict）识别不了
补充一个用MdxBuilder制作mdd的坑：
MdxBuilder大文件特别版用的挺顺手，但不能制作数据文件(.mdd)。后来才知道，制作数据文件(.mdd)要用标准版本。如仅进行数据文件(.mdd)制作，标准版本勾选Build Data archive only后就不用填写Source路径等字段。
但需要处理超大量数据制作mdx的时候，MdxBuilder标准版本会出现内存不足的现象。MdxBuilder 3.0 beta1 大文件特别版这个版本进行了一些特殊处理，减少了内存消耗，但只能支持MDict(Html)/MDict(Compact HTML)模式打包mdx。
1 个赞
4.css文件名不要有空格，起名注意区分，虽然欧路可同名识别，但是打包进mdd，有空格就识别不了；
5.使用特殊符号命名，比如®，Export时会提示打开错误；
6.使用MdxExport时，不要在词典信息处按换行；
7.词典名留空，方便大家改成自己喜欢的。
2 个赞
我做的 教育部 异体字 是用官方打包的，目前没遇到官方的打不出来的问题。21.2G
欧路可自定义 另外我建议这个需要设置
21.2G是mdd吧，制作mdd也只能用标准版。如果是制作大型mdx，很容易碰上内存问题，往往需要大文件版，而其对应mdd则另外用标准版打包。
1 个赞
比如 the little dic，真的大
1 个赞
据说GetDict 2.6 转出style常有机会出现乱码
（有style.txt要用Compact HTML格式打包）
这时候改用GetDict 2.3 即可
但GetDict2.3不能解mdd
所以, 结论是:
要解mdd, 请用GetDict 2.6
要解mdx, 请用GetDict 2.3
看来MdxExport3.5也不错
https://www.pdawiki.com/forum/thread-17709-1-1.html
还有个说法：反編譯mdd最好還是用xwang-mdict-analysis這個工具，從不會亂，原先是什麼樣子，轉出來還是什麼樣子。
要去最新的commit下载
2 个赞
Mdx在各种词典软件上的适配是个烦人的事情，琐碎鸡毛蒜皮但不得不注意。以欧陆为例：
- 欧陆词典不支持tif图片格式。图片型词典在优化后只能保存为体积稍大的png格式。有些词典背景透明图片在欧路夜间模式下看不了，而白色背景下正常。
- 欧陆词典无法直接设置发音库。
看来欧陆还有很多地方需要改进啊
1 个赞
应该是可以的吧。。。你骗我没用过欧路
能的吧，还支持同名呢
已删。看到的这个说法，原来不靠谱。
话说我还是ios版欧陆正版用户，但没怎么用，还没把电脑上的词典考进去。@Arlin
如果使用js，就有与其他词典js产生冲突的可能，js冲突原因往往出在这两个mdx都用了同一个函数名。尤其是当在其他词典js的基础上进行改造时，一定要改本词典中定义的函数名称，不然可能会和之前词典起冲突。
如果遇到某本词典必须放在第一位才能正确点击展开和隐藏，很有可能就是因为这个原因，把其中一个改名就好了。
这也说明，js中的函数名最好特殊一些。
这在各个软件应该是一样的，因为都是把一次查询结果当成一个大网页。
参考以下例子
4 个赞
readmdict 解析出的 HTML 内容用 CR LF 换行，即 Windows 的惯例。于是和 Linux 惯用的 LF 有冲突。我的 Vim 充当二五仔，在 Linux 下偏偏用 dos fileformat 来解码用 readmdict 解压出的 txt，于是不会显示 ^M，害我仔细找 CR 了半天。
2 个赞
虽说 HTML 规范貌似用 CR LF 换行，但我自己写的字典和脚本都用 LF 换行，在我的 GoldenDict for Linux 下倒是照常换行，至于在 Windows 下表现如何我就不知道了。
2 个赞
欧路不是可以自定义发音库吗
1、最基本的源文件格式
set ff=dos
set nobomb
set fileencoding=UTF-8
否则，中文出现乱码、第一个词条被吞没、无法构建mdx等
2、 跳转到当前词条的某个位置
<a href="entry://目标词条#目标ID">链接内容</a>
ID设置可以使用：<a id="filepos120046"></a>
ID设置不能使用：<span id="filepos120046"></span>
3、图片使用ComicEnhancer Pro处理后，GoldenDict或许会不认：
Update：这是GoldenDict的bug，已经修复。
4 个赞
原来是ComicEnhancer Pro处理导致的问题。@阿彌陀佛 兄很多图片正是用ComicEnhancer Pro进行过处理。技术细节我不懂，我猜可能是PNG文件在ComicEnhancer Pro处理过程中被压缩了，然后在MDXBuilder里再次被压缩，于是官方版本GoldenDict 没有考虑这种情况导致该图片不能正确显示（深蓝踩过这个坑目前版本没有这个问题）。
不过这个bug 经 @last_idol 探讨后，在 @nonwill 的GoldenDict版本中被解决了。讨论过程见
1 个赞
扩充词头需要注意的：MDX转跳死循环原因和解决办法
再补充我的一点发现，关于词条显示顺序。假设词头是foo。
在编译mdx时，当aaa内容是@@@LINK=foo1、bbb内容是@@@LINK=foo2时，TXT里面
foobar
@@@LINK=aaa
</>
foobar
@@@LINK=bbb
</>
那么在编译的mdx查询foobar会先显示词条foo1内容，再显示词条foo2内容。这时候上下顺序决定显示顺序。
但如果bbb内容不是@@@LINK=foo2跳转链接，而是具有实际内容的词条，那么编译的mdx查询foobar会先显示这个具有实际内容的词条，再接词条foo1内容。这时候上下顺序决定不了显示顺序。
其原因，应该是mdx查询foobar时，先找词头为foobar且具有实际内容的词条，然后按照从上到下顺序显示词头为foobar的所有@@@LINK=跳转链接。
2 个赞