5

アプリケーションには比較的単純なマークダウン パーサーが必要です。太字やイタリック体などの単純なものです。ライブラリを探していましたが、多くはかなり大きいようです。たとえば、markedは 20,000 個の星で非常に人気があります。そして、2,000 行近くのコードです。これがどれほど大きいかはわかりませんが、かなり複雑に見えます。

一般的に、私は物事をシンプルに保ち、可能な限り依存関係を制限することを好みます。これらすべての行が何をしているのか正確にはわかりませんか?このライブラリは 100 行にも満たないもので、テキストを対応するマークダウンに変換するために単純な正規表現を使用しているだけです。

私の質問は、基本的に、他のライブラリは何をしているのですか? より単純な正規表現に焦点を当てたアプローチを使用することを選択することで、何かが欠けていますか? 後者のライブラリは何らかの形で安全ではありませんか? 私が知らない他の要因を考慮する必要がありますか?

前者のライブラリは非常に人気があり、後者のライブラリには星が 1 つも付いていないため、明らかに、私が見逃している重要なものがあるようです。私はそれが何であるか分かりません。単純なケースでは後者で十分であり、それが必要な場合は前者がより「完全」であることを願っていますが、その結論に飛びつきたくありません。

4

1 に答える 1

6

Markdown パーサーが複雑になる要因はいくつかあります。つまり、「単純な正規表現ベース」の方法を使用して、Markdown パーサーを構築できます。実際、これはまさに参照実装が (Perl で) 使用するものです。既存のドキュメントで Markdown 構文を HTML 構文に置き換える一連の正規表現を実行します。それでも、ソース コードは、コメント、ライセンスなどを含めて 1451 行のコードで構成されています。これらの機能には、正規表現の使用を大幅に複雑にするネスト、エスケープなどのサポートが含まれます。

一部の人々は、そのような実装が制限されていると感じています。それはすべて、Markdown パーサーに何を求めるかによって異なります。

たとえば、リファレンス実装では構文を拡張することはほぼ不可能です。例として、Python-Markdown (私はその開発者です) は参照実装を採用し、各正規表現に名前を付け、サードパーティの拡張機能が新しい正規表現を置換または挿入する方法を提供しました。これを可能にする定型コードは、かなり多くのコード行を追加します。ちなみに、Markdown は古く、Python-Markdown などのライブラリは長年にわたって変化し、成長してきました。最初のバージョンはリファレンス実装を非常によく模倣していましたが、今日ではそれらの間に類似点を見つけるのは難しいでしょう.

出力を制御する方法を提供するほど、構文を拡張することに関心がない人もいます。たとえば、マークされたJS ライブラリは抽象構文ツリー (AST) を出力し、それをレンダラーに渡すことができます。レンダラーは AST (基本的にはトークンのリスト) を受け入れ、他の形式を出力します。その他の形式は HTML である可能性もあれば、他の形式である可能性もあります。Pandocはこれを利用して、多くのドキュメント形式との間で変換を行います。当然、これによりコード行が追加されます。

追加の要因は、実装するかどうかに関係なく、実装がルールのすべての機能をサポートしていない場合、Markdown ではないと多くの人が主張することです。実際、何年にもわたって、多くの実装で非標準機能が追加されてきました (例として GitHub Flavored Markdown を参照してください)。人々はこれらの非標準機能に依存し始め、実装がそれらをサポートしていないと不平を言うバグ レポートを提出します。Python-Markdown の開発者として、ライブラリが実際にサポートを提供している場合、そのような報告を定期的に目にします。デフォルトでは有効になっていません。これが彼らに指摘されると、彼らの反応はしばしば理解に欠けます。したがって、すべての標準機能をサポートしない限り、一般消費向けに作成された実装は長くは続きません。

さらに複雑なのは、標準機能に関して実装間で完全な一致がないことです。詳細については、Babelmark 2 FAQを参照してください。その FAQ には、かなりニュアンスのある多くの文書化された相違点があります。人々は、これらの小さな違いが本当に重要だと感じています。そのため、人々のグループがCommonmarkを作成しました、マークダウンの厳密な仕様。ただし、Commonmark は Markdown の作成者の承認を受けていないため、Markdown と見なすことができるかどうかについては疑問があります。さらに、いくつかの場所では、仕様自体が認めているように、元の規則に直接違反しています。とにかく、実装が Commonmark 実装であるためには、仕様の文書化されたすべての機能を備えた完全なソリューションを提供する必要があります。参照実装( JS および C) はどちらも非常に大規模です。実際、単純な rexed ベースの置換を使用した実装で Commonmark を実装できるとは思えmarkdown.plません。

ポイントは、最も単純な実装を除くすべての実装で、単に正規表現置換のコレクション以上のものを得ているということです。正確な機能は実装ごとに異なり、それぞれのドキュメントを注意深く読む必要があります。それにもかかわらず、正規表現置換の「単純な」コレクションでさえ、かなり複雑であり、Markdown の文書化された機能をすべて実装するには時間がかかります。それ以下は Markdown とは見なされません。

もう 1 つの考慮事項は、パフォーマンスです。正規表現ベースのパーサーは、ほとんどの一般的な使用 (参照実装が設計されたようにコマンド ラインから実行) には「十分」ですが、よりパフォーマンスの高い実装 (マーク付きまたは Commonmark 参照実装など) は AST を生成し、レンダラーを使用します。 . 正規表現ベースの実装は、Web サーバーが要求ごとに Markdown を HTML に変換している場合に重要なパフォーマンスの点でそれに匹敵することは決してありません。

于 2019-09-04T18:12:25.823 に答える