先に断っておくと、この記事に書いた条件は、すべて CommonMark の仕様に明記されています。Fenced code blocks の項です。

A fenced code block begins with a code fence, preceded by up to three spaces of indentation.
The closing code fence may be preceded by up to three spaces of indentation.

読めば分かります。読んでいませんでした。

書くのは、読まずに正規表現を書いて壊した記録と、仕様の条件をパーサで10通り測った結果です。壊れ方の実物と、直した抜き出し関数は、自分の手元にしかありません。

測定は markdown-it-py 4.0.0（CommonMark 準拠）で行いました。

何が起きたか

記事に、こういうコードを貼っていました。Markdownの記法を取り除く関数です。

CODE_BLOCK = re.compile(r'```.*?```', re.S)
INLINE = re.compile(r'`[^`]*`')

書いたあと、この記事のコードをそのまま実行して出力を確かめたくなりました。記事から抜き出す短いスクリプトを書きます。

blocks = re.findall(r'```(.*?)```', text, re.S)

抜き出した結果を実行したら、NameError: name 're' is not defined で落ちました。抜けていたのは import re です。

コードの途中から切り出されていました。

抜き出しが壊れた理由

正規表現が、コードの中に書いてあるバッククォート3つに反応しています。

非貪欲の (.*?) は、最初に見つかった閉じ記号で止まります。1行目の re.compile(r' のうしろにある3つが、そのまま終端として扱われました。

非貪欲 ```(.*?)``` の結果: 2 個 / "python\nCODE = re.compile(r'"

2個に割れています。1個目は1行に満たない断片です。

ここで一瞬、記事のほうが壊れているのではないかと思いました。表示は正常に見えていましたが、見えているものと解釈されているものが違う可能性があります。

確かめました。壊れていませんでした。

行頭かどうかで、すべてが決まる

仕様のとおり、閉じフェンスとして扱われるのは行の先頭にあるバッククォートの並びだけです。行の途中にあるものは、ただの文字です。

パーサに6通り食わせました。

中に置いた3つの位置	コードブロック数	結果
行の途中	1	壊れない
行頭	2	壊れる
半角スペース3つ字下げ	2	壊れる
半角スペース4つ字下げ	1	壊れない
外側を4本にする	1	壊れない
外側をチルダ `~~~` にする	1	壊れない

3つ字下げでも壊れるのは、閉じフェンスの字下げが3つまで許されているからです。4つ以上は行頭とみなされません。ただし、その4つのスペースはコードの中身として残ります。インデントを1段ずらして回避するのは、結果を変えてしまうので勧めません。

壊れる場合、2個目のブロックのあとに続く行が、コードブロックの外に出ます。

コード外に出た行: ['y = 2']

コードだった行が、地の文として表示されます。見た目で気づける壊れ方ではあります。

フェンスの長さには規則がある

外側を4本にする方法を選ぶなら、規則を1つ覚えておく必要があります。こちらも4通り測りました。

開き	中に出てくる並び	結果
3本	4本	壊れる
4本	4本	壊れる
4本	3本	壊れない
5本	4本	壊れない

閉じフェンスは、開きフェンスと同じ長さか、それより長ければ成立します。逆に言えば、開きより短い並びは閉じになりません。

なので、中に3本が出てくるなら外側は4本、中に4本が出てくるなら外側は5本にします。1本多ければ足ります。

チルダを使う手もあります。~~~ で開けば、中のバッククォートは何本並んでいても閉じになりません。記法が混ざるのを嫌う人もいると思うので、ここは好みだと思います。

閉じ忘れると、最後まで飲み込みます

外側を4本にしたとき、閉じも4本にする必要があります。3本で閉じても閉じフェンスになりません。

そして仕様では、閉じフェンスが見つからないまま文書の終わりに達した場合、開きフェンス以降の全部がコードブロックになります。

外側を増やして閉じ忘れると、**記事の残り全部がコードとして表示されます。**これは壊れ方としては派手なので、プレビューを見ればすぐ分かります。

もう1つ、仕様に書かれていて引っかかりやすいものがあります。バッククォートのフェンスでは、情報文字列にバッククォートを含められません。

```python `code`

これは開きフェンスとして成立しません。言語名のあとにインラインコードを書きたくなる場面はないと思いますが、自動生成で情報文字列を組み立てているなら、ここに当たる余地があります。

抜き出す側の直し方

行頭のフェンスだけを見るようにします。

import re

def extract_code_blocks(text):
    out, cur, opener = [], None, None
    for line in text.split('\n'):
        stripped = line.lstrip()
        indent = len(line) - len(stripped)
        if cur is None:
            m = re.match(r'(`{3,}|~{3,})(.*)$', stripped)
            if m and indent < 4:
                opener = m.group(1)
                cur = []
            continue
        m = re.match(r'(`{3,}|~{3,})\s*$', stripped)
        if m and indent < 4 and m.group(1)[0] == opener[0] \
                and len(m.group(1)) >= len(opener):
            out.append('\n'.join(cur))
            cur, opener = None, None
            continue
        cur.append(line)
    return out

見ている条件は4つです。字下げが4つ未満であること。開きと同じ記号であること。開き以上の長さであること。閉じフェンスの行に情報文字列が書かれていないこと。

**どれも仕様に書いてある条件を、そのまま条件式にしただけです。**先に読んでいれば、最初からこう書けていました。

同じ入力で比べると、こうなります。

非貪欲の正規表現 : 2個 / "python\nCODE = re.compile(r'"
行頭フェンス方式 : 1個 / "CODE = re.compile(r'```.*?```')\nx = 1"

コードが1つの塊として取れています。

余談

この記事にも、バッククォート3つを含むコードブロックが入っています。

書きながら、外側を4本にするかどうか迷いました。結局、そのままにしています。行の途中にしか出てこないので、壊れないことを確かめたからです。

念のため、公開後に自分でもう一度抜き出して実行してみるつもりです。仕様上は壊れないはずですが、レンダリングは仕様だけで決まるものでもないので。Qiita が CommonMark にどこまで準拠しているかは、こちらでは分かりません。

まとめ

仕様に書いてあることと、測って確かめたことを分けて並べます。

仕様に書いてあること

フェンスは行頭から3スペースまでの字下げを許す。4つ以上は行頭ではない
閉じフェンスは、開き以上の長さが必要
閉じフェンスが無いまま文書が終わると、以降が全部コードになる
バッククォートのフェンスでは、情報文字列にバッククォートを含められない

測って確かめたこと

行の途中のバッククォート3つは、ただの文字。ブロックは1つのまま
3つ字下げでは壊れ、4つ字下げでは壊れない（ただし空白が中身に残る）
壊れたとき、続く行が地の文として外に出る

わたしは今回、抜き出す側だけを直しました。記事のほうは壊れていなかったので。

ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。