对 Access 只有很模糊的概念，但是对Office的VBA二次开发略有点经验，如果写个脚本把 mdx 源文件直接导入 Access，或许可以较低的成本做一个PC端的词典制作和查询的综合方案，实现并超越现有的PC端查词软件的功能应该不复杂，毕竟这些独立查词软件底层的数据库操作交给Access做都可以更高效，而且VBA做窗口界面不过也就是拉拉扯扯的简单活。请有经验的专家发表点意见，如果评估时间精力允许打算做做这件事。
这个想法源于Access专家 @Shaoshi 兄的启发，以前多有得罪，皆就事论事，请勿见怪。
（吃惊地发现 Access 没有移动版）
参考：<>Access 与 Excel 最重要的区别是什么? - 知乎<>
<>宇哥教你用Access数据库做成语词典（节选）,教育,资格考试,好看视频<>
瞎琢磨。。。
术业有专攻，建议用下物书堂，目前最好的查词软件。
有没有物書堂的使用方法，耀西，我买来不会用
shaoshi 不是已经用上 access 好多年了吗
如果一开始不想仔细整理，可以直接扔到两个字段里：title, definition。如果想整理，只要把网站的原始css拿来分析一下，所有的字段类型就有了，依此制作一个Access数据库模板，然后写一个脚本逐条拆分过去。只有这个导入脚本需要根据不同的源数据定制一下，人力要求应该不会太高，特别是如果源数据象OED这样的本来就精细度很高明显就是服务器的数据库里用不同字段拼出来的。
在Access里面不难实现现有的几个PC端的查词功能，最后只要用一个函数把所有字段的值拼接成一个完整的html页面。如果需要移动端使用，只要用一个函数直接导出一个mdx源文件txt再压一个mdx。这些都是可以一劳永逸的工作。
相比之下，直接拿一个几百兆甚至上G的源数据拖到EmEditor中进行处理，或用一个python脚本默默地跑一遍，就显得笨拙和低效了。
这样的释义没有任何的html标签，就是在现有的mdx中也没有显示效果，这和Access无关。
Access中的释义字段的内容可以是一段包含 html 标签的文本。如果释义精细分割过，每个字段可以是一段纯文本，Access可以在输出页面根据字段类型和css自动加上格式。
在PC端输出释义页面的工作，在Access中用VBA二次开发容易实现，比从头开始写一个独立软件简单太多。如果需要移动端使用，用一个简单的脚本 Export 一个mdx源文件txt再压出一个mdx给移动设备用。
把 mdx 的源文件 txt文件逐条拆分填入 Access 数据模板内。最简单的办法就是把源文件中的html片段直接填进Access模板内。
这是最省事的办法
我只懂Win平台写点小程序，安卓平台要用还是需在 Access 中导出 mdx的txt源文件压出mdx
“一坨无结构的数据”----这只是最省事的办法，即使这样也比操作一个几百兆上G的txt文件强太多，而且很多网站上抓取的数据css已经把数据的结构分的很清楚，拆分导入Access并不难
功能优点：在PC端上把词典的制作和使用集成在一起
现有的 mdx 转入Access，只需要用上面说的“一坨数据”的最简单方法，就是你以前什么显示效果现在还什么效果
JS和CSS作为一个字段保存，Access内部的查词页面上检索到一个词条后，以它的所有字段数据为原料和加上一个共用的js和css，拼接出一个完整的html页面显示出来
用Access管理，并不能说把制作成本降到十分之一，只能说同等的成本下，得到更好的管理性和扩展性
并不指望Access带来什么神奇的魔力，主要目标----同等的制作成本下，更好的管理性和扩展性。如果管理性和扩展性都不重要，那这个方案对他就没有意义。
Access 似乎是不应被忽略的管理和检索mdx源数据非常高效的工具，花大量时间制作词典的朋友不妨抽点时间研究一下，应该会有不小收获。
Access官方文档：
<>Access video training - Microsoft Support<>
<>Access help & learning<>
<>https://learn.microsoft.com/en-us/office/client-developer/access/access-home<>
多个数据库之间可以独立存在而相互检索数据
<>Import or link to data in another Access database - Microsoft Support<>
<>Microsoft Office Access Lesson #14 - Multiple Databases with linked tables - YouTube<>
<> Access 跨库查询_百度搜索 (baidu.com)<>
补充信息：
<>Access和SQLServer有什么区别？ - 知乎<>
难道没有任何一位坛友也认为 Access 是管理mdx源数据的最佳工具？并且可最方便地定制PC查词客户端？达到同等的正文展示效果并不会显著增加词典制作的工作量？
这当然是针对常常花比较多的时间在制作词典的朋友而言，如果自己不做词典任何工具都是不必要的成本。探索新的技术路线，先务虚再务实是比较实际的做法。
对的，普通用户需要的是一个傻瓜工具，打开mdx，查词的时候发现错漏直接编辑修改 。
我觉得楼主的主题可以上位化概括为将词典拆解后存入数据库，倒未必一定要限定Access。这个想法如果是普适性地对付所有词典，是不现实的。但也不能说毫无用处，可以针对一两本词典进行这项工作。比如我就想要一个能够生成一词一义一句的anki卡片的工具，如果预先拆解了一本词典，就很容易做到。
access不能跨平台，支持这个是浪费时间。
首先谢谢各位的回帖
这还真给你说着了。我本人的习惯是一个项目先在脑子放一阵子，如果能得到旁人的意见那是最好的，无论嘲笑也好甚至说的一文不值都没关系，如果有人能比我自己还感兴趣先实现了那岂不更好。
论坛有一位姓王的哥们，总是被大家嘲笑，这个问题我是这么看的，参与这个论坛，不论是提出需求还是发表负评，只要相互尊重，都是一种贡献，总觉得别人成心要来占你便宜的那种想法不是很健康。大家都受教育这么多年，希望自己的劳动成果得到肯定比伸手拿到一本mdx要有价值的多。
站长查查就知道，我对词典没什么太大需求，现在用的古代汉语词典是百度来的丑的一批也凑合用，最大的收获是 @feiwu 兄制作的一本名人字号词典，而且也做了点小小的贡献，还有 @douglarek 兄制作的胡注通鉴，一直在用。
以前的老板说过一句话，他说你们好好工作两年增长才干后跳槽出去薪水翻个跟头，最终得到最大好处的还是你们自己。这话也可以理解成忽悠，看什么角度了。
Access有mac版，Linux上肯定是没有，因为不能跨所有平台就是浪费时间，这个有点过了吧
CHM有两大缺陷，不能加载多部词典，不能方便地编辑源数据，所以放弃了。
你为啥不考虑SQLite?