ここは複雑だと思われますか？ 保存する前にhtml-purifyerをいくつか追加してください。 はい、そうです。これは、特定の状況がなかった場合に実行できた可能性があります。
- 1つのメモに大量のテキストを含めることができます（数メガバイト）。
- 変更を保存するための多数の同時リクエストが予想されます。
- 保存要求は、異なる言語で書かれた異なる部分から行われることが期待されています。
- テキストを処理した後、保存する前に、追加のチェックが可能です。
- 処理後は、ノートの外観を元の外観にできるだけ近づける必要があります（理想的には、外観が完全に変わらないようにする必要があります）。
- 保存されたメモを表示するときのページレイアウトは「苦しむ」べきではありません。
- iframeを使用することは不可能です。
最初の3つのポイントには、メインコードとは別に機能するソリューションが明らかに必要です。 4番目の方法では、キュー（RabbitMQなど）の使用を除外するか、同等の方法で、キューを使用する際に重要なソリューションが必要になります。
最後に、最後の3つのポイントでは、最初は有効ではない可能性が高いという事実（「左」および/または閉じられていないタグ、属性、値）を考慮して、レイアウトの深い処理が必要です。 たとえば、要素の幅が100500に設定されている場合、この値は「許可」の定義に該当せず、削除または置換する必要があります（設定によって異なります）。
上記のすべての議論は、
すべてをゼロから書かないために、私の人生を単純化し、ある種の軽量フレームワークを使用することにしました。 選択は竜巻にかかった。彼とはすでに経験があったからだ。
スケーラビリティの考慮事項に基づいて、nginxはロードバランサーとしてシステムに追加されました。 このような構造により、パーサーインスタンスを追加するだけで、かなり広い範囲で処理能力を高めることができます。 また、パーサーからの応答を待機するクライアントのタイムアウトにより、最大待機時間を設定できます。これにより、ユーザーが快適ゾーンを離れることはありません（「すべてがハングしている」という感覚は生じません）。
最初は、htmlパーサーエンジンとしてlxmlが選択されました。 優れた高速Cパーサー。 そして、いくつかの「驚き」がなければ、すべてが彼とうまくいきます。
まず、このような「栄光」で作業する過程で、lxmlライブラリーがhtml-documentを「壊れた」xml-appとして解釈するというよく知られた事実が現れました。 この機能は、最初は懸念を引き起こしませんでしたが、増え続ける「クランチ」を生み出し始めました。 そのため、たとえば、lxmlは「」が単一のタグであると強く信じており、次の変換「=> <span />」を正しく実行しました。
しかし、「二番目に」出てこなければ、「クランチ」に耐えることができます。 実際のデータのコピーでのテスト実行中に、「セグメンテーションフォールト」に従ってパーサーが安定してクラッシュしました。 この理由は不明です。 なぜなら 約5千件のレコードを処理した後に「出発」が発生することが保証されました。 内容に関係なく（サンプリングはテーブルのさまざまな場所から行われました）。
したがって、一定量の「コーン」を蓄積して、「Beautiful Soup」、「html5lib」、およびそれらの動作松葉杖の束に落ち着きました。
この決定の後、「ここにある、幸福」がほとんど見え始めました。 そして、この幸福は、パーサーによって処理されたmsn.comページが目を引くまで正確に続きました。 このページの注目すべき機能は、「input」タグの「type」属性の積極的で架空の使用と、「position：absolute;」のレイアウトデザイナーの愛情です。そして、もちろん、見つかった繊細なスポットをカバーするテストを書きます。
現在、ウェブ上の多くのページに無効なhtmlが含まれていると抽象的に確信しているだけでなく、新しい「サプライズ」が来るのを待っています。 予防措置を講じようとして、私たちは待っています、そしていつか、すべてのフィルター、すべてのトリックを通過した彼女に会うことを知っています。 抽象画家の熱狂的なせん妄の産物であるページが表示されます...