md4c
1.0.0
MD4Cは「Markdown for C」の略であり、それがまさにこのプロジェクトの目的です。
要するに、MarkDownはこのREADME.mdファイルの書き込み言語です。
次のリソースは、あなたがそれに不慣れな場合はもっと説明できます：
MD4Cは、次の機能を備えたCでのMarkdownパーサーの実装です。
コンプライアンス：一般的に、MD4CはCommonMark仕様の最新バージョンに準拠することを目指しています。現在、私たちはCommonmark 0.31に完全に準拠しています。
拡張機能： MD4Cは、一般的に要求され、受け入れられている拡張機能をサポートしています。以下を参照してください。
パフォーマンス： MD4Cは非常に高速です。
コンパクトさ： MD4Cパーサーは、1つのソースファイルと1つのヘッダーファイルに実装されています。標準Cライブラリ以外に依存関係はありません。
埋め込み： MD4Cパーサーは他のプロジェクトで簡単に再利用できます。そのAPIは非常に簡単です。実際、 md_parse()は1つだけです。
プッシュモデル： MD4Cは完全なドキュメントを解析し、アプリケーションによって提供されるコールバック関数をほとんど呼び出して、すべてのブロックの開始/終了、すべてのスパンの開始/終了、およびテキストコンテンツを使用します。
移植性： MD4Cは、WindowsおよびPOSIXに準拠したOSを構築および動作させます。 （少なくとも、プラットフォームがヒープメモリ管理を含むC標準ライブラリを提供する限り、他のほとんどのプラットフォームでも実行するのは簡単です。）
エンコーディング： MD4Cは、デフォルトでは、入力ドキュメントのUTF-8エンコードが期待されます。ただし、Ascii-Only Control文字（つまり、すべてのUnicode固有のコードを無効にするために）を認識するためにコンパイルできます。または（Windows上）UTF-16（つまり、一般的に「Unicode」と呼ばれるWindows上にあるもの）が期待されます。詳細については、以下をご覧ください。
許容ライセンス： MD4CはMITライセンスの下で利用できます。
Markdownドキュメントを解析するだけが必要な場合は、 md4c.hを含めてMD4Cライブラリ（ -lmd4c ）にリンクする必要があります。または、パーサーが単一のCソースファイルにのみ実装されるため、 md4c.[hc]
主な提供された関数はmd_parse()です。マークダウン構文のテキストと、いくつかのコールバック関数へのポインターを提供する構造へのポインターを取得します。
md_parse()が入力を処理すると、コールバックを呼び出します（マークダウンブロックまたはスパンを入力または残すとき、およびドキュメントのテキストコンテンツを出力するとき）、アプリケーションがそれを別の形式に変換するか、画面にレンダリングします。
MarkdownをHTMLに変換する必要がある場合は、 md4c-html.hとMD4C-HTMLライブラリ（ -lmd4c-html ）に対するリンクを含めます。または、ソースmd4c.[hc] 、 md4c-html.[hc] 、およびentity.[hc]コードベースに。
マークダウン入力を変換するには、 md_html()関数を呼び出します。 Markdown入力を受け取り、提供されたコールバック関数を呼び出します。コールバックには、HTML出力のチャンクが供給されます。典型的なコールバックの実装は、チャンクをバッファーに追加するか、ファイルに書き込みます。
デフォルトの動作は、Commonmark仕様で定義されたMarkDown構文のみを認識することです。
ただし、適切なフラグを使用すると、動作を調整して、いくつかの拡張機能を有効にすることができます。
フラグMD_FLAG_COLLAPSEWHITESPACEを使用すると、非自明の白面が単一のスペースに崩壊します。
フラグMD_FLAG_TABLESを使用すると、GitHubスタイルのテーブルがサポートされています。
Flag MD_FLAG_TASKLISTSを使用すると、GitHubスタイルのタスクリストがサポートされています。
フラグMD_FLAG_STRIKETHROUGHを使用すると、ストライクスルースパンが有効になります（Tilde Marksに囲まれたテキスト、 ~foo bar~ ）。
FLAGでは> MD_FLAG_PERMISSIVEURLAUTOLINKS許容URLオートリンク（ <に囲まれていません）がサポートされています。
フラグMD_FLAG_PERMISSIVEEMAILAUTOLINKSでは、許容電子メールAutolinks（ <に囲まれていません） >サポートされています。
www.example.com MD_FLAG_PERMISSIVEWWWAUTOLINKS使用MD4Cは、 http:スキームを想定します。
$$...$$ MD_FLAG_LATEXMATHSPANS $...$ （ただし、HTMLレンダラーはカスタムタグ<x-equation>で逐語的に出力します。）
フラグMD_FLAG_WIKILINKSでは、Wikiスタイルのリンク（ [[link label]]および[[target article|link label]] ）がサポートされています。 （HTMLレンダラーは、カスタムタグ<x-wikilink>にそれらを出力していることに注意してください。）
Flag MD_FLAG_UNDERLINEでは、アンダースコア（ _ ）は、通常の強調や強力な強調ではなく、下線を示します。
Commonmarkの機能（一部の人々は、ミスフィーチャーと見なされる人）は、次のフラグで無効になる場合があります。
フラグMD_FLAG_NOHTMLSPANSまたはMD_FLAG_NOHTMLBLOCKSでは、それぞれRAWインラインHTMLまたはRAW HTMLブロックが無効になります。
フラグMD_FLAG_NOINDENTEDCODEBLOCKSを使用すると、インデントされたコードブロックが無効になります。
CommonMarkの仕様では、Unicodeコードポイントのシーケンスは有効なCommonmarkドキュメントであると宣言しています。
しかし、綿密な検査の下で、Unicodeは、マークダウンドキュメントを解析する際に、非常に具体的な状況ではあらゆる役割を果たします。
強調と強力な強調を処理する際の単語境界を検出するには、ユニコード文字（それが空白であろうと句読点であろうと）のいくつかの分類が必要です。
（ケース非感受性）リンク参照ラベルと対応するリンク参照定義の一致の場合、Unicode Case折りたたみが使用されます。
HTMLエンティティ（EG & ）および数値文字参照（Eg #またはಫ ）をユニコードの等価物に翻訳するため。
ただし、MD4Cはこの翻訳をレンダラー/アプリケーションに残します。レンダラーは実際に出力エンコードを知っているはずであり、この種の翻訳を実際に実行する必要があるかどうかを知っているからです。 （たとえば、レンダラーがHTMLを出力すると、エンティティが翻訳されていないままになり、作業をWebブラウザーに延期する可能性があります。）
MD4CはCommonmarkのこのプロパティに依存しており、実装は大部分がエンコーディングに依存しています。 MD4Cコードのほとんどは、選択したエンコードがASCIIと互換性があることのみを想定しています。つまり、128未満のコードポイントはASCIIと同じ数値値を持っていること。
入力MD4Cが理解していないことは、単にドキュメントテキストの一部として見られ、レンダラーのコールバック関数に変更されていません。
MD4Cが理解しなければならない2つの状況（単語境界検出とリンク参照マッチング）は、次のプリプロセッサマクロで指定されているように処理されます（MD4Cが構築されている時点で指定されています）：
プリプロセッサマクロMD4C_USE_UTF8が定義されている場合、MD4Cは境界検出という単語のUTF-8を想定し、リンクラベルのケース非感受性マッチングについて想定します。
これらのマクロが明示的に使用されない場合、これはデフォルトの動作です。
Windowsでは、Preprocessor Macro MD4C_USE_UTF16が定義されている場合、MD4Cはcharの代わりにWCHARを使用し、そのような状況でUTF-16エンコードを想定します。 （UTF-16は、Windows開発者が通常「Unicode」と呼ぶものであり、Win32APIが一般的に機能するものです。）
このマクロはmd4c.hのタイプにも影響するため、MD4Cを構築するときとmd4c.hを含めるときの両方をマクロを定義する必要があることに注意してください。
また、これはパーサー（ md4c.[hc] ）でのみサポートされています。 HTMLレンダラーはこれをサポートしておらず、この機能を使用するために独自のカスタムレンダラーを作成する必要があります。
Preprocessor Macro MD4C_USE_ASCIIが定義されている場合、MD4CはASCII入力に過ぎないと想定しています。
それは、事実上、非ASSASCIIの空白または句読点文字がそのように認識されず、リンクリファレンスマッチングがASCII文字（ [a-zA-Z] ）でのみケースに伴う方法で機能することを意味します。
パーサーのAPIは、 md4c.hのコメントで非常によく文書化されています。同様に、Markdown-to-HTML APIは、そのヘッダーmd4c-html.hで説明されています。
また、より包括的なドキュメントを提供するProject Wikiもあります。ただし、それは不完全であり、いくつかの詳細はやや時代遅れかもしれません。
Q：MD4Cは他のマークダウンパーサーと比較してどうですか？
A：他のいくつかの実装は、MarkdownパーサーとHTMLジェネレーターを、MarkdownからHTMLへの変換を可能にするインターフェイスの後ろに隠された単一の絡み合ったコードに組み合わせています。他の方法で入力を処理したい場合、それらはしばしば使用できません。
第二に、ほとんどのパーサー（すべてではないにしても、少なくともC/C ++言語の範囲内）は完全なDOMのようなパーサーです。マークダウンドキュメント全体の抽象的構文ツリー（AST）表現を構築します。それには時間がかかり、それはより大きなメモリフットプリントにつながります。
ASTを必要とする限り、ASTを構築することは完全に問題ありません。そうでない場合、MD4Cを使用することは、メモリ消費の点で大幅に速く、空腹が少なくなる可能性が非常に高くなります。
最後になりましたが、一部のマークダウンパーサーは素朴な方法で実装されています。スマートに作成された入力パターンを供給すると、二次（またはさらに悪い）解析時間を示す場合があります。 MD4Cが秒のほんの一部で解析できるものは、長い時間またはおそらく数時間に変わる可能性があります。したがって、このような素朴なパーサーを使用して信頼されていないソースからの入力を処理すると、サービス拒否攻撃の可能性が本当の危険になります。
私たちの努力の多くは、どんな種類のクレイジーな入力MD4Cパーサーが供給されていても、線形解析時間を提供することに費やされました。 （サブ線形解析時間につながる入力パターンが発生した場合は、躊躇してバグとして報告しないでください。）
Q：MD4Cは入力検証を実行しますか？
A：いいえ。そして、私たちはそれを誇りに思っています。 :-)
Commonmark仕様では、Unicode文字のシーケンスは有効なMarkdownドキュメントであると述べています。 （実際には、これは多かれ少なかれUTF-8エンコーディングを意味します。）
言い換えれば、仕様によれば、マークダウン構文の構築が何らかの形で壊れているかどうかは関係ありません。それが壊れている場合、それは認識されず、パーサーはそれを逐語的なテキストとして見るはずです。
MD4Cはこれをさらに一歩進めます。バイトのシーケンスを有効な入力と見なし、完全にジゴ哲学（ごみ箱、ごみん）に続きます。つまり、不正なUTF-8バイトシーケンスは、テキストの一部としてそれぞれのコールバックに伝播します。
入力がよく形成されたUTF-8ドキュメントであることを検証する必要がある場合は、自分でそれを行う必要があります。これを行う最も簡単な方法は、MD4Cパーサーに渡す前にドキュメント全体を単に検証することです。
MD4CはMITライセンスでカバーされています。ファイルLICENSE.md参照してください。
他の言語へのポートとバインディング：
CommonMark-D：MD4CのポートからD言語。
Markdown-Wasm：MD4CのポートからWebAssemblyへ。
PYMD4C：MD4C用のPythonバインディング
MD4Cを使用したソフトウェア：
Imgui_md：親愛なるImguiのMarkdown Renderer
Markdown Monolithアセンブラー：ブラウザベースの本を構築するためのコマンドラインツール。
QownNotes：Markdown SupportとOwnCloud / NextCloud統合を備えたプレーンテキストファイルメモ帳とTODOリストマネージャー。
QT：クロスプラットフォームC ++ GUIフレームワーク。
Textosaurus：QTとScintillaに基づくクロスプラットフォームテキストエディター。
8番目：クロスプラットフォーム連結プログラミング言語。
