JP2011024179A - Ｈｔｔｐパケットにおけるハングルまたは日本語のデコード方法と装置、及びこれを用いたハングルまたは日本語ウェブコンテンツの分析方法 - Google Patents

Abstract

【課題】ＨＴＴＰパケットにおけるハングルまたは日本語のデコード方法と装置、及びこれを用いたハングルまたは日本語ウェブコンテンツの分析方法を提供する。
【解決手段】トラフィックモニターリング装備においてＨＴＴＰトラフィック分析を行うときに、ＨＴＴＰパケットペイロード内にエンコードされているハングルまたは日本語文字列を探知して解読する方法／装置と、これを用いて探索したＨＴＭＬ若しくはＸＭＬなどのウェブ文書の内容を分析してユーザがどの種類のコンテンツに関心を持っているかを分析する。
【選択図】図１

Description

本発明はトラフィックモニターリング装備においてＨＴＴＰトラフィック分析を行うときに、受信されたＨＴＴＰパケットペイロード内にハングルまたは日本語がエンコードされているかどうかを探知し、これを解読する方法／装置及びこの方法により解読されたウェブコンテンツの内容を分析する方法に関する。すなわち、本発明は、トラフィックモニターリング装備においてＨＴＴＰトラフィック分析を行うときに、ＨＴＴＰパケットペイロード内にエンコードされているハングルまたは日本語文字列を探知して解読する方法／装置と、これを用いて探索したＨＴＭＬ若しくはＸＭＬなどのウェブ文書の内容を分析してユーザがどの種類のコンテンツに関心を持っているかを分析する方法に関する。

インターネットに代表されるネットワークの活性化に伴い、ネットワークの属性と特徴を正確に理解し、各種のネットワーク上において発生する問題（トラフィック問題、保安問題など）の原因を明確に究明して解決するためにトラフィック分析またはパケット分析が行われている。

ポート番号を用いたトラフィック分析方法は簡単であるため盛んに活用されているものの、分析の正確度が低いという不都合がある。より正確な分析方法として、パケットペイロードにおいてアプリケーションの特定のシグニチャーの存否を判断して分析する方法がある。しかしながら、特定のシグニチャーを探索することは容易ではなく、シグニチャーが変わる度に更新をしなければならないという欠点がある。その他にも、ＩＰアドレス若しくはｔｃｐポート番号などのフィールドとパケットサイズなどの特徴をＳＶＭ（Support Vector Machine）などの機械学習に適用してトラフィックを分析する方法もある。しかしながら、これらの方法論は、インターネットアプリケーションを分類することが主たる目的である。

一方、このような既存の研究及び分析の観点から逸脱して、ネットワークに流れるＨＴＴＰプロトコルを利用するウェブアプリケーションパケットを対象としてハングルまたは日本語ＨＴＭＬ若しくはＸＭＬ文書を抽出してコンテンツ別に分類することにより、ユーザがインターネットにおいてどの種類のコンテンツに関心が多く、どのような行動パターンを示すかなどを把握する必要性が高まりつつある。

現在、インターネット上には、パケット分析を簡単に且つ正確に行う上で役立つような種々のツール（Ethereal、Wireshark、Snifferら）が存在する。しかしながら、これらのツールは、パケットのペイロードの内容をアスキーコード文字列として表示することに留まっており、ハングルからなる文字列がＨＴＴＰパケットに含まれている場合、その内容を知ることができない。韓国や日本の場合、インターネット上の情報はほとんどハングルや日本語にエンコードされたウェブコンテンツであるため、インターネットトラフィックの内容を精度よく分析し、且つ、ユーザの行為を把握するためのコンテンツ分析のためには、アスキーコードではなく、ハングルまたは日本語文字列として自動的に認識して解読することの必要性が増大されている。

現在、ＨＴＴＰにおいて使われるハングルエンコード方法は、ハングル完成型コード（ＫＳ完成型標準ハングルコード、ＫＳＣ５６０１）を用いたエンコード、ＥＵＣ−ＫＲ、ＵＴＦ−８、ＵＴＦ−１６に大別できる。しかしながら、現在、ほとんどのウェブサーバがハングル完成型コード（ＫＳＣ５６０１）、特に、ＥＵＣ−ＫＲとＵＴＦ−８を用いてウェブページを伝送しているのが現状である。

ハングル完成型コードは２バイト完成型コードであり、２３５０文字のハングルを支援する（ＫＳＣ５６０１）。ＥＵＣ−ＫＲは、Bell Lab.において、ＵＮＩＸ（登録商標）上において英文字以外の文字を支援するために提案した拡張ＵＮＩＸ（登録商標）コードのうちハングルエンコード方式であり、英文はＫＳＣ５６３６（新名称はＫＳ×１００３）で処理し、ハングルはＫＳＣ５６０１（新名称はＫＳ×１００１）で処理する。ここで、ＫＳＣ５６３６は英文字に対する標準であり、韓国工業標準情報処理分野（Ｃ）の５６３６番標準案を言い、既存のアスキーコードにおいて逆スラッシュ（￥）をウォン表示に代替したコードである。すなわち、ＥＵＣ−ＫＲは、ＫＳＣ５６０１とＫＳＣ５６３６を併合したコードを使用する８ビット文字エンコードであると考えればよい。

ＵＴＦ−８とＵＴＦ−１６はユニコードのための可変長文字エンコード方式の一つである（ＩＳＯ／ＩＥＣ１０６４６）。ＵＴＦ−８エンコードは、ユニコード１文字を表示するために１バイトから４バイトまでを使用する。例えば、Ｕ＋００００からＵ＋００７Ｆの範囲にあるアスキー文字は、ＵＴＦ−８において１バイトだけで表示される。同様に、Ｕ＋００８０からＵ＋０７ＦＦまでは２バイトであり、Ｕ＋０８００からＵ＋ＦＦＦＦまでの間に入るハングルは３バイトでエンコードされる。ＵＴＦ−１６は、基本多国語平面（ＢＭＰ：Basic Multilingual Plane）に属する文字はそのまま１６ビット値にエンコードし、それ以上の文字は特定の方式により３２ビットにエンコードする。

現在ＨＴＴＰにおいて使われる日本語エンコード方法は、ＳＨＩＦＴ−ＪＩＳ、ＥＵＣ−ＪＰ、ＵＴＦ−８、ＵＴＦ−１６に大別できる。

