也就是总结下来：
1、词典制作者的需求：确实有A==>B==C==A的情形
2、MDX设计：现有@@@LINK太粗暴，让词典软件难以处理，且缺乏词条ID，难以精确跳转。
3、词典软件：对上述处理需要同步改进，避免现有情形造成查询时软件崩溃。
2 个赞
有些作者自己实现了隐藏的词头来实现完美的跳转，但不是普通人能做到的。
之前拿了一个w3 Kindle版来制作成stardict辞典给goldendict安卓来用，提取了原型、原型的变形词条以及词条id(变形词条和词条id未必有)放在词头，
编译前的文本格式是tab文本:
词头\thtml标签内容
例子:take|takes|taken|taking|took|filepos[0-9]{9}\thtml标签内容
|前后左右的词条会放在*.syn文件里，filepos[0-9]{9}是词条id或者是词头内容的id跳转标识可以有多个(用来跳转的，跳转链接处理成filepos([0-9]{9})#filepos\1，由于跳转id是唯一的，即使goldendict安卓显示了两个take(词头相同，内容不同)，都能正确跳转(不会跳到别的地方去，因为不是根据词条来跳转的)。
mdict辞典通过隐藏词头实现完美的跳转大概是怎么实现的?
之前折腾了goldendict安卓兼容html内容的stradict辞典，发现能支持zip64(要utf-8文本编码识别拉丁字符，能读文件夹的文件)，能读取idzip(*.dz)压缩的stardict 3.0.0辞典，似乎意味着文本*.dict.dz和压缩zip都能大于4GB。
1 个赞
和stardict的处理差不多。对相同的词头，生成一个随机字符串的词头，然后正常的词头跳转到这个随机字符串上。
take
1. to get into one's hands
random_string
1. to get into one's hands
</>
take
@@@LINK=random_string
特殊词头最好不要随机生成。如果随机生成，那原有的 a[‘href’] 也得重写。
有能力生成随机字符串的作者，自己能处理。
原有的 a[‘href’] 和特殊词头之间有对应关系，如果随机生成后者，再想修改前者（保持对应）就很难了。
就是没有对应关系才要随机字符串的词头，正常的词头不用改。
可能我没表达清楚。举个例子吧：
_test_abc_1
123456
</>
_test_abc_2
654321
<a href="entry://_test_abc_1">abc<sup>1</sup></a>
/*由 <a href="abc_1">abc<sup>1</sup></a> 简单转换而来*/
</>
abc
@@@LINK=_test_abc_1
</>
abc
@@@LINK=_test_abc_2
</>
```您说的这个死循环问题，仅看到了最简单的一种死循环现象。真实的MDX词库中，@@@LINK跳转情况可以复杂得多。可以有多级跳转，可以不在第1级就现死循环而是到第N级才出现；同一个词在同一级上还可以有多个跳转，这多个跳转中有的是正常跳转到有实质内容的新词而有的就是(立即或者将来再跳转多次后)形成死循环闭合环；而且某一个相同词头可以出现多次：有的有实质内容，有的又是跳转；且以上几种情况还可以是同时出现 —— 这一切都源于MDX词库作者不够认真仔细造成。
这个死循环问题您也不必要操心，欧路/GoldenDict等词典软件开发者不是吃干饭的，如果连问题都没有考虑过随意就能让一个死循环的MDX将词典软件搞死，那您也太小看这些软件开发者的水平了。软件开发者水平高低的一个重要标志就是软件的健壮性，不仅能处理最一般的简单的输入情况，还要考虑特殊的输入甚至是攻击性质的恶意输入，在任何情况下都要正常运转不能崩溃。事实上是，这些病态的MDX从来都不会让词典软件罢工，您放心好了！
2 个赞