(57)【特許請求の範囲】
【請求項１】
クライアントから複数のファイル名を受信するファイル名受信ステップと、
前記ファイル名に、第一の文字列とのパターンマッチングを実行する第一パターンマッチング実行ステップと、
前記第一の文字列とのパターンマッチングが成功した場合には、前記第一の文字列に係る第一の名称に所定のフラグ情報を付加して出力する第一のフラグ情報付加出力ステップと、
前記第一の文字列とのパターンマッチングが失敗した場合には、前記第一の文字列に係る第一の名称に前記フラグ情報を付加せずに出力する第一のフラグ情報抑止出力ステップと、
前記ファイル名に、前記第一の文字列とは異なる第二の文字列とのパターンマッチングを実行する第二パターンマッチング実行ステップと、
前記第二の文字列とのパターンマッチングが成功した場合には、前記第二の文字列に係る第二の名称に所定のフラグ情報を付加して出力する第二のフラグ情報付加出力ステップと、
前記第二の文字列とのパターンマッチングが失敗した場合には、前記第二の文字列に係る第二の名称に前記フラグ情報を付加せずに出力する第二のフラグ情報抑止出力ステップと、
前記複数のファイル名のそれぞれに、前記第一パターンマッチング実行ステップ、前記第一のフラグ情報付加出力ステップ、前記第一のフラグ情報抑止出力ステップ、前記第二パターンマッチング実行ステップ、前記第二のフラグ情報付加出力ステップ、前記第二のフラグ情報抑止出力ステップを実行するループ処理ステップと、
前記ループ処理ステップの結果として、前記複数のファイル名毎に、前記第一の名称及び前記第二の名称と、前記第一の名称又は前記第二の名称のいずれかに付される前記フラグ情報を付加した文書を出力する文書出力ステップと
を有する文書作成方法。
【請求項２】
前記第一の文字列及び前記第二の文字列は、言語種類を判別する二文字以上の文字列を含むパターンマッチングルールであり、
前記第一の名称及び前記第二の名称は、言語種類を示す文字列であり、
前記複数のファイル名は、前記二文字以上の文字列を含む、請求項１記載の文書作成方法。
【請求項３】
クライアントから複数のファイルを受信するファイル受信ステップと、
前記複数のファイルに付されているファイル名に、第一の文字列とのパターンマッチングを実行する第一パターンマッチング実行ステップと、
前記第一の文字列とのパターンマッチングが成功した場合には、前記第一の文字列に係る第一の名称に所定のフラグ情報を付加して出力する第一のフラグ情報付加出力ステップと、
前記第一の文字列とのパターンマッチングが失敗した場合には、前記第一の文字列に係る第一の名称に前記フラグ情報を付加せずに出力する第一のフラグ情報抑止出力ステップと、
前記ファイル名に、前記第一の文字列とは異なる第二の文字列とのパターンマッチングを実行する第二パターンマッチング実行ステップと、
前記第二の文字列とのパターンマッチングが成功した場合には、前記第二の文字列に係る第二の名称に所定のフラグ情報を付加して出力する第二のフラグ情報付加出力ステップと、
前記第二の文字列とのパターンマッチングが失敗した場合には、前記第二の文字列に係る第二の名称に前記フラグ情報を付加せずに出力する第二のフラグ情報抑止出力ステップと、
前記複数のファイルに付されている複数のファイル名のそれぞれに、前記第一パターンマッチング実行ステップ、前記第一のフラグ情報付加出力ステップ、前記第一のフラグ情報抑止出力ステップ、前記第二パターンマッチング実行ステップ、前記第二のフラグ情報付加出力ステップ、前記第二のフラグ情報抑止出力ステップを実行するループ処理ステップと、
前記ループ処理ステップの結果として、前記複数のファイル名毎に、前記第一の名称及び前記第二の名称と、前記第一の名称又は前記第二の名称のいずれかに付される前記フラグ情報を付加した文書を出力する文書出力ステップと
を有する文書作成方法。
【請求項４】
前記第一の文字列及び前記第二の文字列は、言語種類を判別する二文字以上の文字列を含むパターンマッチングルールであり、
前記第一の名称及び前記第二の名称は、言語種類を示す文字列であり、
前記複数のファイル名は、前記二文字以上の文字列を含む、請求項３記載の文書作成方法。
【請求項５】
クライアントから入力される複数のファイル名に付与する属性情報の名称が格納される属性情報名称フィールドと、前記ファイル名が所定の文字列を含んでいるか否か判別するための文字列パターンが格納されるファイル名パターンフィールドと、各レコードを一意に識別する識別子が格納される識別子フィールドとを有するルールテーブルと、
前記クライアントから前記複数のファイル名を受信し、前記複数のファイル名に対して、前記ルールテーブルの各レコードの前記ファイル名パターンフィールドから前記文字列パターンを読み出し、前記文字列パターンとのパターンマッチングを実行し、前記パターンマッチングが成功した場合には前記属性情報の名称に所定のフラグ情報を付加して出力し、前記パターンマッチングが失敗した場合には前記属性情報の名称に前記所定のフラグ情報を付加せずに出力する処理を繰り返して、前記複数のファイル名毎に、前記ルールテーブルの全レコードの前記属性情報の名称と、前記パターンマッチングが成功した前記属性情報の名称に係る前記フラグ情報を付加した文書を出力するファイル名解釈部と
を具備する文書作成サーバ。
【請求項６】
クライアントから送信される複数のファイルに付与する属性情報の名称が格納される属性情報名称フィールドと、前記複数のファイルのファイル名が所定の文字列を含んでいるか否か判別するための文字列パターンが格納されるファイル名パターンフィールドと、各レコードを一意に識別する識別子が格納される識別子フィールドとを有するルールテーブルと、
前記クライアントから前記複数のファイルを受信し、前記複数のファイル名に対して、前記ルールテーブルの各レコードの前記ファイル名パターンフィールドから前記文字列パターンを読み出し、前記文字列パターンとのパターンマッチングを実行し、前記パターンマッチングが成功した場合には前記属性情報の名称に所定のフラグ情報を付加して出力し、前記パターンマッチングが失敗した場合には前記属性情報の名称に前記所定のフラグ情報を付加せずに出力する処理を繰り返して、前記複数のファイル名毎に、前記ルールテーブルの全レコードの前記属性情報の名称と、前記パターンマッチングが成功した前記属性情報の名称に係る前記フラグ情報を付加した文書を出力するファイル名解釈部と
を具備する文書作成サーバ。
【請求項７】
コンピュータに、
クライアントから複数のファイル名を受信するファイル名受信ステップと、
前記ファイル名に、第一の文字列とのパターンマッチングを実行する第一パターンマッチング実行ステップと、
前記第一の文字列とのパターンマッチングが成功した場合には、前記第一の文字列に係る第一の名称に所定の属性情報を付加して出力する第一の属性情報付加出力ステップと、
前記第一の文字列とのパターンマッチングが失敗した場合には、前記第一の文字列に係る第一の名称に前記属性情報を付加せずに出力する第一の属性情報抑止出力ステップと、
前記ファイル名に、前記第一の文字列とは異なる第二の文字列とのパターンマッチングを実行する第二パターンマッチング実行ステップと、
前記第二の文字列とのパターンマッチングが成功した場合には、前記第二の文字列に係る第二の名称に所定の属性情報を付加して出力する第二の属性情報付加出力ステップと、
前記第二の文字列とのパターンマッチングが失敗した場合には、前記第二の文字列に係る第二の名称に前記属性情報を付加せずに出力する第二の属性情報抑止出力ステップと、
前記複数のファイル名のそれぞれに、前記第一パターンマッチング実行ステップ、前記第一の属性情報付加出力ステップ、前記第一の属性情報抑止出力ステップ、前記第二パターンマッチング実行ステップ、前記第二の属性情報付加出力ステップ、前記第二の属性情報抑止出力ステップを実行するループ処理ステップと、
前記ループ処理ステップの結果として、前記複数のファイル名毎に、前記第一の名称及び前記第二の名称と、前記第一の名称又は前記第二の名称のいずれかに付される前記属性情報を付加した文書を出力する文書出力ステップと
を実行させる、文書作成プログラム。
【請求項８】
コンピュータに、
クライアントから複数のファイルを受信するファイル受信ステップと、
前記複数のファイルに付されているファイル名に、第一の文字列とのパターンマッチングを実行する第一パターンマッチング実行ステップと、
前記第一の文字列とのパターンマッチングが成功した場合には、前記第一の文字列に係る第一の名称に所定のフラグ情報を付加して出力する第一のフラグ情報付加出力ステップと、
前記第一の文字列とのパターンマッチングが失敗した場合には、前記第一の文字列に係る第一の名称に前記フラグ情報を付加せずに出力する第一のフラグ情報抑止出力ステップと、
前記ファイル名に、前記第一の文字列とは異なる第二の文字列とのパターンマッチングを実行する第二パターンマッチング実行ステップと、
前記第二の文字列とのパターンマッチングが成功した場合には、前記第二の文字列に係る第二の名称に所定のフラグ情報を付加して出力する第二のフラグ情報付加出力ステップと、
前記第二の文字列とのパターンマッチングが失敗した場合には、前記第二の文字列に係る第二の名称に前記フラグ情報を付加せずに出力する第二のフラグ情報抑止出力ステップと、
前記複数のファイルに付されている複数のファイル名のそれぞれに、前記第一パターンマッチング実行ステップ、前記第一のフラグ情報付加出力ステップ、前記第一のフラグ情報抑止出力ステップ、前記第二パターンマッチング実行ステップ、前記第二のフラグ情報付加出力ステップ、前記第二のフラグ情報抑止出力ステップを実行するループ処理ステップと、
前記ループ処理ステップの結果として、前記複数のファイル名毎に、前記第一の名称及び前記第二の名称と、前記第一の名称又は前記第二の名称のいずれかに付される前記フラグ情報を付加した文書を出力する文書出力ステップと
を実行させる、文書作成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書作成方法、文書作成サーバ及び文書作成プログラムに関する。
より詳細には、少ない手間で複数のファイルに所定の属性情報を付加してアップロードすることのできるｗｅｂサーバに関する。
【背景技術】
【０００２】
一般的に、ｗｅｂサーバでｃｇｉ（Common Gateway Interface）を用いてファイルをアップロードする場合、ｃｇｉにはアップロードするファイル名をフルパスで入力する他に、ファイルの説明文等を入力する欄が設けられているのが通例である。アップロードしたファイルをアップロードした者とは別の者がダウンロードする際に、アップロードされた複数のファイルがそれぞれどのような中身であるのか、そしてどれが所望するファイルであるのかを判別するために必要だからである。
なお、特許文献１に本発明と関係すると思われる文献を示す。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２６０１９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
アップロードするファイルの数が一つや二つ程度の少ない数であれば、説明文等の入力の作業量は小さいので、クライアントを操作する者の作業量の負担は軽い。しかし、アップロードするファイルの数が四つ、五つ、或はそれ以上の数量をまとめてアップロードしなければならない、となると、クライアントを操作する者の作業量は膨大になる。
このようなシチュエーションが想定される場合の一例として、プリンタドライバがある。
プリンタドライバは、機能追加やバグフィクスを行う度に、ＯＳ別、そして言語別にドライバを作成する必要がある。ここで言語とは、日本語、英語、フランス語、ドイツ語等の自然言語を指す。また、複数のプリンタのプリンタドライバに共通に搭載されている機能に対して共通のバージョンアップやバグフィクスがあった場合には、それら複数のプリンタ毎に、一斉にバージョンアップを実施しなければならない。そうなると、アップロードするファイルの数は膨大になり、それらアップロードされるファイル毎に一つずつ手入力で説明文を記入しなければならない、となると、その作業量が極めて重くなることは容易に想像できる。
説明文の入力を省略し、例えばプリンタドライバが対応する言語を予め定めておき、プルダウンメニュー等で選択させる、という方法もあるが、これも「選択する」という手作業が必要になるので、あまり作業量の軽減には寄与しない。
【０００５】
本発明は係る課題を解決し、多くのファイルをアップロードする際に、ファイル毎に付与する属性情報を自動的に付加することで、操作者の作業量を大幅に軽減する、文書作成方法、文書作成サーバ及び文書作成プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明の文書作成方法は、クライアントから複数のファイル名を受信するファイル名受信ステップと、ファイル名に、第一の文字列とのパターンマッチングを実行する第一パターンマッチング実行ステップと、第一の文字列とのパターンマッチングが成功した場合には、第一の文字列に係る第一の名称に所定のフラグ情報を付加して出力する第一のフラグ情報付加出力ステップと、第一の文字列とのパターンマッチングが失敗した場合には、第一の文字列に係る第一の名称にフラグ情報を付加せずに出力する第一のフラグ情報抑止出力ステップと、ファイル名に、第一の文字列とは異なる第二の文字列とのパターンマッチングを実行する第二パターンマッチング実行ステップと、第二の文字列とのパターンマッチングが成功した場合には、第二の文字列に係る第二の名称に所定のフラグ情報を付加して出力する第二のフラグ情報付加出力ステップと、第二の文字列とのパターンマッチングが失敗した場合には、第二の文字列に係る第二の名称にフラグ情報を付加せずに出力する第二のフラグ情報抑止出力ステップと、複数のファイル名のそれぞれに、第一パターンマッチング実行ステップ、第一のフラグ情報付加出力ステップ、第一のフラグ情報抑止出力ステップ、第二パターンマッチング実行ステップ、第二のフラグ情報付加出力ステップ、第二のフラグ情報抑止出力ステップを実行するループ処理ステップと、ループ処理ステップの結果として、複数のファイル名毎に、第一の名称及び第二の名称と、第一の名称又は第二の名称のいずれかに付されるフラグ情報を付加した文書を出力する文書出力ステップとを有する。
【０００７】
ファイル名に一定の規則を設け、これを解釈して属性情報を生成する処理を実行することで、面倒な属性情報の入力の手間がなくなると共に、複数のファイルを一括してアップロードできるので、入力作業量が大幅に軽減される。
【発明の効果】
【０００８】
本発明により、多くのファイルをアップロードする際に、ファイル毎に付与する属性情報を自動的に付加することで、操作者の作業量を大幅に軽減する、文書作成方法、文書作成サーバ及び文書作成プログラムを提供できる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態の一例である、ファイル送信システムの全体像及び機能を示すブロック図である。
【図２】ファイル名の例と、そのファイル名に対応するルールテーブルの例である。
【図３】クライアントとｗｅｂサーバとの間の処理の流れを示すタイムチャートである。
【図４】ファイル名解釈ｃｇｉが実行する、ファイル名から言語を判定してｈｔｍｌ文書を作成する処理の流れを示すフローチャートである。
【図５】ファイル名解釈ｃｇｉが生成するｈｔｍｌ文書の一例である。
【図６】ファイル名解釈ｃｇｉが生成したｈｔｍｌ文書を、ｗｅｂブラウザで読み込んで表示部に表示させた際の、画面表示の一例である。
【図７】ファイル受信ｃｇｉが生成したダウンロード用ｈｔｍｌ文書を、ｗｅｂブラウザで読み込んで表示部に表示させた際の、画面表示の一例である。
【図８】ファイル名解釈ｃｇｉとファイル受信ｃｇｉの処理を一体化させた、クライアントとｗｅｂサーバとの間の処理の流れを示すタイムチャートである。
【発明を実施するための形態】
【００１０】
図１は、本発明の実施形態の一例である、ファイル送信システムの全体像及び機能を示すブロック図である。
ファイル送信システム１０１は、クライアント１０２とｗｅｂサーバ１０３がネットワーク１０４で接続されて構成される。
クライアント１０２は周知のパソコンであり、これにネットワークＯＳがインストールされ、周知のｗｅｂブラウザが稼働している。
クライアント１０２のｗｅｂブラウザとネットワークＯＳは、入出力制御部１０５を構成する。入出力制御部１０５は、ネットワーク１０４を通じてｗｅｂサーバ１０３から送信されるｈｔｍｌ（Hyper Text Markup Language）文書をディスプレイである表示部１０６に表示したり、キーボードやマウス等のポインティングデバイスである操作部１０７が出力する操作情報をｈｔｔｐ（Hyper Text Transfer Protocol）等の所定のフォーマットに変換して、ネットワーク１０４を通じてｗｅｂサーバ１０３に送信する。
【００１１】
ｗｅｂサーバ１０３は周知のサーバコンピュータであり、ネットワークＯＳがインストールされ、ｗｅｂサーバプログラム１０８が稼働している。なお、ｗｅｂサーバ１０３はパソコンであっても良い。
ｗｅｂサーバプログラム１０８はクライアント１０２から送信される要求に応じて、図示しない不揮発性ストレージ内に存在する案内ｈｔｍｌ文書１０９を送信したり、ファイル名解釈部ともいえるファイル名解釈ｃｇｉ（Common Gateway Interface）１１０或はファイル受信ｃｇｉ１１１を実行してその実行結果を送信する。
【００１２】
案内ｈｔｍｌ文書１０９は、ｈｔｍｌのテキストファイルである。この案内ｈｔｍｌ文書１０９には、クライアント１０２からアップロードする予定のファイルのファイル名を複数記入する、テキストボックスのフォームと、後述する言語判別ルールデータベース１１２に格納されているルールテーブルのうちの一つを選択する、プルダウンメニューのフォームが形成されている。
【００１３】
フォームとは、ｈｔｍｌの仕様の一つであり、ｆｏｒｍタグと呼ばれる"<form ...>"で始まり、"</form>"で閉じられる。フォームが形成されているｈｔｍｌ文書では、所定のパラメータを入力し或は選択し、その後送信ボタンを押すことで、入力或は選択されたパラメータがｈｔｔｐのＰＯＳＴメソッドで送信される。
【００１４】
クライアント１０２が案内ｈｔｍｌ文書１０９を表示部１０６に表示した状態で、ユーザは図示しない不揮発性ストレージ内に設けられているアップロード用ファイルディレクトリ１１３に格納されているアップロード対象となるファイルを複数選択して、テキストボックスにファイル名を記入する。その後、ユーザが操作部１０７を操作して「送信」ボタンをクリックすると、ファイル名のテキストと、選択したルールテーブルの名称が、ＰＯＳＴメソッドにてファイル名解釈ｃｇｉ１１０に向けて送信される。
【００１５】
ｗｅｂサーバプログラム１０８はクライアント１０２から送信された、ファイル名解釈ｃｇｉ１１０に向けた要求を受信し、ファイル名解釈ｃｇｉ１１０を起動すると共に、クライアント１０２からＰＯＳＴメソッドで送信された、ファイル名のテキストと、選択されたルールテーブルの名称を、ファイル名解釈ｃｇｉ１１０に渡す。
【００１６】
ファイル名解釈ｃｇｉ１１０は、所定のパラメータを受け取ってテキストを出力する、周知の一般的なｃｇｉである。ファイル名解釈ｃｇｉ１１０は、ファイル名のテキストと、選択されたルールテーブルの名称を受け取り、言語判別ルールデータベース１１２から該当するルールテーブルを読み出して所定の処理を行った後、ｈｔｍｌ文書のテキストを出力する。ファイル名解釈ｃｇｉ１１０が出力したテキスト（ｈｔｍｌ文書）は、ｗｅｂサーバプログラム１０８を通じてクライアント１０２に送信される。
【００１７】
ファイル名解釈ｃｇｉ１１０が作成したｈｔｍｌ文書には、先にクライアント１０２から受信したファイル名を、クライアント１０２によって指定されたルールテーブルで解釈して、ファイル名毎に言語の種別を判定した結果が、プルダウンメニュー形式のフォームで形成されている。また、このｈｔｍｌ文書には、ファイルの実体を送信するためのテキストボックスのフォームも形成されている。
【００１８】
クライアント１０２が、このファイル名解釈ｃｇｉ１１０が作成したｈｔｍｌ文書を表示部１０６に表示した状態で、ユーザは図示しない不揮発性ストレージ内に設けられているアップロード用ファイルディレクトリ１１３に格納されているアップロード対象となるファイルを複数選択して、テキストボックスにファイル名を記入する。その後、ユーザが操作部１０７を操作して「送信」ボタンをクリックすると、予めｈｔｍｌ文書にフォームとして記載されていたファイル名と、選択されていた言語名と、ファイルの実体が、ＰＯＳＴメソッドにてファイル受信ｃｇｉ１１１に向けて送信される。
【００１９】
ｗｅｂサーバプログラム１０８はクライアント１０２から送信された、ファイル受信ｃｇｉ１１１に向けた要求を受信し、ファイル受信ｃｇｉ１１１を起動すると共に、クライアント１０２からＰＯＳＴメソッドで送信された、ファイル名と、選択されていた言語名と、ファイルの実体を、ファイル受信ｃｇｉ１１１に渡す。
【００２０】
ファイル受信ｃｇｉ１１１は、ファイルの実体をファイル格納ディレクトリ１１４に出力すると共に、ファイル名のテキストと、選択されていた言語名とを受け取り、所定の処理を行った後、二つのｈｔｍｌ文書のテキストを出力する。一つはクライアント１０２に向けて送信するための、受信完了を示すｈｔｍｌ文書であり、もう一つは任意のクライアント１０２がファイル格納ディレクトリ１１４に格納されたファイルをダウンロードするためのリンクが埋め込まれた、ダウンロード用ｈｔｍｌ文書１１５である。
【００２１】
ファイル受信ｃｇｉ１１１が出力した、受信完了を示すテキスト（ｈｔｍｌ文書）は、ｗｅｂサーバプログラム１０８を通じてクライアント１０２に送信される。その一方で、ファイル受信ｃｇｉ１１１は、同時に不揮発性ストレージ内の所定の場所にダウンロード用ｈｔｍｌ文書１１５も作成する。
【００２２】
ダウンロード用ｈｔｍｌ文書１１５が作成された以降は、任意のユーザがダウンロード用ｈｔｍｌ文書１１５にアクセスすると、ダウンロード用ｈｔｍｌ文書１１５に埋め込まれている、「Ａタグ」と呼ばれるタグで形成されたリンクをクリックすることによって、所望のファイルをファイル格納ディレクトリ１１４からダウンロードすることができる。
【００２３】
図２は、ファイル名の例と、そのファイル名に対応するルールテーブルの例である。ルールテーブルは、言語判別ルールデータベース１１２に格納されている。
図２（ａ）は、第一番目のファイル名の例であり、図２（ｂ）は図２（ａ）の第一番目のファイル名の例に対応する、第一番目のルールテーブルである。
図２（ａ）のファイル名は、ファイル名のピリオド直前の最後の二文字が言語の種別を示すアルファベットの組み合わせである。図２（ｂ）のルールテーブルは、入力されたファイル名がどの言語に該当するのかを判別するための、周知の正規表現文字列である。
【００２４】
図２（ｂ）に示す、正規表現の意味を説明する。「da\.(exe|zip|hqx)$」という正規表現文字列は、「da」、「\.」、「(exe|zip|hqx)」そして「$」に分けられる。
先ず、「da」は、「da」という文字列そのものと一致する（マッチ（ｍａｔｃｈ）する）ことを意味する。
次に、「\.」は、任意の一文字を示す「.」（ピリオド）という特殊文字に、特殊文字の意味を打ち消して文字そのものと一致するための「\」（円マーク或はバックスラッシュ）が前置されていることで、ピリオドそのものに一致することを意味する。
次に、「(exe|zip|hqx)」は、「(」及び「)」の括弧で囲まれた中の文字列をグルーピングすることを意味すると共に、「|」（縦線或はパイプライン）で区切ることで、複数の文字列をｏｒ条件で結合することを意味する。つまり、「exe」又は「zip」又は「hqx」のいずれか一つの文字列に一致することを意味する。
最後に「$」（ダラー）は正規表現の特殊文字で、文字列の終端に一致することを意味する。
【００２５】
つまり、「da\.(exe|zip|hqx)$」という正規表現文字列は、「ファイル名の終端にある拡張子の前にあるピリオドから手前二文字に、文字列"da"が存在する」時に、マッチすることとなる。
ファイル名解釈ｃｇｉ１１０は、図示しない正規表現ライブラリの機能を用いて、以上に記した正規表現文字列に対して、入力されるファイル名が合致するのかの、パターンマッチングを行う。
【００２６】
ルールテーブルは、第一番目のフィールドが言語種類の名称（「言語種類名称」フィールド）であり、第二番目のフィールドが正規表現文字列（「ファイル名パターン」フィールド）であり、識別子フィールドともいえる第三のフィールドがｈｔｍｌ文書を作成する際に使用する言語種類のパラメータ名称（「ＶＡＬＵＥ」フィールド）である。もし、ルールテーブルをプレーンテキストファイルで構成する場合は、フィールドセパレータは正規表現文字列と混同しない文字が望ましい。例えばタブや、周知の簡易言語ＡＷＫでサブセパレータ（SUBSEP）のデフォルト値として使用されている”￥０３４”、或はＣ言語等で用いられるＮＵＬＬ等、非表示のコントロールキャラクタが考えられる。
【００２７】
図２（ｃ）は、第二番目のファイル名の例であり、図２（ｄ）は図２（ｃ）の第二番目のファイル名の例に対応する、第二番目のルールテーブルである。
図２（ｃ）のファイル名は、ファイル名の先頭の二文字が言語の種別を示すアルファベットの組み合わせである。図２（ｄ）のルールテーブルも、図２（ｂ）と同様の、周知の正規表現文字列である。
【００２８】
図２（ｄ）に示す、正規表現の意味を説明する。「^da」という正規表現文字列は、「^」と「da」に分けられる。
先ず、「^」（キャレット）は正規表現の特殊文字で、文字列の始端に一致することを意味する。
次に、「da」は、「da」という文字列そのものと一致する（マッチ（ｍａｔｃｈ）する）ことを意味する。
【００２９】
つまり、「^da」という正規表現文字列は、「ファイル名の先頭から文字列"da"が存在する」時に、マッチすることとなる。
【００３０】
図３は、クライアント１０２とｗｅｂサーバ１０３との間の処理の流れを示すタイムチャートである。
クライアント１０２の入出力制御部１０５は、ユーザが操作部１０７を操作することで操作部１０７から出力される操作情報を受けて、ｗｅｂサーバ１０３に対して、案内ｈｔｍｌ文書１０９の送信を要求する（Ｓ３０１）。
ｗｅｂサーバプログラム１０８はクライアント１０２から送信された要求を受信すると（Ｓ３０２）、案内ｈｔｍｌ文書１０９を送信する（Ｓ３０３）。
入出力制御部１０５は案内ｈｔｍｌ文書１０９を受信すると、表示部１０６に表示する（Ｓ３０４）。
【００３１】
案内ｈｔｍｌ文書１０９がクライアント１０２の表示部１０６に表示された状態で、ユーザはアップロード用ファイルディレクトリ１１３に格納されているアップロード対象となるファイルを複数選択して、テキストボックスにファイル名を記入する。その後、ユーザが操作部１０７を操作して「送信」ボタンをクリックすると、ファイル名のテキストと、選択したルールテーブルの名称が、ＰＯＳＴメソッドにてファイル名解釈ｃｇｉ１１０に向けて送信される（Ｓ３０５）。
【００３２】
ｗｅｂサーバプログラム１０８はクライアント１０２から送信された、ファイル名解釈ｃｇｉ１１０に向けた要求を受信すると、ファイル名解釈ｃｇｉ１１０を起動すると共に、クライアント１０２からＰＯＳＴメソッドで送信された、ファイル名のテキストと、選択されたルールテーブルの名称を、ファイル名解釈ｃｇｉ１１０に渡す（Ｓ３０６）。
ファイル名解釈ｃｇｉ１１０は、ファイル名のテキストと、選択されたルールテーブルの名称を受け取り、所定の処理を行った後、ｈｔｍｌ文書のテキストを出力する。ファイル名解釈ｃｇｉ１１０が出力したテキスト（ｈｔｍｌ文書）は、ｗｅｂサーバプログラム１０８を通じてクライアント１０２に送信される（Ｓ３０７）。
入出力制御部１０５は、ファイル名解釈ｃｇｉ１１０が作成したｈｔｍｌ文書を受信すると、表示部１０６に表示する（Ｓ３０８）。
【００３３】
このファイル名解釈ｃｇｉ１１０が作成したｈｔｍｌ文書がクライアント１０２の表示部１０６に表示された状態で、ユーザはアップロード用ファイルディレクトリ１１３に格納されているアップロード対象となるファイルを複数選択して、テキストボックスにファイル名を記入する。その後、ユーザが操作部１０７を操作して「確定」ボタンをクリックすると、予めｈｔｍｌ文書にフォームとして記載されていたファイル名と、選択されていた言語名（「ＶＡＬＵＥ」フィールドの値）と、ファイルの実体が、ＰＯＳＴメソッドにてファイル受信ｃｇｉ１１１に向けて送信される（Ｓ３０９）。
【００３４】
ｗｅｂサーバプログラム１０８はクライアント１０２から送信された、ファイル受信ｃｇｉ１１１に向けた要求を受信すると、ファイル受信ｃｇｉ１１１を起動すると共に、クライアント１０２からＰＯＳＴメソッドで送信された、ファイル名と、選択されていた言語名と、ファイルの実体を、ファイル受信ｃｇｉ１１１に渡す（Ｓ３１０）。
【００３５】
ファイル受信ｃｇｉ１１１は、ファイルの実体をファイル格納ディレクトリ１１４に出力すると共に、ファイル名のテキストと、選択されていた言語名とを受け取り、所定の処理を行った後、二つのｈｔｍｌ文書のテキストを出力する。一つはクライアント１０２に向けて送信するための、受信完了を示すｈｔｍｌ文書であり、もう一つは任意のクライアント１０２がファイル格納ディレクトリ１１４に格納されたファイルをダウンロードするためのリンクが埋め込まれた、ダウンロード用ｈｔｍｌ文書１１５である。
【００３６】
ファイル受信ｃｇｉ１１１が出力した、受信完了を示すテキスト（ｈｔｍｌ文書）は、ｗｅｂサーバプログラム１０８を通じてクライアント１０２に送信される（Ｓ３１１）。
入出力制御部１０５は、ファイル受信ｃｇｉ１１１が作成したｈｔｍｌ文書を受信すると、表示部１０６に表示する（Ｓ３１２）。
ファイル受信ｃｇｉ１１１は、ステップＳ３１１において受信完了を示すテキスト（ｈｔｍｌ文書）を作成してクライアント１０２に送信する一方で、同時に不揮発性ストレージ内の所定の場所にダウンロード用ｈｔｍｌ文書１１５も作成する（Ｓ３１３）。
【００３７】
図４は、ファイル名解釈ｃｇｉ１１０が実行する、ファイル名から言語を判定してｈｔｍｌ文書を作成する処理の流れを示すフローチャートである。図３のステップＳ３０７の中身に該当する。
ｗｅｂサーバプログラム１０８を通じて起動されると（Ｓ４０１）、ファイル名解釈ｃｇｉ１１０は最初にｈｔｍｌ文書の上段部分を作成し、ｗｅｂサーバプログラム１０８を通じてクライアント１０２へ出力する（Ｓ４０２）。
次に、ファイル名解釈ｃｇｉ１１０はｗｅｂサーバプログラム１０８から配列変数として引き渡されたファイル名の配列のうち、最初のファイル名を注目する（Ｓ４０３）。
【００３８】
これ以降はループ処理である。
先ず、ファイル名解釈ｃｇｉ１１０はｈｔｍｌ文書中でフォームを形成する最初の部分を作成し、ｗｅｂサーバプログラム１０８を通じてクライアント１０２へ出力する（Ｓ４０４）。
次に、ファイル名解釈ｃｇｉ１１０はｗｅｂサーバプログラム１０８から引き渡された、ユーザによって選択されたルールテーブルの名称に合致するルールテーブルを、言語判別ルールデータベース１１２から読み出し、ルールテーブルの最初のレコードの「ファイル名パターン」フィールドに記されている最初のルール（正規表現文字列）に注目する（Ｓ４０５）。
【００３９】
次に、ファイル名解釈ｃｇｉ１１０は図示しない正規表現ライブラリを用いて、現在注目しているルールテーブルのレコードに記されているルール（正規表現文字列）を読み込み、現在注目しているファイル名とマッチするか、判定する（Ｓ４０６）。
もし、ファイル名がルールにマッチしたら、現在注目しているルールテーブルの「言語種類名称」フィールドに記されている言語名称と、「ＶＡＬＵＥ」フィールドに記されているパラメータ名称を読み込み、「ＳＥＬＥＣＴＥＤ」文字列を伴う「ＯＰＴＩＯＮ」タグを出力する（Ｓ４０７）。具体的には、例えば以下のようにタグを出力する。
「<OPTION VALUE="da" SELECTED>Dansk</OPTION>」
【００４０】
この「ＳＥＬＥＣＴＥＤ」文字列は、プルダウンメニュー形式のフォームにおいて、デフォルトで選択される項目に付する文字列である。そして、本実施形態においては、クライアント１０２から入力されたファイル名が当該言語に対応すると判定したことを示す、フラグ情報でもある。
【００４１】
ステップＳ４０６の時点で、もし、ファイル名がルールにマッチしなかったら、現在注目しているルールテーブルの「言語種類名称」フィールドに記されている言語名称と、「ＶＡＬＵＥ」フィールドに記されているパラメータ名称を読み込み、「ＳＥＬＥＣＴＥＤ」文字列を伴わない「ＯＰＴＩＯＮ」タグを出力する（Ｓ４０８）。具体的には、例えば以下のようにタグを出力する。
「<OPTION VALUE="da">Dansk</OPTION>」
【００４２】
ステップＳ４０７又はＳ４０８の後、ファイル名解釈ｃｇｉ１１０は現在注目しているルールテーブルのレコードが最後のレコードであるか否か確認する（Ｓ４０９）。もし、まだ最後のレコードでないのなら（Ｓ４０９のＮＯ）、ファイル名解釈ｃｇｉ１１０はルールテーブルの現在注目しているレコードを次のレコードへ進めて（Ｓ４１０）、再度ステップＳ４０６から処理を繰り返す。
ステップＳ４０９で、最後のレコードに至ったのなら（Ｓ４０９のＹＥＳ）、ファイル名解釈ｃｇｉ１１０はステップＳ４０４に対応する、フォームを形成する最後の部分を作成し、ｗｅｂサーバプログラム１０８を通じてクライアント１０２へ出力する（Ｓ４１１）。
【００４３】
ステップＳ４１１の後、ファイル名解釈ｃｇｉ１１０は現在注目している配列変数中のファイル名が、配列変数の最後の要素であるか否か確認する（Ｓ４１２）。もし、まだ最後の要素でないのなら（Ｓ４１２のＮＯ）、ファイル名解釈ｃｇｉ１１０は配列変数の現在注目している要素を次の要素へ進めて（Ｓ４１３）、再度ステップＳ４０４から処理を繰り返す。
【００４４】
ステップＳ４１２で、最後の要素に至ったのなら（Ｓ４１２のＹＥＳ）、ファイル名解釈ｃｇｉ１１０はステップＳ４０２に対応する、ｈｔｍｌ文書の後段部分を作成し、ｗｅｂサーバプログラム１０８を通じてクライアント１０２へ出力して（Ｓ４１４）、一連の処理を終了する（Ｓ４１５）。
【００４５】
図５は、ファイル名解釈ｃｇｉ１１０が生成するｈｔｍｌ文書の一例である。図５では、ｈｔｍｌ文書中で、図４の対応するステップによって出力される箇所を明示している。但し、図５では図面の関係上、ファイル名を入力するためのテキストボックスについては省略していることに注意されたい。
図６（ａ）、（ｂ）及び（ｃ）は、ファイル名解釈ｃｇｉ１１０が生成したｈｔｍｌ文書を、ｗｅｂブラウザで読み込んで表示部１０６に表示させた際の、画面表示の一例である。
【００４６】
図５に示したｈｔｍｌ文書は、図６（ａ）のように表示される。そして、プルダウンメニューをクリックすると、それぞれ図６（ｂ）及び図６（ｃ）のように表示される。文字色が反転している部分が、図４のステップＳ４０７で「ＳＥＬＥＣＴＥＤ」文字列を伴って出力された結果である。
【００４７】
ユーザは、図６のように表示されたｈｔｍｌ文書の内容を確認した上で、ｈｔｍｌ文書に別途設けられているテキストボックスに、図３のステップＳ３０５と同様に複数のファイル名を記入し、「確認」ボタンをクリックする。すると、「ＳＥＬＥＣＴＥＤ」文字列が付されている「ＶＡＬＵＥ」フィールドの値が、ファイル名と共にファイル受信ｃｇｉ１１１へ送信される。
【００４８】
図７は、ファイル受信ｃｇｉ１１１が生成したダウンロード用ｈｔｍｌ文書１１５を、ｗｅｂブラウザで読み込んで表示部１０６に表示させた際の、画面表示の一例である。
ファイル受信ｃｇｉ１１１は、クライアント１０２から、予めｈｔｍｌ文書にフォームとして記載されていたファイル名と、選択されていた言語名（「ＶＡＬＵＥ」フィールドの値）と、ファイルの実体を、ＰＯＳＴメソッドにて受信すると、「ＶＡＬＵＥ」フィールドの値で言語判別ルールデータベース１１２中のルールテーブルを検索し、「言語種類名称」フィールドの値を読み出して、ファイル名と共にＡタグの説明文を構成する。こうして、言語名称とファイル名が並んだリンクがファイル毎に列挙されたｈｔｍｌ文書が作成される。
【００４９】
これまではファイルを一つずつアップロードする際にその属性情報（上記実施形態では「言語」が該当する）を手作業で選択しなければならなかったが、本実施形態では、ファイル名に規則を設け、これを解釈して属性情報を生成する処理をｗｅｂサーバ側に持たせたことで、面倒な属性情報の入力の手間がなくなると共に、複数のファイルを一括してアップロードできるので、入力作業量が大幅に軽減される。
【００５０】
本実施形態は、以下のような応用が可能である。
（１）ファイル名解釈ｃｇｉ１１０とファイル受信ｃｇｉ１１１の処理は、一体化することが可能である。つまり、複数のファイルを一括してアップロードするだけで、ファイル名から言語を判別して、ダウンロード用ｈｔｍｌ文書１１５を生成することができる。
図８は、ファイル名解釈ｃｇｉ１１０とファイル受信ｃｇｉ１１１の処理を一体化させた、クライアント１０２とｗｅｂサーバ１０３との間の処理の流れを示すタイムチャートである。
【００５１】
この応用例において、ステップＳ８０１は図３のステップＳ３０１に、ステップＳ８０２は図３のステップＳ３０２に、ステップＳ８０３は図３のステップＳ３０３に、ステップＳ８０４は図３のステップＳ３０４に対応する。そして、ステップＳ８０４でクライアント１０２の表示部１０６に表示される案内ｈｔｍｌ文書は、ファイル名のテキストを送信する代わりに、複数のファイルの実体そのものを送信する（Ｓ８０５）。
【００５２】
ファイル受信ｃｇｉは、クライアントからファイルの実体と選択されたルールテーブルの名称を受信すると（Ｓ８０６）、受信したファイルをファイル格納ディレクトリ１１４に格納した後、ファイル名を抽出して、図４に示した内容と同様の処理を行った後、受信完了を示すｈｔｍｌ文書を作成して送信する（Ｓ８０７）。
ステップＳ８０８は、図３のステップＳ３１２に対応する。
ファイル受信ｃｇｉは、ステップＳ８０７を実行すると共に、ダウンロード用ｈｔｍｌ文書を作成する（Ｓ８０９）。
【００５３】
（２）ｃｇｉの代わりにＪａｖａ（登録商標）アプレットを用いてもよい。
（３）パターンマッチングでは正規表現を用いたが、パターンマッチングはこれに限られるものではなく、最低限、文字列の部分一致ができる手法であれば採用が可能である。
【００５４】
本実施形態では、ファイル送信システムを開示した。
これまではファイルを一つずつアップロードする際にその属性情報を手作業で選択しなければならなかったが、本実施形態では、ファイル名に一定の規則を設け、これを解釈して属性情報を生成する処理をｗｅｂサーバ側に持たせた。これにより、面倒な属性情報の入力の手間がなくなると共に、複数のファイルを一括してアップロードできるので、入力作業量が大幅に軽減される。
【００５５】
以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
【符号の説明】
【００５６】
１０１…ファイル送信システム、１０２…クライアント、１０３…ｗｅｂサーバ、１０４…ネットワーク、１０５…入出力制御部、１０６…表示部、１０７…操作部、１０８…ｗｅｂサーバプログラム、１０９…案内ｈｔｍｌ文書、１１０…ファイル名解釈ｃｇｉ、１１１…ファイル受信ｃｇｉ、１１２…言語判別ルールデータベース、１１３…アップロード用ファイルディレクトリ、１１４…ファイル格納ディレクトリ、１１５…ダウンロード用ｈｔｍｌ文書
【図１】
0005509899.tif 000002
【図２】
0005509899.tif 000003
【図３】
0005509899.tif 000004
【図４】
0005509899.tif 000005
【図５】
0005509899.tif 000006
【図６】
0005509899.tif 000007
【図７】
0005509899.tif 000008
【図８】
0005509899.tif 000009