正規表現を使用してHTMLを解析する：なぜそうしないのですか？

質問者が正規表現を使用してHTMLから一部の情報を取得する、stackoverflowのすべての質問には、必然的に正規表現を使用してHTMLを解析しないことを示す「回答」が含まれます。

何故なの？Beautiful Soupのように、引用符で囲まれていない「実際の」HTMLパーサーが存在することは承知しており、パワフルで便利だと確信していますが、単純、迅速、またはダーティなことをしているのであれば、その理由はいくつかの正規表現が問題なく機能するときに、複雑なものを使用するのは面倒ですか？

さらに、私が正規表現について理解していない根本的なものがあって、それらを一般的に解析するのに悪い選択にしていますか？

正規表現ではHTMLの完全な解析はできません。これは、正規表現では不可能である開始タグと終了タグのマッチングに依存しているためです。

正規表現は正規言語にのみ一致しますが、HTMLは文脈自由言語であり、正規言語ではありません（@StefanPochmannが指摘したように、正規言語も文脈自由なので、文脈自由は必ずしも規則的ではありません）。HTMLの正規表現でできることはヒューリスティックだけですが、すべての条件で機能するわけではありません。正規表現によって誤って照合されるHTMLファイルを提示する可能性があります。

素早い汚れに対しては正規表現で問題ありません。ただし、知っておくべき基本的なことは、HTML を正しく解析する正規表現を作成することは不可能であることです。

その理由は、正規表現が任意にネストされた式を処理できないためです。正規表現を使用して、ネストされたパターンを照合できますか？を参照してください。

（http://htmlparsing.com/regexesから）

<img>タグからURLを抽出しようとしているHTMLファイルがあるとします。

<img src="http://example.com/whatever.jpg">

したがって、Perlで次のような正規表現を記述します。

if ( $html =~ /<img src="(.+)"/ ) {
    $url = $1;
}

この場合、$url実際にはが含まれます http://example.com/whatever.jpg。しかし、次のようなHTMLを取得し始めるとどうなりますか。

<img src='http://example.com/whatever.jpg'>

または

<img src=http://example.com/whatever.jpg>

または

<img border=0 src="http://example.com/whatever.jpg">

または

<img
    src="http://example.com/whatever.jpg">

またはあなたはから偽陽性を得始めます

<!-- // commented out
<img src="http://example.com/outdated.png">
-->

それはとてもシンプルに見え、単一の変更されないファイルの場合はシンプルかもしれませんが、任意のHTMLデータに対して実行することになるすべてのことについて、正規表現は将来の心痛のレシピにすぎません。

2つの簡単な理由：

• 悪意のある入力に対抗できる正規表現を書くのは難しいです。ビルド済みのツールを使用するよりも難しい
• 必然的に行き詰まるとんでもないマークアップを処理できる正規表現を書くのは難しいです。ビルド済みのツールを使用するよりも難しい

一般的な解析のための正規表現の適合性について：それらは適切ではありません。ほとんどの言語を解析するために必要な種類の正規表現を見たことがありますか？

解析に関する限り、正規表現は、入力がトークンに分解される「字句解析」（レクサー）ステージで役立ちます。実際の「構文解析ツリーの構築」段階ではあまり役に立ちません。

HTMLパーサーの場合、整形式のHTMLのみを受け入れることが期待されます。これには、正規表現で実行できる機能以外の機能が必要です（これらは「カウント」できず、指定された数の開始要素が同じ数でバランスされていることを確認できません）終了要素の）。

ブラウザーがかなり寛大な方法で扱うHTMLを「ねじ込む」には多くの方法がありますが、ブラウザーの自由な動作を再現して正規表現ですべてのケースをカバーするにはかなりの労力が必要です。場合、それはあなたのシステムに深刻なセキュリティギャップをもたらす可能性があります。