ＳＨＩＦＴ−ＪＩＳ（ＪＩＳ×０２０８：１９９７ Appendix １）は、ＪＩＳ×０２０１とＪＩＳ×０２０８などを使用する日本語文字エンコードであり、ＳＪＩＳと略称する。１９８２年に開発され、日本内において広く使用されるに伴い、ＪＩＳ×０２０８：１９９７の付属書１として標準化された。バイトコードからなるＳＨＩＦＴ−ＪＩＳは多数の拡張が制定されたが、これらの中でＪＩＳ×０２０８の拡張により制定されたマイクロソフトのコードページ９３２が最も多用される。中でも、ひらがらは０ｘ８２９Ｆ〜０ｘ８２Ｆ１、カタカナは０ｘ８３４０〜０ｘ８３９６であり、最後に、漢字は、いくつかを除いては０ｘ８８９Ｆ〜０ｘＥＥＥＣ、０ｘＦＡ５Ｃ〜０ｘＦＣ４Ｂの範囲に属する。

ＥＵＣ−ＪＰは、Bell Lab.において、ＵＮＩＸ（登録商標）上において英文字以外の文字を支援するために提案した拡張ＵＮＩＸ（登録商標）コードのうち日本語エンコード方式であり、ＥＵＣのエンコード方式上にアスキーとＪＩＳ×０２０８文字集合を配置したものであり、半角カナ（ＪＩＳ×０２０１）とＪＩＳ補助漢字（ＪＩＳ×０２１２）も含むことができる。中でも、ひらがなは０ｘＡ４Ａ１〜０ｘＡ４Ｆ３、カタカナは０ｘＡ５Ａ１〜０ｘＡ５Ｆ６であり、最後に漢字は２バイトの０ｘＢ０Ａ１〜０ｘＦＣＥＤと０ｘ８ＦＡ２Ａ０〜０ｘ８ＦＦＥＦＥ範囲の３バイトの補助漢字から構成されている。

ＵＴＦ−８とＵＴＦ−１６は、ユニコードのための可変長文字エンコード方式の一つである（ＩＳＯ／ＩＥＣ１０６４６）。ＵＴＦ−８エンコードは、ユニコード１文字を表示するために１バイトから４バイトまでを使用する。例えば、Ｕ＋００００からＵ＋００７Ｆの範囲にあるアスキー文字はＵＴＦ−８において１バイトだけで表示される。同様に、Ｕ＋００８０からＵ＋０７ＦＦまでは２バイトであり、Ｕ＋０８００からＵ＋ＦＦＦＦまでの間に入る日本語は３バイトにエンコードされる。ＵＴＦ−１６は、基本多国語平面に属する文字はそのまま１６ビット値にエンコードし、それ以上の文字は特定の方式により３２ビットにエンコードする。

本発明は、ＨＴＴＰパケットにおいてハングルまたは日本語がエンコードされているかどうかを確認し、エンコードされている場合にこれをハングルまたは日本語文字列にデコードして表現（出力）可能な方法及び装置を提供することを目的とする。

また、本発明は、前記ハングルまたは日本語のデコード方法によりデコードされたＨＴＭＬ／ＸＭＬ文書単位で解読されたハングルまたは日本語コンテンツをカテゴリ別に貯蔵されたハングルまたは日本語キーワードとのマッチングを通じて当該文書を特定のコンテンツカテゴリに分類して、ウェブコンテンツ分析だけではなく、当該網におけるユーザの行為までも把握できるようにすることを目的とする。

以下、説明の便宜のために、いくつかの用語を定義する。

「フロー」とは、共通のアドレス対（送信元アドレス、送信元ポート番号、受信先アドレス、受信先ポート）、ホスト対（送信元ホストアドレス、受信先ホストアドレス）、ネットワークアドレス対（送信元ネットワークアドレス、受信先ネットワークアドレス）、ＡＳ番号対（送信元ＡＳ番号、受信先ＡＳ番号）などとして与えられる条件を満足する制限された時間内に到着するＩＰパケットの流れとして定義される。このため、受信されたパケットのヘッダーを分析すれば、そのパケットが特定のフローに属するか、属すればフローの何番目のパケットであるか、または、最後のパケットであるかなどを確認することができる。ＩＰパケットヘッダー分析は、従来周知の事項であるため、詳細な説明を省略する。

「ペイロード（payload=message body）」はパケットのヘッダーに対応する概念であり、ユーザ情報（コンテンツ）を保有するパケットの部分を意味する。ペイロードは、圧縮されている場合もある。

上述した課題を解決するために、本発明は、フロー情報などが格納されるフローテーブルが介在されたハングルまたは日本語のデコード方法／装置、これによりデコードされたハングルまたは日本語ウェブコンテンツの分析方法に関する。

（１）フローに相当するパケットのペイロードを組立した後にデコードする方法
本発明によるハングルまたは日本語のデコード方法は、フロー情報などが格納されるフローテーブルが介在されたハングルまたは日本語のデコード方法において、（Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の第２段階（適合性分析段階）に移行し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記の第３段階（ペイロード組立段階）に移行する第１段階（フロー分析段階）と、（Ｂ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後に下記の第３段階（ペイロード組立段階）に移行し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する第２段階（適合性分析段階）と、（Ｃ）前記段階（Ｂ）において、ＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能であると分析されたパケットのペイロード部分を格納し、前記段階（Ａ）において、最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在すると確認されたパケットのペイロードを既存に格納されている当該フローのペイロードに連結してフローを組立する第３段階（ペイロード組立段階）と、（Ｄ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新して前記第１段階に移行する第４段階（フローテーブル管理段階）と、（Ｅ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、（１）前記パケットが圧縮されたものであれば、フローの最後のパケットまで組立されたフローのペイロードの圧縮を解凍した後、（２）圧縮されたものではなければそのまま前記フローのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする第５段階（圧縮解凍／デコード段階）と、を含んでなるＨＴＴＰパケットにおけるハングルまたは日本語のデコード方法である。

別途の詳細な付加説明がなくても、本発明の特性から、通信上の瑕疵などによりそれ以上受信または分析するパケットがない場合、前記デコード方法の遂行が中断されることは言うまでもない（以下、同じ）。

本発明において、前記フローテーブルは、フローを識別可能な情報フィールドと、削除予約フラグフィールド、フロー維持時間フィールド、ハングルまたは日本語エンコード型フィールド、ＨＴＴＰパケットのペイロード長フィールド及び圧縮有無フラグ情報フィールドを含むことが好ましい。もし、フロー維持時間フィールドがある場合、後続パケットが所定のフロー維持時間（例えば、３０秒）内に受信されなければデコードを終了するようにしてもよい。削除予約フラグフィールドがある場合、初期フロー分析段階においてパケットが最後のパケットである場合（すなわち、パケットのＴＣＰヘッダーにＦＩＮフラグが設定された場合）、これを削除予約フラグに記録しておき、この記録の有無を確認することによりパケットが最後のパケットであるかどうかを確認するようにしてもよい。すなわち、フローテーブルに設定された削除予約フラグがあるか、または、所定のフロー維持時間を超えたフローがあるかをチェックして、あればフローテーブルを削除（初期化）する。

