Mediawikiパーサーの仕組み

MediaWikiパーサーの翻訳、公開されています。

   2009   , , -,        ,  -,      ,     Mediawiki,      .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Mediawikiパーサーは、 Mediawikiエンジンコードの基本的な部分です。 これがないと、Wikipediaの記事にさまざまなタグ（セクション、リンク、写真）を挿入できません。 他の記事のマークアップを表示したり、すばやく変更することさえできませんでした。 Wikiマークアップは、初心者でもHTMLの専門家でも簡単に書くことができるほど柔軟です。 このため、パーサーのコードはやや複雑であり、長年にわたってそれを改善するための多くの試みが行われてきました。 ただし、今日でも、世界最大のウェブサイトの1つであるウィキペディアにとっては十分に高速です。 この貴重な（しかし少し難解な）コードの内部を見てみましょう。

簡単な歴史

免責事項 私が理解しているように、この物語は主にウィキメディアのメーリングリストに長年参加してきた議論や、ウィキマニア会議2006の議論から集められました。2008年まで、Mediawikiパーサーは、 （高速化のため）1つのパス内に維持するだけでなく、常に新しいルールが既存のコードに追加されたという事実のためです。 時間が経つにつれて、パーサーコードは実際のスパゲッティコードになり、デバッグするのが非常に難しく、改善するのがさらに難しくなりました。 書き換えることはほとんど不可能でした。なぜなら エンジンのコアを指します。 新しいコードのどこかでエラーが発生した場合、数百万のウィキペディアページが一瞬で飛んできた可能性があります。

どうする

この問題を解決する方法について多くの議論が始まりました。 誰かがパーサーをCで書き直すことを提案しました。これにより、パーサーは高速になり、1つのパスではなくループでテキストを解析できるようになります。これは、Wikipediaページに含まれるテンプレートとサブパターンの数が増えるために必要になりました。 また、Mediawikiの構文を変更して、一部の構造の分析のあいまいさを排除する提案もありました（たとえば、「」 ''太字または斜体？ ''太字または斜体？ '' ''またはトリプルと中括弧の関係テンプレート）。

最終的に、パーサーをPHPに残し（Cで書き直すとMediawiki開発者が2つのクラスに分割されるため）、パーシングを前処理と解析の 2段階に分割することが決定されました。 プリプロセッサの仕事は、wikitextをXML DOMとして表現することでした。 解析の段階で、DOMツリーは、有効な静的HTMLを取得するために、必要な数の反復サイクルで処理されました（たとえば、テンプレートを置き換えるため）。 DOMのループ処理は非常に高速で、XHTMLの観点からも非常に自然です。 PHPでは、このような処理も非常によくサポートされています。

プリプロセッサ

Mediawikiソースフォルダーには、2つのバージョンのプリプロセッサ、HashとDOMのバージョンがあり、それぞれ/includes/parser/Preprocessor_Hash.phpと/includes/parser/Preprocessor_DOM.phpにあります。

DOMバージョンはHashバージョンとほぼ同じであるため、DOMバージョンに集中しますが、オプションのPHPコンポーネントであるPHP XMLサポートを使用するため、より高速に動作します。 プリプロセッサクラスで最も重要な関数はpreprocessToObj（）と呼ばれます。 Preprocessor_DOM.phpファイル内には、プリプロセッサが使用する他のいくつかの重要なクラスがあります：PPDStack、PPDStackElement、PPDPart、PPFrame_DOM、およびPPNode_DOM。

プリプロセッサはあなたが考えるよりも少ない

Mediawiki XMLはどのようなものですか？ 以下は、ウィキテキスト「{{MySpattern}} this [[test]]」がXML表現でどのように見えるかの例です。

 <root> <template> <title>mytemplate</title> </template> this is a [[test]] </root>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注。 内部リンクがまったく処理されないこと。 プリプロセッサコードは、後の段階で実行できる作業を回避します（そして、これには理由があります）。したがって、プリプロセッサの唯一の実際の作業は、テンプレートおよび他のいくつかのことのためのXML要素を作成することです。 これらのこと、すなわち ベースノード（完全なリスト）：テンプレート、tplarg、コメント、ext、ignore、h



Wikitextを使用したことがある場合は、これらの基本ノードに対応するマークアップが既にわかっています。 念のため、ここにあります：

• テンプレート =二重中括弧{{...}}
• tplarg =トリプル中括弧{{{...}}}
• comment =任意のタイプのHTMLコメント
• ext =別の拡張子で理解する必要があるすべてのもの
• ignore = noincludeタグ、およびincludeonlyタグとその中のコンテンツ
• h =セクション

