正在制作新的词典格式 KPBD

技术交流与词典编修
1

新格式的后缀名是 KPBD，下面这个文件是目前的工作成果：包含一个词头，一条义项和三条例句，已经可以支持词头、义项反查和例句搜索。

sample.db (2.5 KB)

这里记录一些遇到的问题，讨论下是否可行：

  1. 词典包含重复的词条：有些词典不同词性的词头分成了两个文件，搜索的时候体验不是很好，打算避免这种情况，每个文件需要加上唯一的标题，标题不参加搜索，只用于区分搜索的结果：

    make (verb)
make (noun)

  2. 词典包含重复的例句：比如 SIO 双解词典，有 800 万条例句，简单过滤后，不重复的只有 126 万条，实际还可以进一步删减。比如下面这条例句，对应 4 条不同的中文翻译，生成索引的时候，应该全部索引吗？或者只索引第一条？

    1. A 15-year lifespan is not uncommon for a dog. 15年的寿命对狗而言是比较常见的。
2. A 15-year lifespan is not uncommon for a dog. 狗活15年并不少见。
3. A 15-year lifespan is not uncommon for a dog. 狗活15年并不稀奇。
4. A 15-year lifespan is not uncommon for a dog. 对于狗来说, 十五年的寿命并非罕见。

  3. 词典包含提取的子词条：有些词典做了二次提取，这样词头、义项、例句全部重复了，搜索的时候会出现两次结果，而且很多子词条二次加工后，HTML 结构上和父词条很相似无法区分，可能需要词典作者专门标记出子词条，这样索引的时候可以忽略这些重复项。

    make 
make for something @ 子词条
make off @ 子词条

  4. 是否要支持拼音和假名（读音）的搜索和排序？现有的词典格式对中文和日语搜索来说体验不是很好，以拼音为例：外国人学习中文的时候主要使用拼音搜索，这里的问题是会出现同音字，需要词典作者专门标记出主词条和拼音词条。排序的时候，如果搜索拼音按拼音排序，搜索汉字按汉字排序。

    例 % lì
力 % lì
荔 % lì

  5. 计划对多国语言的搜索和字体显示提供更好的支持，比如西班牙语、法语、德语、越南语，需要所有 html 文件加上 lang 属性。

    <html lang="zh-hans">

  6. 是否要支持全文搜索？目前感觉义项反查和例句搜索已经足够使用了，计划在 EPUB 文件中实现，如果很困难的话，也可能会是新的文件格式。

==========

上面这些问题，涉及到正在制作的生成器，类似 MDXBuilder 用于生成新的词典格式，可能问题会越做越多，可以发现新的格式无法直接从现有的词典中转换，词头、义项、例句都需要重新标注，因为新格式的目标是实现物书堂级别的搜索结果，达到类似或者更好的使用体验。

对词典格式有其他问题的话，也欢迎讨论！

8 Likes
2

很好的探索。配套的环境也要跟上。词典制作与导出，与MDX的互转互换。各大词典软件APP的兼容。当然体验要全面超越MDX，或有明显优势才有搞头。

1 Like
3

我觉得目前的格式主要问题在于共享编辑，格式还是要简单，工具要求低，每个人手头工具都可以打开编辑。一种简单设想就是html+css+js，然后zip压缩存储。

1 Like
4

关于SIO一条英文句子对应四条中文翻译的情况，个人感觉对于中文翻译的四种情况还是保留。因为这样用不同的中文词语解锁时，都可以搜索到这个英文句子。
个人使用中，感觉SIO汉语词语搜索时搜索功能很强大，句子中出现的词语基本都能搜索到。这比牛津朗文的查得率高。即使是英文词组，SIO查得率也比一般词典高。

1 Like
5

不如直接就是zip压缩包，文件名就是zip，也不搞什么新格式，这样手机上也能编辑。

1 Like
6

规定啥格式的，不算啥，标准层面的事儿，真正大头的都是生态如何建立。这些事儿，看你能抓住目前的通用格式有啥痛点，提出啥有针对性的解决方案。如果仅仅是平行替换的话，生态肯定不容易建立起来，毕竟迁移成本摆着呢。

1 Like
7