本発明の前記第２段階（適合性分析段階）において、ＨＴＴＰヘッダーにシグニチャー１（「Content-Type：ＸＸＸ」及び｛「charset＝ＹＹＹ」または「encoding＝ＹＹＹ」｝、ここで、ＸＸＸが「ｔｅｘｔ／ｈｔｍｌ」または「ｔｅｘｔ／ｘｍｌ」）が存在し、ＹＹＹが、（１）ハングルエンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＫＲ、ｅｕｃ−ｋｒ、ＫＳ＿Ｃ＿５６０１またはｋｓ＿ｃ＿５６０１であるか、または、（２）日本語エンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＪＰ、ｅｕｃ−ｊｐ、ＳＨＩＦＴ−ＪＩＳまたはｓｈｉｆｔ−ｊｉｓである場合に、フローテーブルを生成して第３段階（ペイロード組立段階）に移行することが好ましい。

（２）また、本発明によるハングル及び日本語デコード装置は、上述した方法を行うための装置であり、（Ａ）受信されたパケットのＩＰヘッダーを分析して最初のパケットであるかどうかを確認するヘッダー分析部と、（Ｂ）前記ＨＴＴＰパケットヘッダーとペイロードの一部情報を参照して、ＨＴＴＰ応答パケットであるか、あるいは、ハングルまたは日本語デコードが可能なパケットであるかを判断する適合性分析部と、（Ｃ）適合性が確認されたパケットのペイロードを組立するペイロード組立格納部と、（Ｄ）フロー情報を生成、管理するフローテーブル管理部と、（Ｅ）組立が完了されたフローのペイロードをパーシングを通じてデコードする圧縮解凍／デコードブと、を備えるＨＴＴＰパケットにおけるハングルまたは日本語デコード装置である。

（３）本発明によるハングルまたは日本語ウェブコンテンツの分析方法１は、上述した方法によりデコードされたハングルまたは日本語ウェブコンテンツと所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析することを特徴とするハングルまたは日本語ウェブコンテンツの分析方法である。

（４）パケットごとにペイロードを順次にデコードした後にコンテンツ分析する方法（ペイロード組立段階がない方法）
本発明によるハングルまたは日本語ウェブコンテンツの分析方法２は、フロー情報などが格納されるフローテーブルが介在されたハングルまたは日本語ウェブコンテンツの分析方法において、（Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の第２段階（適合性分析段階）に移行し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記の第３段階（圧縮解凍／デコード段階）に移行する第１段階（フロー分析段階）と、（Ｂ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後に下記の第３段階（圧縮解凍／デコード段階）に移行し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する第２段階（適合性分析段階）と、（Ｃ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、（１）前記パケットが圧縮されたものであれば、パケットペイロードの圧縮を解凍した後、（２）圧縮されたものではなければそのまま前記パケットのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする第３段階（圧縮解凍／デコード段階）と、（Ｄ）デコードされたハングルまたは日本語ウェブコンテンツと所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析する第４−１段階（パターンマッチング段階）と、（Ｅ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新し、前記第１段階に移行する第４−２段階（フローテーブル管理段階）と、を含むＨＴＴＰパケットにおけるハングルまたは日本語ウェブコンテンツの分析方法である。

この場合、前記フローテーブルには、上述した（１）におけるフィールドに１バイト格納空間フィールドが追加されることが好ましい。１バイト格納空間はハングルと日本語の２バイトエンコード方式を反映したものであり、下記のように活用される。

すなわち、前記第３段階（圧縮解凍／デコード段階）及び第４−２段階（フローテーブル管理段階）において、（ａ）前記パケット（ｎ）がフローの最後のパケットではない場合、ハングルまたは日本語デコードを行い、最後の１バイトが残留するときにこれをフローテーブルの１バイト格納空間に一時的に格納し、（ｂ）次のパケット（ｎ＋１）の処理時に前記一時的に格納された１バイト情報を次のパケット（ｎ＋１）のペイロード先端に添付した後にデコードするのである。

前記第２段階（適合性分析段階）は、上述した（１）と同様でありうる。

本発明により、ＨＴＴＰパケットにエンコードされているハングルまたは日本語文字列を探知して解読するとき、ハングル完成型コード値と比較してその値に相当するハングルまたは日本語文字を出力することが可能になる。

また、本発明により、ハングルまたは日本語文字列が多数のパケットに跨っている場合、同じ出発地と目的地ＩＰアドレス／ポート番号を有する連続したＨＴＴＰパケットに対しても、エンコード情報がなくてもハングルまたは日本語文字列を探知して解読できるようにする。

さらに、本発明により、探知されたハングルまたは日本語文字列情報を利用することが可能になり、ＨＴＴＰトラフィックの詳細な分析が可能になる。

本発明によれば、探知されたハングルまたは日本語文字列情報を用いてトラフィックモニターリングシステムが設けられたネットワーク内のユーザがどのようなウェブコンテンツを楽しむかを把握することができる。このような情報を基に、ウェブコンテンツ製作者は、特定のウェブポータルにおける人気コンテンツ結果ではなく、様々なウェブポータルを利用する総合的な結果を得ることができ、ネットワーク管理者や新たにネットワークを設計するエンジニアは、ネットワーク優先順位経路の設定などのネットワーク管理を最適化する上で活用することが可能になる。

本発明によるハングルまたは日本語のデコード方法及びその結果として得られたウェブコンテンツを分析する方法の一例を示す全体フローチャートである。 本発明によるハングルまたは日本語のデコード方法の他の例を示すフローチャートである。 本発明によるハングルまたは日本語のデコード方法及びその結果として得られたウェブコンテンツを分析する方法のさらに他の例を示す全体フローチャートである。 本発明の圧縮解凍／デコード段階の一例を示す詳細フローチャートである。

以下、添付図面に基づき、本発明を詳述する。しかしながら、これらの図面は本発明の技術的思想の内容と範囲を容易に説明するための例示に過ぎず、これにより本発明の技術的範囲が限定されたり変更されることはない。また、これらの例示に基づいて本発明の技術的思想の範囲内において種々の変形と変更が可能であることは当業者にとって当然である。

図１は、本発明によるハングルまたは日本語のデコード方法及びその結果として得られたウェブコンテンツを分析する方法の一例を示す全体フローチャートであり、図２は、本発明によるハングルまたは日本語のデコード方法の他の例を示すフローチャートである。図１及び図２の例は、フローに相当するあらゆるパケットのペイロードを組立した後にデコードする方式である。

