JP2002351709A - 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム - Google Patents

Abstract

(57)【要約】 【課題】データ変換実行時でないと出力データ形式が判
明しないような入力データの変換方法、入力データの変
換プログラム、および入力データの変換システムを提供
する。 【解決手段】入力モジュール３０は、モジュールマネー
ジャー２１に対して該モジュールの出力データ形式を通
知し、モジュールマネージャー２１は、この通知に基づ
いて１番目のデータ変換モジュール３１を生成してパイ
プラインの末尾に結合する。データ変換モジュール３１
は、該モジュールの出力データ形式をモジュールマネー
ジャー２１に通知し、モジュールマネージャー２１は、
その通知に基づいて２番目のデータ変換モジュール３２
を生成してパイプラインの末尾に結合する。以下、多重
化された入力データの多重化数分だけこの動作を繰り返
し、パイプラインの終端位置に出力モジュールを結合す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、多様な形式のメデ
ィアデータの処理が可能な入力データの動的変換方法、
入力データの動的変換プログラム、および入力データの
動的変換システムに関する。

【０００２】

【従来の技術】コンピュータを利用したデータの通信形
態、データの保存形態が多様化し、また、データの種類
がマルチメディア化してくると、データの受信側、復号
側においてデータ変換（デコード）の柔軟性が必要にな
ってくる。例えば、入力データが、「.zip」の拡張子で
表される圧縮データの場合には、データの受信側におい
ては、「.zip」の形式の圧縮ファイルを展開するための
データ変換モジュール（プログラム）が必要になる。ま
た、例えば、特定の形式で暗号化されている入力データ
を復号化する時には、データの受信側においては、その
特定形式に対応した復号化のためのデータ変換モジュー
ルが必要になる。この場合、多くの閉じたシステムで
は、入力データを固定のデータ変換形式に設計すること
が可能であるために、受信側においては、そのデータ変
換形式に対応する特定のデータ変換モジュールだけを用
意しておけばよい。しかし、インターネット等のオープ
ン状態のシステムや、複数種類のデータ変換形式を扱う
システムでは、データ変換モジュールを固定しておく
と、入力されてくる全てのデータに対応できなくなって
しまう。

【０００３】そこで、従来は、次の（Ａ）または（Ｂ）
の方式が採用されていた。

【０００４】（Ａ）図１１に示すシステムでは、入力デ
バイスからの入力データを、入力モジュール５０に入力
し、さらにその出力をデータ変換モジュール５１に入力
し、さらにその出力を出力モジュール５２に入力して、
この出力モジュール５２から出力デバイスに対してデー
タを出力する。

【０００５】各モジュールは、後から自由に組み込むこ
とのできるプラグインモジュールである。入力モジュー
ル５０は、指定した入力デバイスから入力データを取り
込み、データ変換モジュール５１は、入力モジュール５
１からの入力データを所定のデータ変換形式に変換す
る。また、出力モジュール５２は、データ変換されたデ
ータを指定した出力デバイスに対して出力する。通常、
各モジュールはパイプライン接続され、各モジュールで
のデータ処理が並列的に行われるようにして、入力デー
タのストリーミング処理が可能となっている。

【０００６】以上の構成において、入力データのファイ
ルが多重化されていない場合、すなわち、一度だけのデ
ータ変換（エンコード）によって、目的の出力データが
得られるファイルの場合、たとえばデータが特定の形式
で圧縮されているだけの入力データの場合は、データ変
換モジュール５１は、入力データを伸長するための１つ
のデータ変換モジュールからなる。また、入力データが
２重にエンコードされた多重ファイルとなっている場
合、たとえば、データが圧縮されてさらに暗号化されて
いる場合には、データ変換モジュール５１は暗号化デー
タを復号化するためのデータ変換モジュールと、圧縮デ
ータを伸張するためのデータ変換モジュールとの２つか
らなる。このように、入力デバイスから入力されるデー
タの種類に応じて、すなわち、エンコードされた数と各
エンコードの形態に対応するデータ変換モジュール５１
をプラグインモジュールとして任意に組み込むことによ
り、任意の入力データに対してデータ変換（デコード）
を実現することが可能である。

【０００７】（Ｂ）図１２は、「特開２０００−２３６
３８６号」に示されるシステムの構成図である。変換前
のソースデータは、方式変換制御器６０によって、その
ソースデータ内に含まれている宛て先データフォーマッ
トを読み取られ、そのフォーマットにデータ変換するた
めに必要なストリーミング変換モジュール６１〜６３が
選択され、且つそれらが最適に配列される。ソースデー
タであるストリーミングデータはこの配列された変換モ
ジュールにより、パイプライン制御によってデータ変換
（デコード）される。

【０００８】

