なぜ強調表示できず ** が表示されるのか — Perlで始まったMarkdownの歴史と日本語文書における課題

YAPC::Fukuoka 2025 Day1 TrackB 9:45~

Transcript

1. なぜ強調表⽰できず ** が表⽰されるのか — Perlで始まったMarkdownの歴史と ⽇本語⽂書における課題 hkws / 2025.11.14 YAPC:Fukuoka 2025
2. ⾃⼰紹介 • hkws（かわせ）と⾔います • 通信系の会社でWebアプリケーション開発を10年くらいやってます • 副業で 書籍 x LLM なプロダクトの開発をしています • YAPC初参加です。よろしくお願いします！
3. これ、よく⾒ませんか？
4. これ、よく⾒ませんか？ ちゃんと強調できている箇所もある 強調できてない？
5. どんなデータをもとにレンダリングされているのか？ Markdownをレンダリングしており、どちらも “**” で強調されている ※ 見やすさのために適宜改行を入れている
6. どんなmarkdownテキストの時に強調表⽰に失敗するのか • 失敗パターン ◦ 開始側の"**"の後が鉤括弧である（私は**「あれ**と⾔った） ◦ 終了側の"**"の前が鉤括弧である（私は**あれ」**と⾔った） • 失敗しそうなのに成功するパターン ◦ 開始側の"**"の後が鉤括弧、前がスペース（私は **「あれ**と⾔った） ◦ 終了側の"**"の前が鉤括弧、後がスペース（私は**あれ」** と⾔った） • スペースがあっても失敗するパターン ◦ "**" をスペースで囲んでいる場合（私は ** あれ**と⾔った）
7. 強調表⽰に失敗する原因 • 原因は Markdown の仕様化を⽬指す CommonMark の仕様に由来 • CommonMark は強調表⽰の仕様だけでもルールが17ある • しかも未解決のケースがある：Issue • 単に “*” や “**” で囲まれた箇所を <em> や <strong> にしてくれればいいの に、なんでそんなにややこしいことになっているのか？
8. Markdownの始まりと強調仕様の変遷
9. Markdownの始まり • John Gruber⽒を中⼼に規定された、Webライター向けのテキストからHTML へ変換するための ◦ プレーンテキストをフォーマットする構⽂ ◦ プレーンテキストをHTMLに変換するPerlスクリプト: Markdown.pl HTML is a publishing format; Markdown is a writing format. • 読みやすく書きやすいプレーンテキスト形式で記述し、それを構造的に有効 なHTMLに変換できる
10. The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email. オリジナルのMarkdownの思想 Markdownの書式設定構⽂の最⼤の設計⽬標は、可能な限り読みやすくすることです。Markdownで フォーマットされた⽂書は、タグや書式指定でマークアップされているようには⾒えず、プレーンテキス トとしてそのまま公開できるべきであるという考え⽅です。Markdownの構⽂は、既存のテキストから HTMLに変換するフィルターから影響を受けていますが、Markdown構⽂の最⼤のインスピレーション源 は、プレーンテキストメールのフォーマットです。 John Gruber https://daringfireball.net/projects/markdown/
11. オリジナルのMarkdownの課題 • 細部が未定義 -> 実装が異なるツールが乱⽴し、 互換性が⽋如 ◦ Stack OverflowやGithub等、各社で独⾃に改良して実装 ◦ Babelmarkにより22個ものMarkdown Parserの出⼒を⽐ 較すると、出⼒が15種類にもなった例もあった ◦ In Markdown, we literally built a Tower of Babel
 • 2004年を最後に、John Gruber⽒によるメンテ ナンスが停⽌
