MDファイルとは

MD はプレーンテキスト形式です。どのエディターでも開けます。 編集とプログラム間のデータ受け渡しのために使われます。

拡張子は .md、正式名称は Markdown です。ただしどちらも、そのファイルが中に何を持てるかほどには多くを語りません。このページの残りは、その中身についての話です。

2004 年までさかのぼります。 仕様は CommonMark です。

古さが役に立つのは、ごく実務的な理由からです。形式が古いほど、それを覚える時間が多くのプログラムに与えられてきたということだからです。

仕様書がそのまま公開されているので、中身を推し量るのではなく文書を読んで実装できます。この形式が数多くのプログラムに載っているのはそのためであり、20 年前に書かれたファイルが今も開けるのもそのためです。ただし「仕様が公開されている」ことと「使用料が要らない」ことは別の話です。中でコーデックを包んでいる形式では、特許のライセンスは仕様書が答えていない別の問題として残ります。

Visual Studio Code、Obsidian、Typoraが読めますし、同じ種類のプログラムならたいてい読めます。

ファイルが開かないとき、形式が悪いことはめったにありません。たいていはプログラムのほうが形式より古いのです。もっと古い形式に変換してしまうのが確実な逃げ道で、このサイトの残りの部分はそのためにあります。

これを読めるブラウザーはありません。

これを変換するいちばんよくある理由がこれです。形式が悪いのではありません。ファイルを見せたい場所が、それを読めないというだけのことです。

MD は、開いて手を入れるために作られています。作業が続いているあいだはこの形式でファイルを持ち、完成したものが必要になるたびに、ここから書き出してください。

Markdown が存在するのは、HTML を手で書くのは面倒で、ワープロで書くと誰も差分を取れないファイルができてしまうからです。これは、名前が付く前からプレーンテキストのメールですでに使われていた慣習の集まりです。行頭のシャープは見出し、単語をアスタリスクで囲めば太字、行頭のハイフンは箇条書きになります。この形式のこの形式を知らない人が読んでも、原文がそのまま読めるという点が要点です。

この性質があるからこそ、文書化の場でこれが主流になりました。Markdown で書いた README、変更履歴、技術メモ、ブログ記事はテキストファイルです。バージョン管理に入れられ、二人が編集して結果をマージでき、レビューする人は何かを描画しなくても差分を読めます。バイナリのワープロ形式ではこのどれも実現できません。

唯一の Markdown というものは存在しません。2004 年のもともとの説明は非公式なもので、多くの部分が未決定のまま残されたため、実装ごとにその隙間が違う形で埋められました。CommonMark は正確な仕様を目指した本気の試みで、現行の多くのエディターがこれに従っています。GitHub Flavored Markdown は CommonMark にいくつかの追加を加えたもので、多くの人が実際に使ってきたのはこちらです。

一番混乱を招く追加機能は表です。パイプ区切りの表は CommonMark の一部ではなく GitHub の拡張機能で、多くのエディターや静的サイトジェネレーターも対応していますが、厳密な実装には存在しません。リポジトリでは完璧に表示される表が、別の場所ではパイプの並びとして表示される場合、それはファイルが壊れているのではなく、相手のツールがその拡張機能を実装していないだけです。タスクリストや取り消し線、自動リンクも同じ種類の拡張機能です。

多くの Markdown ファイルは、三つのハイフンで囲まれた、タイトルや日付、タグの一覧のようなブロックから始まります。これはフロントマターと呼ばれるもので、たいてい YAML、時に TOML や JSON で書かれ、Markdown そのものではありません。静的サイトジェネレーターやノートアプリ、文書ビルドツールはこれを文書についてのメタデータとして読み込み、描画する前に取り除きます。

フロントマターを知らないツールは、それをページ冒頭の文字通りのテキストとして表示してしまいます。変換した文書が三つのハイフンとキーと値の並びから始まっている場合、これが原因です。変換する前にそのブロックを削除するのが対処法です。

ページサイズも、余白も、フォントも、行間も、改ページも、フッターもありません。これは欠陥ではなく機能です。ファイルは構造 — これは見出し、これは引用、これはコード — だけを記述し、見た目は描画する側に任せます。同じ文書が、書き直すことなくウェブページにも、PDF にも、スライド資料にもなれます。

コメントも、変更履歴も、「この段落は三回目の改訂」という表現方法もありません。その役目はバージョン管理が代わりに担い、しかもより上手にこなします。これがこの形式が選んでいる取り引きです。文書に必要なのが履歴ではなくレビューのワークフローであるなら、ワープロのほうが正直な道具です。

よくある行き先は PDF で、何で書かれたかを気にしない相手に送る文書 — クライアントに渡す仕様書、メモの集まり、マニュアル — に向いています。変換によって構造上の記号が実際の書式に変わります。見出しは見出しになり、コードブロックは等幅フォントのまま、リストは入れ子構造を保ちます。

HTML もよくある行き先で、そもそも Markdown が HTML の省略記法として設計されているため、変換というより翻訳に近い作業です。DOCX への変換は特定の状況で役立つと知っておく価値があります。テキストエディターで書いて、変更履歴付きの Word ファイルしか受け付けない相手に渡す、という場合です。

六枚の図を表示する Markdown ファイルは、実は図を一枚も含んでいません。含んでいるのは六つのパスだけで、画像はディスクやサーバー上の別の場所にあります。周囲のフォルダーを付けずにファイルだけを移動させると、すべての画像が消えます。

これは変換時にも重要です。変換ツールは見つけられる画像しか埋め込めないため、相対パスはファイルが実際にある場所から解決される必要があります。文書をメールで送るときにも同じことが問題になります。素材を伴わない .md ファイルを送ることは、骨組みだけを送ることと同じです。画像が要点なら、すべてが一つのファイルに収まる PDF に変換してください。

どんなテキストエディターでも構いません。メモ帳、TextEdit、nano など、ファイルがテキストだからです。これがこの形式全体の魅力で、2004 年に書かれた Markdown 文書が、今日でも何もインストールせずに開ける理由です。

専用のエディターはライブプレビューを追加してくれます。執筆中には本当に便利ですが、ファイル自体には何の関係もありません。Visual Studio Code、Obsidian、Typora はどれも入力しながら描画してくれますが、どれも他が読めない情報を保存しているわけではありません。どれを選ぶかは好みの問題であって、後戻りのできない決断ではありません。ほとんどの文書形式についてはそうは言えません。