先ず、図１について説明する。図１による方法は、大きく、［フロー分析段階→適合性分析段階→ペイロード組立段階→フローテーブル管理段階→圧縮解凍／デコード段階］を含んでなる。このとき、発明の趣旨から、フローテーブル管理段階は、その流れからみて、適合性分析段階以降であればいつ行われても同じ結果を示すことは当業者にとって当然である。このため、本発明及びその説明／図面において、フローテーブル管理段階をたとえ第４段階で表現したが、これは順序を示すものではない（以下、同じ）。

（Ａ）第１段階（フロー分析段階）においては、受信したＴＣＰ／ＩＰパケットが多数のＨＴＴＰパケットのうち既に受信されたＨＴＴＰ応答パケットと関連する残りのパケットであるか（すなわち、フローに相当するか）を判断する。［もちろん、フローの最初のパケットであり、且つ、適合性（ハングル／日本語デコード可能性）が確認された場合には、フローテーブルが生成される。］

この段階においては、受信されたパケットがフローの最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ、ＨＴＴＰ応答パケットではないフローであるか、あるいは、ハングル／日本語デコードが不可能なフローであることが最初のパケットにより既に確認されたものであるため、さらなる措置なしに終了する。もちろん、ヘッダー情報がないパケットであり、且つ、フローテーブルにもないパケットであれば、いかなる処理なしに終了した後、直ちに次のパケットがあるかどうかを調べるような順序に従う。

最初のパケットではなく、且つ、当該フローテーブルが存在すれば、ＨＴＴＰ応答パケットであり、且つ、ハングル／日本語デコードが可能なフローであることが最初のパケットにより既に確認されたものであるため、前記フローに相当する連続するパケットとして認識し、第２段階（適合性分析段階）を経ることなく直ちに第３段階（ペイロード組立段階）に移行する。ここで、「パケットの当該フローテーブル」とは、パケットなどの出発／目的ＩＰアドレス、出発／目的ポートを有する先行パケットの情報が格納されたフローテーブルのことを言う。

受信されたパケットがフローの最初のパケットであれば、第２段階（適合性分析段階）に移行する。

（Ｂ）第２段階（適合性分析段階）においては、フローの最初のパケットである場合、受信パケットが応答パケットであるか、及びハングルまたは日本語デコードが可能であるかを確認してそれに対するフローテーブルを生成する。

すなわち、前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、２バイトハングルまたは日本語デコードが可能なパケットであれば、フローテーブルを生成した後に第３段階（ペイロード組立段階）に移行する。一方、ＨＴＴＰ応答パケットがないか、あるいは、２バイトハングルまたは日本語デコードが不可能なパケットであれば、さらなる措置なしに終了する。

前記フローテーブルは、フローを識別可能な情報（出発ＩＰアドレス、目的ＩＰアドレス、出発ポート、目的ポート、受信した時間、識別子、フラグ、断片化オフセットなどの全部または一部）及び削除予約フラグ及びフロー維持時間などのフィールドから構成してもよい。

このようにして生成されたフローテーブルは、第１段階（フロー分析段階）においてフローの最初ではないパケットのフローテーブルであるかどうかを確認するために活用され、下記の第４段階（フローテーブル管理段階）において管理される。

一方、本発明は、前記フローテーブルを第２段階前に生成していて、適合性がないと判断されれば初期化することを排除しない。

第２段階の詳細については、後述する。

（Ｃ）第３段階（ペイロード組立段階）においては、ハングルまたは日本語デコード適合性が確認されたフローのパケットＨＴＴＰペイロードのストリングを組立／格納する段階である。

すなわち、ＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能であると分析されたパケットのペイロードを格納する。このとき、最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在すると確認されたパケット（ｎ番目パケット）のペイロード（ｐ_ｎ）を既存に格納されている当該フローのペイロードが組立されたストリング（ｐ_１＋ｐ_２＋…ｐ_ｎ−１）に連結して追加されたペイロードが組立されたストリング（ｐ_１＋ｐ_２＋…ｐ_ｎ−１＋ｐ_ｎ）を生成する。

（Ｄ）第４段階（フローテーブル管理段階）は、ハングルまたは日本語文字列が多数のＨＴＴＰパケットに跨っているとき（すなわち、パケットがフローに受け渡されるとき）、最初のＨＴＴＰパケットが応答パケットであり、ハングルまたは日本語変換が可能な場合に後続する予定の同一フローのパケットを直ちにペイロード組立するためにフローテーブルを挿入、維持、削除する段階である。すなわち、パケットがフローの最後のパケットである場合にフローテーブルを初期化して終了し、最後のパケットではない場合にフローテーブルを更新し、前記１段階（フロー分析段階）に移行する。

受信されたパケットが最後のパケットである場合（すなわち、パケットのＴＣＰヘッダーにＦＩＮフラグが設定された場合）、これをフローテーブルの削除予約フラグに記録しておき、この記録の有無を確認することによりパケットが最後のパケットである場合にフローテーブルを削除（初期化）する。また、もし、フロー維持時間フィールドがある場合、後続パケットが所定のフロー維持時間（例えば、３０秒）内に受信されなければデコードを終了し、フローテーブルを削除（初期化）することができる。

以上の過程を通じて受信されたパケットのペイロードを組立することが可能になり、フローの最後のパケットのペイロードまで組立された後にはフローテーブルの全ての情報が削除（初期化）される。

（Ｅ）第５段階（圧縮解凍／デコード段階）は、所定のフローのペイロード組立が完了された後にこれを一括してデコードする段階である。

すなわち、前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットが圧縮されたものであれば、フローの最後のパケットまで組立されたフローのペイロードの圧縮を解凍した後にハングルまたは日本語にデコードし、圧縮されたものではなければ、ボディをそのままハングルまたは日本語にデコードする。デコード方法の詳細については後述する。

本発明の請求項１は第５段階までに関するものであり、請求項５は第６段階（コンテンツ分析段階）が追加されたものである。

（Ｆ）第６段階（コンテンツ分析段階）は、上述した過程によりデコードされたハングルまたは日本語ウェブコンテンツと所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析する段階である。詳細は後述する。