12. CommonMarkプロジェクトの発⾜ 2009年12⽉、Jeff Atwood⽒がMarkdownにおけるリーダーシップの不在を指摘 As Markdown’s “parent,” John has a few key responsibilities in shepherding his baby to maturity. Namely, to lead. To set direction. Beyond that initial 2004 push, he’s done precious little of either. Markdownの「親」として、ジョンには我が⼦を成熟へ⾄らせるための重要な責 任がいくつかある。それは、導くことと、⽅向性を⽰すことだ。2004年の最初の 試みを除けば、彼はそのどちらにもほとんど貢献していない。 Jeff Atwood https://blog.codinghorror.com/responsible-open-source-code-parenting/
13. CommonMarkプロジェクトの発⾜ • 2012年10⽉、Jeff Atwood⽒によりMarkdownの標準仕様とテストスイート の策定を提案 • Github, Reddit, Stack Exchange, オープンソースコミュニティの主要メン バーで⾮公開のワーキンググループを発⾜ • 2014年9⽉、 Standard Markdown としてPublic Review • John Gruber⽒より、プロジェクト名に "Markdown" を含めることは許容で きないと通達 -> CommonMarkとしてスタート
14. I have appealed to existing conventions and considerations of simplicity, readability, expressive power, and consistency. I have tried to ensure that “normal” documents in the many incompatible existing implementations of markdown will render, as far as possible, as their authors intended. And I have tried to make the rules for different elements work together harmoniously. 決定にあたっては、既存の慣習や、簡潔性、可読性、表現⼒、⼀貫性といった観点を重視しました。互換 性のない多くの既存の markdown 実装における「通常の」⽂書が、可能な限り作成者の意図どおりに表 ⽰されるように努めました。また、異なる要素のルールが調和して機能するように努めました。 CommonMarkの思想 -> オリジナルのMarkdownの思想、および既存のmarkdown⽂書との互換性を保ちつつ、曖 昧さを排除するように策定 John MacFarlane https://blog.codinghorror.com/standard-flavored-markdown/ https://johnmacfarlane.net/beyond-markdown.html
15. • プレーンテキストとしても公開できる、⼈間にとっての読みやすさ書きやす さを重視した、仕様が寛⼤なオリジナルのMarkdown • オリジナルのMarkdownを尊重しつつ、仕様の曖昧さを無くそうとする CommonMark • では、強調”**”はオリジナルのMarkdownではどう処理されていて、それを CommonMarkはどう仕様化しようとしたのか？ ⼤まかな流れ
16. • Markdownでは、2種類の強調がある ◦ 強調: “*”または”_”で囲まれた部分を<em>タグに置換 ◦ 強い強調: “**”または”__”で囲まれた部分を<strong>タグに置換 • ⾔葉の定義 ◦ 約物: ⽂や語句を区切ったり、省略‧強調したり、また記述を代⽤させるために⽤ いられる句読記号、括弧類など ▪ 厳密には、ASCII punctuation characterおよびUnicode punctuation character ◦ マーカー: “*”, “_”, “**”, “__”のような、強調の開始/終了を意味する記号（列） 話のための準備
17. 強調表⽰の仕様の変遷 - Markdown.pl オリジナルのMarkdown.plでは、以下のサブルーチンで<em>と<strong>の変換 を⾏う
18. 強調表⽰の仕様の変遷 - Markdown.pl <strong>の処理後<em>を処理するため、<strong>の処理では中⾝の余分な*や_ を飲み込んでいる • ** や __ の内部の * や _ を許容する • 中⾝の先頭/末尾は空⽩以外
19. 強調表⽰の仕様の変遷 - v0.13以前の強調表⽰の仕様 CommonMarkでは、オリジナルを尊重して以下のように強調表⽰を仕様化 1. 単⼀の"*"は、その後に空⽩が続かない限り、強調を開始できる 3. 単⼀の"*"は、その前に空⽩がない限り、強調を閉じることができる 5. ⼆重の"**"は、その後に空⽩が続かない限り、強い強調を開始できる 7. ⼆重の"**"は、その前に空⽩がない限り、強調を閉じることができる 13. ネスト数は最⼩限に抑える。例えば、 <strong>...</strong>の解釈は、 <em><em>...</em></em>という解釈よりも常に優先される
20. 強調表⽰の仕様の変遷 - <strong>の中の<em>の問題 ネストを許容した前述の仕様は、開き/閉じが不定になるケースがあることが判明 実装によっては期待しない出⼒になってしまった Markdownテキスト: 期待する出⼒: CommonMark v0.13時点でのTryページの実装: 以下のどちらにも当てはまる 1. 単一の"*"は、その後に空白が続かない限り、強調を開始できる 3. 単一の"*"は、その前に空白がない限り、強調を閉じることができる
21. "*"前後の空⽩だけでなく、約物も考慮した形式で強調表⽰を定義 • 強調表⽰の開始 = left-flanking delimiter ◦ 約物 -> マーカー -> 空⽩でも約物でもない⽂字 ◦ 空⽩ -> マーカー -> 約物 • 強調表⽰の終了 = right-flanking delimiter ◦ 空⽩でも約物でもない⽂字 -> マーカー -> 約物 ◦ 約物 -> マーカー -> 空⽩ 強調表⽰の仕様の変遷 - left/right-flankingの導⼊ These are “**strongly emphasized**” words 白：空白　赤：マーカー　黄：非空白・非約物　 青：約物 left-flanking right-flanking These are **“strongly emphasized”** words (*Gomphocarpus 強調の開始にだけマッチ！
22. 強調表⽰の仕様の変遷 - left/right-flanking 平たく⾔うと以下の条件（マーカーとして"**"を想定） • 強調表⽰の開始 ◦ "**" の直後が空⽩または約物でない または ◦ "**" の直後が約物で、"**" の直前が空⽩または約物 • 強調表⽰の終了 ◦ "**" の直前が空⽩または約物でない または ◦ "**" の直前が約物で、"**" の直後が空⽩または約物
23. なぜ⽇本語だと強調表⽰に失敗するのか 分かち書き（語の区切りに空⽩を挟んで記述すること）をしない⾔語は、 強調開始時："**" の直後が約物で、"**" の直前が空⽩または約物 強調終了時："**" の直前が約物で、"**" の直後が空⽩または約物 というルールが⾃然に満たされない Time **(really)** flies 空白→マーカー→約物：OK！ 私は**「あれ」**と言った 直前に空白がない：NG！ 英語：分かち書きする 日本語：分かち書きしない
24. ⽇本語等いくつかの⾔語（CJK: Chinese, Japanese, Korean）で空⽩による強調 の開始/終了判定が適⽤できないという課題は、2017年から議論されている • Emphasis and East Asian text • Emphasis with CJK punctuation 現在有⼒な解決策は、（すごくざっくり⾔うと）マーカーの直後が⾮CJK約物 で、直前がCJK⽂字であれば、left-flankingとして扱うというもの CommonMarkにおける現在の検討状況 これは強調を”**開始**”可能 これも強調を**”開始”**可能 赤：マーカー　黄：CJK文字　青：非CJK約物
25. • Markdown Parser/Rendererを組み込んだアプリケーション開発者が採⽤で きる対策 ◦ CJK friendlyな実装が組み込まれたParser/Rendererを利⽤する（例: Comrak） ◦ CJK friendlyなプラグインを利⽤する（例：remark-cjk-friendly） 現状できる対策 • markdownでの⽂書作成ユーザが採⽤できる対策 ◦ 開始時は空⽩ -> マーカー -> 約物、終了時は約物 -> マーカー -> 空⽩となるように ⽂書を書く ◦ ⽣HTMLを書く
26. CommonMarkにおけるその他の⽇本語の問題
27. CommonMarkには以下のようなソフト改⾏の説明がある ソフト改⾏（Soft line break）の説明 これについて、以下の点が指摘されている • “ソフト改⾏はHTMLで改⾏またはスペースとしてレンダリングされうる”は不明瞭 • 中国語や⽇本語⽂内でのソフト改⾏は、実際にはブラウザによって表⽰結果が異なる ◦ Firefoxでは、スペースを⼊れずに⼆つの⾏を結合 ▪ こちらはCSS Text Module仕様に従った挙動 ◦ Blink/WebKit系では、スペースを⼊れて結合 コードスパンやHTMLタグ内でなく、2つ以上のスペースまたはバックスラッシュで先⾏さ れていない通常の改⾏は、ソフト改⾏としてパースされる。（ソフト改⾏はHTMLで改⾏ま たはスペースとしてレンダリングされうる(※may)。ブラウザ上での結果は同じである。）
28. ルビ（<ruby>） Issue: Proper ruby text (<rb>) syntax support in Markdown • ルビ（ふりがなのような本⽂に付属する⽂字）の記⼊をCommonMarkで仕 様化しようという提案 ◦ furigana_markdown: [図](-と)[書](-しょ)[館](-かん)
 ◦ parsedown_rubytext: [図書館]^(としょかん)
 • Status: Open • 現状の対応策 ◦ ⽣HTMLの<ruby><rt><rp> を書く ◦ extensionを利⽤する
29. まとめ • 強調表⽰（**）に失敗することがあるのは、CommonMarkの仕様に由来 • Markdownはプレーンテキストメールの慣習にインスパイアされた⽂法に なっている ◦ **強調表⽰の*ネスト*を許容** • CommonMarkは、オリジナルのマークダウンとの互換性を重視しつつ、仕様 の曖昧さを排除しようとしている ◦ 強調表⽰のパースを、スペースによる分かち書きがあることを前提として仕様化 • ⽇本語には分かち書きがないため、強調表⽰に失敗してしまう • ソフト改⾏やルビといったCJKと関連が深い話題についても、現在議論中
31. CommonMarkはいつv1.0になるのか？ • 実際、もうv1.0で良くない？と⾔う議論はある: Issue ◦ ⼤きな仕様変更は⻑らくない ◦ 外から不要に不確実性だと思われる可能性を除ける • @jgm (John MacFarlane⽒)の反応 ◦ “当初、1.0前に解決すべきと⾒ていた課題が未解決ではある” ▪ Ambiguity in block quote definition など ▪ 未解決の問題がこれほど⻑く残っているなら、それは重要じゃないのでは？と反論も ◦ “1.0と呼ぶこと⾃体には前向きだが、それで何かが⼤きく変わるとは思わない” ◦ CJKにおける強調の問題も重要視 ▪ “世界⼈⼝の4分の1にとってより有⽤なものとなるよう、強調構⽂解析規則を修正する ことが望ましいでしょう” ▪ “もちろん、これらの問題を 1.0 では解決せずに残し、後で対処することもできます。”