词库词序排列的问题
用MdxBuilder编译.mdx词库时，具有相同词头的三个独立词条，编译前txt中是以0001，0002，0003等正常顺序排列的，但编译后程序中查询显示的却是0002，0001，0003。别人编译的mdx，显示的却是正常的词序。很长一段时间，一直不知是什么原因
解决方法，借鉴
尝试了一下，用MdxBuilder编译前，在第一个词条的词头前面再加上两行</>，即一共三行（如该词条前面只有两行</>则编译后消失），然后再编译txt为mdx。
一点感想：
这样子操作词条数会+1，如果N个词条都这样子操作则词条数会+N。不开源工具在使用中碰到bug实在是尴尬啊
最近用MdxExport.3.6 解包一个mdx，其源代码里头有大量的软回车（即箭头向下符号），如下图
之前听说有些txt用其他开源工具编译失败，但用官方的工具可以成功编译。显然，MdxExport是可以无视软回车的，估计这种兼容处理是其容错性强的一个方面吧。
是的。既然解包了，肯定会顺手规范处理。
另一个可以成功编译的例子：mdx官方工具不仅可以无视软回车，硬回车也没问题。
现实中，很多小白并不会一开始就注意规范。mdx官方工具容错性强，是其广泛流行的一个重要因素。如果门槛过高过于严格，无疑会挫伤小白们参与的积极性；但过分降低门槛，就会出现目前mdx面临的一些窘境。
可见，规范和使用是鱼肉熊掌不可兼得的trade-off关系，需要在两者之间进行精细取舍权衡。毕竟，绝大多数老手是从小白一步一步成长起来的。
今天第一次遇到链接图片打包时编译器提示出错，把img文件夹从中文命名的文件夹中移出再编译再ok了。
用的哪个编译工具？
没注意到的话，每打包一次就少一个词条噢
有时候确实会吃一条，大部分情况都是正常的，不知道什么原因
mdxbuilder 没有出现这个问题，这说的是lgmcw改良了排序的writemdict.py
【支持超大文件】Python MDX词典打包工具 2019-11-19更新
https://www.pdawiki.com/forum/thread-36415-1-1.html
(出处: 掌上百科 - PDAWIKI)
吃一条的原因可能是文本编码为utf-8有签名的原因，改为无签名应该就没问题。
lgmcw这个之前说是python 2代码。分号作为语句结束也可能是js。
我用的是zzzsleep的mdict-utils mdict 打包解包工具。
pip install mdict-utils
排序方面没发现有问题。推荐使用
mdict-utils 的排序处理标点符号时，用的是python 自带的符号库，这个符号库里面的符号特别少，中文标点都没有匹配，不知道 mdxbuilder 的作者有没有处理中文标点。
这么说好像可以跟一些奇怪的mdx联系起来了。
Use the Right Word的英文版由于原来文本中的'都是全角的’，经过不同的打包工具的辗转之后，一些mdx缺失了这些’，造成阅读理解上的不便。貌似研究社新編英和活用大辞典有些mdx版本有相似问题。
即便只是一个打包工具，也是有很多坑的啊。幸如 Linus’s Law所言，Given enough eyeballs, all bugs are shallow。
大小写转换也有很多坑，unicode 码表上大小写的 i 各有24种，这些要不要处理，碰到小语种的词典，还涉及到变形问题，不是一句大小写敏感就能说清的。
就算是英语词典，有时候也要注意古英语的特殊字符。如OED
/original/2X/5/5a184f5439fdb51838c75376058b47c74da11c31.png
没有深入研究过这个。
直觉是除了惯常排序（字母拼音笔画等等）外，utf-8内的按编号排？utf-8外的没必要参与排序了。
不管代码最后采用什么排序，类似这种有点含糊的问题，应该在规范中提一句备忘，便于后续完善改进，也是格式规范的题中之义。
我来更新 4 个。
No.1 转化词头当中的 HTML 符号实体 或者 HTML URL 编码
No.2 自闭合标签
No.3 转化链接中的标点。
假设：
<a>I love "U"</a>
处理成了：
<a href="entry://I love "U""> I love "U" </a>
经过解析后，会变成：
<a href="entry://I love" U=""> I love "U" </a>
▲ MDX 中，一些特殊字符采用 URL编码反倒不能正确跳转 (比如 ® )。
转标点符号这个问题，我在提取词组跳转到主词条时经常会忘记而费时返工。
No.4 去除空白行和首尾空白
今儿个修了自己发现的 Free Dictionary of Idioms 2020 当中存在的以上问题。
P 站更新链接点这里，目前里面的百度网盘链接还没有更新，奶牛链接里的是最新版。
我觉得最大的缺点就是无论是mdx格式，还是mdict，以及mdxbuilder都没有一个详细的说明。
比如我制作日语相关的辞典时，相对于mdx，结果还是用对汉字支持不佳的epwing来得方便。因为遇到问题我基本都可以通过读帮助文件找到答案。
所以我完全不觉得没有说明文件和规范这一点会对入门者友善，反而会因此劝退许多人。因为入门者往往遇到困难就是在许多小的方面，可能是某个选项的作用，可能是带符号的词条，可能是小语种字符或音标，可能是代码版本。是改一下内容即可，还是根本就不支持，需要自己摸石头过河。
其实上面列出的许多问题，并不一定需要开源，只需要作者稍微作个说明即可。支持（或不支持）什么格式，最大长度多少，限制是什么。以及程序中的某个选项具体有什么意义，选取后会产生什么不同结果等等。
具体我举三个我到目前都没有弄清的问题。（我平时主要用ebwin，所以是在ebwin中使用自制mdx时遇到的问题，可能有点小众。）
1，a href跳转。
在mdict中似乎可以实现词条的文中跳转，但是ebwin中只能跳转到词头。我还就此问过ebwin的作者。它说原因是mdx是没有锚点的，所以a href跳转只能通过重新检索词头的方式来实现。
这个问题在词头有重复时就相当有问题了，结果只能列出所有词条，而非转到特定的某条，自然也就不能保证第一个结果就是正文所指向的。
我最后用的解决方法是词头一律以数字来做，真正的词头做成跳转。但是跳转时这些不想显示的数字就会在搜索条上显示出来，如果有数字词条的话还会产生相互干扰。
2，检索结果缺失（这一点不确定是ebwin的问题还是mdx的问题）
比如：mdxbuilder打开strip key功能，转换如下的文本。
(词头有空格）
a·b
1111111111111
</>
a b c
1111111111111
</>
a a c
1111111111111
</>
aac
1111111111111
</>
abd
1111111111111
</>
以a检索可以检索到所有词条。但是以ab检索的话，显示不出abd。以aac检索的话，只显示a a c，不显示aac。
3，mdxbuilder的index block size到底按什么确定。
具体比如有如下的词典文本。为了方便跳转，文本词头均为数字，主词条设为跳转。
12120
abcdefg
</>
12121
aaaaaaa
</>
……
真正词头
@@@LINK=12120
</>
真正词头2
@@@LINK=12121
</>
……
当index block size设为32k时，用1212可以检索出所有词条，但是用12120就会搜不到这个词。index block size设为64k时可以搜到部分，到128k时可以搜到全部。词头本身都是5位数字，真正词头也不长，不知道为什么就是这个结果。
以上的后两条可能是ebwin的问题，不过也是因为mdx没有一个技术性文档，所以ebwin的作者也无从确认一定是ebwin的问题并调试。所以即使我反馈给他结果也是石沉大海。
用ABBYY时应该先修改一个合适的显示字体，有的字体对于大写I，小写l，数字1，以及大写O，数字0很难分别。
最简单的解法就是。。第一条设为无意义的
