这文章属于专题的一部分，详见：Markdown知识贴
下面谈谈为知笔记（简称“为知”，下同）中的Markdown功能，包括为知Markdown支持的语法，Markdown功能的实现，目前已知的问题和对为知Markdown的展望等方面。
根据为知的Markdown说明和简单测试，为知目前支持的语法有
为知允许用户直接复制或拖动插入图片，和用自带的编辑器插入图片和表格，希望用这种方式来弥补Markdown文档自身对本地图片与表格的缺陷。这个看似很多编辑器都在支持的功能，但是为知这种方式得到的Markdown文档无法与目前可见所有Markdown编辑器兼容。
为知的Markdown与一般的Markdown有很大的不同，这产生了很多奇妙的现象：
不知道大家有没有对这些现象产生强烈的疑问？对我而言，这些疑问在一段时间里常常在我脑海种浮现。当我同时解压一个Md笔记与普通笔记做对比的时候，上面的现象都会得到了解释。
一篇Markdown笔记与一篇普通笔记所包含的文件是一样的，而找遍整个Markdown笔记压缩包都不会找到一个以.md为后缀的文件。只有一个名为index.html的文档，而这就是我们要找的Markdown文档。
这就是为知Markdown的真相：为知的Markdown笔记是Html文档格式的，为知的Markdown功能是在HTML上实现的！
当我们使用一个所见即所得HTML编辑器的时候，它的实现逻辑是这样的：
编辑器作用于HTML文档的源码，然后HTML文档被渲染成网页返还编辑器显示，实现了所见即所得。
而一般的Markdown编辑器的实现逻辑是这样的：
编辑器作用于Markdown源码，并返还编辑器中显示。如果支持实时渲染，Markdown会转化成HTML语法，然后渲染成网页实时返还编辑器中显示。
为知的Markdown是建立在HTML基础上的，所以逻辑更加复杂：
为知编辑器作用于HTML源码，HTML被渲染成记录着Markdown的网页，如果是编辑模式，这个写着Markdown的网页就直接在编辑器中显示，相当于HTML编辑器的逻辑。如果是阅读模式，网页上的Markdown被转化成HTML，然后HTML渲染成网页（最终结果）返还编辑器中显示。
看图的左侧，类似一个所见即所得HTML编辑器逻辑。看图的右侧，类似一个Markdown编辑器的渲染过程。所以为知的Markdown实现方法可以简单的总结为在一个所见即所得HTML编辑器上搭载了一个Markdown渲染工具。
下面是吐槽总结点评的时间：
我们知道，Markdown的目的是转化成HTML发布，而为知的Markdown却使用HTML记录，总给人一种本末倒置的感觉。原本的HTML渲染成Markdown，然后Markdown又被渲染成HTML，又给人太迂回的感觉，不对，是为知遵循否定之否定的必然规律实现了螺旋上升……Markdown本身是纯文本，而为知的Markdown文本是HTML渲染之后得到的，可以是富文本，所以使用为知自带编辑器经常会得到格式古怪的“Markdown源码”文本。一般的Markdown编辑器是针对纯文本的，所以富文本的为知Markdown文本中的图片会被冲掉。因为渲染了两次，所以经常会闪一下。因为Markdown文本是用HTML记录的，所以加个后缀就可以当作Markdown（其实内部没有进行两者之间的转化），所以为知的Markdown与普通笔记可以共用一个编辑器，所以所有可以用来编辑HTML的编辑器都可以用来编辑为知的Markdown文本。
这种Markdown实现方式，最直观的问题应该是效率问题。因为流程太长，而且需要渲染两次，打开Markdown笔记的速度必然会收到影响，本人的实际体验是打开一篇Markdown笔记一般都需要2s左右，中间会看到Markdown文本先被显示然后被替换。看到自己电脑渲染这么慢，我都替为知的服务器心疼。使用Editor.md插件的时候更是明显，写一篇稍微长一点的Markdown笔记就会变得十分慢，需要关闭标签重新打开，但是没过多久又会变卡。
长远的看，这种Markdown会被底层的HTML深深的束缚住，难以发展，比如想开发一款Markdown编辑器，那么这个编辑器首先是要基于HTML编辑器的，而为知自带的HTML编辑器都又很多问题，让人很怀疑为知开发这Markdown编辑器的能力。再比如想加入本地图片功能，在不改变现有HTML文件包结构的情况下很实现难。
当然，这种方式也不是一无是处，有一个非常大的好处就是可以让所有的笔记格式齐平，这对搜索、笔记整理以及文件安全是有很大帮助的，因为同时支持两种不同的格式会让搜索和笔记整理的工作量大增，所有的功能和规则都要开发两套，那工作量是翻倍的，而且会容易变得非常不稳定。这大概也是大象（印象笔记）一意孤行不采用Markdown的原因之一吧。
最后说一下为知独创的添加图片和表格方式，那是一种为知自己图方便的办法，让第一次渲染得到的图片和表格在第二次渲染中不被过滤直接输出。Markdown本身是兼容HTML标签的，但是为知这么一搞，变成了好像是HTML在兼容Markdown语法一样。而且这样让Markdown变成带图片的富文本，这样的Markdown是个非源码又非所见即所得的四不像。这可能体现了为知对Markdown的理解，但是这样做没有太大意义，真正使用Markdown写笔记的人是不会用这种方式的，因为为知不是Bear，目前还没有足够的用户粘性，让用户只用自带编辑器来书写Markdown，而且这种方法也与Editor.md插件不兼容呢。如果有为知官方人员阅读此文，请考虑放弃这种添加图片和表格的方式，探索更好的方式。
虽然对为知的Markdown抱怨甚多，但还是展望一下为知Markdown的未来，希望为知能看到。
解决效率问题
说实在，这是本人目前面临最大的问题，而且也是最直观的问题，打开Markdown笔记会比普通笔记慢一拍，而且会闪（在移动端也是如此），插件编辑会卡顿。虽然这些问题都是为知Markdown机制决定的，Markdown笔记会比普通笔记有更多的步骤，但还是希望为知在这个问题上想想办法。重构Markdown的实现机制？还是更改处理的顺序，先区分Markdown笔记和普通笔记再进行渲染？
还有插件编辑Markdown一段时间后容易变慢，这个当然与个人机器性能有关，但是我打开Word写长文本一点问题都没有，反而用为知写Markdown觉得卡，这很尴尬。自从用了为知的Editor.md插件之后我就没有在使用其他Markdown编辑器了，最近用Markdown写长文本，响应慢的问题越来越严重。目前已经产生了放弃使用为知编辑笔记的想法了，以后可能只把为知做收集和整理，将笔记书写交给其他应用。如果为知有能力自己开发一款自带的Markdown编辑器的话，虽然不能从根本上解决问题，但是在响应速度上应该可以得到很大的改善，不过这需要提前对Markdown笔记和普通笔记进行区分就是了。
Markdown编辑器
虽然有Editor.md插件，但是一个自带的Markdown编辑器总是需要的，插件的功能再多，性能上总是受限的，而且使用插件编辑Markdown时笔记工具栏会消失，无法编辑标题，无法添加附件，无法添加标签等等。现在的Markdown编辑器发展太快，因为Markdown语法本身就限定了功能的范围，所以目前的Markdown编辑器的关注点大多在用户体验上。虽然拿一个专业编辑器来要求一个笔记软件是不公道的，笔记软件也很难达到那样的高度（Bear那样极度强化书写功能的怪物例外），但是一个专门的Markdown编辑器非常必须。Markdown只是书写语言，是为平台或编辑器服务的，不同于HTML，不是发布语言，所以不要奢望把Markdown完全交给外部编辑器，为知的Markdown编辑器应该实现下面几点功能：
保证Markdown的纯文本特性。首先编辑器书写的Markdown文本应该以纯文本呈现，乱七八糟的格式太影响书写。其次是编辑器可以让从别处复制过来的富文本转化成Markdown语法的纯文本。如果不能重新搭建一个Markdown编辑器，起码在现有的HTML编辑器中加入一个纯文本模式的功能。
图片插入。前面说过图片插入的问题，HTML式的插入图片破坏了Markdown纯文本特性。那有没有方法，既能满足Markdown语法，又不破坏现有的HTML文件框架，甚至可能被外部纯文本编辑器编辑过后不掉图？我有个idea不知道可不可行，供参考。首先图片依然存放在\index_files\……路径下，编辑器中新增一个板块专门管理和查看\index_files\……下的图片（这里暂且将这个板块称为图床），然后图片Markdown语法使用参考式。每当在图床中添加图片，会在Markdown文档最后添加一个参考id，id为图片名字。用户想添加图片的时候，使用参考式图片语法![][id]即可插入图片。如果将图片直接拖拽到Markdown文档，会在图床和\index_files\……路径下添加图片，同时在Markdown文档中插入一个完整的参考式语法。图床最好会锁定\index_files\……下的图片，只有在图床中删除图片，才能让图片从\index_files\……中删除。如果想使用外部编辑器，只要先把需要用到的图片放到图床，然后调出外部编辑器，使用参考式语法就可以同样插入图片。另外还能让用户在图床中对图片进行放大查看、修改和替换。我觉得这是个难度少，但是受益巨大的做法，请为知认真考虑。
最好有语法高亮或语法识别。对于双栏实时预览，我觉得其实意义不大，那是给初学者用来过渡的，因为会造成信息冗余，占用笔记区空间，而且实时渲染也需要占用一定的资源。但是Markdown毕竟是源码输入，难免会打错语法，所以输入Md语法之后编辑器最好提供一个反馈，或是高亮，或是其他的样式改变。
编辑时空格可以被方便显示。空格是Markdown语法中很重要的语法元素，空格的数量不对就可能造成一些语法错误，但是空格不方便看，希望编辑时空格会被方便显示出来。有的编辑器将空格显示为灰色的点·。
目前的自带编辑器无法实现对大纲的预览，在阅读模式才可以看到大纲，如果愿意开发Markdown编辑器，希望可以加入大纲功能。如果为知笔记不希望在编辑器上着力太多，请优先实现第一第二点。
Markdown语法
为知其实已经支持挺多Markdown语法的，所以这里稍微提一些展望
目前不少Markdown支持元数据，有点类似HTML的开头部分，可以添加标题，作者之类的信息，很实用。但是鉴于目前为知的Markdown机制，元数据好像只会添麻烦。但是这里说个题外话，目前的界面标题栏于工具栏共用一行，而笔记页标签又有题目，感觉有点信息冗余：
多希望题目这一类的信息放到文档开头，打开向下箭头可以查看和修改更多信息，然后向下滚动的时候可以被隐藏，画了个示意图：
是时候让为知为Markdown也做点贡献了，希望为知可以发明个绘制简单的思维导图的语法，可以像绘制流程图一样，使用围栏式区块代码实现，代码用Markdown的列表或者标题就行。我觉得这样比使用开发插件或模板来的实在，更有用户粘性，可以源远流长，成为一大亮点。而且国外其实已经有软件实现了Markdown语法向思维导图的转化，只是没有将其设计成语法用于Markdown书写。
为知作为一款笔记软件，如果不把编辑作为重点的话，那么希望在阅读方面做一些优化，尤其是Markdown的渲染和阅读。比如对于单独成段的图片，可以渲染成区块，有的衍生语法就是这么设计的，还有如果图片比较大，阅读时支持点击放大查看。
开放API。为知笔记作为一款笔记软件，功能上不可能面面俱到。如果为知笔记的开发重点不在笔记编辑这一块的话，像大象一样开放API或许是最好的选择，毕竟只有Win端才支持插件和外置编辑器。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。