【発明が解決しようとする課題】上記（Ａ）のシステム
では、データ処理を行うパイプラインの処理ステージ
（プラグインモジュール）が一旦設定された段数に固定
されるために、データ処理の柔軟性に欠ける問題があ
る。すなわち、図１１のデータ変換モジュール５１を一
旦、決めてしまうと、その入力データ形式と出力データ
形式が決まってしまうため、他の形式の入力データが入
力したときには正しくデータ変換（デコード）すること
が出来ない。また上記（Ａ）（Ｂ）のシステムとも、実
行時でないと出力データ形式が判明しない入力データに
対しては対応することができない問題がある。実行時で
ないと出力データ形式が判明しない入力データとは、デ
ータを複数の変換形式で多重にエンコードして多重ファ
イルとし、且つその変換形式が事前に分かっていない入
力データをいう。このような入力データでは、そのデー
タのデータ変換を実際に実行しなければ、少なくとも最
初にエンコードしたときのデータ変換形式を知ることが
できない。したがって、データ変換の実行前では、たと
えば図１１においては、どうような変換モジュール５１
を配置してよいか分からず、また図１２では、どのよう
なストリーミング変換モジュールを選択していいかを判
断することができない。

【０００９】本発明の目的は、データ変換実行時でない
と出力データ形式が判明しないような入力データに動的
に対応する入力データの変換方法、入力データの変換プ
ログラム、および入力データの変換システムを提供する
ことにある。

【００１０】

【課題を解決するための手段】本発明に係る入力データ
の変換方法は、次のように構成したものである。 デー
タを複数の変換方式で多重にエンコードして多重ファイ
ルとした入力データに対し、下記の（１）〜（３）のス
テップを実行する。

【００１１】（１）エンコード順と逆順に多重ファイル
内の各ファイルのヘッダのみを参照して各ファイルの出
力データ形式を判定し、該形式への変換に必要なデータ
変換モジュールを選択する。

【００１２】（２）上記（１）で選択されたデータ変換
モジュールを選択された順に結合する。

【００１３】（３）上記（２）によって結合されたデー
タ変換モジュール群で入力データの変換処理を実行す
る。

【００１４】本発明では、上記（１）の処理を行うと
き、データボディの変換（デコード）処理は行わない。
多重ファイルの極く一部のデータであるヘッダのみを参
照して各ファイルの出力データ形式を判定し、該形式へ
の変換に必要なデータ変換モジュールを選択する。この
ため、データ変換を実行するまでに、データ変換（デコ
ート）に必要なすべてのデータ変換モジュールを選択す
ることが出来る。そして、これらの選択されたデータ変
換モジュールを選択された順に結合する。このようにし
て結合したデータ変換モジュール群に対し、入力データ
の変換処理を実行する。したがって、たとえば、拡張子
「.zip」の圧縮ファイルを、さらに拡張子「.mrm」の暗
号化ファイル（「.mrm」は特定の暗号化拡張子）として
２重のファイルとした入力データをデータ変換処理する
場合、本発明では、最初に出力データ形式が「.mrm」で
あることを判定して、そのデータ変換形式に対応するデ
ータ変換モジュールを選択し、次に、出力データ形式が
「.zip」であることを判定して、そのデータ変換形式に
対応するデータ変換モジュールを選択し、この選択した
順にそれらのデータ変換モジュールを結合する。同様
に、たとえば、上記の拡張子「.mrm」のファイルを、さ
らに、暗号化して３重のファイルとした場合には、その
暗号化のデータ変換形式に対応するデータ変換モジュー
ルを最初の位置に結合する。

【００１５】このように、本発明では、データを複数の
変換形式で多重にエンコードして多重ファイルとした入
力データに対し、各ファイルのヘッダの出力データ形式
を次々と読み込んでいって、その入力データを最終の出
力データに変換するまでに必要なデータ変換モジュール
を自動的に選択して結合することができる。これによ
り、入力データに対応して、動的にデータ変換モジュー
ルを結合することができる。

【００１６】また、本発明では、上記選択可能な全ての
データ変換モジュール群をあらかじめ定義しておき、こ
の中から必要なデータ変換モジュールを選択する。この
ようにしておけば、あらかじめ、多数のデータ変換モジ
ュールをプラグインファイルとして用意しておき、その
中から自動的にデータ変換に必要なデータ変換モジュー
ルが選択されるようになる。

【００１７】また、本発明では、上記のようにして結合
されたデータ変換モジュールの入力側に入力モジュール
を結合し、出力側に出力モジュールを結合する。入力モ
ジュールは、入力デバイスから入力データを入力する。
また、入力データのＵＲＬ（Uniform Resource Locato
r) や、通信の際のプロトコルのレスポンスヘッダを参
照して（例えば、ＨＴＴＰプロトコルにおけるレスポン
ドヘッダ中のコンテンツタイプヘッダを参照する）ファ
イルの出力データ形式を判定する。また、出力モジュー
ルは、結合されているモジュール分の最後段にあるデー
タ変換モジュールに結合して、最終の変換後のデータを
出力する。さらに、各モジュールを管理するモジュール
マネージャーに対して、この出力マネージャーが終端で
あることを通知する。

