聊一聊制作mdx词典时那些容易踩到的坑

readmdict 解析出的 HTML 内容用 CR LF 换行,即 Windows 的惯例。于是和 Linux 惯用的 LF 有冲突。我的 Vim 充当二五仔,在 Linux 下偏偏用 dos fileformat 来解码用 readmdict 解压出的 txt,于是不会显示 ^M,害我仔细找 CR 了半天。

1 Like

虽说 HTML 规范貌似用 CR LF 换行,但我自己写的字典和脚本都用 LF 换行,在我的 GoldenDict for Linux 下倒是照常换行,至于在 Windows 下表现如何我就不知道了。

欧路不是可以自定义发音库吗

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或许会不认:

需要用Photoshop之类另存一下。

2 Likes

原来是ComicEnhancer Pro处理导致的问题。@阿彌陀佛 兄很多图片正是用ComicEnhancer Pro进行过处理。技术细节我不懂,我猜可能是PNG文件在ComicEnhancer Pro处理过程中被压缩了,然后在MDXBuilder里再次被压缩,于是官方版本GoldenDict 没有考虑这种情况导致该图片不能正确显示(深蓝踩过这个坑目前版本没有这个问题)。

不过这个bug 经 @last_idol 探讨后,在 @nonwill 的GoldenDict版本中被解决了。讨论过程见

扩充词头需要注意的: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 Likes

词库词序排列的问题
用MdxBuilder编译.mdx词库时,具有相同词头的三个独立词条,编译前txt中是以0001,0002,0003等正常顺序排列的,但编译后程序中查询显示的却是0002,0001,0003。别人编译的mdx,显示的却是正常的词序。很长一段时间,一直不知是什么原因

解决方法,借鉴
https://www.pdawiki.com/forum/thread-3558-1-1.html
尝试了一下,用MdxBuilder编译前,在第一个词条的词头前面再加上两行</>,即一共三行(如该词条前面只有两行</>则编译后消失),然后再编译txt为mdx。

一点感想:
这样子操作词条数会+1,如果N个词条都这样子操作则词条数会+N。不开源工具在使用中碰到bug实在是尴尬啊

最近用MdxExport.3.6 解包一个mdx,其源代码里头有大量的软回车(即箭头向下符号),如下图


在emeditor中用正则\n搜索可以匹配两类换行符,但用\r或\r\n只能匹配硬回车、不能匹配软回车。

之前听说有些txt用其他开源工具编译失败,但用官方的工具可以成功编译。显然,MdxExport是可以无视软回车的,估计这种兼容处理是其容错性强的一个方面吧。

1 Like

是的。既然解包了,肯定会顺手规范处理。

另一个可以成功编译的例子:mdx官方工具不仅可以无视软回车,硬回车也没问题。

现实中,很多小白并不会一开始就注意规范。mdx官方工具容错性强,是其广泛流行的一个重要因素。如果门槛过高过于严格,无疑会挫伤小白们参与的积极性;但过分降低门槛,就会出现目前mdx面临的一些窘境。

可见,规范和使用是鱼肉熊掌不可兼得的trade-off关系,需要在两者之间进行精细取舍权衡。毕竟,绝大多数老手是从小白一步一步成长起来的。

2 Likes

今天第一次遇到链接图片打包时编译器提示出错,把img文件夹从中文命名的文件夹中移出再编译再ok了。

用的哪个编译工具?

image
没注意到的话,每打包一次就少一个词条噢

有时候确实会吃一条,大部分情况都是正常的,不知道什么原因

mdxbuilder 没有出现这个问题,这说的是lgmcw改良了排序的writemdict.py

:fleur_de_lis:【支持超大文件】Python MDX词典打包工具 2019-11-19更新
https://www.pdawiki.com/forum/thread-36415-1-1.html
(出处: 掌上百科 - PDAWIKI)

1 Like

吃一条的原因可能是文本编码为utf-8有签名的原因,改为无签名应该就没问题。

lgmcw这个之前说是python 2代码。分号作为语句结束也可能是js。

我用的是zzzsleep的mdict-utils mdict 打包解包工具。

pip install mdict-utils
排序方面没发现有问题。推荐使用

1 Like

mdict-utils 的排序处理标点符号时,用的是python 自带的符号库,这个符号库里面的符号特别少,中文标点都没有匹配,不知道 mdxbuilder 的作者有没有处理中文标点。

这么说好像可以跟一些奇怪的mdx联系起来了。
Use the Right Word的英文版由于原来文本中的'都是全角的,经过不同的打包工具的辗转之后,一些mdx缺失了这些,造成阅读理解上的不便。貌似研究社新編英和活用大辞典有些mdx版本有相似问题。

即便只是一个打包工具,也是有很多坑的啊。幸如 Linus’s Law所言,Given enough eyeballs, all bugs are shallow。

大小写转换也有很多坑,unicode 码表上大小写的 i 各有24种,这些要不要处理,碰到小语种的词典,还涉及到变形问题,不是一句大小写敏感就能说清的。

1 Like

就算是英语词典,有时候也要注意古英语的特殊字符。如OED
/original/2X/5/5a184f5439fdb51838c75376058b47c74da11c31.png