要約

  • RFC 7763は2016年3月発行のIETF情報提供RFCで、text/markdownを登録した。登録内容ではcharsetが必須で、書き手が想定した文法を示すvariantは任意だ。
  • variantは受信側への手掛かりであり、処理を強制する命令ではない。RFC 7764にはOriginal、GFM、CommonMark、Pandocなど複数の書き方が記録された。
  • IANAはメディアタイプとMarkdownの変種を別の登録簿で扱う。名前が共有されても、実際の表示を作るのは読み手のプログラムだ。

縦線が列にならない日

Markdownの原稿は、ただのテキストとしても読める。見出しの印、箇条書きの印、コードの囲いが目に見える。その気軽さが、各サービスでの拡張を後押しした。あるサービスの表記法を覚えた書き手は、列を並べるために縦線を打つ。別の処理系が同じ原稿を開くと、縦線は表ではなく行の中の文字になる。両者のファイルが一致していても、読者の受け取る情報の形は一致しない。

たとえば引き継ぎ表に担当者と期限が並んでいたとする。移行先で列が消えれば、人名と日付の対応が追いにくくなる。バックアップの照合では異常が出ない。失われたのは文字列ではなく、文字列に与えた構造である。文書の保全をファイルの保全だけで測ると、この種類の損失が見えなくなる。

同じ月のRFC 7764は、この問題を生んだ歴史を記録した。2004年のJohn GruberとAaron SwartzによるMarkdownを起点に、Original、GFM、CommonMark、Pandocなどの変種が並ぶ。GFMの説明には表、フェンスで囲うコードブロック、URLの自動リンクなどが含まれる。これらは製品名の飾りではない。一つひとつが、記号をどのような画面に変えるかを決める規則だ。

名前を送る仕組み

RFC 7763が最初に解いたのは、通信上の身元である。メールの添付やHTTPの応答にtext/markdownと記せば、受信側はプレーンテキスト一般とは違う内容だと分かる。登録ではcharsetを必須にした。バイト列を文字に直す方法が決まって初めて、#や|を文法として扱える。このタイプに既定の文字集合は置かれていない。

次の問いは「どのMarkdownか」だった。任意のvariantを使えば、Content-Type: text/markdown; charset=UTF-8; variant=Originalのように書き手の意図を添えられる。値がなければ、読み方は受信側とその場の文脈に委ねられる。値があっても、RFCはそれをヒントとして扱う。受信側は指定された変種を採用できるし、別の扱いを選べる。

ここで主導権がはっきりする。送信側は「この文法で書いた」と伝えられる。受信側は、その文法を実装している範囲でしか実行できない。名札にGFMと書かれていても、表に対応しない解析器へ表の機能は湧いてこない。RFCが意図を保つために勧めるのは、相手が理解する変種を選ぶという実務上の確認だ。

名札自体が途中で落ちることもある。RFC 7764は、メディアタイプのパラメーターを運べる通信路から文書が離れる場合を論じた。単独の.mdファイルには、元のvariantが付いていないことがある。RFC 7763は、その情報を内容と一緒に記録するよう促した。本文が保管されても、本文の読み方を示す情報は別途守らなければ消える。

登録簿に解析器は入っていない

IANAのメディアタイプ登録簿にはtext/markdownが載る。別のMarkdown変種登録簿にはOriginal、GFM、CommonMark、Pandocなどが並び、登録は先着順の手続きで受け付けられる。共通の呼び名は、異なるシステムが意思を伝える助けになる。実際のソフトにどの機能があるかは、そのソフトを動かして確かめるしかない。

「Markdown対応」という表示を見た運営者は、そこで検査を終えがちだ。しかし移行作業で必要なのは、利用者の原稿にある表、見出し、リンク、コードブロックを新旧双方で表示して比べることだ。ソースのハッシュが同じなら輸送は成功している。表示が変われば、解釈する側の境界が動いたと分かる。

今回参照した四つの公式資料は規則と登録状態を示す。どの製品がいつvariantを送信し、どの受信ソフトが従ったかを言うには、日付のある製品資料、ソースの版、実際の応答記録が要る。2016年の確かな変化は、Markdownが通信上の名前を得たことと、読み方の最終判断がなお受信側に置かれたことである。