【００１８】本発明によれば、入力モジュールを結合す
ることによって、入力データを取り込むための入力デバ
イスを任意のデバイスから選択することができる。たと
えば、ローカルファイル（コンピュータ内のファイルシ
ステムに存在するファイル）をソースとして指定するこ
ともできるし、ＵＲＬによって、インターネットからダ
ウンロード可能なファイルをソースとして指定すること
もできる。また、出力モジュールを結合することによっ
て、出力デバイス適合するデータを出力することが可能
になる。

【００１９】

【発明の実施の形態】図１は、本発明に係る入力データ
の動的変換方法が実施されるデータ処理装置の構成図で
ある。このデータ処理装置は、たとえば、パーソナルコ
ンピュータ、携帯電話などの携帯型データ処理装置から
なり、データ変換の対象となる入力データは、動画、静
止画、音声、文字などの多様なメディアデータを含むこ
とが可能である。データ処理装置本体１は、データ処理
を行うＣＰＵ１０、メインメモリ１１、ビデオコントロ
ーラ１２、ネットワークコントローラ１３、オーディオ
コントローラ１４、ローカルストレージ１５、Ｉ／Ｏデ
バイス１６を含んでいる。メインメモリ１１には、本発
明に係る入力データの動的変換プログラムが搭載され
る。ビデオコントローラ１２には，ディスプレイモニタ
２が接続され、入力データを処理した結果としての画像
データを表示したり、ユーザとのインターフェイスをす
ることができる。ネットワークコントローラ１３には、
インターネットなどのネットワーク３が接続されてい
る。オーディオコントローラ１４には、スピーカー４が
接続され、入力データを処理した結果としての音声デー
タを出力することができる。Ｉ／Ｏデバイス１６には、
キーボード、マウスなどを含むユーザインターフェイス
５が接続されている。

【００２０】上記メインメモリ１１に記憶される入力デ
ータの動的変換プログラムは、ＨＤＤ等のローカルスト
レージ１５に保存しておくことが可能であり、ネットワ
ーク３を介して、任意のリソースからも取得することが
可能である。また、ＣＤ−ＲＯＭやフロッピィ（Ｒ）デ
ィスクなどの任意の記憶媒体を介して取得することも可
能である。このデータ処理装置では、ネットワーク３を
介して取得可能な入力データファイル、または、ローカ
ルストレージ１５に記憶されているローカルファイルを
ソースとして、これを上記の動的変換プログラムによっ
て動的にデータ変換処理する。そして、その処理の結果
をディスプレイ２に映像、文字などとして出力し、また
は、スピーカー４に音声として出力する。後述のよう
に、動的変換プログラムによるデータ変換モジュールの
選択と結合は一瞬で行うことが出来、その後は、データ
変換処理がストリーミング処理される。

【００２１】図２は、上記入力データの動的変換プログ
ラムを構成するモジュール（単位プログラム）群を示し
ている。

【００２２】このモジュール群は、アプリケーションモ
ジュール２０、単位処理モジュールマネージャー（以
下、モジュールマネージャーという）２１、一つ以上の
単位処理モジュール（以下、モジュールという）２２と
で構成される。アプリケーションモジュール２０は、ユ
ーザとのインターフェイスを行うユーザインターフェイ
スモジュールを含み、また、特定の入力データファイル
のデータ変換処理を行うことをモジュールマネージャー
２１に対して通知する。このアプリケーションモジュー
ルは、たとえば、Windows(R) 98 などのＯＳにおいて
は、拡張子が「.exe」の実行モジュールとして表現され
る。

【００２３】モジュールマネージャー２１は、モジュー
ル２２を管理する。具体的には、プラグインモジュール
としてあらかじめ用意されている複数のモジュール２２
の情報、すなわち、各モジュールが処理可能なデータ変
換形式（入力データと出力データの各々のデータ形式）
を収集してリスト上に各モジュールを定義し、アプリケ
ーションモジュール２０で指定された入力データファイ
ルをデータ変換( デコード) するために必要なモジュー
ル２２を結合する。なお、この実施形態では、結合され
たモジュール２２は、図３に示すように順次結合されて
パイプラインとして構築され、入力データファイルのパ
イプライン処理が可能となっている。図３に示す例で
は、モジュール２２内の入力モジュール３０がまず選択
され、次いで、この後段に第１番目のデータ変換モジュ
ール３１が結合され、次いで、この後段に第２番目のデ
ータ変換モジュール３２が結合され、次いで、この後段
に第３番目のデータ変換モジュール３３が結合され、最
後に出力モジュール３４が結合される。このようにして
パイプラインが構築されると、次に、入力データが入力
モジュール３０に入力されて入力データのデータ変換
（デコード）処理が行われる。このとき、パイプライン
により、実時間でストリーミング変換処理を行うことが
できる。