図示はしないが、上述したハングルまたは日本語のデコード方法（第１段階〜第５段階）は、（Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の適合性分析部に伝達し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記のペイロード組立格納部に伝達するヘッダー分析部と、（Ｂ）前記パケットのＨＴＴＰヘッダーまたはボディの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後に下記のペイロード組立格納部に伝達し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する適合性分析部と、（Ｃ）前記適合性分析部においてＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能であると分析されたパケットのペイロードを格納し、前記ヘッダー分析部において最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在すると確認されたパケットのペイロードを既存に格納されている当該フローの組立されたペイロードに連結してフローを組立するペイロード組立格納部と、（Ｄ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新するフローテーブル管理部と、（Ｅ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットが圧縮されたものであればフローの最後のパケットまで組立されたフローのペイロードの圧縮を解凍した後に前記フローのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする圧縮解凍／デコード部と、を備えるＨＴＴＰパケットのハングルまたは日本語デコード装置により行われうる。

一方、本発明においては、（１）上述したように、一旦所定のフローに相当するパケットの全てのペイロードを組立した後に圧縮有無を確認して圧縮を解凍する方式（図１）も採用可能であるが、（２）先ず、所定のフローが圧縮パケットであるかどうかを確認しておき、パケットのペイロードを組立した後に圧縮を解凍する方式も採用可能である。後者の方式に関するフローチャートを図２に示す。図２に例示する方式は、図１の方式に比べてやや複雑な構成であるものの、究極的に同じ概念に基づくものであり、同じ結果が得られる。図１についての説明部分を参照すれば、図２を容易に理解することができるため、さらなる説明を省略する。

図３は、本発明によるハングルまたは日本語のデコード方法及びその結果として得られたウェブコンテンツを分析する方法のさらに他の例を示す全体フローチャートである。これは、パケットごとにペイロードを順次にデコードし、直ちにパターンマッチングなどの方法によりコンテンツを分析する方式である。

図３の例において、フロー分析段階、適合性分析段階及びフローテーブル管理段階は図１の例と同様であるため、それについての説明を省略し、圧縮解凍／デコード段階（第３段階）及びパターンマッチング段階（第４−１段階）についてのみ説明する。

（Ａ）第１段階（フロー分析段階）は、図１と同様である。

（Ｂ）第２段階（適合性分析段階）は、図１と同様である。

（Ｃ）第３段階（圧縮解凍／デコード段階）は、パケットが圧縮されたものであればパケットペイロードの圧縮を解凍した後に、また、圧縮されたものでなければそのまま前記パケットのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする段階である。すなわち、フローを組立せずにパケット別に直ちにデコードする。このため、この段階においてデコードされたコンテンツはフロー全体が保有したコンテンツの一部（部分）となる。

（Ｄ）第４−１段階（パターンマッチング段階）は、パケット別ペイロードがデコードされたハングルまたは日本語ウェブコンテンツの一部に対して所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析する段階である。

（Ｅ）第４−２段階（フローテーブル管理段階）は、図１と同様である。

この例によれば、特定の時点においてはコンテンツの一部に関する内容が分析されるものの、所定のフローに相当する全てのパケットが第３段階と第４−１段階を経ると、結局はフロー全体が有するウェブコンテンツに関する内容が分析される。これにより、結果は図１に例示する方式による結果と同様になる。

一方、２バイトにエンコードされたハングルまたは日本語文字列の上位１バイトと下位１バイトが分けられて相異なるパケットのペイロードに載せられて伝達される場合が発生する。この場合に鑑みて、フローテーブルのフィールドには１バイト格納空間が追加されることが好ましい。この場合、前パケット（ｎ−１番目）においてデコード後に最後の１バイトが残ると、これをフローテーブルの１バイト格納空間に格納しておく。次いで、次のパケット（ｎ番目）をデコードするときにフローテーブルの１バイト格納空間に上位１バイトが格納されているかを確認し、上位１バイトが存在すれば現在パケット（ｎ番目）の先頭に追加した後にデコードを行う。

本発明の第２段階（適合性分析段階）においては、フローの最初のパケットであり、且つ、前記パケットに対するフローテーブルが存在しない受信パケットが応答パケットであるか、及びハングルまたは日本語デコードが可能であるかを確認し、両方とも満足する場合にそのパケットに対するフローテーブルを生成する。もちろん、ヘッダー情報もなく、フローテーブルもないパケットであれば、いかなる措置なしに流れを終了する。

先ず、フローの最初のパケットがＨＴＴＰ応答パケットであるかどうかを確認する必要がある。

すなわち、ＨＴＴＰヘッダーに「ＨＴＴＰ／１．１ ２００ ＯＫ」というストリングを探索してＨＴＴＰ応答パケットの有無を調べる。参考までに、ＴＣＰ連結のための３段階ハンドシェーク方法により、ＨＴＴＰ要求パケット、それに対するサーバ側のＡＣＫが送られてきた後にユーザが要請したＨＴＴＰ応答パケットが伝送される。

次いで、受信されたＨＴＴＰ応答パケットに対してＨＴＴＰのヘッダーとペイロードの情報のうち一部を抽出してハングルまたは日本語デコードが可能であるか、及び可能であれば、どのエンコード型であるかを調べる。確認されたエンコード型はフローテーブルの当該フィールドに記録される。

例えば、ＨＴＴＰヘッダーにシグニチャー１（「Content-Type：ＸＸＸ」及び｛「charset＝ＹＹＹ」または「encoding＝ＹＹＹ」｝、ここで、ＸＸＸが「ｔｅｘｔ／ｈｔｍｌ」または「ｔｅｘｔ／ｘｍｌ」）が存在し、ＹＹＹが（１）ハングルエンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＫＲ、ｅｕｃ−ｋｒ、ＫＳ＿Ｃ＿５６０１またはｋｓ＿ｃ＿５６０１であるか、あるいは、（２）日本語エンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＪＰ、ｅｕｃ−ｊｐ、ＳＨＩＦＴ−ＪＩＳ、Ｓｈｉｆｔ−ＪＩＳまたはｓｈｉｆｔ−ｊｉｓである場合にそれぞれハングルまたは日本語エンコードが可能なパケットとして解釈する。ハングルまたは日本語エンコードが可能なパケットであることが認められた場合、前記パケットの情報を格納するフローテーブルを生成し、第３段階（ペイロード組立段階）に移行する。それ以外の場合、いかなる措置なしに終了する。

一方、デコードされるコンテンツのサイズ（長さ）を知る必要がある場合がある。コンテンツのサイズは「Content-Length:」と「Transfer-Encoding:chunked」を通じて求めることが可能である。前者からはコンテンツの長さを直ちに求めることが可能であるのに対し、後者の場合にはコンテンツと関連するパケット（すなわち、フロー）を受信し終わった後に求めることができる。例えば、Content-LengthはＨＴＴＰヘッダーフィールドのうちコンテンツの長さを直接的に表示するフィールドであり、「Content-Length：ＺＺＺ」のように表現され、コンテンツの長さが「ＺＺＺ」バイトであることを意味する。Transfer-Encodingについては、圧縮解凍と関連する部分において説明する。