問題は、HTMLと正規表現に関連する質問をするほとんどのユーザーが、動作する独自の正規表現を見つけられないためにこれを行うことです。次に、DOMパーサーまたはSAXパーサーなどを使用すると、すべてが簡単になるかどうかを考える必要があります。XMLに似たドキュメント構造で作業するために最適化および構築されています。

もちろん、正規表現で簡単に解決できる問題があります。しかし、重点は簡単にあります。

http://.../正規表現で問題ないように見えるすべてのURLを検索したいだけの場合。ただし、クラス「mylink」を持つa要素内にあるすべてのURLを検索する場合は、適切なパーサーを使用する方がよいでしょう。

正規表現は、ネストされたタグ構造を処理するようには設計されていません。実際のHTMLで発生する可能性のあるすべてのエッジケースを処理することは、せいぜい（最悪の場合、不可能）複雑です。

答えは計算理論にあると思います。正規表現を使用して言語を解析するには、定義上、「標準」（リンク）である必要があります。HTMLは、通常の言語の多くの基準を満たさないため、通常の言語ではありません（HTMLコードに固有の多くのレベルのネストに関係しています）。計算理論に興味があるなら、この本をお勧めします。

この式は、HTML要素から属性を取得します。それはサポートします：

• 非引用/引用属性
• 一重/二重引用符、
• 属性内の引用符のエスケープ、
• 等号の周りのスペース
• 任意の数の属性、
• タグ内の属性のみをチェックし、
• コメントをエスケープし、
• 属性値内の異なる引用符を管理します。