【００２４】なお、上記モジュールマネージャー２１
は、ＯＳとしてWindows( R) 98などを採用した場合に、
拡張子「.dll」のモジュールとして表現され、モジュー
ル２２は、プラグインフォルダーに拡張子「.dll」のモ
ジュールとして格納される。

【００２５】図４は、入力データの構成例を示してい
る。図に示すように、入力データファイルは、3 重の多
重ファイルとなっている。ファイルＦ３は、元のデータ
であり、ファイルＦ２はＦ３のエンコードファイル、フ
ァイルＦ１はＦ２のエンコードファイルである。各ファ
イルのヘッダ（Ａ１、Ａ２、Ａ３）に、そのファイルを
デコードしたときの出力データ形式が記憶されている。
例えば、ファイルＦ１のヘッダＡ１には、ファイルＦ２
の出力データ形式が記憶され、ファイルＦ２のヘッダＡ
２には、ファイルＦ３の出力データ形式が記憶されてい
る。同図に示す入力データをデータ変換（デコード）処
理するには、図３に示すように、入力モジュール３０、
出力モジュール３４と、その間に結合される３つのデー
タ変換モジュール３１〜３３が必要である。最初のデー
タ変換モジュール３１は、入力モジュールにより通知さ
れた出力データ形式によるデータ変換処理を行い、２番
目のデータ変換モジュール３２は、ヘッダＡ１に記憶さ
れている出力データ形式によるデータ変換処理を行い、
３番目のデータ変換モジュール３３は、ヘッダＡ２に記
憶されている出力データ形式のデータ変換処理を行う。
なお、ヘッダＡ３に記憶されている情報は、ファイルＦ
３に固有なものであってデータボディの実質的な変換処
理は行われない。そして、実際のデータ変換処理を行う
前に、各ヘッダＡ１〜Ａ３に記憶されている出力データ
形式が読み取られて、図３に示すようなパイプラインが
構築される。パイプラインが構築されると、入力データ
は入力モジュール３０に読み込まれて、ストリーム処理
が行われていく。

【００２６】上記のように、モジュール２２の選択と結
合は、入力モジュール３０と出力モジュール３４間に入
力データをデータ変換（デコード）するのに必要な複数
のデータ変換モジュールを選択して結合することであ
る。これを図示すると図５のようになる。

【００２７】まず、ソースとなる入力データをネットワ
ーク３またはローカルストレージ１５のどちらから取得
するかを設定して入力データが適正に入力させるように
する入力モジュール３０を選択する。次に、この入力モ
ジュール３０によって入力データのＵＲＬやＨＴＴＰプ
ロトコルにおけるレスポンスヘッダ中のコンテンツタイ
プヘッダを参照して出力データ形式を判定し、これをモ
ジュールマネージャー２１に通知する。モジュールマネ
ージャー２１は、この最外郭のファイルの出力データ形
式を判定すると、その変換に必要な最初のデータ変換モ
ジュール３１をプラグインフォルダーの中に記憶されて
いる複数のデータ変換モジュール群から選択する。且
つ、その選択したデータ変換モジュールを入力モジュー
ル３０に結合する。次に、データ変換モジュール３１
は、入力データのファイルのヘッダＡ１に記憶されてい
る出力データ形式を判定し、この出力データ形式をモジ
ュールマネージャー２１に通知する。モジュールマネー
ジャー２１は、この出力データ形式を判定して、そのデ
ータ変換に必要なデータ変換モジュール３２をプラグイ
ンフォルダーの中に記憶されているデータ変換モジュー
ル群から選択し、且つ、データ変換モジュール３１の末
尾に結合する。さらに同様にして、データ変換モジュー
ル３２の末尾にデータ変換モジュール３３を結合し、最
後に、出力デバイスに対してデータを出力するための出
力モジュール３４をデータ変換モジュール３３に結合す
る。そして、このようにして結合したパイプラインに対
し、モジュールマネージャー２１は、入力データの入力
を開始し、データ変換（デコード）を実行する。

【００２８】次に、具体的な例について、図６〜図８を
参照して説明する。

【００２９】図６は、入力データの形式例である。この
例では、入力データが3 重ファイルとなっている。元の
データのエンコード順は、拡張子「.zip」による圧縮
と、「.mrm」による暗号化の順である。元のデータはＭ
ＩＤＩデータである。したがって、この多重ファイル
は、ＭＩＤＩファイルＦ３と、圧縮ファイルＦ２と暗号
化ファイルＦ１を多重化したものである。

