发布的词典成品若没有附带原始的JSON，而依然是HTML的话，别人要重新改造这个词典，依然是个很麻烦的事。非程序员，好像难以做到。不知如何解决？
用模板渲染的话，发布的就是原始 JSON。
能否进一步解释一下：上述哪些属于词典的范畴？哪些属于词典程序的范畴？
这样对于我们只懂HTML、CSS和正则的非程序员，可以更好的理解。特别是第一个问题，对于希望能够方便自定义词典的普通制作者，很关心。目前的mdx，让我们只要知道制作HTML网页，就可以制作出词典。不知切换到这个新模式下，我们需要具备什么样的知识背景？
3 个赞
可能需要学习JSON和HTML模板的书写格式，再具体要问楼主了。
JSON类似常见的INI配置文件，以键/值对形式存在，如下INI文件的组织形式：
title=freemdict
def=make knowledge free
title, def 是键名称，等号后面的freemdict 和 make knowledge free 分别是对应的值，这里把title 当作词头, def 当作解释项，这两键名称由你自己定义，更多键值对也可以，转化成 JSON文件，如下：
{"title": "freemdict", "def": "make knowledge free"}
可以注意到，冒号前是键名称，冒号后面跟着是对应的值，只是用双引号保护起来了。更多的 JSON语法说明可以参考 w3c 的 JSON 教程：链接
简单的HTML模板可以想象成把HTML 文件挖坑后的样子，由模板引擎负责把JSON里的键/值对填充进模板对应的坑里生成HTML。下面是一个词条的HTML片段：
<div>
<h2>freemdict</h2>
<span>make knowledge free</span>
</div>
参考上面的 JSON 格式，把词头和解释项，用前后两个花括号挖坑后就变成了 HTML 模板：
<div>
<h2>{{ title }}</h2>
<span>{{ def }}</span>
</div>
模板引擎由作者提供，模板引擎会查找 JSON 里的 title 和 def，把他们对应的值填充进这个模板里相应位置，生成正常的 HTML：
<div>
<h2>freemdict</h2>
<span>make knowledge free</span>
</div>
在有了 JSON 和 HTML 模板后，只需要更新 JSON 里的内容，就能生成对应的 HTML。词典作者们的主要任务就是书写 HTML 模板，原始JSON数据的提取参考作者#37楼。
3 个赞
如果JSON字符串很复杂，有没有方法或者程序能自动生成模板？ 
要问作者了。
感谢这么浅显易懂的细致解释！如果是这样，数据和格式彻底分开了，比HTML和CSS分的还彻底，对后期重新利用确实再方便不过了！强烈支持！！
新格式最好能很方便地从现有mdx 转换过去。
以论坛COD9 双解的mdx为例，其标签绝大多数是自定义的，这种情况转换方不方便呢？
如果不能，那新格式可能只会用于部分新词典。
举个代表性词条agree为例
<rw><hwd><c>agree</c></hwd></rw>
<rw><phx><pho>/əˈɡri:/</pho></phx></rw>
<rw><sa>
<prx><pos>v.</pos> (<h>agrees</h>, <h>agreed</h>, <h>agreeing</h>)</prx>
<def>
<sb><sqn>1</sqn> <prx><pos>intr.</pos></prx>
<def><uit><en>hold a similar opinion</en> <zh><cn>同意，意见一致</cn> </zh>
<ex> <exp> <eps>
<eg><en><x>I agree with you about that</x></en> <zh> <cn>我同意你对此事的意见</cn></zh></eg>
<eg><en><x>they agreed that it would rain</x></en> <zh> <cn>他们都认为会下雨</cn></zh></eg>
</eps></exp></ex></uit></def></sb>
<sb><sqn>2</sqn> <prx><pos>intr.</pos> (often foll. by <cn>常后跟</cn> <x>to</x>, or <x>to</x> + infin.)</prx>
<def><uit><en>consent</en> <zh><cn>赞同，赞成</cn> </zh>
<ex> <exp> <eps>
<eg><en><x>agreed to the arrangement</x></en> <zh> <cn>赞同所做的安排</cn></zh></eg>
<eg><en><x>agreed to go</x></en> <zh> <cn>同意前往</cn></zh></eg>
</eps></exp></ex></uit></def></sb>
<sb><sqn>3</sqn> <prx><pos>intr.</pos> (often foll. by <cn>常后跟</cn> <x>with</x>)</prx>
<sc><sqa>a</sqa> <def><uit><en>become or be in harmony</en> <zh><cn>融合，和谐</cn></zh></uit></def></sc>
<sc><sqa>b</sqa> <def><uit><en>suit; be good for</en> <zh><cn>适合；适宜</cn> </zh>
<ex> <exp> <eps>
<eg><en><x>caviar didn't agree with him</x></en> <zh> <cn>鱼子酱不合他的胃口</cn></zh></eg>
</eps></exp></ex></uit></def></sc>
想起来，肯定比直接改HTML来得难，好像在做逆向工程。估计对于复杂的大型词典，通常一个模板是不够的，或实现起来很难，可能得通过多个HTML模板实现。
我看 COD9 这种类似的源码也头大，从HTML提取JSON，是最困难的工作，别的都简单多了。
是的。
不过即便是mdx，如果是从无到有写css文件，或者对mdx进行大改，对这些自定义标签的含义和嵌套结构都要搞清楚才行。
新格式在设想阶段尽量多考虑一些。到了实施阶段，还是一步步慢慢来吧，投石问路。
1 个赞
赞同！定义了字典内容的"数据结构"，一切都好办
mdx确实不好，但json数据更差，效率什么的都会因此大大下降。mdx格式应朝提高处理效率方面改善，而不是相反。但结果需要干了再说，electron其差无比，但还是有人用。但如寄希望于别的开发者，则估计没人会从事这个json格式字典开发的。
1 个赞
建议结合大家的讨论完善一下proposal：从必要性、充分性、存在性、可行性、唯一性、最优性、满意性等角度进行充分的阐述。这是开始庞大计划前的准备，既描绘清楚未来的前景，也回答各种疑问，从而争取最广泛的支持。
同时，来个分阶段的实施计划，规划一下可能的资源投入和分阶段成果，并设计社区参与的方式和途径。毕竟听起来这是个庞大的计划，拆分到可理解或可执行的程度，可让希望之火燃烧的更旺一些。
1 个赞
应该是提高了，不知道你降低是怎么降低的。
原本甚至用用 IDM 加一个 文本编辑器 就能成的词典，现在还要学习 JSON 生成 解析之类的。
咱们不说别的，来做一个只有一个词条的词典，简单点，这个网址：「天 てん①」的意思与用法详解，日语学习词典 - MOJi辞書
我来说现在 MDX 技术下我怎么做。
- 打开这个网址
- 按下 ctrl s
- *可选，去掉头部和不必要的元素 脚本等（可以不用去，display:none 一把梭）
- 加上词头行，</> 行
- 打包
怎么样，是个人都看得懂也会做吧。
Agreed
我期望有新的格式出现，但是不要忘了，用户不接受，等于零。另外词典最重要的是索引问题，你提到的增修删改倒还在其次。你认为数据组织需要有一些规定，而不是一坨HTML塞进去，我完全赞同！也完全支持！然后你提到的 JSON 特性，也可以直接用 sqlite（要协同就转mysql，不转也行。。单线程） 嘛，规定好几张表，哪些字段，大家遵守就是了。
总之，我会支持你的，但是，MDX 之所以能是 MDX，我们今天在这儿讨论 MDX 及新格式，就是因为他的简单，好上手。
也许新格式的推广不是一件容易的事情，那就让子弹再飞一会，改成置顶两个月了。
1 个赞