(?:\<\!\-\-(?:(?!\-\-\>)\r\n?|\n|.)*?-\-\>)|(?:<(\S+)\s+(?=.*>)|(?<=[=\s])\G)(?:((?:(?!\s|=).)*)\s*?=\s*?[\"']?((?:(?<=\")(?:(?<=\\)\"|[^\"])*|(?<=')(?:(?<=\\)'|[^'])*)|(?:(?!\"|')(?:(?!\/>|>|\s).)+))[\"']?\s*)

ご覧ください。デモのように、「gisx」フラグを使用するとよりうまく機能します。

HTML / XMLは、マークアップとコンテンツに分かれています。正規表現は、字句タグの解析を行う場合にのみ役立ちます。内容を推測できると思います。SAXパーサーに適しています。タグとコンテンツは、要素のネスト/クローズを追跡できるユーザー定義関数に配信できます。

タグの解析に関する限り、正規表現を使用してタグを解析し、ドキュメントからタグを取り除くことができます。

長年のテストの結果、私はブラウザがタグを正しく解析する方法と不正な方法の両方を解析する方法の秘密を発見しました。

通常の要素は次の形式で解析されます：

これらのタグのコアはこの正規表現を使用します

 (?:
      " [\S\s]*? " 
   |  ' [\S\s]*? ' 
   |  [^>]? 
 )+

これ[^>]?は代替の1つとして気付くでしょう。これは、不正な形式のタグからの不均衡な引用に一致します。

それはまた、正規表現に対するすべての悪の最も根源的なものでもあります。それが使用される方法は、それの貪欲で、一致しなければならない定量化されたコンテナを満足させるために衝突を引き起こします。

パッシブに使用すれば問題はありませんが、必要な属性/値のペアを挿入することによって何かを強制的に一致させ、バックトラックからの適切な保護を提供しない場合、それは制御不能の悪夢です。

これは単純な古いタグの一般的な形式です。[\w:]タグ名を表すことに注意してください ？実際には、タグ名を表す有効な文字は、信じられないほどのUnicode文字のリストです。

 <     
 (?:
      [\w:]+ 
      \s+ 
      (?:
           " [\S\s]*? " 
        |  ' [\S\s]*? ' 
        |  [^>]? 
      )+
      \s* /?
 )
 >

さらに、すべてのタグを解析せずに特定のタグを検索できないこともわかります。つまり、可能ですが、（* SKIP）（* FAIL）のような動詞の組み合わせを使用する必要がありますが、それでもすべてのタグを解析する必要があります。

その理由は、タグ構文が他のタグなどの中に隠れている可能性があるためです。

したがって、すべてのタグを受動的に解析するには、以下のような正規表現が必要です。この特定のものは、非表示のコンテンツにも一致します。

新しいHTML、xml、またはその他の新しい構成要素が開発されたら、それを代替の1つとして追加するだけです。

Webページのメモ-これで
問題が発生したWebページ（またはxhtml / xml）を見たことがありません。見つけた場合はお知らせください。

パフォーマンスのメモ-簡単です。これは、私が見た中で最も速いタグパーサーです
（知っている方が速いかもしれません）。
特定のバージョンがいくつかあります。スクレーパーとしても優れて
います（ハンズオンタイプの場合）。

完全な生の正規表現

<(?:(?:(?:(script|style|object|embed|applet|noframes|noscript|noembed)(?:\s+(?>"[\S\s]*?"|'[\S\s]*?'|(?:(?!/>)[^>])?)+)?\s*>)[\S\s]*?</\1\s*(?=>))|(?:/?[\w:]+\s*/?)|(?:[\w:]+\s+(?:"[\S\s]*?"|'[\S\s]*?'|[^>]?)+\s*/?)|\?[\S\s]*?\?|(?:!(?:(?:DOCTYPE[\S\s]*?)|(?:\[CDATA\[[\S\s]*?\]\])|(?:--[\S\s]*?--)|(?:ATTLIST[\S\s]*?)|(?:ENTITY[\S\s]*?)|(?:ELEMENT[\S\s]*?))))>

フォーマットされた外観

 <
 (?:
      (?:
           (?:
                # Invisible content; end tag req'd
                (                             # (1 start)
                     script
                  |  style
                  |  object
                  |  embed
                  |  applet
                  |  noframes
                  |  noscript
                  |  noembed 
                )                             # (1 end)
                (?:
                     \s+ 
                     (?>
                          " [\S\s]*? "
                       |  ' [\S\s]*? '
                       |  (?:
                               (?! /> )
                               [^>] 
                          )?
                     )+
                )?
                \s* >
           )

           [\S\s]*? </ \1 \s* 
           (?= > )
      )

   |  (?: /? [\w:]+ \s* /? )
   |  (?:
           [\w:]+ 
           \s+ 
           (?:
                " [\S\s]*? " 
             |  ' [\S\s]*? ' 
             |  [^>]? 
           )+
           \s* /?
      )
   |  \? [\S\s]*? \?
   |  (?:
           !
           (?:
                (?: DOCTYPE [\S\s]*? )
             |  (?: \[CDATA\[ [\S\s]*? \]\] )
             |  (?: -- [\S\s]*? -- )
             |  (?: ATTLIST [\S\s]*? )
             |  (?: ENTITY [\S\s]*? )
             |  (?: ELEMENT [\S\s]*? )
           )
      )
 )
 >

「場合によります」。ここに記載されているすべての理由により、正規表現がHTMLを正確に解析できないこと、および解析できないことは事実です。ただし、それを誤る結果（ネストされたタグを処理しないなど）が軽微であり、正規表現が環境で非常に便利な場合（Perlをハッキングする場合など）は、先に進んでください。

サイトにリンクしているWebページを解析しているとしましょう（おそらく、Googleリンク検索で見つけた可能性があります）。リンクを取り巻くコンテキストの一般的なアイデアをすばやく取得したいと考えています。スパムのリンクを警告するような小さなレポートを実行しようとしています。

その場合、一部のドキュメントを誤って解析することは大きな問題にはなりません。誰もが間違いを見ることになるでしょう、そしてあなたが非常に運が良ければ、あなたが個別にフォローアップできるほど十分にはありません。

私はそれがトレードオフだと言っていると思います。正確なパーサーを実装または使用することは、正確であることが重要でない場合は、問題なく簡単です。

仮定に注意してください。たとえば、公開されるものを解析しようとしている場合に、正規表現のショートカットが逆効果になるいくつかの方法を考えることができます。

正規表現を使用してHTMLからいくつかの情報を解析することが正しい方法である場合は確かにあります-それは特定の状況に大きく依存します。

上記のコンセンサスは、一般的にそれは悪い考えであるということです。ただし、HTML構造がわかっている場合（変更される可能性が低い場合）、それでも有効なアプローチです。

HTML自体は規則的ではありませんが、表示しているページの一部が規則的である可能性があることに注意してください。

たとえば、<form>タグをネストするとエラーになります。Webページが正しく機能している場合、正規表現を使用してを取得する<form>ことは完全に合理的です。

最近、Seleniumと正規表現のみを使用してWebスクレイピングを行いました。私は私が望んでいたデータを入れたので、それで逃げた<form>（私も数えることができるように、簡単な表形式で入れ<table>、<tr>そして<td>-実際には非常に珍しいとする非入れ子にします）。アクセスに必要な構造の一部がコメントで区切られていたため、ある程度、正規表現はほとんど必要でさえありました。（Beautiful Soupはあなたにコメントを与えることができますが、Beautiful Soupを使ってつかん<!-- BEGIN -->で<!-- END -->ブロックすることは困難でした。）

ただし、ネストしたテーブルについて心配する必要がある場合は、私のアプローチではうまくいきませんでした。Beautiful Soupに頼らなければならなかっただろう。ただし、それでも、正規表現を使用して必要なチャンクを取得し、そこからドリルダウンできる場合があります。

実際、正規表現によるHTML解析はPHPでは完全に可能です。ネストされたタグを取得するために毎回、貪欲な指定子を使用してそこから正規表現strrposを見つけ<て繰り返すために使用して、文字列全体を逆方向に解析する必要があります。大きなものでは空想的ではなく、ひどく遅いですが、私はそれを自分のウェブサイトの個人用テンプレートエディターに使用しました。私は実際にはHTMLを解析していませんでしたが、データベースエントリをクエリしてデータのテーブルを表示するために作成したいくつかのカスタムタグ（私の<#if()>タグは、このようにして特別なエントリを強調表示できます）。私は、あちこちにいくつかの自己作成タグ（その中に非常に非XMLデータがある）だけをXMLパーサーに使用する準備ができていませんでした。

したがって、この質問はかなり死んでも、Google検索には表示されます。私はそれを読み、「チャレンジは受け入れられる」と考え、すべてを置き換える必要なしに簡単なコードを修正しました。同様の理由を探している人に別の意見を提供することにしました。また、最後の回答は4時間前に投稿されたため、これはまだホットなトピックです。

私もこれについて正規表現を試してみました。主に次のHTMLタグとペアになっているコンテンツのチャンクを見つけるのに役立ちます。また、一致する終了タグは検索しませんが、終了タグを取得します。自分の言語でスタックをロールして、それらをチェックします。

'sx'オプションとともに使用します。運が良ければ 'g'も：

(?P<content>.*?)                # Content up to next tag
(?P<markup>                     # Entire tag
  <!\[CDATA\[(?P<cdata>.+?)]]>| # <![CDATA[ ... ]]>
  <!--(?P<comment>.+?)-->|      # <!-- Comment -->
  </\s*(?P<close_tag>\w+)\s*>|  # </tag>
  <(?P<tag>\w+)                 # <tag ...
    (?P<attributes>
      (?P<attribute>\s+
# <snip>: Use this part to get the attributes out of 'attributes' group.
        (?P<attribute_name>\w+)
        (?:\s*=\s*
          (?P<attribute_value>
            [\w:/.\-]+|         # Unquoted
            (?=(?P<_v>          # Quoted
              (?P<_q>['\"]).*?(?<!\\)(?P=_q)))
            (?P=_v)
          ))?
# </snip>
      )*
    )\s*
  (?P<is_self_closing>/?)   # Self-closing indicator
  >)                        # End of tag

これはPython用に設計されています（他の言語でも機能する可能性があり、まだ試していません。ポジティブ先読み、ネガティブ後読み、および名前付き後方参照を使用しています）。サポート：

• タグを開く- <div ...>
• タグを閉じる- </div>
• コメント- <!-- ... -->
• CDATA- <![CDATA[ ... ]]>
• 自己終了タグ- <div .../>
• オプションの属性値- <input checked>
• 引用符で囲まれていない/引用符で囲まれた属性値- <div style='...'>
• 一重/二重引用符- <div style="...">
• エスケープされた引用- <a title='John\'s Story'>
  （これは本当に有効なHTMLではありませんが、私はいい人です）
• 等号の周りのスペース- <a href = '...'>
• 興味深いビットの名前付きキャプチャ

また、あなたが忘れてしまったときのように、不正なタグにトリガーないことについて、かなり良いことだ<かを>。

あなたの正規表現フレーバーが名前付きキャプチャの繰り返しをサポートしている場合、あなたはゴールデンですが、Python reはそうではありません（正規表現はサポートしていますが、通常のPythonを使用する必要があります）。ここにあなたが得るものがあります：

• content-次のタグまでのすべてのコンテンツ。これは省略できます。
• markup -すべてが入ったタグ全体。
• comment -コメントの場合、コメントの内容。
• cdata-の場合<![CDATA[...]]>、CDATAの内容。
• close_tag-終了タグ（</div>）の場合は、タグ名。
• tag-開始タグ（<div>）の場合、タグ名。
• attributes-タグ内のすべての属性。繰り返しグループを取得しない場合は、これを使用してすべての属性を取得します。
• attribute -繰り返し、各属性。
• attribute_name -繰り返し、各属性名。
• attribute_value-繰り返し、各属性値。引用されている場合は、引用符も含まれます。
• is_self_closing-これは/自己終了タグの場合であり、それ以外の場合は何もありません。
• _qおよび_v-これらを無視します。それらは内部で後方参照に使用されます。

正規表現エンジンが名前付きキャプチャの繰り返しをサポートしていない場合は、各属性を取得するために使用できるセクションが呼び出されます。ただ、上のその正規表現を実行しattributes、それぞれを取得するグループattribute、attribute_nameおよびattribute_valueそれから。

デモはこちら：https : //regex101.com/r/mH8jSu/11

正規表現は、HTMLのような言語には十分強力ではありません。もちろん、正規表現を使用できる例がいくつかあります。ただし、一般的には解析には適していません。

あなたが知っている...あなたがそれを行うことはできないという多くの考え方があります、そして私はフェンスの両側の誰もが正しいと間違っていると思います。あなたはCANそれを行うが、それはそれに対して1つの正規表現を実行しているよりも、処理はもう少しかかります。例としてこれ（私は1時間以内に書いた）を取り上げます。これはHTMLが完全に有効であることを前提としていますが、前述の正規表現を適用するために使用している言語によっては、HTMLを修正して、HTMLが成功することを確認できます。たとえば、存在しないはずの終了タグを削除します</img>。次に、閉じている単一のHTMLスラッシュを、それらが欠落している要素に追加します。

これは、JavaScriptのようなHTML要素の検索を実行できるライブラリを作成する状況で使用します[x].getElementsByTagName()。正規表現のDEFINEセクションで記述した機能をつなぎ合わせて、要素のツリー内を一度に1つずつステップ実行するために使用します。

それで、これはHTMLを検証するための最後の100％回答になりますか？いいえ。しかし、それは始まりであり、もう少し作業を行うことで、それを実行できます。ただし、1つの正規表現実行の中でそれを実行することは、実用的でも効率的でもありません。