【００３０】暗号化ファイルＦ１のヘッダＡ１には、出
力データ形式として拡張子「.zip」が指定されている。
また、圧縮ファイルＦ２のヘッダＡ２には、出力データ
形式として拡張子「.mid」が指定されている。また、Ｍ
ＩＤＩファイルＦ３のヘッダＡ３には、ＭＩＤＩフォー
マットに関する情報が指定されている。なお、ＭＩＤＩ
ファイルＦ３はＭＩＤＩデータであるために、他のフォ
ーマットにデータ変換する必要は本来ないが、本実施形
態では、ＭＩＤＩファイルをより扱い易い内部独自フォ
ーマットに変換し、最終段である出力モジュールに渡す
ようにしている関係上、その内部独自フォーマットの出
力データ形式をモジュールマネージャーに対して通知し
ている。

【００３１】図７は、各モジュールからモジュールマネ
ージャーに対して出力データ形式を通知したり、モジュ
ールマネージャーから各モジュールに対して動作指定を
行う時に使う通知データ形式を示している。図７に示す
ように、この通知データ形式は、領域１〜領域５を備え
ており、領域１から順に、「タグ」、「ＵＲＬ」、「Ｍ
ＩＭＥ」、「ＥＸＴ」、「付加情報」を記憶する。「タ
グ」は、モジュールマネージャーから各モジュールに対
する動作の種類を指定する。「ＵＲＬ」は、モジュール
マネージャーから入力モジュールに対してＵＲＬを指定
する。「ＭＩＭＥ」は、ＭＩＭＥ（Multipurpose Inter
net Mail Extensions)タイプを指定する。「ＥＸＴ」は
拡張子を指定する。「付加情報」は、必要に応じて付け
る付加情報を指定する。このうち、「ＭＩＭＥ」と「Ｅ
ＸＴ」でモジュールからモジュールマネージャーに対す
る出力データ形式の通知を行う。なお、出力データ形式
は、拡張子「ＥＸＴ」かＭＩＭＥタイプ「ＭＩＭＥ」に
よって行うことができる。通常、拡張子が指定されてい
る時には、ＭＩＭＥタイプは不要であるが、拡張子は、
誤操作によって、または意図的に変更される可能性があ
るために、ＭＩＭＥタイプの方が信頼性が高いとされ
る。モジュールマネージャーからは、「タグ」または
「ＵＲＬ」が各モジュールに対して通知される。入力モ
ジュールに対しては、「ＵＲＬ」が通知される。この
「ＵＲＬ」は、たとえば、「file://c:/test.mrm」であ
ったり、または、「http://...... 」であったりする。
前者は、ローカルストレージ１５（図１参照）のファイ
ル格納場所を指定し、後者はネットワーク３に接続され
るファイル格納場所を示す。一般に、これらの「file」
や「http」あるいは「ftp 」はプロトコルと称され、こ
のプロトコルに「パス」と「ファイル名」が結合される
ことによって取得ファイルを指定することができる。

【００３２】図８は、図６に示す入力データに対し、パ
イプラインを構築するステップを説明する図である。

【００３３】Ｔ１：モジュールマネージャー２１が、ア
プリケーションモジュール２０（図２参照）からファイ
ル（入力データ）オープン要求を受信する。

【００３４】Ｔ２：プロトコルが適合する入力モジュー
ル３０を生成する。ここでは、プロトコルを「file」と
する。したがって、入力データ( ファイル) は、ローカ
ルストレージ１５（図１参照）からロードされる。

【００３５】Ｔ３：モジュールマネージャー２１は、通
知データＤ１により、ファイル「test.mrm」を指定し
て、入力モジュール３０をオープンする。

【００３６】Ｔ４：入力モジュール３０は、指定された
ファイルの拡張子を参照して出力データ形式を判定す
る。指定されたファイルがコンテンツファイルそのもの
ではなく、ＨＴＴＰプロトコルでコンテンツファイルを
送信するためのサーバサイドスクリプトである場合もあ
るので、拡張子で出力データを特定できない場合にはＨ
ＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテ
ンツタイプヘッダを参照し、出力データ形式を判定す
る。この場合は、「test.mrm」の拡張子「.mrm」によ
り、出力データ形式が拡張子「.mrm」で表現される暗号
化データであることがわかるので、これをモジュールマ
ネージャー２１に通知する。この通知は、通知データＤ
２の領域４において行う。

【００３７】Ｔ５：拡張子「.mrm」の暗号化データをデ
コード（変換）するためのデータ変換モジュール３１を
生成する。

【００３８】Ｔ６：モジュールマネージャー２１は、生
成したデータ変換モジュール３１をパイプラインの末尾
に結合する（ここでは、入力マネージャー３０に結合す
る）。

【００３９】Ｔ７：モジュールマネージャー２１は、デ
ータ変換モジュール３１をオープンする。この動作は、
通知データＤ２の領域１によって指定する。

【００４０】Ｔ８：データ変換モジュール３１がオープ
ンされることによって、パイプラインを介してこのデー
タ変換モジュール３１にデータの一部が入力される。こ
の時、データ変換モジュール３１は、暗号化ファイルＦ
１のヘッダＡ１を参照して、次にデコード（変換）すべ
き圧縮ファイルＦ２の出力データ形式を判定してモジュ
ールマネージャー２１に通知する。この通知は、通知デ
ータＤ３の領域４によって行う。