要するに、本発明において、デコード適合性分析段階は、受信されたパケットが応答パケットであるか、及びハングルまたは日本語デコードが可能であるかを調べて、これに相当するパケットだけをろ過する過程である。ハングルまたは日本語をどのエンコード方式を用いてエンコードしたかを調べ、所定の条件を満足するパケットに対しては、出発地ＩＰアドレス、目的地ＩＰアドレス、出発地ポート番号、目的地ポート番号、削除予約フラグ、フロー維持時間、使用されたエンコード型、ＨＴＴＰパケットのペイロード長、圧縮有無フラグ情報などが格納されたフローテーブルを生成する。

本発明において、ペイロード組立段階は、上述した適合性分析段階を経たパケットのフローに相当する全てのパケットのペイロードをパケット順序に従い連結して格納する段階である。その詳細は上述の通りである。

図４は、本発明の圧縮解凍／デコード段階の一例を示す詳細フローチャートである。

図１または図２の場合には、当該フローの全ての情報が組立された後に圧縮解凍／デコードされ、図３の場合には当該フローのパケット別に順次に圧縮解凍／デコードされる点で相違点があるが、実際に「圧縮解凍／デコード」は同様に行われるため、まとめて説明する。

（１）（圧縮解凍過程）圧縮解凍／デコード段階においては、先ず、現在パケットが圧縮されたパケットであるかどうかを検査する。これは、シグニチャー３（「Content-Encoding：ＹＹＹ」、ＹＹＹ＝「gzip」 or 「deflate」）の存否により判断する。「gzip」という文字列の代わりに「x-gzip」、「deflate」の代わりに「x-deflate」という文字列がきたときにもそれぞれgzip、deflateは同じ圧縮アルゴリズムであると理解する。シグニチャー３が存在する場合、フローテーブルに圧縮フラグを設定し、利用された圧縮アルゴリズムを記録する。

圧縮されているデータを解凍する上で最も重要なのは、データの無欠性とそのサイズである。また、未圧縮ＨＴＴＰフローであるとしても、完全なＨＴＭＬ／ＸＭＬ文書単位で分析をするためには、データのサイズを知ることは必要である。

ＨＴＴＰにおいて伝達しようとするデータのサイズは、上述したように、「Content-Length」（図４におけるシグニチャー１）フィールドと、「Transfer-Encoding」（図４におけるシグニチャー２）フィールドを用いてウェブブラウザーに知らせる。もし、ＨＴＴＰヘッダーにシグニチャー１が設定されていると、直ちにそのサイズを知ることができるため、次の段階に移行することができる（４００）。しかしながら、シグニチャー２が設定されていると、全体的にデータを検査していきながら、chunkデータのサイズと実際データ、chunk区切子を区分して格納しなければならない（４１０）。すなわち、シグニチャー２が設定されているＨＴＴＰパケットの場合にはヘッダーとペイロードを区分する区切子である
の形態で伝達される。このため、一つのフロー内においてそれぞれのchunkデータごとに１６進数形態のサイズ値を抽出して加算した値が実際に伝送しようとする総データのサイズとなる（４２０）。さらに、伝送するデータが最後である旨を知らせるために、当該パケットの最後の部分にシグニチャー３を一緒に載せて伝送する。もし、シグニチャー３がなければ、当該フローがパケットを完全に受信しなかったと判断し、当該フローは廃棄する（４３０）。上記の過程を経ると、ウェブサーバが伝送しようとするデータのサイズを知ることが可能になる。