以上です。 それ以外はすべて無視され、元のウィキテキストとしてパーサーに返されます。

プリプロセッサはどのように機能しますか？

ここでは特別なことは何もありませんが、いくつかの言葉は言う価値があります。 必要なXML表現を取得するために、プリプロセッサは、このテキストに含まれる文字数だけ、ループ内でWikitextを通過します。 構文のおかげで、テキスト内の何でも表現できる再帰パターンを正しく処理する他の方法はありません。 したがって、ウィキペディアの記事に40,000文字が含まれている場合、サイクルは40,000回の反復で構成される可能性があります。 これで、パーサーにとって速度が非常に重要である理由が明らかになりました。

自身の解析

XMLコードの生成に使用される残りのプリプロセッサと追加のクラスをスキップします。 パーサー自体に注目し、Wikipediaの記事をクリックしたときのパーサーの典型的なケースを見てみましょう。 ただし、ここでは、ウィキが可能な手段でキャッシュされることを忘れてはなりません。したがって、ページをクリックするたびにページの解析が発生することはほとんどありません。



Articleオブジェクトから始まる、現在のバージョンのページの典型的なパーサー呼び出しツリーを次に示します。

01.記事->ビュー

02.-記事-> getContent

03. ----記事-> loadContent

04. ------ Article-> fetchContent->データベースから取得したウィキテキストを返します

05.-記事-> outputWikiText->解析の準備

06. ----パーサー->解析

07. ------パーサー-> internalParse

08. --------パーサー-> replaceVariables

09. ----------パーサー-> preprocessToDom

10. ------------プリプロセッサ-> preprocessToObj

11. ----------フレーム->展開

12. --------パーサー-> doTableStuff

13. --------パーサー-> replaceInternalLinks

14. --------パーサー-> replaceExternalLinks

15. ------パーサー-> doBlockLevels

16. ------パーサー-> replaceLinkHolders

これらの機能を見てみましょう。 繰り返しますが、これらは主な関数であり、この例で呼び出されるすべての関数ではありません。 項目2〜4は、データベースから記事のウィキテキストを取得して返します。 このテキストはoutputWikiTextオブジェクトに渡され、Parser :: parse（）関数に渡すために準備されます。

その後、ポイント8〜11で再び興味深いものになります。 replaceVariables関数内で、テキストはDOM表現に変わり、記事内の各文字のループで、上記のテンプレート、サブパターン、および他のノードの開始ラベルと終了ラベルが検索されます。



ポイント番号11は、Preprocessor_DOM.phpファイル（上記）の他のクラスの知識を必要とするため、ここでスキップする興味深いステップです。 エキスパンドは非常に重要な機能であり、多くのこと（再帰呼び出しを含む）を行いますが、DOMノードからテキストを実際に抽出する仕事をすると言うだけで十分です（テンプレートはネストできるので、常にフルテキストを取得するわけではありません） 3つのタイプを除いて、すべてのwikiタグを明らかにする反転された有効なHTMLテキスト（含まれている各記事から）、:テーブル、リンク、およびリスト。 したがって、上記の例では、「{{MyTemplate}} this [[test]]」expand（）はフォームのテキストを返します。



「[[text]]をテンプレートからインクルードしました。これは[[test]]です」



この簡単な例からわかるように、テーブル、リンク、リストを除き、すべてがこの段階で整理されています。

リンクは特別な場合です

はい、リンクには独自のセクションがあります。 そしておそらく、それらが（編集に加えて）wiki自体を作るものの最も重要な部分だからです。 ただし、パーサーコードの残りのマークアップから非常に特別な方法で理解しているためです。 特別なのは、2つの段階で処理されることです。最初の段階では、各リンクに一意のIDが割り当てられ、2番目の段階では、その有効なHTMLが「リンクホルダー」の場所に挿入されます。 この例では、最初の段階の後に得られた結果を以下に示します。



「テンプレートに<！-LINK 0->を含めました。これは<！-LINK 1->です。」



ご想像のとおり、リンクのテキストとフォームLINK #IDのIDを一致させる配列もあります。これはmLinkHoldersという名前のParserクラスの変数です。 マッチングに加えて、この変数は各リンクのTitleオブジェクトも保存します。



したがって、リンクを解析する2番目のステップでは、この配列を使用して検索と置換を簡単にします。 今すべて！ 完成したテキストをドアの外に送ります！

次のステージ

次の投稿では、プリプロセッサとPreprocessor__DOM.phpファイルのクラスの詳細、つまり初期DOM XMLツリーを構築するためにどのように使用されるかに集中します。 Unbox拡張機能で情報ボックスをキャッシュするためにどのように使用したかについても説明します。