【００４１】Ｔ９：モジュールマネージャー２１は、上
記Ｔ８で通知された出力データ形式に対応するデータ変
換モジュール３２を生成する。この時の出力データ形式
は拡張子「.zip」で表現されるものであるから、このデ
ータ変換モジュール３２は、拡張子「.zip」の圧縮デー
タをデコード（変換）するものである。

【００４２】Ｔ１０：モジュールマネージャー２１は、
データ変換モジュール３２をパイプラインの末尾に結合
する。ここでは、データ変換モジュール３２はその前段
のデータ変換モジュール３１に結合される。

【００４３】Ｔ１１：データ変換モジュール３２をオー
プンする。このオープン動作は、通知データＤ３の領域
１で指定される。

【００４４】Ｔ１２：データ変換モジュール３２がオー
プンされることによって、パイプラインを介してこのデ
ータ変換モジュール３２にデータの一部が入力される。
この時、データ変換モジュール３２は、多重化されてい
る入力データの圧縮ファイルＦ２のヘッダＡ２を参照す
る。ヘッダＡ２にはデータ変換モジュール３２でデコー
ド（変換）した時の出力データ形式が記憶されている。
この出力データ形式は、この例では、拡張子「.mid」で
表されるＭＩＤＩデータを表す。そして、このデータ変
換モジュール３２は、その出力データ形式を通知データ
Ｄ４の領域４によってモジュールマネージャー２１に通
知する。

【００４５】Ｔ１３：モジュールマネージャー２１は、
上記Ｔ１２での通知を受けると、拡張子「.mid」で表さ
れるＭＩＤＩデータをデコード（変換）するためのデー
タ変換モジュール３３を生成する。

【００４６】Ｔ１４：モジュールマネージャー２１は、
上記Ｔ１３で生成したデータ変換モジュール３３をパイ
プラインの末尾に結合する。この例では、データ変換モ
ジュール３３をデータ変換モジュール３２に結合する。

【００４７】Ｔ１５：モジュールマネージャー２１は、
データ変換モジュール３３をオープンする。

【００４８】Ｔ１６：データ変換モジュール３３がオー
プンすることによって、入力データの一部がパイプライ
ンを通過してデータ変換モジュール３３に入力される。
この時、データ変換モジュール３３は、受け取ったＭＩ
ＤＩファイルをより扱い易い内部独自フォーマットに変
換する。ここでは、その出力データ形式は「applicatio
n/x-midi2 」で表されている。データ変換モジュール３
３は、このようにして判定した出力データ形式をモジュ
ールマネージャー２１に通知する。なお、「applicatio
n/x-midi2 」の出力データ形式は、拡張子ではなくＭＩ
ＭＥタイプによって指定される。したがって、通知デー
タＤ５の領域３を使用してモジュールマネージャー２１
に通知される。

【００４９】Ｔ１７：モジュールマネージャー２１は、
上記Ｔ１６の通知を受けると、出力モジュール３４を生
成する。

【００５０】Ｔ１８：モジュールマネージャー２１は、
出力モジュール３４をパイプラインの末尾に結合する。
ここでは、出力モジュール３４をデータ変換モジュール
３３に結合する。

【００５１】Ｔ１９：モジュールマネージャー２１は、
出力モジュール３４をオープンする。このオープン動作
は、通知データＤ５の領域１によって行う。

【００５２】Ｔ２０：出力モジュール３４がオープンさ
れることによって、入力データの一部はパイプラインを
通過し、出力モジュール３４において自らがパイプライ
ンの終端位置にあることを判定する。そこで、出力モジ
ュール３４は、モジュールマネージャー２１に対して通
知データＤ６の領域１により、自らが終端であることを
通知する。

【００５３】以上のＴ１〜Ｔ２０の処理において、各モ
ジュールが読み込むデータは、多重化された入力データ
のヘッダのデータだけである。このため、パイプライン
の構築に必要な処理時間は、一瞬である。また、この例
では、図６に示すように３重に多重化された入力データ
に対するパイプライン構築を示したが、４重に多重化さ
れた入力データであれば、入力モジュール３０と出力モ
ジュール３４間に、データ変換モジュールがもう１つ追
加されることになる。このように、本実施形態では、多
重化された入力データのエンコードと逆順に各ファイル
のヘッダのみを参照して各ファイルの出力データ形式を
判定し、該形式への変換（デコード）に必要なデータ変
換モジュールを選択してパイプラインを結合していくた
めに、入力データの多重化数やエンコード方式を知らな
くても、正しくデコード（変換）するためのパイプライ
ンを動的に構築することができる。なお、パイプライン
を構築した後は、入力モジュール３０に入力データが入
力され、パイプラインによってストリーミング処理され
ていく。