zip 不适合作为词典格式：zip 格式本身是没有索引的，如果需要查找的文件名在 zip 文件的末尾，需要读取所有文件名才能找到对应的文件。有些 zip 的解压库实现了快速读取，但每次加载的时候，都需要重建索引（hashtable），文件越多越慢。

8

搜索可以和 SIO 在线版的体验保持一致，目前的词典软件大多需要从左向右开始搜索词组，或者只能搜索连续的单词，KPBD 默认支持模糊搜索，不再需要使用通配符（wildcard）搜索词头。

搜索词头 “二虎”：九牛二虎之力；“take easy”：take it easy
搜索例句 “日程”：I have a very full diary today. 我今天的工作日程排得很紧。

9

不会平行替换，替换成本确实可能很高，但使用体验会很好，类似物书堂 APP。

1 Like
10

感谢楼主，很期待您给我们带来新的体验！

1 Like
11

请问是否开源？如何安装试用？

12

是否开源还在纠结，目前还不能安装试用。

目前进展：格式本身已经开发完成，索引生成和相关字段的搜索已经实现，正在制作类似 MdxBuilder 的词典生成工具，不确定的细节还比较多，除主贴里提到的问题外，不同类型的文本都需要人工标注，怎么样标注怎么提取还没有确定，实现越简单可以参与的作者就越多。

2 Likes
13

易于编辑的格式和高效的搜索是矛盾的。

1 Like
14

如果开源个社区版，有利于前期测试、推广。后期铺开了可以增加付费版、付费插件之类的。

mdx生态的接入：一键转换。

新词典的制作：编辑格式仍用 mdx.html.txt ，通过增加标签的kpbd开头的class来进一步标记更详细的内容（释义、例句、翻译、异形等）。这样方便过去经验的重复使用，然后一键转换成新格式方便运行。（没有进一步标记的，只能支持原有搜索功能（词头、全文））

2 Likes
15

目前是这样计划的，所有文本类型都有对应的 class 名称。可能不会支持一键转换，新格式的生成工具会检查所有 HTML 标签的有效性，避免有标签没有闭合，还会对外部资源进行检查，比如样式、图片、音频链接，还有各类跳转链接，确保没有缺失。

2 Likes
16

新格式除了义项反查，和例句搜索，计划再增加自定义搜索，允许自行标注搜索的内容，可以实现类似全文搜索的效果，但更加准确和高效。

17

已完成：

  1. 日语支持平假名片假名叠字符通搜。
  2. 拉丁字母支持变音符轻重音符通搜。

目前进展：

发现简单的文本标记无法准确表达词典的结构，现在所有词头义项例句都需要预先提取成 JSON 格式，方便生成词典索引，好处是搜索给出的信息更加丰富，新格式生成器的工作会轻松很多，预计两到三周内可以完成。

2 Likes
19

主要是标签文本匹配的问题。新格式的索引在导入文本的时候需要指定文本的语言，比如下面这种 HTML 结构，这几天还看到了很多类似的嵌套结构，或者完全是平的结构，一个 P 标签从头写到尾。

<span class="def_text">
to build, create, or produce (something) by work or effort
    <span class="mw_zh">做；制作；生产；创造</span>
</span>

减少词典制作者的工作一定是优先目标，但目前看仅使用正则很难实现文本的导入工作。

用 JSON 可以显示更丰富的搜索结果：比如义项反查的时候，同时显示对应的词头和例句，并且可以随时跳转回到原始的位置。这个搜索结果是可以聚合显示的，可以直接代替现有的反查词典。

目前的设计排版信息不需要还原，排版仍然是用的 HTML，仅需要提取索引，每条义项就是最小的 JSON 索引单元，只需要给出对应的词头和例句就可以了，比如下面这个单元：

class Sense {
    title: Title,
    headwords: DValue<Headword>,
    tags: TValue<Tag>,
    dt: Sentence,
    examples: TValue<Example>,
}
21

这个办法是可以提取，但需要做特殊处理，和每个 class 标签对应完整文本的要求有冲突，需要区分内部的文本节点。

1 Like
22

嗯，我看了下朗文，释义也是平铺的，需要手动指定从哪里开始到哪里结束算释义文字。

这样需要额外添加container，复杂度直接 tostring 存到json里差不多了。

1 Like