データのサイズを知った後、圧縮アルゴリズムが適用されたデータに対して圧縮解凍過程を経る。ＨＴＴＰにおいて最も多用される圧縮アルゴリズムであるgzipは、１０バイトのgzipヘッダーフィールドと圧縮されたデータ、４バイトのＣＲＣ３２フィールド、４バイトのＩＳＩＺＥフィールドから構成されている。１０バイトのヘッダーフィールドのうちフラグの設定有無によってヘッダーと圧縮データとの間にさらにオプションフィールドがありうるが、ＨＴＭＬ／ＸＭＬを伝送するＨＴＴＰにおいては上述した基本的な部分だけを考慮すればよい。また、gzipは内部の圧縮データを生成するためにdeflateアルゴリズムを使用する。すなわち、そこにgzipヘッダーとその他のフィールドが付加されてgzipフォーマットの圧縮データが生成される。ほとんどのgzipとdeflateはZlib library(http://www.zlib.net、ＲＦＣ１９５０）を用いて圧縮し且つ解凍する。本発明においても、Zlib libraryを適用して圧縮を解凍することができる。

ＨＴＴＰパケットに適用された圧縮アルゴリズムがdeflateである場合、圧縮されたデータとそのデータサイズが正確であれば、Zlib libraryにおいて支援する関数を用いて圧縮を解凍することができる（４５０）。但し、いくつかのzlibヘッダーを含まずにデータを伝送するウェブサーバがあり、２バイトのZlibヘッダーを圧縮データの先頭に挿入して圧縮解凍を行う場合もある。

このような過程を経て圧縮されていたペイロードが圧縮解凍される。もちろん、受信されたパケットが圧縮されたものではなければ、圧縮解凍過程は省略される。

（２）（デコード過程）圧縮解凍されたり、最初から圧縮されていないペイロードをハングルまたは日本語にデコードする。図１または図２の場合、組立が完了されたフロー全体をデコードした後にパターンマッチングを行うことも可能であるが、フローをデコードすると同時にパターンマッチングを行うことでコンテンツ分析をすることも可能である。もちろん、図３の場合には、当然のことながら、パケット別に順次にデコードされた部分を直ちにパターンマッチングする。

もちろん、パケットがＵＴＦ−８などの多国語を支援するエンコード型であれば、エンコードされた３バイトを２バイトのユニコード値に変換する。

ハングルまたは日本語の有無は変換された２バイト値により判断する。（ａ）ユニコード文字コードチャート（http://www.unicode.org/charts/）を参照すれば、０ｘ１１００〜０ｘ１１ＦＦ（ハングル字母）、０ｘＦＦＡ１〜０ｘＦＦＤＣ（半角字母）、０ｘ３１３０〜０ｘ３１８Ｆ（ハングル互換字母）、０ｘＡＣ００〜０ｘＤ７ＡＦ（ハングル音節）がハングルを示すコード範囲であり、（ｂ）０ｘ３０４０〜０ｘ３０９Ｆ（ひらがな）、０ｘ３０Ａ０〜０ｘ３０ＦＦ（カタカナ）、０ｘＦＦ００〜０ｘＦＦＥＦ（全角ローマ字及び半角カタカナ）、０ｘ４Ｅ００〜０ｘ９ＦＡＦ（ＣＪＫ統合漢字−共通及び非共通漢字）、０ｘ３４００〜０ｘ４ＤＢＦ（ＣＪＫ統合漢字拡張漢字Ａ集合-非常用漢字）が日本語を示すコード範囲である。

デコードされた２バイトがこの範囲内のコード値を有している場合、若しくは、ユニコードテーブルを参照可能な場合、ＵＴＦ−８でエンコードされた文書がハングルまたは日本語を含んでいるかどうかを知ることができる。すなわち、下記表１に示す方式によりエンコードが行われる。

例えば、パケット内において「上」という文字はＥＣ９Ｃ８４の３バイトで表現され、二進数としては１１１０１１００ １００１１１００ １００００１００で表現される。太字だけを組み合わせると、１１００−０１１１−００００−０１００のようになり、１６進数で表現すれば、Ｃ７０４の「上」（Ｕ＋Ｃ７０４）というユニコード値を有することが分かる。このような方式によりＵＴＦ−８においてハングルにデコードすることができる。

圧縮解凍／デコードを経たデータに対して、パターンマッチングを経るコンテンツ分析段階が行われる。

パターンマッチングは、上述したように、組立が完了されたフロー全体をデコードした後に行うことも可能であるが、フローをデコードすると同時に行うことも可能である。この過程は、大きく、キーワードを格納、管理するコンテンツ分類辞書と、コンテンツ分類関数若しくはアルゴリズムを活用して行われる。

（１）（コンテンツ分類辞書）コンテンツ分類のためのカテゴリ区分方法、区分数、各カテゴリに対応するキーワードの種類及び数などはユーザが任意に設定することができる。

例えば、大型ポータルサイトの分類を参照して、ショッピング／宅配、成人、株式／金融、インターネットコミュニティ、ゲーム、音楽、映画、メール／メッセンジャー、教育、ニュース／ウェブサービスなどにカテゴリを分類することができる。次いで、各カテゴリ別にキーワードを相互排他的に（すなわち、一つのキーワードは一つのカテゴリに割り付けられるように）選定して格納する。

このように選定／格納されたデータベースを「コンテンツ分類辞書」と称する。

ここでは、例示的に簡単なカテゴリ分類方法を提示（表２）し、例をとって説明する。表２においてはハングルだけで表現したが、日本語でも同じコンテンツ分類辞書を作成可能であることはいうまでもない。必要に応じて、英語などの他の言語よりなるキーワードも追加可能である。キーワードは、１カテゴリ当たりに１５〜２０個程度に選定することが良い。

（２）（分類関数／アルゴリズム）次いで、キーワードパターンマッチングによるコンテンツ分類が行われる。

パケットペイロードのデータを基にコンテンツを分類するこの方法は、基本的に、テキストデータの文書分類と一脈相通するといえる。すなわち、それぞれのカテゴリに属するキーワードがテキスト文書にいかに多く属しているかの情報を基にベイジアン学習若しくはＳＶＭなどの機械学習を用いてコンテンツを分析する。すなわち、ＨＴＭＬ／ＸＭＬ文書単位で統合されたパケットのペイロードにおいてキーワードマッチングを通じてカテゴリ別のキーワードマッチング頻度数を計算する。この情報を基にテキストデータを分類する上で最も良好な性能を発揮すると知られているアルゴリズムの一つであるベイジアン学習とＳＶＭ方法を用いて当該ＨＴＭＬ／ＸＭＬ文書単位のパケットがいかなるコンテンツを格納しているかを機械的に判断することになる。

一般的に、テキストデータマイニングにおいては、マシンランニングアルゴリズムに入れるデータをbags-of-wordsなどの方法を利用する。このような方法は高い正確度を提供するが、かなり長い演算時間を要する。

１カテゴリ当たりのキーワード数の違いが激しい場合、正規化の概念を適用してキーワードヒット数（マッチングされたカウント）を当該カテゴリの総キーワード数で割ることにより、下記表３に示すデータを得る。

−Ｎ：ハングルデコードを通じての総文書数（最後の文書番号）
−Ｋ：コンテンツカテゴリ総数（最後のカテゴリ番号）
−Ｆ_{ｓｉｍｐｌｅ}：当該文書内において最初に発見されたキーワードが属するカテゴリ
−文書の実際のカテゴリ番号：オプション。検証のためにマニュアル的に求めた当該文書の実際カテゴリ。

上記のデータを得た場合、下記のコンテンツ分類関数を利用することができる。

Ｆ_{ｓｉｍｐｌｅ}：当該文書内において最初に発見されたキーワードが属するカテゴリ
Ｆ_ｍａｘ：当該文書内において最も多いキーワードヒットを記録したカテゴリ
Ｆ_ｓｖｍ：上記のカテゴリ別ヒット数情報を基にＳＶＭマシンランニングアルゴリズムを通じて分類された結果

実際に必要な情報（正確度若しくは速度など）に合わせて分類関数を利用することができる。これは、全数調査若しくはサンプリングを通じて検証されたデータとの比較により決定すればよい。

Claims (9)

1. フロー情報が格納されるフローテーブルが介在されたハングルまたは日本語のデコード方法において、
   （Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の第２段階（適合性分析段階）に移行し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記の第３段階（ペイロード組立段階）に移行する第１段階（フロー分析段階）と、
   （Ｂ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後、下記の第３段階（ペイロード組立段階）に移行し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する第２段階（適合性分析段階）と、 （Ｃ）前記段階（Ｂ）においてＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能であると分析されたパケットのペイロードを格納し、前記段階（Ａ）において最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在すると確認されたパケットのペイロードを既存に格納されている当該フローのペイロードに連結してフローを組立する第３段階（ペイロード組立段階）と、
   （Ｄ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新して前記第１段階に移行する第４段階（フローテーブル管理段階）と、
   （Ｅ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、（１）前記パケットが圧縮されたものであれば、フローの最後のパケットまで組立されたフローのペイロードの圧縮を解凍した後、（２）圧縮されたものではなければそのまま前記フローのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする第５段階（圧縮解凍／デコード段階）と、
   を含んでなることを特徴とするＨＴＴＰパケットにおけるハングルまたは日本語のデコード方法。
2. 前記フローテーブルは、フローを識別可能な情報フィールド、削除予約フラグフィールド、フロー維持時間フィールド、ハングルまたは日本語エンコード型フィールド、ＨＴＴＰパケットのペイロード長フィールド及び圧縮有無フラグ情報フィールドを含むことを特徴とする請求項１に記載のＨＴＴＰパケットにおけるハングルまたは日本語のデコード方法。
3. 前記第２段階（適合性分析段階）において、
   ＨＴＴＰヘッダーにシグニチャー１（「Content-Type：ＸＸＸ」及び｛「charset＝ＹＹＹ」または「encoding＝ＹＹＹ」｝、ここで、ＸＸＸが「ｔｅｘｔ／ｈｔｍｌ」または「text/xml」）が存在し、ＹＹＹが（１）ハングルエンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＫＲ、ｅｕｃ−ｋｒ、ＫＳ＿Ｃ＿５６０１またはｋｓ＿ｃ＿５６０１であるか、（２）日本語エンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＪＰ、ｅｕｃ−ｊｐ、ＳＨＩＦＴ−ＪＩＳ、Ｓｈｉｆｔ−ＪＩＳまたはｓｈｉｆｔ−ｊｉｓである場合にフローテーブルを生成して第３段階（ペイロード組立段階）に移行することを特徴とする請求項１に記載のＨＴＴＰパケットにおけるハングルまたは日本語のデコード方法。
4. 請求項１から請求項３のいずれかに記載の方法を行うための装置であり、
   （Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の適合性分析部に伝達し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記のペイロード組立格納部に伝達するヘッダー分析部と、
   （Ｂ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後に下記のペイロード組立格納部に伝達し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する適合性分析部と、
   （Ｃ）前記適合性分析部においてＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能であると分析されたパケットのペイロードを格納し、前記ヘッダー分析部において最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在すると確認されたパケットのペイロードを既存に格納されている当該フローのペイロードに連結してフローを組立するペイロード組立格納部と、
   （Ｄ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新するフローテーブル管理部と、
   （Ｅ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットが圧縮されたものであればフローの最後のパケットまで組立されたフローのペイロードの圧縮を解凍した後に前記フローのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする圧縮解凍／デコード部と、
   を備えてなることを特徴とするＨＴＴＰパケットにおけるハングルまたは日本語のデコード装置。
5. 請求項１から請求項３のいずれかに記載の方法によりデコードされたハングルまたは日本語ウェブコンテンツと所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析することを特徴とするハングルまたは日本語ウェブコンテンツの分析方法。
6. フロー情報が格納されるフローテーブルが介在されたハングルまたは日本語ウェブコンテンツの分析方法において、
   （Ａ）受信されたパケットのヘッダーを分析して前記パケットがフローの最初のパケットであるかどうかを確認し、（１）最初のパケットである場合に下記の第２段階（適合性分析段階）に移行し、（２）最初のパケットではなく、且つ、前記パケットに対するフローテーブルが存在しなければ終了し、存在すれば下記の第３段階（圧縮解凍／デコード段階）に移行する第１段階（フロー分析段階）と、
   （Ｂ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、前記パケットがＨＴＴＰ応答パケットであると共に、ハングルまたは日本語デコードが可能なパケットであれば、前記パケットに対するフローテーブルを生成した後に下記の第３段階（圧縮解凍／デコード段階）に移行し、ＨＴＴＰ応答パケットではないか、あるいは、ハングルまたは日本語デコードが不可能なパケットであれば終了する第２段階（適合性分析段階）と、
   （Ｃ）前記パケットのＨＴＴＰヘッダーまたはペイロードの情報を参照して、（１）前記パケットが圧縮されたものであればパケットペイロードの圧縮を解凍した後、（２）圧縮されたものでなければそのまま前記パケットのＨＴＴＰペイロードのストリングからハングルまたは日本語をデコードする第３段階（圧縮解凍／デコード段階）と、
   （Ｄ）デコードされたハングルまたは日本語ウェブコンテンツと所定のキーワードセットとのパターンマッチングを行うことにより前記ウェブコンテンツの内容を分析する第４−１段階（パターンマッチング段階）と、
   （Ｅ）前記パケットがフローの最後のパケットである場合にフローテーブルを初期化し、最後のパケットではない場合にフローテーブルを更新し、前記第１段階に移行する第４−２段階（フローテーブル管理段階）と、
   を含んでなることを特徴とするＨＴＴＰパケットにおけるハングルまたは日本語ウェブコンテンツの分析方法。
7. 前記フローテーブルは、フローを識別可能な情報フィールド、削除予約フラグフィールド、フロー維持時間フィールド、１バイト格納空間フィールド、ハングルまたは日本語エンコード型フィールド、ＨＴＴＰパケットのペイロード長フィールド及び圧縮有無フラグ情報フィールドを含むことを特徴とする請求項６に記載のＨＴＴＰパケットにおけるハングルまたは日本語ウェブコンテンツの分析方法。
8. 前記第２段階（適合性分析段階）において、
   ＨＴＴＰヘッダーにシグニチャー１（「Content-Type：ＸＸＸ」及び｛「charset＝ＹＹＹ」または「encoding＝ＹＹＹ」｝、ここで、ＸＸＸが「ｔｅｘｔ／ｈｔｍｌ」または「ｔｅｘｔ／ｘｍｌ」）が存在し、ＹＹＹが（１）ハングルエンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＫＲ、ｅｕｃ−ｋｒ、ＫＳ＿Ｃ＿５６０１またはｋｓ＿ｃ＿５６０１であるか、あるいは、（２）日本語エンコード型であるＵＴＦ−８、ｕｔｆ−８、ＥＵＣ−ＪＰ、ｅｕｃ−ｊｐ、ＳＨＩＦＴ−ＪＩＳ、ｓｈｉｆｔ−ＪＩＳまたはｓｈｉｆｔ−ｊｉｓである場合にフローテーブルを生成し、第３段階（圧縮解凍／デコード段階）に移行することを特徴とする請求項６に記載のＨＴＴＰパケットにおけるハングルまたは日本語ウェブコンテンツの分析方法。
9. 前記第３段階（圧縮解凍／デコード段階）及び第４−２段階（フローテーブル管理段階）において、
   （ａ）前記パケット（ｎ）がフローの最後のパケットではない場合、ハングルまたは日本語デコードを行い、最後の１バイトが残留するときにこれをフローテーブルの１バイト格納空間に一時的に格納し、
   （ｂ）次のパケット（ｎ＋１）の処理時に前記一時的に格納された１バイト情報を次のパケット（ｎ＋１）のペイロード先端に添付した後にデコードすることを特徴とする請求項６に記載のＨＴＴＰパケットにおけるハングルまたは日本語ウェブコンテンツの分析方法。