【００５４】図９は、パイプラインによって入力データ
のデコード（変換）処理が行われていく時の状態を示し
ている。入力モジュール３０に入力された入力データ
は、データ変換モジュール３１で復号化され、次のデー
タ変換モジュール３２で伸長され、次のデータ変換モジ
ュール３３で、特定のＭＩＤＩデータに変換され、最後
の出力モジュール３４で、出力デバイスに出力される。

【００５５】なお、図２において、各モジュール２２
は、プラグインモジュールとして特定のプラグインフォ
ルダーに収納されている。モジュールマネージャー２１
は、パイプラインを構築する前に、このプラグインフォ
ルダー内の各モジュールの情報を収集し、リストを作成
して各モジュールを定義しておく。モジュールの定義と
は、そのモジュールがどのような処理を行うことができ
るかなどの機能を判定してリスト上に記憶しておくこと
である。モジュールマネージャー２１は、事前にこのよ
うにして定義したデータ変換モジュール群の中から適切
なものを選択し、パイプライン構築のために生成する。
ここで言う生成とは、オブジェクト指向言語において、
クラスの実体（インスタンス）を生成するという意味合
いである。たとえば、入力モジュール３０を生成すると
は、メモリ上に入力モジュール３０の実体が生成される
ことをいう。

【００５６】図１０は、本実施形態によって、パイプラ
インを構築するための手順を示すフローチャートであ
る。

【００５７】ステップＳＴ１において、モジュールマネ
ージャー２１は、プラグインフォルダーに置かれている
全てのモジュールの情報を収集する。ＳＴ２では、モジ
ュールマネージャー２１が、アプリケーションモジュー
ル２０からファイル（入力データ）のオープン要求を受
信する。モジュールマネージャー２１は、要求されたプ
ロトコルに適合する入力モジュール３０をオープンしパ
イプラインの先頭に追加する（ＳＴ３）。さらに、モジ
ュールマネージャー２１は、ＳＴ４において入力モジュ
ール３０をオープンする。

【００５８】オープンした入力モジュール３０は、最外
郭のファイルの出力データ形式をＵＲＬやＨＴＴＰプロ
トコルにおけるレスポンスヘッダ中のコンテンツタプヘ
ッダから判定してモジュールマネージャー２１に通知す
る。モジュールマネージャー２１は、この通知を受けて
出力データ形式を得るとともに（ＳＴ５）、パイプライ
ンの終端でないことを判定して（ＳＴ６）、出力データ
形式に適合するモジュール（データ変換モジュールか出
力モジュール）を生成し、パイプラインの末尾に追加す
る（ＳＴ７）。また、そのモジュールをオープンして
（ＳＴ８）、ＳＴ５に戻る。モジュールマネージャー２
１は、パイプラインの終端であることを知ると、それ以
後のパイプライン構築動作を停止し、以下、続いてデー
タボディのデコード（変換）処理が行われる。

【００５９】以上の処理において、ＳＴ１〜ＳＴ８のパ
イプライン構築動作は、ヘッダのデータのみで処理され
る。したがって、入力データ全体を全て受け取っていな
くても、入力データを正しく変換（デコード）するのに
必要で十分なパイプラインの構築が出来る。そして、パ
イプラインによるデータボディの変換処理はストリーミ
ングにより可能である。

【００６０】本実施形態では、多重にエンコードした多
重ファイルの入力データに有効であるが、多重でない１
回のみエンコードした入力データであっても対応するこ
とが可能である。この場合は、入力モジュールと出力モ
ジュール間に１つのデータ変換モジュールが結合される
ことになる。また、各モジュールをパイプライン接続す
ることによって、入力データのストリーミング処理を可
能としたが、各モジュールを単にカスケード（従属）接
続して、各段階で１ファイル毎に、順にデコード（変
換）処理を行うようにしてもよい。

【００６１】また、本発明は、複数のデータ変換モジュ
ールの前後に入力モジュールと出力モジュールを結合し
てパイプラインを構築したが、入力モジュールと出力モ
ジューは必ずしもなくてもよく、これらの機能をデータ
変換モジュールに持たせることも可能である。

【００６２】

【発明の効果】本発明によれば、データ変換（デコー
ド）を実行する時でないと最終出力データ形式が判明し
ないような入力データ、すなわち、データのエンコード
処理が多重化された多重ファイルを扱うことができる。
また、データ変換モジュールの段数は固定されずに動的
に作成されるために、多様なデータフォーマットに対応
することができる。

【図面の簡単な説明】

【図１】本発明の実施形態であるデータ処理装置の構成
図

【図２】本発明の実施形態である入力データの動的変換
プログラムのモジュール群を示す図

【図３】パイプラインが構築される様子を示す図

【図４】データを複数の変換方式で多重にエンコードし
て作成した多重ファイルの概念構成図

