[20] Markdown は、テキスト系マーク付け言語の一種です。
[21] GitHub などエンジニア向け製品が採用したことで普及し、 世界的に使われるようになりました。しかし製品ごとに大きく異なる方言のため相互運用性は絶望的に低い状態にあります。
[65] 長期保存される文書の場合、互換性のために必要な場合を除き、 HTML など他のファイル形式を検討するべきです。
[17] Markdown には様々な方言があり、標準が存在しません。 標準化の試みが複数ありましたが、相互に矛盾しており、 相互運用性は存在しないと言わざるを得ません。
[53] 近年 GitHub Flavored Markdown が人気を博しており、 これが事実上の標準と言われることもあります。しかし仕様書は存在せず、 GitHub Flavored Markdown 対応を謳う実装もそれぞれ異なる拡張を施しているなど、 「有力な方言」以上のものと位置づけるのは難しそうです。
[76] GitHub を含むいくつかの実装者が参加して CommonMark の標準化が進行しています。これがもっとも「標準」 に近い仕様書のようです。しかし GitHub その他の実装は CommonMark を独自に拡張したものですから、 これだけ実装すれば済むというものにはなっていません。
[81] CommonMark も中核部分を「共通」の「標準」 として記述することが目標で、 言語の統一を目指しているものではなさそうです。 CommonMark を採用した上で、 構文の拡張や変更ができることを売りにした実装がある >>80 (しかも実際に採用されて拡張された例がある) ことからもわかるように、 Markdown コミュニティーには統一言語確立のモチベーションよりも独自拡張を好む風習があるようです。
[44] 同じ方言に対応していると主張する実装であっても、更に細かい方言である場合があります。 (各項を参照。)
[19] 同じものを実装すると主張するソフトウェア同士でも解釈が一定しないことは普通です。 同じ会社の別の製品や、場合によっては同じ製品の異なる版同士で、 異なって解釈されることもよくあります。
[45] 例えばネイティブアプリケーション版でプレビューを見ながら Webサイトに投稿したら、 Webページでは違って見えることがあります。
[38] ある製品向けに記述した Markdown の文書を、無変換でそのまま他の製品に完全に移植できることは期待しない方が安全です。
[77] 方言名 (略称) 自体が既に衝突しているとかいう状況には草不可避wwww
[78] 「○FM」全部埋まっているのでは?と思ったけど全然埋まっていないwwww スクランブリングコードDさんがんばれwwwww
[83] MFM (Markup language For Misskey) は 「Misskeyで使えるMarkdown風の構文」 と説明されていて、 Markdown であるとは主張していません。 実際、独自性が強いです。
[54] Typetalkメッセージ書式は Markdown の一部構文に対応していますが、 それ自体が Markdown であるとは主張していないようです。
[94] Markdown Flavors · commonmark/commonmark-spec Wiki · GitHub, https://github.com/commonmark/commonmark-spec/wiki/Markdown-Flavors
[95] Deployed Extensions · commonmark/commonmark-spec Wiki · GitHub, https://github.com/commonmark/commonmark-spec/wiki/Deployed-Extensions
[97] PHP Markdown Extra, , https://michelf.ca/projects/php-markdown/extra/
[96] GitHub - vmg/redcarpet: The safe Markdown parser, reloaded., https://github.com/vmg/redcarpet
[88] CommonMark を含む多くの Markdown の方言は、 Markdown 文中に HTMLタグを記述可能としています。 HTMLタグは、 HTMLタグが生成されるべきことを表します。 そのまま素通しで出力する実装もあるでしょうし、 何らかの加工をして出力する実装もあることでしょう。
[89] Markdown における HTMLタグは、 HTML 本来のタグとは仕様が異なることがあります。 タグ構文がHTML構文解析器と違った形で解釈されますし、 HTML にない独自の属性が利用可能な場合もあります。
[90] HTMLタグに囲まれた部分が Markdown として解釈されるかどうかは実装によります。
[92] HTML に Markdown を含めることはできません。 script data block のような形で Markdown データを含めることはできますが、 それはあくまで文書が何らかの独自の形で使い得るデータとして含めているものに過ぎず、 HTML が表す文書構造の一部分の記述の手段として Markdown を利用することはできません。
[93] HTML をモデルに開発された構文や HTML を生成することを目的とした言語のようなものの中には、 HTML に基づく構造を全体構造とし、 その一部分に Markdown に基づく構造の利用を認めていることがあります。
[22] IETF は RFC 7763 でMIME型
text/markdown
を規定しています >>15。
variant
引数[23] 方言問題のため variant
引数を定義していますが、
これはヒントとされており >>15、
一応はIANA登録簿 >>24 も用意されているものの、
その値を用いる義務もありません。
[50] つまり一応方言問題の対策は用意したというポーズだけで、 実際何の役にも立ちません。どのような値が与えられた時受信者がどう解釈するべきかも規定されていません。 例えば未知の値を指定された時や、指定された値と実際の内容に齟齬がある時、 指定された方言に対応していない時などに、 どのように動作するべきかはまったく不明です。
charset
引数[26] charset
引数があり、必須とされています >>15。
[27] RFC 6838 に従ったものだ >>15 と言っていますが、
それは政治的に正しいのかもしれませんが、
text/plain
や text/html
で
charset
引数が正しく運用されてこなかった歴史を踏まえると、
この規定に意味があるのかは謎です。
[28] RFC は Markdown の仕様書で文字コードが規定されていないといっていますが、
そもそも、今の時代、 UTF-8 固定の実装が多いのではないかという気もします。
charset
引数が指定されない場合にどう扱うべきなのかは不明です。
[29] 更に他の任意の引数も使える >>15 とされています。
方言ごとに引数の意味を定めるべきだと言っていますが、
variant
省略時に使用してはならないとの規定もありません。
variant
引数の制約もあってないようなものですから (>>23)、
実質的に標準化を放棄しているだけです。
[25] そもそも MIME型の引数というもの自体の相互運用性と可搬性がほとんどない現状で、 これらの定義すら曖昧な引数もほとんど役に立ちそうにありません。 実装は引数をすべて無視するべきですし、著者は引数を使うべきではありません。
text/x-markdown
[60]
MIME型
text/x-markdown
が使われることもあります。
text/markdown
より前から使われていました。
[86]
新しい実装は text/markdown
を使うべきで、
text/x-markdown
を生成するべきではありません。
[87]
実装は
text/x-markdown
も
text/x-markdown
も等価として認識するべきです。
[30] RFC 7763 は、
text/markdown
における素片識別子は方言次第としつつ、独自の構文も定めています
>>15。
[31] 独自の構文は、 application/x-www-form-urlencoded
風ではありますが、曖昧な説明があるだけです。
[32] line=123
のようにして、行を指定できます >>15。
この line
は RFC 5147 text/plain
素片識別子の
line
と同じ意味であり、 0起算とされています >>15。
また line=10
が入力の 11 個目の行を表すと例示されています
>>15。
Markdown の処理の結果の行は入力の行とは異なるかもしれませんし、
Markdown として解釈される構文のみを含む行で変換により消失するかもしれませんし、
そもそも行という概念がない形式に変換される可能性すらあるでしょう。
しかしそうだとすると素片識別子は Markdown ソースコードの表示には使えても、
変換結果には使えないかもしれません。
更には、改行の表現は環境によって異なるので実装は注意が必要 >>15
だとありますが、具体的にどうしろとは書かれておらず
(RFC 5147 もいろいろな可能性を挙げるだけで処理方法は明確にしていません)、
相互運用性への意欲がまったく感じられません。
こんなものを使えと言われても無理でしょう。
[46] Markdown の実装は色々あってそれぞれに異なる解釈があり、 同じ実装の異なる版で動作が異なることもよくあります。
[47] アプリケーションの開発者は、独自の方言を新たに作るべきではありません。 既存のライブラリーがあれば、それを利用するべきです。
[49] ただし、一度 HTML などに変換したら終わりの場合はともかく、 長期的に保存されるデータの場合は、利用するライブラリーが継続的に適切にメンテナンスされる見込みがあるか、 慎重に判断する必要があります。バージョンアップしたら古いデータの解釈が変わってしまうというリスクがあります。
[37] 実装によっては、色々な方言の仕様を取り込んだ結果機能として破綻しているものもあります。
[36] はてなブログのMarkdownは出自の異なる2種類の脚注構文を含んでおり、 それぞれ違った形で HTML として出力されるようです。
[39] 最悪プレインテキストとしてほぼ解釈できるとはいえ、重要な文書は Markdown で記述しない方が安全です。
[57] 書き慣れている人も多いので下書き形式としては便利かもしれませんが、 中長期的に保存したい文書や情報交換目的に採用するのは考えものです。
[82] Data Package | Frictionless Standards, , https://specs.frictionlessdata.io/data-package/#metadata
The description MUST be
markdown リンク http://commonmark.org/ (opens new window) formatted – this also allows for simple plain text as plain text is itself valid markdown.
[34] RFC 7763 は、 Markdown のプレビューに使う MIME型を指定するための
Content-Disposition:
ヘッダーの
preview-type
引数を定義しています。
[2] tantek / Markdown ( ( 版)) http://tantek.pbworks.com/w/page/59905776/Markdown
[3] ( ( 版)) http://www.iana.org/assignments/media-types/text/markdown
[4] draft-ietf-appsawg-text-markdown-04 - The text/markdown Media Type ( ( 版)) http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-04
[5] the MDE manifest ( ( 版)) http://markdown-extended.github.io/manifest/
[6] Markdown Community Group ( ( 版)) http://www.w3.org/community/markdown/
[7] karlcow/markdown-testsuite ( ( 版)) https://github.com/karlcow/markdown-testsuite
[8] Markdown Syntax Specification ( ( 版)) http://rawgit.com/karlcow/markdown-testsuite/master/markdown-spec.html
[9] The Markdown-Discuss Archives ( ( 版)) https://pairlist6.pair.net/pipermail/markdown-discuss/
[11] Comments ( ( 版)) http://doc.rust-lang.org/nightly/book/comments.html
[13] Markdown - Qiitaマークダウンの癖 - Qiita ( 版) http://qiita.com/Takeru/items/0c5e3f7910498b846bc1
[15] RFC 7763 - The text/markdown Media Type ( 版) https://tools.ietf.org/html/rfc7763
[16] RFC 7764 - Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations ( 版) https://tools.ietf.org/html/rfc7764
[24] Markdown Variants ( 版) https://www.iana.org/assignments/markdown-variants/markdown-variants.xml
[43] Extending Markdown · scholmd/scholmd Wiki () https://github.com/scholmd/scholmd/wiki/Extending-Markdown
[66] mime: please add 'text/x-markdown' for markdown file extensions (md, markdown) to the _defaultExtensionMap · Issue #12857 · dart-lang/sdk () https://github.com/dart-lang/sdk/issues/12857
[79] Producing HTML, , http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html#parsing-markdown
[84] 2024-07-07 togetterのMarkdown記法ではH3 H4 H5…見出しは使えるか実験 - Togetter [トゥギャッター] () https://togetter.com/li/2397177
[85]
>>84 Hn と書いているが実際にはMarkdownの見出し構文のこと。
実際に出力されている HTML によると、
#
は h2
,
##
は h3
,
###
から ######
は span
(以上すべて少しずつ CSS
が違う)、
#######
は Markdown 構文として解釈されずそのまま出力。
text/markdown
の仕様書の役割だと思うのですが...