(57)【要約】【課題】ＪＳＰなどにより動的コンテンツを生成する際の処理に要する時間を短縮することができる技術を提供する。【解決手段】動的コンテンツを作成するプログラムを生成する装置において、該装置を内部的にはテキストを所定の汎用的な文字エンコーディングにより表現して取り扱うものとし、該装置に対し、コンテンツの静的部分を構成するための静的テキストを含む所定のファイルに基づき、動的コンテンツを作成するプログラムを生成する手段と、静的テキストについての、コンテンツ用の文字エンコーディングによる文字コードの情報を、プログラムが利用できるように、予め用意する手段（ステップ３６、３７）とを設ける。【選択図】図３
2005332146.tif 000002
【特許請求の範囲】
【請求項１】
テキストを所定の汎用的な文字エンコーディングにより表現して、動的コンテンツを作成するプログラムを生成する装置であって、
コンテンツの静的部分を構成するための静的テキストを含む所定のファイルに基づき、動的コンテンツを作成するプログラムを生成する手段と、
前記静的テキストについての、前記コンテンツ用の文字エンコーディングによる文字コードの情報を、前記プログラムが利用できるように、予め用意する手段と、
を備える動的コンテンツ作成プログラムの生成装置。
【請求項２】
前記ファイルについて、前記文字コード情報の用意が可能か否かを判定する手段を有し、この手段により肯定的判定がなされたことに応答して、前記文字コード情報の用意が行われることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項３】
前記判定手段は、前記ファイルについて、前記コンテンツ用文字エンコーディングが決定的であるか否かを判定する手段を備え、この手段によって決定的であると判定されたことに応答して、肯定的判定を行うものであることを特徴とする請求項２に記載の動的コンテンツ作成プログラムの生成装置。
【請求項４】
前記判定手段は、集約関係にある複数の前記ファイルを、前記コンテンツ用文字エンコーディングを変更する命令を含まない第１分類のものと、それ以外のものとに分類する手段を備え、前記集約関係にある複数のファイルのすべてが前記第１分類に属し、かつそれらのファイルのすべてについて前記コンテンツ用文字エンコーディングが同一であることを条件として、それらのファイルについて、肯定的判定を行うものであることを特徴とする請求項２に記載の動的コンテンツ作成プログラムの生成装置。
【請求項５】
前記判定手段は、前記請求項４の肯定的判定を行わなかったことを条件として、前記集約関係にある複数ファイルのそれぞれを節として集約関係を示すグラフを作成し、該グラフ中の連結成分を求め、各連結成分のうち、連結成分内のすべてのファイルが、前記第１分類に属し、かつ単一のファイルとしてみた場合の前記コンテンツ用文字エンコーディングが同一であるものについては、その連結成分に属する各ファイルについて、肯定的判定を、該肯定的判定がなされなかったファイルから呼び出されるものでないことを条件として、行うものであることを特徴とする請求項４に記載の動的コンテンツ作成プログラムの生成装置。
【請求項６】
前記文字コード情報を予め用意する手段は、集約関係にある複数の前記ファイルから生成する各プログラムの実行コンテキストを考慮し、実行コンテキストに応じて、採用される前記コンテンツ用文字エンコーディングが変化するプログラムについては、実行時に採用される可能性のある前記コンテンツ用文字エンコーディング毎に、前記静的テキストの文字コード情報の用意を行うものであることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項７】
前記文字コード情報を予め用意する手段は、
集約関係にある複数の前記ファイルを、前記コンテンツ用文字エンコーディングを変更する命令を含まない第１分類のものと、それ以外のものとに分類する手段と、
集約関係にある複数の前記ファイルのそれぞれについて、その前記コンテンツ用文字エンコーディングを一意に決定することができる決定的ファイルであるか否かを判定する手段と、
集約関係にある複数の前記ファイルのそれぞれについて、その静的テキストについての前記コンテンツ用の文字コード情報が、そのファイルから生成されるプログラムの実行時に、該静的テキストを前記汎用的な文字エンコーディングによる表現から前記コンテンツ用文字エンコーディングによる表現にエンコードすることにより生成されるものであるか否かを判定する手段とを備え、
集約関係にある複数の前記ファイルのうち、前記決定的ファイルではなく、かつ前記実行時のエンコードを要するファイルから呼び出されるものでもないものについて、集約されていないファイルを根とする実行コンテキスト木を取得し、
すべてのファイルが前記第１分類に属する木、又は根のファイルに基づくプログラムが前記コンテンツ生成のための出力に関してバッファリングを行う木について、その根のファイルについての前記コンテンツ用文字エンコーディングをその木に属する全ファイルについて採用し、
かかる採用が行われたファイルについて、その静的テキストについての、採用されたコンテンツ用文字エンコーディングによる文字コード情報を、そのファイルから生成されるプログラムが利用できるように、予め用意するものであることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項８】
前記文字コード情報を予め用意する手段は、
集約関係にある複数の前記ファイルを、前記コンテンツ用文字エンコーディングを変更する命令を含まない第１分類のもの、前記コンテンツ用文字エンコーディングを決定的に変更する命令を含む第２分類のもの、及びそ前記第１分類及び第２分類以外の第３分類のものに分類する手段と、
集約関係にある複数の前記ファイルのそれぞれについて、前記コンテンツ用文字エンコーディングを一意に決定することができる決定的ファイルであるか否かを判定する手段と、
集約関係にある複数の前記ファイルのそれぞれについて、その静的テキストについての前記コンテンツ用の文字コード情報が、そのファイルから生成されるプログラムの実行時に、該静的テキストを前記汎用的な文字エンコーディングによる表現から前記コンテンツ用文字エンコーディングによる表現にエンコードすることにより生成されるファイルであるか否かを判定する手段とを備え、
集約関係にある複数の前記ファイルのうち、前記決定的ファイルではなく、かつ前記実行時のエンコードを要するファイルから呼び出されるものでもないものについて、集約されていないファイルを根とする実行コンテキスト木を取得し、
それらの木のうち、すべてのファイルが前記第１分類に属する木ではないという条件、根のファイルに基づくプログラムが前記コンテンツ生成のための出力に関して有限のバッファサイズによるバッファリングを行い、バッファが満たされたときに例外を投げる木であるという条件、及び、前記第３分類のファイルから呼ばれるファイルを除去した後、最も後で最も深いファイルが前記第２分類に属する木であるという条件をすべて満たすものについて、該最も後で最も深いファイルの前記コンテンツ用文字エンコーディングをその木に属する全ファイルについて採用し、
かかる採用が行われたファイルについて、その静的テキストについての、採用されたコンテンツ用文字エンコーディングによる文字コード情報を、そのファイルから生成されるプログラムが利用できるように、予め用意するものであることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項９】
前記ファイルが、所定の複数言語について共通の意味を有するものとして規定された国際コードであって、該コードに対応する前記複数言語それぞれの文字コードがリソースとして用意されているものを含むことを条件として、そのファイルを、前記リソース、及び前記複数言語のうちの指定された言語に基づき、前記国際コードを前記静的テキストで表現した形式に変換する手段を有することを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項１０】
前記文字コード情報の用意を行うことができないファイルについては、該文字コード情報が、そのファイルから生成されるプログラムの実行時に、該静的テキストを前記汎用的な文字エンコーディングによる表現から前記コンテンツ用文字エンコーディングによる表現にエンコードすることによって作成されるように前記プログラムの生成を行うことを特徴とするする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項１１】
前記静的テキストについての文字コード情報の用意は、前記汎用的文字エンコーディングによる表現にデコードされた前記静的テキストを、前記コンテンツ用の文字エンコーディングによる表現にエンコードすることにより行われることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項１２】
前記文字コード情報の用意は、前記静的テキストについてのエンコーディングが前記ファイルにおけるものと、前記コンテンツにおけるものとで同一であることを条件として、前記ファイルにおける静的テキストをそのまま用いることによって行われることを特徴とする請求項１に記載の動的コンテンツ作成プログラムの生成装置。
【請求項１３】
コンピュータを、請求項１の装置として機能させることを特徴とする動的コンテンツ作成プログラムを生成するためのプログラム。
【請求項１４】
テキストを所定の汎用的な文字エンコーディングにより表現して、動的コンテンツを作成するプログラムを生成する方法であって、
コンテンツの静的部分を構成するための静的テキストを含む所定のファイルに基づき、動的コンテンツを作成するプログラムを生成する手順と、
前記静的テキストについての、前記コンテンツ用の文字エンコーディングによる文字コードの情報を、前記プログラムが利用できるように、予め用意する手順と、
を備える動的コンテンツ作成プログラムの生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツの静的部分を構成するための静的テキストを含む所定のファイルに基づき、動的コンテンツを作成するプログラムを生成する装置、プログラム、及び方法に関する。
【背景技術】
【０００２】
従来、サーバがクライアントに提供する動的Ｗｅｂページの設計を容易化する技術の１つとして、ＪＳＰ（ジャバサーバページ；Ｊａｖａ（登録商標）Ｓｅｒｖｅｒ  Ｐａｇｅｓ）技術が知られている（非特許文献１参照）。ＪＳＰは言わばＪａｖａ（登録商標）プログラムが埋め込まれたＨＴＭＬページである。ＪＳＰは、Ｗｅｂサーバに配置しておくことにより、クライアントからのリクエストに応じ、Ｊａｖａ（登録商標）プログラムが展開されたＨＴＭＬページをクライアントに提供する。すなわち、ＪＳＰは最初のリクエストがあったとき、サーブレット形式のＪａｖａ（登録商標）コードにコンパイルされ、実行される。その後は、コンパイルされた状態でメモリに常駐し、２度目以降のリクエストに対しては、直ちに実行されることになる。
【０００３】
ＪＳＰではJavax.servlet.jsp.JSPWriterオブジェクトが、変数名をoutとして陰に存在する。すべての出力はこのオブジェクトを通し、ＨＴＴＰレスポンスとしてクライアントへ送られる。出力が直接Javax.servlet.http.HTTPServletResponseオブジェクトの出力ストリームに書き込まれることはない。その理由のひとつは、出力をバッファリングする必要性にある。すなわち、ＪＳＰでは既に実行した出力をキャンセルして別の処理を行う場合がある。例えば<jsp:forward
page=”foo.jsp”>の実行に際しては、これを実行する以前の出力をキャンセルし、foo.jspに制御を移す。そのような場合のため、出力を直ちに送出することなく、バッファに蓄積しておく必要がある。
【０００４】
さらに、JSPWriterはJava.io.OutputStreamのサブクラスではなく、Java.io.Writerのサブクラスである。つまりJSPWriterがバッファに蓄える内容は、バイト配列ではなく、文字配列である。文字配列で蓄積するようにした理由は、一般には、ＪＳＰから変換され、コンパイルされるサーブレットは、どのようなコード変換を行ってHTTPServletResponseオブジェクトの出力ストリームに書込みを行うかが分からないことにある。
【０００５】
例えば図３６のようなfoo.jspが、図３７のようなbar.jspをインクルード（include）していたとする。このとき、初期の文字コードはfoo.jspによって指定されたＩＳＯ−８８５９−１であるが、bar.jspはバッファがフラッシュされていない限り、ＪＳＰの仕様上、それをシフトＪＩＳに変更することが可能である。以上のような理由により、ＪＳＰではテキストをバイト配列ではなく文字配列として扱っている。
【０００６】
つまり、通常のＪＳＰにおいては各国語のための文字コードセット、例えば日本語の場合ではシフトＪＩＳ等が、国際化対応ＪＳＰの多くにおいてはＵＴＦ８が、ページ文字エンコーディング及び応答文字エンコーディングのいずれか又は双方に使用される。これに対し、Ｊａｖａ（登録商標）内部では、ＵＴＦ１６が文字エンコーディングに使用される。このため、ＪＳＰがコンパイルされるとき、ＪＳＰ内のテキストはＵＴＦ１６に変換される。したがって、ＪＳＰの実行に際しては、応答毎に、応答文字エンコーディングを行う必要がある。
【０００７】
【非特許文献１】マーク・ロス（MarkRoth）他１名、「ジャバ・サーバ・ページ仕様書バージョン２．０（JavaServer PagesTM SpecificationVersion2.0）」、［online］、平成１５年１１月２４日、サン・マイクロシステム（Sun Microsystems Inc.）、［平成１６年４月２９日検索］、インターネット＜ＵＲＬ：http://www.jcp.org/aboutJava/communityprocess/first/jsr152/index2.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００８】
上述のように、実行時におけるＪａｖａ（登録商標）プログラムでは、外部においてはバイトストリームで表現されている文字を文字ストリームに変換して処理するようにしている。このため、ドキュメントを出力する際には、文字ストリームを、各アプリケーション特有の文字セットに変換する必要がある。この、応答文字エンコーディングには、意外に多くの時間を要している。これが、ＪＳＰの実行速度を低下させる要因のひとつとなっている。
【０００９】
本発明の目的は、このような従来技術の問題点に鑑み、ＪＳＰなどにより動的コンテンツを生成する際の処理に要する時間を短縮することができる技術を提供することにある。
【課題を解決するための手段】
【００１０】
本発明に係る動的コンテンツ作成プログラムの生成装置及び方法は、内部的にはテキストを所定の汎用的な文字エンコーディングにより表現して取り扱い、コンテンツの静的部分を構成するための静的テキストを含む所定のファイルに基づき、動的コンテンツを作成するものである。そして上記の目的を達成するため、本発明は、静的テキストについてのコンテンツ用の文字エンコーディングによる文字コードの情報を、プログラムが利用できるように、予め用意することを特徴とする。また、本発明に係るプログラムは、かかる装置としてコンピュータを機能させることを特徴とする。
【００１１】
ここで、動的コンテンツ作成プログラムとしては、たとえばＪＳＰ（ジャバ・サーバ・ページ）コンパイラが該当する。動的コンテンツとしては、たとえばＨＴＭＬやＸＭＬで記述された動的Ｗｅｂコンテンツが該当する。所定のファイルとしては、たとえばＪＳＰファイルが該当する。所定の汎用文字エンコーディングとしては、例えばＵＴＦ−１６が該当する。コンテンツ用の文字エンコーディングとしては、たとえばＩＳＯ−８８５９−１や、ＵＴＦ−８、シフトＪＩＳが該当する。
【００１２】
この構成において、ファイルからプログラムを生成するとき、入出力以外の内部的処理においてはテキストを所定の汎用的文字エンコーディングにより表現して扱うようにしている。このため、従来、プログラムの生成時には、ファイルの静的テキストを、該汎用的文字エンコーディングによる表現にデコードし、これを用いて該静的テキストを出力するプログラム部分を作成するとともに、プログラムの実行により動的コンテンツを生成するときには、該静的テキストを、該汎用的文字エンコーディングによる表現から、コンテンツ用の文字エンコーディングによる表現にエンコードするようにしていた。このため、プログラムの生成後、生成したプログラムを繰り返し実行する場合には、実行毎に該エンコードが行われていた。
【００１３】
これに対し、本発明によれば、静的テキストについてのコンテンツ用文字エンコーディングによる文字コードの情報を、プログラムが利用できるように、予め用意することができるようにしたため、作成されるプログラムは、この文字コード情報を利用することにより、コンテンツ用文字エンコーディングによる表現へのエンコードを行う必要なく、コンテンツの静的テキスト部分を出力することができる。したがって、生成されたプログラムが所定期間、繰り返し実行される場合、動的コンテンツを作成する際の処理に要する時間を短縮することができる。
【００１４】
なお、文字コード情報の用意は、前記汎用的文字エンコーディングによる表現にデコードされた静的テキストを、コンテンツ用の文字エンコーディングによる表現にエンコードすることにより行うことができる。また、静的テキストについてのエンコーディングが前記ファイルにおけるものと、コンテンツにおけるものとで同一であることを条件として、ファイルにおける静的テキストを何ら変換することなくそのまま用いることによっても文字コード情報の用意を行うことができる。
【００１５】
本発明の好ましい態様においては、前記ファイルについて、文字コード情報の用意が可能か否かを判定し、肯定的判定がなされたことに応答して、文字コード情報の用意が行われる。この肯定的判定は、たとえば、前記ファイルについて、コンテンツ用文字エンコーディングが決定的であると判定されたことに応答して行われる。
【００１６】
肯定的判定はまた、集約関係にある複数のファイルを、コンテンツ用文字エンコーディングを変更する命令を含まない第１分類のものと、それ以外のものとに分類した場合、集約関係にある複数のファイルのすべてが第１分類に属し、かつそれらのファイルのすべてについてコンテンツ用文字エンコーディングが同一であることを条件として、それらのファイルについて、行われる。
【００１７】
この肯定的判定が行われなかった場合でも、集約関係にある複数ファイルのそれぞれを節として集約関係を示すグラフを作成し、該グラフ中の連結成分を求め、各連結成分のうち、連結成分内のすべてのファイルが、第１分類に属し、かつ単一のファイルとしてみた場合のコンテンツ用文字エンコーディングが同一であるものについては、その連結成分に属する各ファイルについて、肯定的判定を行うことができる。ただしこの肯定的判定は、該肯定的判定がなされなかったファイルから呼び出されるファイルでないことを条件として、行われる。
【００１８】
また、文字コード情報を予め用意する手段は、集約関係にある複数のファイルから生成する各プログラムの実行コンテキストを考慮し、実行コンテキストに応じて、採用されるコンテンツ用文字エンコーディングが変化するプログラムについては、実行時に採用される可能性のあるコンテンツ用文字エンコーディング毎に、静的テキストの文字コード情報の用意を行うものであってもよい。
【００１９】
たとえば、文字コード情報を予め用意する手段として、集約関係にある複数のファイルを、コンテンツ用文字エンコーディングを変更する命令を含まない第１分類のもの、コンテンツ用文字エンコーディングを決定的に変更する命令を含む第２分類のもの、並びに第１分類及び第２分類以外の第３分類のものに分類する手段と、集約関係にある複数のファイルのそれぞれについて、そのコンテンツ用文字エンコーディングを一意に決定することができる決定的ファイルであるか否かを判定する手段と、集約関係にある複数の前記ファイルのそれぞれについて、その静的テキストについての前記コンテンツ用の文字コード情報が、そのファイルから生成されるプログラムの実行時に、該静的テキストを前記汎用的な文字エンコーディングによる表現から前記コンテンツ用文字エンコーディングによる表現にエンコードすることにより生成されるものであるか否かを判定する手段とを備えるものを用いる。
【００２０】
そして、集約関係にある複数ファイルのうち、前記決定的ファイルではなく、かつ前記実行時のエンコードを要するファイルから呼び出されるものでもないものについて、集約されていないファイルを根とする実行コンテキスト木を取得し、すべてのファイルが第１分類に属する木、又は根のファイルに基づくプログラムがコンテンツ生成のための出力に関してバッファリングを行う木について、その根のファイルについてのコンテンツ用文字エンコーディングをその木に属する全ファイルについて採用し、かかる採用が行われたファイルについて、その静的テキストについての、採用されたコンテンツ用文字エンコーディングによる文字コード情報を、そのファイルから生成されるプログラムが利用できるように、予め用意する。
【００２１】
あるいは、集約関係にある複数ファイルのうち、前記決定的ファイルではなく、かつ前記実行時のエンコードを要するファイルから呼び出されるものでもないものについて、集約されていないファイルを根とする実行コンテキスト木を取得し、それらの木のうち、すべてのファイルが第１分類に属する木ではないという条件、根のファイルに基づくプログラムが前記コンテンツ生成のための出力に関して有限のバッファサイズによるバッファリングを行い、バッファが満たされたときに例外を投げる木であるという条件、及び、第３分類のファイルから呼ばれるファイルを除去した後、最も後で最も深いファイルが第２分類に属する木であるという条件をすべて満たすものについて、該最も後で最も深いファイルの前記コンテンツ用文字エンコーディングをその木に属する全ファイルについて採用し、かかる採用が行われたファイルについて、その静的テキストについての、採用されたコンテンツ用文字エンコーディングによる文字コード情報を、そのファイルから生成されるプログラムが利用できるように、予め用意する。
【００２２】
前記ファイルが、所定の複数言語について共通の意味を有するものとして規定された国際コードであって、該コードに対応する前記複数言語それぞれの文字コードがリソースとして用意されているものを含むものであることを条件として、そのファイルを、前記リソース、及び前記複数言語のうちの指定された言語に基づき、前記国際コードを静的テキストで表現した形式に変換することにより、本発明を適用することができる。
【００２３】
なお、文字コード情報の用意を行うことができないファイルについては、従来の場合と同様に、該文字コード情報が、そのファイルから生成されるプログラムの実行時に、該静的テキストを汎用的文字エンコーディングによる表現からコンテンツ用文字エンコーディングによる表現にエンコードすることによって作成されるようにプログラムの生成が行われる。
【発明の効果】
【００２４】
本発明によれば、予め用意された文字コード情報を利用することにより、プログラムはコンテンツ用文字エンコーディングへのエンコードを行う必要なく、コンテンツの静的テキスト部分を生成することができる。したがって、生成されたプログラムが所定期間、繰り返し実行される場合、動的コンテンツを作成する際の処理に要する時間を短縮することができる。
【００２５】
たとえば、ＪＳＰの場合、直接Servletにより応答の出力ストリームに書き込む場合に比べ、応答文字エンコーディングによる表現へのエンコード処理が余分に必要となっているが、全体に占めるエンコード処理の割合が１０％、出力文書に占めるテンプレート・テキストの割合が９０％であると仮定すれば、本発明により９％程度の速度向上を期待することができる。しかも本発明を適用するためのアプリケーションの変更は一切必要がない。
【発明を実施するための最良の形態】
【００２６】
図１は本発明の一実施形態に係る動的コンテンツ作成プログラム生成装置を用いた動的コンテンツ生成装置のシステム構成を示す。このシステムは、ＪＳＰ、サーブレット等で構成されるＷｅｂモジュール１、ＪＳＰからＪＳＰページ・サーブレットを生成するＪＳＰコンパイラ２、ＪＳＰページ・サーブレットを起動するＪＳＰサーブレット３、クライアントからの要求に応じ、ＪＳＰサーブレット３を起動するサーブレット・コンテナ４、サーブレットのソースコードをバイトコードにコンパイルするＪａｖａ（登録商標）コンパイラ５を備える。バイトコードはＪａｖａ（登録商標）仮想マシン６によって実行される。Ｊａｖａ（登録商標）仮想マシン６は、ＯＳ７に依存することなくＪａｖａ（登録商標）プログラムの動作を保証するものである。
【００２７】
図２は図１のシステムが稼動し得るコンピュータのハードウェア構成を示す。このコンピュータは、プログラムに基づくデータ処理や各部の制御を行う中央処理装置２１、中央処理装置２１が実行中のプログラムや関連するデータを高速にアクセスできるように記憶する主記憶装置２２、プログラムやデータを記憶する補助記憶装置２３、入力装置や出力装置を接続するための入出力インタフェース２４、外部の通信回線へ接続するための通信インタフェース２５等を備える。補助記憶装置２３には図１の処理システム１を構成する各ソフトウェアやデータベースがインストールされている。
【００２８】
クライアントからの要求を受信すると、サーブレット・コンテナ４は、ＪＳＰサーブレット３を起動する。ＪＳＰサーブレット３はＪＳＰから生成されるＪＳＰページ・サーブレットを起動する。ＪＳＰページ・サーブレットの実行により、動的コンテンツが生成される。生成された動的コンテンツは、サーブレット・コンテナ４を経て、クライアントに送られる。
【００２９】
このようなＪＳＰの実行により生成されるコンテンツにおいて、動的に変化する部分以外の不変の部分を生成するＪＳＰ部分はテンプレート・テキストと呼ばれる。文字数で考えれば、出力されるＨＴＭＬ等の文書の大部分はテンプレート・テキストによって占められている。そこで本実施形態においては、テンプレート・テキストのコード変換を省略することにより処理速度を向上させるようにしている。なお、実行時にアプリケーション・ロジックの結果としてＪＳＰから参照されるオブジェクトや即値については、何度も参照されるならばコード変換を初回のみにして２回目以降は省略することも考えられる。しかしこれについては、全体の効率改善への寄与度は小さいことが予想されるので、行わない。
【００３０】
以下、ＪＳＰから生成されるサーブレットを「ＪＳＰページ・サーブレット」という。また、実際のサーブレット・コンテナ４においてＪＳＰページ・サーブレットを生成し、それにフォワードするサーブレットを「ＪＳＰサーブレット」という。従来技術によって生成され、実行されるＪＳＰページ・サーブレットを「通常ＪＳＰページ・サーブレット」という。本発明に従って生成され、実行される、応答文字エンコーディングの省略がなされたＪＳＰページ・サーブレットを「最適化ＪＳＰページ・サーブレット」という。
【００３１】
本実施形態では、include等を伴わず、単体で実行されるＪＳＰから最適化ＪＳＰページ・サーブレットを生成する。まず、ＪＳＰが使用する応答文字エンコーディングを決定する。このエンコーディングとして何を用いるかについっては、ＪＳＰの仕様書により定められている。例えばＪＳＰ２．０の場合には、仕様書の第４章において規定されているものを用いる。また同時に、ＪＳＰ自身のコード化に用いられているページ文字エンコーディングが何であるかを決定する。この決定は、ＪＳＰの仕様書に定められているアルゴリズムに従って行うことができる。以下では前者のエンコーディングをresponseEncoding、後者をpageEncodingとする。
【００３２】
次に、実際にＪＳＰサーブレットから最適化ＪＳＰサーブレットを生成する。その際、従来技術と異なるのは_jspServiceメソッドを生成する部分である。図３はこの_jspServiceメソッドの生成アルゴリズムを示す。まず、このメソッドの局所変数outには、JSPWriterではなく、バイト配列のプリントが可能なWriterインスタンスが代入されるようにする（ステップ３１）。このクラスを仮にJSPWriterOutputStreamと呼ぶことにする。このJSPWriterOutputStreamクラスは例えば図４のようなＡＰＩになる。このＡＰＩでは、このクラスをインスタンス化した後、応答文字エンコーディングを管理するためのプロパティcharacterEncodingに対し、最初に決定した変数responseEncodingを与えるようにしている。
【００３３】
次に、ＪＳＰから字句を読み取り（ステップ３２）、読み取った字句がテンプレート・テキスト以外の場合には、通常ＪＳＰページ・サーブレットの場合と同様なコンパイルを行う（ステップ３４、３５）。なお、変数outが示すJSPWriterOutputStreamオブジェクトはJSPWriterの型を有する。このため、従来のＪＳＰプロセッサによるコンパイルに際してエラーが発生しなかったＪＳＰについては、本発明に従ったＪＳＰプロセッサによる場合でもコンパイル・エラーなどは起こり得ない。
【００３４】
一方、読み取った字句がテンプレート・テキストである場合には、そのテキストに基づき、バイト配列を作成する（ステップ３４、３６）。この作成は、次のいずれかの方法で行うことができる。第１の方法は、ＪＳＰパーザがＪＳＰ内の文字列を、pageEncodingを用いて文字型に変換した場合に適用することができる方法である。すなわち、Stringオブジェクト等に切り出されたテンプレート・テキストを、そのpageEncodingを用いてバイト配列に逆変換する。第２の方法は、pageEncodingとresponseEncodingとが同一である場合にのみ使用できる方法である。ＪＳＰ内のテンプレート・テキストに相当する領域を、文字型に変換せずにバイト型のまま、バイト配列として切り出す。
【００３５】
次に、作成したバイト配列を、変数outで示されるJSPWriterOutputStreamインスタンスのwrite(byte[])メソッドの引数に渡して出力するようにする（ステップ３７）。
【００３６】
ステップ３２〜３７の処理は、ファイルの終端（ＥＯＦ）を読み込むまで繰り返す（ステップ３３）。これにより、_jspServiceメソッドの生成が完了する。
【００３７】
以上では、抽象クラスJSPWriterOutputStreamとしてのＡＰＩのみを示したが、次に、具象クラスが実際にどのように動作するかを示す。まず、基底クラスJSPWriterでは抽象メソッドとなっており、テンプレート・テキスト以外の部分から呼ばれている各種printメソッドは、引数で与えられるプリント対象の値をcharacterEncodingでエンコードしてバイト配列に変換し、write(byte[])メソッドにフォワードする。例えば、print(Java.lang.String)メソッドの実装は図５のような単純なものになる。
【００３８】
また、write(byte[])メソッドは、ＪＳＰの仕様に従うように、出力がバッファされない場合には、HttpServletResponseオブジェクトのgetOutputStream()メソッドで得られるOutputStreamに対し、引数のバイト配列をそのまま書き込むようにする。
【００３９】
一方、出力がバッファされる場合は、出力を文字型ではなくバイト型でバッファ内に保持し、バッファサイズを超えたとき、autoFlush属性がtrueであれば、バッファの内容を同様に、HttpServletResponseオブジェクトのgetOutputStream()メソッドで得られるOutputStreamに書き込み、autoFlush属性がfalseであれば、基底クラスの場合の動作と同様にIOExceptionを投げる。
【００４０】
次に具体例として、実際にサーバ上のプログラム（サーブレット）としての集約関係のない典型的なＪＳＰが実行される様子を示す。図６は実行されるhelloworld.jspという名前のＪＳＰを示す。このＪＳＰのページ文字エンコーディング及び応答文字エンコーディングはシフトＪＩＳである。ＪＳＰの参照実装としてTomcatを用い、これに含まれるＪＳＰコンパイラであるJasperにより、helloworld.jspから図７のような_jspServiceメソッドを含む通常ＪＳＰページ・サーブレットのhelloworld_jspクラスを生成することができる。なお、図中のwrite文７１の引数が文字化けしてしまっているが、これはhelloworld_jspクラスのソースコードのエンコーディングが原因であり、実用上は問題ない。
【００４１】
このメソッド内で、write文７１の引数はStringオブジェクトであり、outで示されるJspWriterがフラッシュされると、応答文字エンコーディングを行わなければならない。そこで本発明に従った最適化ＪＳＰページ・サーブレットでは、write文７１を図８のように変換する。ここで、out変数がキャストされているJspWriterOutputStreamは前述のバイト配列を出力することが可能なクラスである。また、この例ではtmpという局所変数で表現しているが、write(byte[])メソッドの引数は、元のＪＳＰ中の"<p>こんにちは"という１行をシフトＪＩＳにエンコーディングした場合のバイト列である。このバイト配列を出力するメソッドを用いることによって、テンプレート・テキストを、各応答の生成毎に応答文字エンコーディングする必要をなくすることができる。
【００４２】
上述の実施形態では、ＪＳＰの応答文字エンコーディングが決定済みである場合について述べた。しかし、ＪＳＰが単体で実行されずに集約がなされ、かつ各ＪＳＰが別々の応答文字エンコーディングを用いるような複雑な場合では、応答文字エンコーディングを決定することは自明ではない。ＪＳＰにおける集約関係は、<jsp:include>、<jsp:doBody>、<jsp:invoke>等のＪＳＰタグや、Ｊａｖａ（登録商標）x.servlet.jsp.PageContext#include等のメッソド呼び出しによって表現される。次に、そのような一般の場合についても、実際のＪＳＰサーブレットが使用する応答文字エンコーディングを導出するようにした実施形態について説明する。
【００４３】
図９は本発明の他の実施形態に係るＪＳＰサーブレットの実行サイクルを示す。すなわちＪＳＰサーブレットは、まず初期化を行い（ステップ９１）、応答文字エンコーディングが単一である場合には（ステップ９２）、ＨＴＴＰリクエストを受け取る毎に（ステップ９３）、単一応答文字エンコーディング用のＪＳＰサーブレットの実行を繰り返す（ステップ９４）。一方、応答文字エンコーディングが複数の場合は、ＨＴＴＰリクエストを受け取る毎に（ステップ９５）、複数応答文字エンコーディング用のＪＳＰサーブレットの実行を繰り返す（ステップ９６）。
【００４４】
図１０は上述の初期化フェーズ（ステップ９１）の処理を示す。まず、ステップ１０１においてアプリケーション内のすべてのＪＳＰを３種類に分類する。ここでは説明の都合上、ブラック、グレイ、及びホワイトの３色に色分けして分類する。ただし、３種類に分類したのは、後述のさらに改良された実施形態の説明の都合上からである。したがって本実施形態では、グレイとブラックの代わりに、ホワイト以外のすべてを含むノンホワイトを用い、２種類に分類することも可能である。
【００４５】
ブラックは、図３７のbar.jspのように、応答文字エンコーディングを変更する命令を含むＪＳＰを意味する。ただし、ページ・ディレクティブのcontentType属性は、応答文字エンコーディングの初期値を設定することができるが、変更することはできないので、この命令には含まれない。例えば、<%@
page contentType="text/html; charset=Shift_JIS"%>は、応答文字エンコーディングを初期値としてシフトＪＩＳに設定できるが、すでに定まっている値を上書きして変更することはできないので、このディレクティブだけを含むＪＳＰはブラックではない。ＪＳＰ２．０の仕様では、応答文字エンコーディングを変更する命令として、Javax.servlet.HttpServletResponse#setCharacterEncoding(Java.lang.String)、及びJavax.servlet.HttpServletResponse#setLocale(Java.util.Lcale)がある。
【００４６】
グレイは、応答文字エンコーディングを変更する命令を含むが、if文やwhile文などによって、ある条件が成立した場合にのみその命令を呼ぶＪＳＰを意味する。上記setCharacterEcnodingやsetLocaleメソッドの引数が静的解析では判定できないものも、グレイに該当する。ただし、それらの不確定なメソッド呼出しの後に、決定的なメソッド呼出しによって応答文字エンコーディングが上書きされるものはブラックに分類される。
【００４７】
ホワイトは、応答文字エンコーディングを変更する命令を含まないＪＳＰを意味する。      
【００４８】
この色分けによる分類において、応答文字エンコーディング変更命令の検出は、単にそのようなメソッドの呼出しを、ＪＳＰファイルから文字列のマッチングによって探索するだけでは不十分であり、当然Ｊａｖａ（登録商標）プログラム解析技術を用いて行うようにする。プログラム解析を行うことができない部分、すなわちリフレクションが使用されている箇所等があった場合には、そのＪＳＰは保守的にグレイ（２種類に分類する場合はノンホワイトでもよい）に分類する。このプログラム解析はＪＳＰだけでなく、直接あるいはタグリブ等から参照されているクラスにも及ばせる必要がある。
【００４９】
次に、ステップ１０２へ進み、Ｗｅｂモジュール内のすべてのＪＳＰがホワイトで、かつその応答文字エンコーディングが同一であるかどうかを判定する。判定結果が肯定的である場合には、これらのＪＳＰを単一のＪＳＰとしてみた場合の問題に帰着させることができる。すなわち、すべてのＪＳＰを、応答文字エンコーディングが決定的である、決定的応答文字エンコーディングＪＳＰとする（ステップ１０３）。また、すべてのＪＳＰの応答文字エンコーディングが同一であるため、このようなＷｅｂモジュールを単一応答文字エンコーディングＷｅｂモジュールと呼ぶことにする。
【００５０】
Ｗｅｂモジュール内の各ＪＳＰの応答文字エンコーディングが同一でない場合には、集約関係があるＪＳＰについて、同一応答文字エンコーディングを用いる可能性に関して判定を行うために、色分けされた各ＪＳＰを節として、集約関係を示すグラフを作成する（ステップ１０４）。集約関係には集約する側とされる側の関係があるので、その関係を保存した有向グラフを作成する。このグラフをＤＧと呼ぶことにする。その際、必ずしも必要ではないが、後述の改良された実施形態の場合と同様に、１つのＪＳＰから発生するすべての有向辺に順番という属性をつけて作成するようにしてもよい。順番とは、ＪＳＰが集約される順番を意味する。言い換えれば、ＪＳＰファイル内で先にある集約アクションの方が上位になる辺を形成する。このようにして作られるＤＧには、正しく動作するＷｅｂアプリケーションの場合には、閉路が存在しないはずである。
【００５１】
ＤＧの有向辺を作成するためには、ＪＳＰから集約アクションを検出する必要がある。これを行うためには、先の応答文字エンコーディングにおける変更命令の検出の場合と同様に、文字列のマッチングのみでは不十分であり、プログラム解析を行う必要がある。その際に、非常に稀ではあるが、集約アクションの解析が不可能である場合や、集約アクションは検出できたが有向辺の行き先となるその引数が変数の場合があるかもしれない。このような集約アクションからは有向辺を作成することなく、そのＪＳＰをグレイ（２種類に分類する場合はノンホワイトでもよい）に変更する。
【００５２】
例えば、図３６及び図３７の２つのＪＳＰから作成されるＤＧは、図１１のような単純なものとなる。foo.jspの分類はホワイトであり、bar.jspの分類はブラックである。bar.jspはfoo.jspに集約されている。また、このfoo.jspが、図１２や図１３のようである場合には、集約されるＪＳＰへのパスが未決定であるため、ＤＧは図１４のようになる。有向辺は作成されず、foo.jspはグレイとされる。
【００５３】
ＤＧが完成した後、グラフ理論でいうところの連結成分を探す（ステップ１０５）。そして、その連結成分内のすべてのＪＳＰがホワイトであり、かつ単一のＪＳＰとしてみた場合の応答文字エンコーディングが同一であるかどうかを調べる（ステップ１０６）。つまり、集約するもの又はされるものによって応答文字エンコーディングが変更される可能性があるが、このような可能性を排除したうえで、応答文字エンコーディングを一意に決定することができるかどうかを調べる。これらの条件を満たすようなＪＳＰの集合は、応答文字エンコーディングが決定的である。したがって、これらのＪＳＰを決定的応答文字エンコーディングＪＳＰとする（ステップ１０７）。一方、上述の条件を満たさないＪＳＰの集合を非決定的応答文字エンコーディングＪＳＰとする（ステップ１０８）。すべての連結成分についてステップ１０６〜１０８の処理を完了したら、Ｗｅｂモジュールが複数の文字エンコーディングを要するものであるとして、初期化処理を終了する。
【００５４】
このようにして、初期化フェーズでは、Ｗｅｂモジュールが、（ａ）すべてのＪＳＰが単一の応答文字エンコーディングを使用する場合と、（ｂ）その他の場合、つまり複数の応答エンコーディングを使用する場合とに判別することができる。そして（ｂ）の場合には、Ｗｅｂモジュール内のすべてのＪＳＰを、決定的応答文字エンコーディングＪＳＰと非決定的応答文字エンコーディングＪＳＰとに分類することができる。
【００５５】
図１５は、上記（ａ）の場合に適用されるＪＳＰサーブレットの実行フェーズ（図９のステップ９４）を示す。まず、最適化ＪＳＰページ・サーブレットが生成済みか否かを判定する（ステップ１５１）。生成済みでないと判定した場合は、最適化ＪＳＰページ・サーブレットを生成し（ステップ１５２）、これを実行する（ステップ１５３）。生成済みであると判定した場合は、生成済みの最適化ＪＳＰページ・サーブレットを実行する（ステップ１５３）。このサーブレット実行フェーズが、図９のステップ９６におけるＪＳＰサーブレットの実行フェーズと異なる点は、最適化ＪＳＰページ・サーブレットの生成処理（ステップ１５２）における_jspServiceメソッドの生成手順にある。その手順は図３に示したとおりである。
【００５６】
図１６は、上記（ｂ）の場合に適用されるＪＳＰサーブレットの実行フェーズ（図９のステップ９６）を示す。まず、実行しようとしているＪＳＰが、従来技術により実行されるＪＳＰから集約されているものであるか否かを判定する（ステップ１６１）。この判定が真となるのは、実行しようとしているＪＳＰが、後述ステップ１６２の従来技術によるＪＳＰの実行処理において再帰的に呼ばれた場合である。この判定は、例えばrequestオブジェクトにomitEncoding属性をもたせ、それをフラグとして用い、それがfalseであるかどうかを調べることによって行うことができる。
【００５７】
この判定結果が真である場合には、本発明に従った文字エンコーディングの省略を適用することが不可能であるため、ＪＳＰの実行は従来の方法で行う（ステップ１６２）。つまり、通常ＪＳＰページ・サーブレットが生成済みでない場合はそれを生成して実行し、生成済みであれば生成済みのものを実行する。ただし、このステップ１６２の処理において、実行中のＪＳＰが集約するＪＳＰを従来技術により実行するか、又は本発明に従った文字エンコーディングの省略を適用して実行するかを上述ステップ１６１において判定するためのフラグをセットする。例えばrequestオブジェクトのomitEncoding属性をfalseにセットする。
【００５８】
ステップ１６１の判定結果が否定的である場合、実行対象のＪＳＰが上記図１０の初期化フェーズで決定した決定的応答文字エンコーディングＪＳＰに該当するか否かの判定を行う（ステップ１６３）。判定結果が否定的である場合、従来の方法でＪＳＰを実行する（ステップ１６２）。判定結果が肯定的である場合、すでにステップ１６５における最適化ＪＳＰページ・サーブレットの生成が行われたか否かを判定する（ステップ１６４）。既に生成が行われていれば、生成済みの最適化ＪＳＰページ・サーブレットを実行し（ステップ１６６）、生成が行われていない場合には、図１５のステップ１５２と同様の方法で、対象ＪＳＰを最適化ＪＳＰページ・サーブレットにコンパイルし（ステップ１６５）、これを実行する（ステップ１６６）。
【００５９】
ここで、同じＪＳＰでも、ステップ１６２のパス、又はステップ１６５及び１６６のパスという異なるパスを通る可能性がある。これらのパスで生成され、実行されるＪＳＰページ・サーブレットは、それぞれ通常ＪＳＰページ・サーブレット、及び最適化ＪＳＰページ・サーブレットという異なるサーブレットである。したがって、異なるクラス名を用いて一方が他方を上書き的に破壊したり、間違って実行したりしないように注意しなければならない。
【００６０】
次に具体例を用いて説明する。たとえば、図１７〜１９に示すそれぞれa.jsp、b.jsp、c.jspという集約関係があるＪＳＰについて、決定的応答文字エンコーディングＪＳＰであるか否かを判定すると（図１０のステップ１０１、１０２）、これら３つのＪＳＰはすべてホワイトであり、しかもその応答文字エンコーディングは唯一シフトＪＩＳに決まる。よってこれらのＪＳＰは、上述実施形態のように、単一のＪＳＰを実行する場合と同様にして実行することができる（図９のステップ９４）。
【００６１】
ところで、現存するＷｅｂアプリケーションにおいて、単一応答文字エンコーディングＷｅｂモジュールはかなり多く、またそれ以外のＷｅｂモジュールにおいても、決定的応答文字エンコーディングＪＳＰの割合はかなり大きい。したがって、単一応答文字エンコーディングＷｅｂモジュールや決定的応答文字エンコーディングＪＳＰに対してだけでも本発明の適用範囲はかなり広いと考えられる。しかし、さらに、その他のＪＳＰについても、次の実施形態によれば、さらに効率化を図ることが可能である場合が存在する。
【００６２】
図２６及び図２７は、図９のステップ９６の複数応答文字エンコーディング用ＪＳＰサーブレットにおけるserviceメソッドによる処理の別の実施形態を示す。すなわち、図２６及び図２７の処理は、図１６の処理を改良したものである。図２６のステップ２６１〜２６６の処理は、図１６のステップ１６１〜１６６の処理と同じである。改良部分は主に図２７に示されている。
【００６３】
ステップ２６３において、実行対象のＪＳＰが決定的応答文字エンコーディングＪＳＰであると判定された場合、ステップ２７１において、実行対象のＪＳＰは集約されて実行されるのか、又は根のＪＳＰかを判定する。この判定は、上述の図１６のステップ１６１及び１６２に関連して説明したフラグ判定方式で行ってもよい。あるいはこの判定は、ベースとする実行時ＪＳＰエンジンがJasperであるならば、その性質をも用いて、単にresponseオブジェクトがorg.apache.jasper.runtime.ServletResponseWrapperIncludeクラスであるか否かを調べることだけによって行うようにしてもよい。
【００６４】
ステップ２７１において実行対象のＪＳＰは集約されていないと判定した場合、ステップ２７２において、実行コンテキスト木を取得する。この処理の詳細は後述する。次に、ステップ２７３において、取得した木のＪＳＰがすべてホワイトかどうかを調べる。すべてホワイトである場合には、ステップ２７４において、この実行コンテキスト全体で使用される応答文字エンコーディングを、根ＪＳＰの応答文字エンコーディングに決定し、後のステップにおいて参照できるように保存する。この後、ステップ２７９へ進む。
【００６５】
ステップ２７３においてすべてホワイトではないと判定した場合には、ステップ２７５において、実行対象のＪＳＰでバッファリングを行うか否かを調べる。バッファリングを行わない場合、すなわちpageディレクティブのbuffer属性にnoneが指定されている場合にはステップ２７４へ進む。一方、バッファリングを行い、バッファを有限とし、それが満たされたときに例外を投げる場合、すなわちpageディレクティブのautoFlush属性にfalseが指定されている場合にはステップ２７６へ進む。また、バッファリングを行い、バッファを有限とし、バッファが満たされたときにそれをフラッシュする場合にはステップ２６２へ進む。仕様に基づけば、ＪＳＰの場合はバッファを無限とすることはできないが、仮に無限にバッファリングを行う場合にはステップ２７６へ進む。
【００６６】
ステップ２７６では、実行コンテキスト木から、グレイのＪＳＰから呼び出されるＪＳＰを取り除いた木を作成し、その木の中からホワイトでない、最も後ろで、最も深いＪＳＰを探す。すなわち、木の根のノードから始めて最後の子供のノードを繰り返したどっていって最後に見つかったものを抽出する。このアルゴリズムは自明である。そのＪＳＰがブラックの場合はステップ２７７へ進み、グレイの場合はステップ２６２へ進む。ステップ２７７では、ステップ２７６で得られたＪＳＰの応答文字エンコーディングを、実行コンテキスト全体で使用される応答文字エンコーディングとして決定し、ステップ２７４の場合と同様にして保存する。その後、ステップ２７９へ進む。
【００６７】
ステップ２７１において集約されていると判定した場合、ステップ２７８において、根ＪＳＰの実行におけるステップ２７４又は２７７で設定した応答文字エンコーディングを採用する。具体的には何もしなくてよい。その後、ステップ２７９へ進む。
【００６８】
ステップ２７９では、既に最適化ＪＳＰページ・サーブレットが生成済みか否かを判定する。生成済みであればそのままステップ２８１へ進む。生成済みでなければ、ステップ２８０において最適化ＪＳＰページ・サーブレットを生成してからステップ２８１へ進む。ステップ２８０におけるサーブレットの生成手順は、図３の場合とは異なる。この生成手順については後述する。
【００６９】
ステップ２８１では、テンプレート・テキストが、上記ステップ２７４、２７７、２７８で決定した応答文字エンコーディングでエンコードされていない場合に、その応答文字エンコーディングを用いてテンプレート・テキストをバイト配列にエンコードし、その応答文字エンコーディングに対応付けて定数表に登録する。この後、ステップ２６６において、ステップ２８０で生成したＪＳＰページ・サーブレットが実行されることになる。その際、そのＪＳＰについて上記ステップ２７４、２７７、２７８において決定された応答文字エンコーディングに対応する、前記定数表中のバイト配列が使用される。
【００７０】
図２８は、ステップ２８１で作成・更新され、ステップ２８０で作成される最適化ＪＳＰページ・サーブレットが利用する定数表として適当なものを示す。採用された応答文字エンコーディングは最適化ＪＳＰページ・サーブレットが参照可能な領域に記憶し、out.write文が参照する、定数表の列を決定することができるようにしておく。
【００７１】
図２９は図２７におけるステップ２８０の処理を示す。この処理では、応答文字エンコーディングが決定的ではないＪＳＰ、すなわち非決定的応答文字エンコーディングＪＳＰに対する最適化ＪＳＰページ・サーブレットを生成する。この生成処理では、決定的応答文字エンコーディングＪＳＰに対するＪＳＰページ・サーブレットの生成（図２６のステップ２６５）の場合とは、_jspServiceメソッドの生成部分が異なる。図２９中のステップ２９１〜２９５の処理は、図３のステップ３１〜３５と同じである。
【００７２】
ステップ２９４において、ＪＳＰから読んだ字句がテンプレート・テキストであるとの判定がなされると、ステップ２９６において、図２８のような定数表に新たな行又は列を追加し、そのテンプレート・テキストを登録する。このテンプレート・テキストは、後で図２７のステップ２８１において、バイト配列に変換され、変換結果が定数表に登録されるはずである。次に、ステップ２９７において、out.write(byte[])メソッドの部分を生成する。その際、定数表の行又は列を参照できるようにしておく。
【００７３】
上述の実行コンテキスト木取得処理（図２７のステップ２７２）について説明する。実行コンテキスト木を作成する方法は種々考えられるが、ここでは最も簡単な次の方法を採用する。実行コンテキスト木取得処理の前に、既に図９中のＪＳＰサーブレット初期化処理（ステップ９１）において、ＤＧ（有向グラフ）を作成（図１０のステップ１０４）する際に、すべての辺に対し順番という属性が付与されている。そこで、実行コンテキスト木取得処理では、ＤＧから実行対象のＪＳＰを１つ選び、そこから到達可能な成分としてのサブグラフを抽出する。正しく動作するＷｅｂアプリケーションから作られるＤＧには閉路が存在しないはずなので、このサブグラフは一般にはＤＡＧ（Ｄｉｒｅｃｔｅｄ  Ａｃｙｃｌｉｃ  Ｇｒａｐｈ；非循環グラフ）になるはずである。このＤＡＧが、木ではなく、複数の到来辺をもつＪＳＰが存在する場合には、そのＪＳＰに相当する節をコピーして木を作成する。最後に木の節の順序関係をＤＧの辺の順番に整理する。
【００７４】
図３０は、根を左、集約されたＪＳＰの列の呼び出される順番が上から下方向とした場合の木の一例を示す。この場合、図２７のステップ２７６における応答文字エンコーディングの導出時には、e.jsp及びf.jspはグレイのＪＳＰであるc.jspから呼び出されるので、無視される。この場合、d.jspが最下最内ＪＳＰとなる。
【００７５】
集約関係によって実行時に応答文字エンコーディングが変化する場合の具体例を示す。図２０〜２２のようなa.jsp、b.jsp、及びc.jspという３つのＪＳＰを例として説明する。この場合、a.jspを実行した場合とb.jspを実行した場合とでは応答文字エンコーディングが異なる。また、c.jspにとっていずれの応答文字エンコーディングを用いるかは、実行時にa.jsp又はb.jspのどちらから集約されるかが決まるまで判明しない。
【００７６】
そこで、この応答文字エンコーディングを決定するために、３つのＪＳＰを３種類の色のどれかに分類し、実行コンテキストの木を作成すると（図２７のステップ２７２）、それぞれ図２３及び図２４のようになる。この双方の木においてすべてのＪＳＰがホワイトであるため、実行コンテキスト全体で使用する応答文字エンコーディングは根の応答文字エンコーディング、つまり根がa.jspの場合はシフトＪＩＳ、b.jspの場合はＥＵＣＪＰとなる。
【００７７】
図２５はc.jspが、a.jsp又はb.jspのどちらから呼び出されても応答生成が可能なサーブレットの一例を示す。_jspServiceメソッドにおいて、部分２５１では、応答文字エンコーディングを示すresponseEncodingを取得するとともに、これに対応するインデックスresponseEncodingIndexを取得している。そして、部分２５２において、responseEncodingを用い、template_text_constant_pool中のresponseEncodingIndexに対応するエンコーディングにより表現されたバイト列をバッファに出力するようにしている。これにより、a.jspから呼び出された場合はシフトＪＩＳ、b.jspから呼び出された場合はＥＵＣＪＰにより表現されたバイト列を出力することができる。
【００７８】
次に、国際化ＪＳＰへの適応化を図った実施形態について説明する。クライアントの選択言語に応じて適切なメッセージ文字列を選んで応答文書を生成することができるＪＳＰ（以下、「国際化ＪＳＰ」という。）では、メッセージ文字列生成部分が、通常のＪＳＰとは異なり、テンプレート・テキストとはなっていない。多くの国際化ＪＳＰはＪＳＴＬ（ＪＳＰ標準タグ・ライブラリ）等の仕様に基づいた国際化タグ・ライブラリーを用いている。
【００７９】
例えば、図３１（ａ）及び（ｂ）のように、内容は同じであるが、表示言語がそれぞれ英語及び日本語であるＨＴＭＬ文書を、同一のＪＳＰによって生成させるためには、ＪＳＴＬ国際化タグを用いる場合、図３２のようなＪＳＰと、図３３のような言語リソースが必要となる。このような国際化ＪＳＰに対しては、テンプレート・テキストの割合が小さいので、上述各実施形態の手法をそのまま適用しても、効率改善を図ることができない。
【００８０】
一方、国際化タグを用いたＪＳＰの場合、国際化タグによるメッセージ生成の実行速度が、テンプレート・テキストの場合に比べ、圧倒的に遅い。そこで、実行時に国際化タグ部分をクライアント選択言語に応じてテンプレート・テキストに展開したローカル化ＪＳＰに変換することによって効率改善を図るようにした既存技術が存在する。
【００８１】
図３４はこの既存技術における処理の様子を示す。例えば図３２のような国際化ＪＳＰ３４１（hello.jsp）が要求された場合、クライアントの選択言語に応じ、図３５（ａ）や同図（ｂ）に示すような英語や日本語用にローカル化したＪＳＰ３４２（hello_en.jsp）や３４３（hello_ja.jsp）を生成し、これにフォワードするようにしている。ローカル化ＪＳＰ３４２及び３４３においては、国際化タグが存在しない分だけ、テンプレート・テキストの割合が大幅に増えている。
【００８２】
本実施形態では、上述各実施形態の技術に対し、このローカル化ＪＳＰ生成技術を組み合わせることによって、国際化ＪＳＰについても、Ｗｅｂページの生成速度を向上させるようにしている。具体的には、ローカル化ＪＳＰ３４２及び３４３に対して上述実施形態の応答文字エンコーディング省略を行うためのＪＳＰコンパイラ及び出力ストリームを適用する。このローカル化ＪＳＰに対する処理は、国際化されてない通常のＪＳＰに対する処理とまったく同様である。
【００８３】
なお、本発明は上述実施形態に限定されず、適宜変形して実施することができる。たとえば、上述においては、ＪＳＰサーブレットによってＪＳＰページ・サーブレットを起動するようにしているが、この代わりに、ユーザ自身がアプリケーションの配置前に、手動により、図９のステップ９１、９４、及び図１５のステップ１５２を行うことにより、ＪＳＰを予めＪＳＰページ・サーブレットにコンパイルしておき、サーブレット・コンテナがそのＪＳＰページ・サーブレットを直接起動するようにしてもよい。
【図面の簡単な説明】
【００８４】
【図１】本発明の一実施形態に係る動的コンテンツ作成プログラム生成装置を用いた動的コンテンツ生成装置のシステム構成を示す図である。
【図２】図１のシステムが稼動し得るコンピュータのハードウェア構成を示すブロック図である。
【図３】図１の構成においてＪＳＰサーブレットから最適化ＪＳＰサーブレットを生成する際の_jspServiceメソッドの生成アルゴリズムを示すフローチャートである。
【図４】図３のメソッドに用いられるＡＰＩを示す図である。
【図５】プリント対象の値をwrite(byte[])メソッドにフォワードするprint(Java.lang.String)メソッドの実装例を示す図である。
【図６】集約関係のない典型的なＪＳＰを例示する図である。
【図７】図６のＪＳＰから生成される通常ＪＳＰページ・サーブレットの一部を示す図である。
【図８】図６のＪＳＰから生成される本発明に従った最適化ＪＳＰページ・サーブレットのうち、図７のサーブレットと異なる部分を示す図である。
【図９】本発明の他の実施形態に係るＪＳＰサーブレットの実行サイクルを示すフローチャートである。
【図１０】図９のフローチャートにおける初期化フェーズの処理を示すフローチャートである。
【図１１】図３６及び図３７の２つのＪＳＰから作成されるＤＧを示す図である。
【図１２】ＤＧが図１４のようになる２つのＪＳＰのうちの一方を示す図である。
【図１３】ＤＧが図１４のようになる２つのＪＳＰのうちの他方を示す図である。
【図１４】図１２及び図１３のＪＳＰから作成されるＤＧを示す図である。
【図１５】ＷｅｂモジュールのすべてのＪＳＰが単一の応答文字エンコーディングを使用する場合に適用されるＪＳＰサーブレットの実行フェーズを示すフローチャートである。
【図１６】Ｗｅｂモジュールが複数の応答文字エンコーディングを使用する場合に適用されるＪＳＰサーブレットの実行フェーズを示すフローチャートである。
【図１７】集約関係がある３つのＪＳＰのうちの１つを示す図である。
【図１８】集約関係がある３つのＪＳＰのうちの他の１つを示す図である。
【図１９】集約関係がある３つのＪＳＰのうちの残りの１つを示す図である。
【図２０】実行時に応答文字エンコーディングが変化する集約関係がある３つのＪＳＰのうちの１つを示す図である。
【図２１】実行時に応答文字エンコーディングが変化する集約関係がある３つのＪＳＰのうちの他の１つを示す図である。
【図２２】実行時に応答文字エンコーディングが変化する集約関係がある３つのＪＳＰのうちの残りの１つを示す図である。
【図２３】図２０〜２２の３つのＪＳＰを３種類の色のどれかに分類し、作成した２つの実行コンテキスト木のうちの１つを示す図である。
【図２４】図２１〜２２の３つのＪＳＰを３種類の色のどれかに分類し、作成した２つの実行コンテキスト木のうちの他の１つを示す図である。
【図２５】図２２のc.jspが、図２０のa.jsp又は図２１のb.jspのどちらから呼び出されても応答生成が可能なサーブレットの一例を示す図である。
【図２６】図９の処理における、複数応答文字エンコーディング用ＪＳＰサーブレットの実行処理の別の実施形態を示すフローチャートである。
【図２７】図２６のフローチャートと接続しているフローチャートである。
【図２８】図２７の処理において作成・更新され、図２７の処理において作成される最適化ＪＳＰページ・サーブレットが利用する定数表として適当なものを示す図である。
【図２９】図２７におけるＪＳＰサーブレットの生成処理を示すフローチャートである。
【図３０】根を左、集約されたＪＳＰの列の呼び出される順番が上から下方向とした場合の木の一例を示す図である。
【図３１】内容は同じであるが、表示言語がそれぞれ英語及び日本語であるＨＴＭＬ文書を例示する図である。
【図３２】ＪＳＴＬ国際化タグを用いて図３１の２つのＨＴＭＬ文書を生成させるＪＳＰを示す図である。
【図３３】ＪＳＴＬ国際化タグを用いて図３１の２つのＨＴＭＬ文書を同一のＪＳＰによって生成させるために必要とする言語リソースを示す図である。
【図３４】国際化タグを用いたＪＳＰの実行の効率改善を図った既存技術における処理の様子を示す図である。
【図３５】図３２の国際化ＪＳＰに基づき図３４の既存技術によりローカル化したＪＳＰを示す図である。
【図３６】図３７のＪＳＰをインクルードしているＪＳＰを例示する図である。
【図３７】図３６のＪＳＰによってインクルードされているＪＳＰを例示する図である。
【００８５】
１：Ｗｅｂモジュール、２：ＪＳＰコンパイラ、３：ＪＳＰサーブレット、４：サーブレット・コンテナ、５：Ｊａｖａ（登録商標）コンパイラ、６：Ｊａｖａ（登録商標）仮想マシン、７：ＯＳ、２１中央処理装置、２２：主記憶装置、２３：補助記憶装置、２４：入出力インタフェース、２５：通信インタフェース、７１：write文、２５１，２５２：部分、３４１：国際化ＪＳＰ、３４２，３４３：ローカル化したＪＳＰ。
【図１】
2005332146.tif 000003
【図２】
2005332146.tif 000004
【図３】
2005332146.tif 000005
【図４】
2005332146.tif 000006
【図５】
2005332146.tif 000007
【図６】
2005332146.tif 000008
【図７】
2005332146.tif 000009
【図８】
2005332146.tif 000010
【図９】
2005332146.tif 000011
【図１０】
2005332146.tif 000012
【図１１】
2005332146.tif 000013
【図１２】
2005332146.tif 000014
【図１３】
2005332146.tif 000015
【図１４】
2005332146.tif 000016
【図１５】
2005332146.tif 000017
【図１６】
2005332146.tif 000018
【図１７】
2005332146.tif 000019
【図１８】
2005332146.tif 000020
【図１９】
2005332146.tif 000021
【図２０】
2005332146.tif 000022
【図２１】
2005332146.tif 000023
【図２２】
2005332146.tif 000024
【図２３】
2005332146.tif 000025
【図２４】
2005332146.tif 000026
【図２５】
2005332146.tif 000027
【図２６】
2005332146.tif 000028
【図２７】
2005332146.tif 000029
【図２８】
2005332146.tif 000030
【図２９】
2005332146.tif 000031
【図３０】
2005332146.tif 000032
【図３１】
2005332146.tif 000033
【図３２】
2005332146.tif 000034
【図３３】
2005332146.tif 000035
【図３４】
2005332146.tif 000036
【図３５】
2005332146.tif 000037
【図３６】
2005332146.tif 000038
【図３７】
2005332146.tif 000039