缘起
早上码字时看见VS Code插件「Markdown All in One」更新了，支持了「删除线」和「code span」，但是在简书并不支持；而简书使用的一种上下标扩展「ℝ^𝕆^ℂℍ」「ℵ~0~」写法，在「markdown-it」则不支持（因为可以用LaTeX语法「$ℝ^𝕆ℂℍ$」「$ℵ_0$」）；而作业部落使用的「Cmd Markdown」接近「markdown-it」。
注：现在简书已经支持「删除线」和「（KaTeX）公式」，仍不支持「高亮」。总之本篇发表时我需要的效果「ℝ𝕆ℂℍ」「ℵ0」在各站点通过不同方式实现，导致本地备份中「原文」不统一。
于是想起了迄今为止三自运动的成果，前一篇提到了「遗留问题已经解决，或已有解决方案」，已经涉及了到什么山上唱什么歌见什么人说什么话在什么站点发什么格式的境外先进革命理论与本地革命实践相结合的问题。
并且，最初转向Markdown的原因，就是为了在站点和本地之间保持「同步」时而不需要大幅修改内容（比如富文本编辑器当中的公式、表格）。不忘初心牢记使命，自力更生艰苦奋斗自己动手丰衣足食这么久了，应该需要小结，不是总结。
理想状态
原教旨主义Markdown的「初心」，是简单的把「带标记的纯文本」翻译为「带标签的网页」，但是其「使命」并未完成就已经「停滞」，因为并没有对应当时（2004年）所有「必须」或「常见」的html「共识」。所以后来才有那么多「扩展」，还百花齐放百家争鸣。
比方说既然粗体斜体对应「<b>」「<i>」或「<strong>」「<em>」标签，那么立刻就要想到「删除线」本来就是html的「<strike>」或「<s>」「<del>」标签，「上下标」本来就是「<sup>」「<sub>」标签。
按理说，上面提到的这些（不需要额外指定样式即可实现的）「基本功能」，对于我的「初级需求」（不需要完整公式支持仅仅是正常文本语境中使用个别术语）来说，在支持Unicode字符前提下的UTF-8编码的网页内部，应该是这样的：
对于其它常见标签，比方说「<q>」「<cite>」，已经在前面《引号与书名号》一篇中测试过了。
既然html出现的本意，也是早期实现，是在互联网上发布「文本内容」，那么这些特定专业之外的普通码字工作者都可能用到的「基本」特性，应该是优先考虑的目标。而原教旨主义Markdown不支持，后来许多扩展也「意识不到」，似乎在这里存在一个「盲区」？
这里没有苛求原作者的意思。在那境外互联网迅猛发展的年代，为了个人的需求而自力更生艰苦奋斗自己动手丰衣足食，当然是值得鼓励和赞赏的。最多只能说，对于原作者的需求而言，原教旨主义提供的功能已经「足够」了。
还有一个可能的原因，那就是在Ascii环境下，用于标记的特殊字符「不够」了。正如这次更新使用双波浪号「~~」标记删除线，以及其它扩展中使用双等号「==」标记高亮，甚至原版中双星号「**」标记粗体……都是在有限的字符内部辗转腾挪的手段。
这也是我一直惦记着为了回避歧义而引入「扩展ASCII字符」自制「EuroMark」或「Markdown Alternate」的原因。还特意提到了包括但不限于法语的引号「«」「»」可作为书名号标记使用，代表「<cite>」标签。在之前测试AsciiMath脚本的时候也已经展示过使用「ゑ」之类Unicode字符标记公式块的效果了也。
也就是说，具体用什么符号可以再商量，甚至还可以根据个人背景和工作环境不同而各不相同，对于仅仅进行文本替换实现的开源的脚本来说，只要提供相应功能，就能「自定义」到用户顺手的程度。
实际上在运用过程中，需要设定样式的「基本」功能也很常见，比如在「markdown-it」广泛应用场景当中最常见的「<code>」和比较常见的「<kbd>」标签。前者从原教旨主义Markdown开始获得广泛支持，各种扩展的「语法着色」其实针对的是「<pre>」标签的代码块。后者则没有被Markdown支持，各种扩展都一样。
<p>代码：「<code>code span</code>」</p> <p>键盘：<kbd>⊞ Win</kbd><kbd>⌘ Cmd</kbd><kbd>⌥ Option</kbd><kbd>⇧ Shift</kbd></p>
上面的内容，在设定样式之后，显示效果是这样的：
那么结论是什么呢？
很显然文本标记与网页标签壹壹对应没必要，大部分罕见的尤其是没有语义功能只有排版作用的标签，都可以通过样式实现。而即便是语义功能，通常习惯上也会在文本内部解决（直接输入）而不是诉诸标记，就比方说引号和书名号。
对于「面向出版码字」的文艺工作者所关注的业界现状都知道，只需要「不带任何格式和标记的纯文本」，无论是网文还是实体。
而对于发布包含丰富多媒体内容的码字人士来说，才有尽可能利用html所有特性的冲动。但是对于「源代码」的处理又不能随心所欲，若是各种标记充沛到了眼花缭乱的程度，已经不能算是「纯文本」了，有悖于「即便阅读源码也不眼晕」的「初心」。
同时还要考虑到，特殊需求可以通过扩展当前功能实现。比方说「流程图」「甘特图」之类，就是利用了「代码块」功能，并没有增加「新语法」，其「向后兼容」的方式是显示「源代码」而不是处理结果。
从这个角度看，对嵌入SVG图片的支持，也可以通过「svg代码块」实现；对数学公式的支持，也可以通过「latex代码块」实现。其它需求以此类推。
于是，达到我所想定的「理想状态」所需的工作，大概有以下几条：
- 扩展「代码块」功能支持「内嵌SVG图片」，目前没发现有实现。
- 追加对应「
<s>」「<sup>」「<sub>」「<cite>」标签的标记，前三个已经有扩展实现。保留对应「<q>」「<kbd>」标记的可能，也就是能让用户自己改脚本夹私货。 - 扩展代码块功能或利用现有扩展的「
$$」（可自定义）标记，支持嵌入MathML格式的公式，对应源代码可以是LaTeX格式，也需要考虑提供更简单的AsciiMath格式。 - 提供对应「
<video>」标签的标记（语法），但在当前html5视频尚未普及而各大站点仍然广泛使用flash并为了广告收入限制外链的情况下，同时考虑到各站点链接形式不同，可以暂时不保证实现，留给用户自定义。同理，提供「<audio>」的标记（语法）。 - 部分扩展中实现的「脚注」功能予以保留。但是，「公式/图片/引用自动编号」这种功能，需要转换程序内部使用「计数器」依赖上下文，不符合「简单文本替换」的最初设计理念，有类似需求的用户通常使用其它软件工具，不解释。
有个原则：转换结果中不能出现任何「可执行」脚本，保持「静态」特征，包括动图、视频、音频之类「准静态」内容。
比如利用Canvas的操作如「WebGL」，乃至「Web Audio API」，虽然提供「互动」可能，但不是「发布」内容的范畴。有类似需求的用户，想必都有直接写网页及对应脚本的能力，这些不是Markdown的义务。
下一步的计划
小结之后，该展望了。一言以蔽之：《三自出版运动》。敬请期待。
先说个「小缘起」，准备「小结」之后当然要考虑下一步的计划，所以又是记忆沉渣泛起。
我在2014年买了个「Kindle Voyage」，当时语境是「出版界」跳将出来一个钦定主角龙傲天力挺钦定文豪叫嚣着要对我多方围堵两面夹攻，与此同时一堆「自媒体」「自出版」的风向喧嚣甚上，还伴随着「众筹集资」（或曰「网络乞讨」）的广告。所以应景思考「出版物」炮制出来之后的发布方式。
于是把Kindle Voyage翻出来插上计算机，登录亚马逊中国下载PC端软件，发现新机是「第二台设备」，因为旧机寿终正寝之前还没注销。当时我没有买任何Kindle电子书，包括免费的那些，而是从繁荣的中文互联网上找了一批拷进去「测试」，后来风向过了也没有再继续。
这次上网乱搜弥补代沟，发现电子书格式当中，开放的也是应用最广泛的ePub格式，被除了亚马逊之外的几乎所有主要电子阅读器厂商支持，偏偏亚马逊坚持私有格式。并且亚马逊的格式，无论是旧mobi还是新azw，功能都不甚强大。
比方说ePub支持SVG而亚马逊不支持，ePub3支持MathML而亚马逊不支持，而Kindle的主要用户据称则是学生，需要看教材和参考书比网文要多。在境外字母佬语境下互联网上以「Kindle、Math、Fomula」之类关键字搜索，这个问题普遍存在，亚马逊方面水军则避重就轻哼哼哈哈不肯直面问题。
顺便，苹果的iBooks就支持ePub，也没用私有格式，虽然目前已经不能在iTunes当中同步了。我手头的「iPod Touch 4」是2010年秋天买的，上面也有了一堆电子书，纯文字的没有插图，看起来还算正常。屏幕小点无所谓，这也算是「测试环境」，暂时不准备买新「设备」如iPad之类。
再说个「小分析」，太阳底下没有新鲜事，古今中外都一样，「出版界」能推出「钦定主角龙傲天」的前提，就是「垄断渠道」，这才能实现「吃拿卡要」和「暴利」。
之前在知乎谈笑风生的时候已经涉及到这个问题了：《范狂夫：如何看待德国科学家与出版业巨头爱思唯尔 (Elsevier) 的对抗？》。
也就是说，「自媒体」「自出版」这些概念，本身是伟大光荣正确并且自由民主进步的，是为了打破垄断实现碳基帐号之间的交流，以及各国宪法规定的「言论自由」「出版自由」等主流价值观条款。
但是，道高一尺魔高一丈，任何高端大气上档次的概念，都会被一拨娱乐至死の逗哔以「解构主义」原则进行「污名化」或「庸俗化」或兼而有之。与此同时每个毛孔都流淌着血和其它肮脏的东西的「资本」，则趁机无下限敛财，各种众筹集资之类网络乞讨乃至诈骗伎俩就这么运用之妙存乎一心了也。
所以，惦记着「码字获利」的用户，总要与「资本」打交道，不仅仅是「出版渠道」，还有「纳税义务」。而单纯的只是要享受「言论自由」「出版自由」权利并与其它碳基帐号「交流」的用户，在当前主流价值观的支持下，总可以找到地方「发布」，最不济也有各种「网盘」，境内外都一样。
从这个角度看，亚马逊不支持通用的开放格式，到底是因为它垄断了渠道呢，还是因为尚未垄断渠道于是只能以封闭形式维持市场份额？在这个细分市场内，苹果和亚马逊其实是竞争对手，苹果依赖的是「平板电脑」，而亚马逊则专攻「电纸书」。
在台式机、笔记本和平板电脑上看电子出版物，并没有超过传统应用的范畴。而「电纸书」节能省电但刷新极慢，不适合动态内容，所针对的使用场景则有较大不同。
目前虽然彩色电子纸已经出现，但成本太高导致用户即便摊平费用也未必达到购买实体书的性价比。而只提供「灰度」的黑白电子纸，所能阅读的内容，一定不包括充沛的多媒体。
因此，「渠道」的问题暂不考虑，只考虑「内容」。
长话短说，自制电子书的工具有得是，开源至少免费的也不少，功能足够。最起码对于ePub这种开放格式，就是html/css按照固定结构打包而已。所以，之前若干篇「三自运动」的所有成果，都可以运用到「自出版」领域，无论原始内容是纯文本、Markdown、html还是由xml转换而成的。
总之，下一步的计划就是这个，把自己码字内容中用到的（纯文本以外的）特殊格式，尝试转换成ePub并在iPod Touch 4上查看，再转换成mobi或azw尝试在Kindle上查看。
后记
昨天完成「本职工作」（惹是生非）之后，也该轮到「业余兴趣爱好」了，毕竟「不会休息就不会工作」嘛。
除了「精神病仆街写手不入流码农数学渣」之类「兼职」之外，还要深入挖掘各种休闲娱乐之消遣手段中所蕴涵的充沛的政治和意识形态内容。
最起码也得从纯技术角度以爱好者身份指点江山激昂文字吧，包括但不限于（之前整理视频素材时重新开始关注的）音乐。