次のようなテーブルにwhoisデータを配置する必要があります
whois サーバーからデータを抽出するスクリプトを作成しましたが、ドメイン拡張子ごとに出力が異なります。
たとえば、.comドメインの登録者の詳細は総アドレスとして表示され、.orgドメインの場合は登録者名、street1、street2、street3 などになります。
そのため、登録者の詳細をデータベースに入れる単位として抽出することはできません。
xmlデータとして取得すれば抽出できると聞いたことがありますが、誰かがこれを回避するのを手伝ってくれますか? ありがとう！。
実際には、問題はそれよりも大きくなっています。
WHOIS サービスは RFC3912 で定義されています。応答内容のフォーマットを一切定義しない、非常に基本的なリクエストプロトコルです。そのため、多くの場合、回答はデータを含むデータベースの形式を反映しており、データベースごとに異なる構文が得られる場合があります。WHOIS は任意のコンテンツに使用できるため、得られる回答の形式について多くの仮定を立てることはできません。ただし、解析可能なコンテンツと、各リクエストに対して同様の形式の回答を受け取ることが期待できることを願っています。
そのため、非常に経験的な方法で実行する必要がある各サーバーの解析ロジックを開発する必要があります。
ただし、ここでは、RFC から得られる開発のためのヒントをいくつか紹介します。
CR+LF ASCII 文字で終わる 1 行で TCP ポート 43 を使用してリクエストを送信する必要があります。
応答が終了したことを意味するだけで、接続の TCP 終了を期待する必要があります。
特にドメイン名については、以前は ASCII エンコーディングへの制限により、一部の登録者が Punycode を使用して DNS システムで一部の (例で強調された) 文字列をエンコードしていたことに注意してください。また、いくつかの返信で会った場合。2003 年以降、国際化ドメイン名が存在するため、Unicode エンコーディングをサポートする必要があります。名前を変換するアルゴリズムは複雑です。RFC 3490 には、これに関する有用な詳細がいくつか記載されています。
幸運を ！
フォーマットを検出し、それらに異なる正規表現を使用する必要があります。あるいは、あなたが述べたように、XML または JSON API を使用することもできます http://whoisxmlapi.com/ http://www.domaintools.com/api/docs/
問題をより適切に処理するには、データベースと処理を拡張する必要があります。
リモート サービスによって提供されるデータは、既に述べたように異なる形式です。したがって、データの取得と解析は互いに独立しているため、これらの問題を分離する必要があります。たとえば、1 つの TLD の形式は時間の経過とともに変化する可能性があります。
まず、ドメインごとにプレーン テキスト データを取得し、そのメタデータを保存します。
その後、2 番目の処理内で解析を行うことができます。既存のメタデータを使用して、必要な解析アルゴリズムを決定できます。これは、長期にわたってアプリケーションを維持するのにも役立ちます。
解析が正しく行われた後、目的の正規化された形式が得られます。
これらの技術的な処理に加えて、whois サービスによって提供される使用条件に注意する必要があります。技術的に可能なことのすべてが、法的または道徳的に受け入れられているわけではありません。他の人の個人的な記録に注意を払い、これに値する敬意を持って扱います。収集したデータを保護します。たとえば、進行中の処理に不要になったデータをアーカイブおよびスクランブル / ロックアウェイします。
同様に参照してください：