【図５】パイプラインの構築手順を示す図

【図６】入力データの形式例を示す図

【図７】通知データの形式を示す図

【図８】パイプラインの構築動作を具体的に説明する図

【図９】構築されたパイプラインによって入力データが
デコード（変換）処理される状態を示す図

【図１０】パイプライン構築の手順を示すフローチャー
ト

【図１１】従来の入力データ変換システムの概略構成図

【図１２】従来の他の入力データ変換システムの概略構
成図

Claims (7)

【特許請求の範囲】
1. 【請求項１】 データを複数の変換方式で多重にエンコ
   ードして多重ファイルとした入力データに対し、下記の
   （１）〜（３）のステップによりデータ変換を行う入力
   データの変換方法。 （１）エンコード順と逆順に多重ファイル内の各ファイ
   ルのヘッダのみを参照して各ファイルの出力データ形式
   を判定し、該形式への変換に必要なデータ変換モジュー
   ルを選択する。 （２）上記（１）で選択されたデータ変換モジュールを
   選択された順に結合する。 （３）上記（２）によって結合されたデータ変換モジュ
   ール群で入力データの変換処理を実行する。
2. 【請求項２】 エンコード順と逆順に多重ファイル内の
   各ファイルのヘッダのみを参照して各ファイルの出力デ
   ータ形式を判定し、該形式への変換に必要なデータ変換
   モジュールを選択する上記ステップにおいて、該ステッ
   プの前に、選択可能な全てのデータ変換モジュール群を
   定義し、この判定したデータ変換モジュール群の中から
   前記データ変換モジュールを選択する、請求項１記載の
   入力データの変換方法。
3. 【請求項３】 前記データ変換モジュール群の先頭に入
   力データを入力デバイスから入力する入力モジュールを
   結合し、前記結合されたデータ変換モジュール群の最終
   段に出力データをデバイスに出力する出力モジュールを
   結合し、このようにして結合されたデータ変換モジュー
   ル群の先頭に入力データを入力してデータ変換を行い、
   出力モジュールから変換後のデータを出力する、請求項
   １または２記載の入力データの変換方法。
4. 【請求項４】 データを複数の変換方式で多重にエンコ
   ードして多重ファイルとした入力データに対し、下記の
   （１）〜（３）のステップをＣＰＵに実行させる入力デ
   ータの変換プログラム。 （１）エンコード順と逆順に多重ファイル内の各ファイ
   ルのヘッダのみを参照して各ファイルの出力データ形式
   を判定し、該形式への変換に必要なデータ変換モジュー
   ルを選択する。 （２）上記（１）で選択されたデータ変換モジュールを
   選択された順に結合する。 （３）上記（２）によって結合されたデータ変換モジュ
   ール群で入力データの変換処理を実行する。
5. 【請求項５】 エンコード順と逆順に多重ファイル内の
   各ファイルのヘッダのみを参照して各ファイルの出力デ
   ータ形式を判定し、該形式への変換に必要なデータ変換
   モジュールを選択する上記ステップをＣＰＵに実行させ
   る前に、選択可能な全てのデータ変換モジュール群を定
   義するステップをＣＰＵに実行させ、この定義したデー
   タ変換モジュール群の中から前記データ変換モジュール
   を選択する、請求項４記載の入力データの変換プログラ
   ム。
6. 【請求項６】 前記データ変換モジュール群の先頭に入
   力データを入力デバイスから入力する入力モジュールを
   結合し、前記結合されたデータ変換モジュール群の最終
   段に出力データをデバイスに出力する出力モジュールを
   結合し、このようにして結合されたデータ変換モジュー
   ル群の先頭に入力データを入力してデータ変換を行い、
   出力モジュールから変換後のデータを出力するステップ
   をＣＰＵに実行させる、請求項４または５記載の入力デ
   ータの変換プログラム。
7. 【請求項７】データを複数の変換方式で多重にエンコー
   ドして多重ファイルとした入力データを入力デバイスか
   ら入力する処理を行う入力モジュールと、 入力されたデータを変換処理する一つ以上のデータ変換
   モジュールと、 前記変換モジュールで変換処理されたデータを出力デバ
   イスに出力する出力モジュールと、 前記入力モジュール、前記データ変換モジュール、前記
   出力モジュールの順に各モジュールを結合し、結合した
   モジュール群の先頭の入力モジュールに入力データを入
   力してデータ変換処理を行わせるモジュールマネージャ
   ーとを備え、 各モジュールは、データ変換モジュール結合時に、その
   モジュールで処理するファイルのヘッダのみを参照して
   各ファイルの出力データ形式を判定してモジュールマネ
   ージャーに通知し、 前記モジュールマネージャーは、モジュール結合時に、
   各モジュールから通知される出力データ形式に対応した
   データ変換モジュールを選択して前のモジュールに結合
   する処理を行うことを特徴とする、入力データの変換シ
   ステム。