JP6397343B2 - 情報処理装置、および、情報処理方法 - Google Patents

Description

本発明は、文字コード体系の変更が伴うデータの処理の技術に関する。

数十年以上前から稼働してきた情報システムが扱ってきたShift-JIS（Japanese Industrial Standards）などの文字コード体系では、文字ごとの表示幅（桁数）とデータサイズ（バイト数）とが同じである。例えば、Shift-JISは、１桁からなる半角文字を１バイトで表し、２桁からなる全角文字を２バイトで表す。よって、情報システムは、文字単位で処理することができ、処理目的とする文字データを誤りなく読み出すことができる。また、上記情報システムの作成に用いた代表的なプログラム言語としてはＣＯＢＯＬ（COmmon Business Oriented Language）がある。ＣＯＢＯＬは、文字データと、非文字としてのバイナリデータとを区別せず同様に処理する。

現在では、グローバル化に伴い、文字コード体系として、例えば、Unicodeが標準採用されつつある。Unicodeは、Shift-JISとは対照的に、文字を桁数で分類しておらず、文字ごとの表示幅とデータサイズとの間に所定の関係が無い。ここで、例えば、ＣＯＢＯＬで作成され、Shift-JISなどの文字コード体系を用いた情報システムに対して、文字コード体系をUnicodeなどに変更したいという要望がある。特に、ＣＯＢＯＬで作成され、Shift-JISなどの文字コード体系を用いて古くから稼働してきた情報システムを、マイグレーションによって、Unicodeなどの文字コード体系を用いる新たな情報システムとして活用したい、という要望が多い。なお、マイグレーションの技術内容については、例えば、特許文献１に開示されている。

特許第４４０５５７１号公報

しかし、文字コード体系を、文字ごとの表示幅とデータサイズとの間に所定の関係が無いUnicodeなどに単に変更しても、情報システムは、１文字の処理のために読み出す必要があるバイト数を知り得ない。その結果、変更した文字コード体系において、文字単位で処理することができず、処理目的とする文字データを誤って読み出してしまう、という不都合が生じる。従来では、文字コード体系の変更の際、開発者が、文字データの処理部分となるプログラムコードを抽出し、適切に修正してこのような不都合を解消しようとしている。また、バイナリデータの処理部分となるプログラムコードの修正は、文字データのそれとは異なるアプローチを必要とする。しかし、これらの人手によるプログラムコードの修正は、多少なりともエラーが生じる場合があり、また、マイグレーションの作業効率の低下や、文字コード体系を変更した情報システムの品質の低下を招きやすい。

そこで、本発明は、このような事情に鑑みてなされたものであり、処理対象のデータの文字コード体系がどのような文字コード体系に変更されたとしても、目的とする処理を確実に行うことができるように支援することを目的とする。

前記目的を達成するために、本発明は、
処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置であって、
１データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を設定するデータ格納領域設定部と、
前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて設定するフラグ格納領域設定部と、
前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取部と、
前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取部と、を備える、
ことを特徴とする。
その他の手段については後記する。

本発明によれば、処理対象のデータの文字コード体系がどのような文字コード体系に変更されたとしても、目的とする処理を確実に行うことができるように支援することができる。

本実施形態の情報処理装置の機能構成を示す図である。 本実施形態の情報処理装置の処理を示すフローチャートである。 実施例１の説明図である。 実施例２の説明図である。 実施例３の説明図である。

以下、本発明の実施形態について添付の図面を参照しながら詳細に説明する。説明の便宜上、データ格納領域は、「ＤＡ」と表記し、フラグ格納領域は、「ＦＡ」と表記する場合がある。

≪構成≫
本実施形態の情報処理装置Ｐは、入力部、出力部、制御部（図１の処理部１に相当。）、および記憶部（図１の記憶部２や作業領域４に相当。）といったハードウェアを含むコンピュータである。例えば、制御部がＣＰＵ（Central Processing Unit）から構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現される。また、そのコンピュータが含む記憶部は、ＣＰＵの指令により、そのコンピュータの機能を実現するためのさまざまなプログラムを記憶する。これによりソフトウェアとハードウェアの協働が実現される。前記プログラムは、記録媒体に記録したり、ネットワークを経由したりすることで提供することができる。

図１に示すように、情報処理装置Ｐは、処理部１、記憶部２、編集ライブラリ３、作業領域４、および、編集ツール５を備える。
処理部１は、情報処理装置Ｐが実行するあらゆる処理の全体を制御する。処理部１が対象とする処理には、例えば、情報処理装置Ｐが扱う文字コード体系の変換に必要な処理が含まれる。

記憶部２は、さまざまな形式の情報を記憶する部位である。記憶部２は、ファイルｆおよび文字コード変換表Ｔを記憶する。
ファイルｆは、テキストファイルまたはバイナリファイルである。ファイルｆがテキストファイルである場合、処理部１は、ファイルｆ中の文字データの文字コード体系を、例えば、入力部などから指定された他の文字コード体系に変更することができる。

文字コード変換表Ｔは、所定の文字集合に属する文字の各々について、情報処理装置Ｐが扱う文字コード体系ごとの文字コードを管理する。処理部１は、採用中の文字コード体系に従ってテキストファイル中の文字データを表現することができる。文字コード体系の変更指定があった場合には、処理部１は、変更前の文字コード体系に従って表現されていた文字データを、変更後の文字コード体系に従って表現することができる。

編集ライブラリ３は、編集ツール５が開くファイルｆを記憶部２から読み込み、読み込んだファイルｆ中のデータを編集ツール５が処理するために必要な処理を行う再利用可能なプログラムである。編集ライブラリ３は、ＤＡ設定部３１（データ格納領域設定部）、ＦＡ設定部３２（フラグ格納領域設定部）、ＦＡ読取部３３（フラグ格納領域読取部）、およびＤＡ読取部３４（データ格納領域読取部）を備える。前記「必要な処理」は、ＤＡ設定部３１、ＦＡ設定部３２、ＦＡ読取部３３、およびＤＡ読取部３４によって実現される。

ＤＡ設定部３１は、１データ分のデータを格納可能であり、各々で領域サイズが均一となるＤＡを、作業領域４に設定する。「１データ分のデータ」とは、１文字を表す文字データ、または、１バイト分のバイナリデータを意味する。１文字を表す文字データのデータサイズは、情報処理装置Ｐが扱う文字コード体系に従って１バイトまたは２バイト以上となる。例えば、文字コード体系がＵＴＦ−８である場合、全角文字１文字は３バイトで表わされる。この場合、ＤＡ設定部３１は、３バイト相当の文字データを格納できるＤＡを作業領域４に設定する。

「１データ分のデータを格納可能」であるとは、１つのＤＡの領域サイズ（容量）を、情報処理装置Ｐが扱う文字コード体系において表現され得る文字データのデータサイズの最大値と同じ値をとるサイズ、または、前記最大値よりも大きな値をとるサイズにする、という意味を含む。例えば、文字コード体系がＵＴＦ−８である場合、１文字は１〜３バイトで表現される（例えば、半角英数文字１文字は１バイト、一部の演算子１文字は２バイト、全角文字１文字は３バイトで表わされる。）。この場合、ＵＴＦ−８において表現され得る文字データのデータサイズの最大値を３バイトとし、１つのＤＡの領域サイズは、３バイトまたは４バイト以上にする。
また、各々のＤＡの領域サイズを均一にすることで、ＤＡの設定に伴う負荷を低減することができる。つまり、１データのデータサイズに合わせてＤＡの領域サイズを適宜変更するという処理は、非効率であり多大な負荷を伴うので、そのような処理は行わない。

ＦＡ設定部３２は、ＤＡに格納されるデータの種類を識別するフラグを格納するＦＡを、ＤＡに対応付けて、作業領域４に設定する。フラグには、例えば、バイナリデータを識別するフラグ、文字データを識別するフラグ、特定のデータを識別するフラグがあるが、文字データについては、例えば、半角文字を識別するフラグ、全角文字の一部を識別するフラグ、を用いることができる（詳細は後記）。なお、１つのＦＡの領域サイズは、任意とすることができるが、１つのＤＡの領域サイズよりも小さくすることが好ましい（例：１つのＦＡの領域サイズは４ビット）。

ＦＡ読取部３３は、フラグが格納されたＦＡを読み取る。ＦＡ読取部３３は、読み取ったＦＡに格納されているフラグを取得する。

ＤＡ読取部３４は、ＦＡに対応付けて設定されたＤＡを読み取る。ＤＡ読取部３４は、読み取ったＤＡに格納されているデータを、このＤＡに対応する読取済のＦＡに格納されているフラグに基づいて取得する。

作業領域４は、情報処理装置Ｐにてデータの読み書きがなされる領域である。作業領域４は、ＤＡ設定部３１が設定するＤＡ、および、ＦＡ設定部３２が設定するＦＡを含む。

編集ツール５は、ファイルｆの編集機能を有するソフトウェア（情報システム）である。編集ツール５は、もともとは（マイグレーション前は）ＣＯＢＯＬで記述されたプログラムコードを、周知の自動変換ツールを用いて、ＪＡＶＡ（登録商標）で記述されたプログラムコードとするように、プログラム言語を変換するものである。ＣＯＢＯＬで記述されたプログラムコードのロジックとＪＡＶＡで記述されたプログラムコードのロジックは同じである。編集ツール５は、編集ライブラリ３にリンクしている。

ＣＯＢＯＬからＪＡＶＡへの変換があったとしても、マイグレーションによってファイルｆを保有することになった情報処理装置Ｐが、ＣＯＢＯＬで示されるロジックを活用してファイルｆを処理することができるように、編集ライブラリ３および編集ツール５が情報処理装置Ｐに導入された、といえる。

なお、本発明の変換前のプログラム言語は、ＣＯＢＯＬに限定されず他のプログラム言語であってもよい。また、本発明の変換後のプログラム言語は、ＪＡＶＡに限定されず他のプログラム言語であってもよい。

≪処理≫
図２に示すように、本実施形態の情報処理装置Ｐは、ファイルｆの編集処理を行うために、以下の手順で動作する。この手順は、処理部１の制御下で行われ、ステップＳ０１から開始する。

ステップＳ０１にて、編集ツール５は、編集ライブラリ３を呼び出す。編集ツール５は、編集処理の対象となるファイルｆを編集ライブラリ３に通知する。ステップＳ０１の後、ステップＳ０２に進む。

ステップＳ０２にて、編集ライブラリ３は、編集処理の対象となるファイルｆを読み込む。ファイルｆが読み込まれると、ファイルｆ中のデータがバイト単位で順次読み出される。ステップＳ０２の後、ステップＳ０３に進む。

ステップＳ０３にて、ＤＡ設定部３１が、作業領域４にＤＡを設定し、ＦＡ設定部３２が、作業領域４にＦＡを設定する。ステップＳ０３の後、ステップＳ０４に進む。

ステップＳ０４にて、ＤＡ設定部３１が、ファイルｆから読み取ったデータを順次、設定したＤＡの各々に１データ分格納し、ＦＡ設定部３２が、ＤＡに格納されたデータのフラグを順次、設定したＦＡの各々に格納する。なお、ＦＡ設定部３２が設定したＦＡの各々に格納されるフラグの値は、例えば、編集ツール５が編集ライブラリ３を呼び出した後（ステップＳ０１）、編集ツール５のプログラムコードの実行部分にて定義されているデータ項目を、ＦＡ設定部３２が確認することで決定することができる。また、ＤＡ設定部３１は、ＦＡに格納されたフラグに基づいて、設定したＤＡの各々に１データ分のデータを格納する。ステップＳ０４の後、ステップＳ０５に進む。

ステップＳ０５にて、ＦＡ読取部３３が、設定されたＦＡを順次読み取り、ＦＡに格納されたフラグを順次取得する。ステップＳ０５の後、ステップＳ０６に進む。

ステップＳ０６にて、ＤＡ読取部３４が、読み取ったＦＡに対応付けて設定されたＤＡを順次読み取り、読み取ったＤＡに格納されているデータを取得する。このとき、取得されたデータは、読み取ったＦＡからすでに取得したフラグの値に基づいて決定された１データ分のデータとなる（詳細は後記）。取得されたデータは、ＤＡ読取部３４によって編集ツール５に順次送信される。ステップＳ０６の後、ステップＳ０７に進む。

ステップＳ０７にて、編集ツール５は、編集ライブラリ３のＤＡ読取部３４から取得したデータの編集処理を行う。フラグを参照せずにデータにアクセスし、データ自体を解析して編集処理を行う場合に比べ、ステップＳ０５のようにフラグを参照してデータの種類を認識した後に、本ステップによるデータの編集処理を行う方が、データ自体の解析に要する時間を短縮することができるため、編集処理の速度を向上させることができる。なお、フラグに応じた編集処理の具体例については後記する。

ステップＳ０８にて、編集ツール５は、データの編集処理の処理結果を出力する。出力先、出力態様などは、編集処理の目的に応じてさまざまであり、説明を省略する。ステップＳ０８の後、図２の処理を終了する。

本実施形態によれば、ファイルｆ中の処理対象のデータの文字コード体系（例えば、文字ごとの表示幅とデータサイズとが同じとなるShift-JIS）が変更され、変更後の文字コード体系（例えば、文字ごとの表示幅とデータサイズとの間に所定の関係が無いUnicode）を用いて前記データを処理する場合において以下のことが導出される。

まず、編集ライブラリ３が、データサイズがさまざまとなる１データを、設定されたＤＡの各々に順次格納し、データの種類を識別したフラグを、対応するＦＡの各々に格納する。つまり、編集ツール５の処理対象となる１データがＤＡによって特定され、１データごとにデータの種類が特定される。

よって、（現在はＪＡＶＡでプログラムコードが記述されているが）データサイズを文字の表示幅でしか特定できないＣＯＢＯＬによってプログラムコードのロジックが組まれた編集ツール５は、各ＤＡ中のデータ全体、および、各ＤＡに対応した各ＦＡ中のフラグを参照する編集ライブラリ３を呼び出すという画一的な手順をとるだけでよい。これにより、編集ツール５は、変更後の文字コード体系によってデータサイズを特定することができなくても、編集処理の目的となる１データを確実に処理することができる。

また、データの種類を区別せず（できず）に同様に処理するＣＯＢＯＬ（文字データもバイナリデータもＸ項目に代入して同様に処理する）によってプログラムコードのロジックが組まれた編集ツール５は、各ＦＡに格納されたフラグを参照する編集ライブラリ３を呼び出すという画一的な手順をとるだけでよい。これにより、編集ツール５は、自身でデータの種類を区別せずとも、データの種類に適した処理結果を誤りなく出力することができる。

また、編集ツール５は、編集ライブラリ３にリンクして必要時に動的に編集ライブラリ３を呼び出すだけでよい。これにより、編集ツール５のプログラムコード自体を過度に修正する必要が無くなり、人手によるプログラムコードの修正誤りを未然に防ぐことができる。
したがって、処理対象のデータの文字コード体系がどのような文字コード体系に変更されたとしても、目的とする処理を確実に行うことができるように支援することができる。

本実施形態の具体的な用途について実施例１〜３として詳細に説明する。

［実施例１］
本実施形態の情報処理装置Ｐは、取り扱う文字コード体系によって処理単位が１バイト以上となる文字データであっても、処理単位が１バイトとなるバイナリデータであっても、編集ライブラリ３を用いて編集ツール５に同様にして編集処理させることができる。

ファイルｆ（バイナリファイル）中のバイナリデータ「0xFF,0x01」を編集ツール５が編集処理する場合について説明する。変更後の文字コード体系をＵＴＦ−３２（１文字を４バイトで表す）とし、ＤＡの各々の領域サイズを、一律に４バイトとする。この場合、１バイトのバイナリデータ２つ分となる「0xFF,0x01」は、ＤＡ設定部３１が設定した２つのＤＡに、例えば、「0x000000FF,0x00000001」としてそれぞれ格納される（格納形態はさまざまであり、１データ分を格納可能でありさえすれば、左記のものに限定しない）。また、編集ライブラリ３は、自身を呼び出した編集ツール５のプログラムコードの実行部分にて定義されているデータ項目をＦＡ設定部３２によって確認して、編集ツール５にはバイナリデータを送信する必要があることを知る。そのため、ＤＡに格納されるデータがバイナリデータであることを示すフラグとして、例えば「−１」を用いるとすれば、ＦＡ設定部３２は、２つの各ＤＡに対応する各ＦＡに「−１」を格納する。図３には、格納されたバイナリデータ「0xFF,0x01」にフラグ「−１」が割り当てられた様子が示されている。

よって、編集ライブラリ３は、ＦＡ読取部３３によって、ＦＡに格納された「−１」を取得することで、ＤＡに格納されたデータは、文字データではなく、バイナリデータであると判定することができ、ＤＡ読取部３４によってバイナリデータ「0xFF,0x01」として確実に取得することができる。つまり、ＤＡに格納済みの１バイトのバイナリデータ２つ分の「0xFF,0x01」を、４バイトの文字データ２つ分の「0x000000FF,0x00000001」（という値を持つ文字）として誤って取得してしまうことはなく、ＤＡへの格納時点のデータサイズおよびデータの種類と、ＤＡからの取得時点のデータサイズおよびデータの種類とが変化してしまうことはない。その結果、編集ライブラリ３は、バイナリデータ「0xFF,0x01」を編集ツール５に確実に送信することができる。

同様に、例えば、ＵＴＦ−３２において、“1”という半角文字を示す文字データ「0x00000031」（４バイト）は、例えば、「0x00000031」としてＤＡ（領域サイズは４バイトに設定）に格納される。この場合、ＦＡ設定部３２が編集ツール５のプログラムコードの実行部分にて定義されているデータ項目を確認することによって、編集ライブラリ３は、編集ツール５には文字データを送信する必要があることを知る。そのため、このＤＡに対応するＦＡには、半角文字であることを示すフラグ「０」が格納される。よって、編集ライブラリ３は、ＦＡ読取部３３によってＦＡに格納された「０」を取得することで、ＤＡに格納されたデータは、バイナリデータではなく、文字データであると判定することができ、ＤＡ読取部３４によって文字データ「0x00000031」（４バイト）として確実に取得することができる。つまり、ＤＡに格納済みの文字データ「0x00000031」（４バイト）を、１バイトのバイナリデータ「0x31」として誤って取得してしまうことはなく、ＤＡへの格納時点のデータサイズおよびデータの種類と、ＤＡからの取得時点のデータサイズおよびデータの種類とが変化してしまうことはない。その結果、編集ライブラリ３は、文字データ「0x00000031」を編集ツール５に確実に送信することができる。

もし、ＦＡを設定しない場合、編集処理を行う他の情報処理装置（例えば、本実施形態の情報処理装置Ｐが備える編集ライブラリ３の存在を知らない装置）とのデータのやり取りなどに問題が発生する。例えば、情報処理装置Ｐにて、KEIS（Kanji processing Extended Information System。文字ごとの表示幅とデータサイズとが同じとなる文字コード体系の１つ。）からＵＴＦ−１６（文字ごとの表示幅とデータサイズと間に所定の関係が無い文字コード体系の１つ）に変更された場合、ＤＡ設定部３１が設定するＤＡは、２バイト（または２バイト以上）となる。バイナリファイルから読み出したバイナリデータ「0x31」は、例えば、「0x0031」として１つのＤＡに格納される。このとき、ＦＡを設定せずに、ＤＡに格納されたデータが文字データであるかバイナリデータであるかを区別しないと、ＤＡから取得されるデータを「0x0031」としてしまい、本来格納したバイナリデータ「0x31」とは、データサイズが異なってしまう。結果的に、編集ツール５は、本来とは異なって取得したデータの編集処理をしてしまい、情報処理装置Ｐは、本来とは異なる処理結果を他の情報処理装置に出力してしまう。

実施例１によれば、編集ライブラリ３は、ＦＡを設定し、ＦＡに格納されたフラグを参照してＤＡに格納されたデータの種類を判定してから編集ツール５にデータを送信する。このため、処理対象のデータの文字コード体系がどのような文字コード体系に変更されたとしても、目的とする処理を確実に行うことができるように支援することができる。

［実施例２］
文字ごとの表示幅（桁数）とデータサイズ（バイト数）とが同じである変更前の文字コード体系の代表例であるShift-JISは、２桁からなる全角文字を２バイトで表している。この場合、１文字を表現するバイトの各々が何桁目であるか（桁順）を、バイトそのものを参照して特定することができた。文字を桁数で分類しておらず、文字ごとの表示幅とデータサイズとの間に所定の関係が無いＵＴＦ−３２などに単に変更した場合、ファイルｆから読み出した１バイトが何桁目であるかは、読み出したバイトそのものを参照しても特定することができない。

本実施形態の情報処理装置Ｐは、テキストファイルとなるファイルｆから文字データを読み出した場合、文字データが半角文字であるか全角文字であるかを区別できるようにするとともに、目的とする文字データを誤りなく取得するために読み出した文字データの桁順を保持可能となるようにＤＡおよびＦＡを設定する。

文字列「AB12あ9zzz」（「あ」以外の文字は半角文字、「あ」は全角文字）を編集ツール５が編集処理する場合について説明する。なお、例えば、変更後の文字コード体系をＵＴＦ−３２とした場合、各文字は４バイトデータであり、ＤＡの各々の領域サイズは例えば４バイトとする。この場合、編集ライブラリ３は、自身を呼び出した編集ツール５のプログラムコードの実行部分にて定義されているデータ項目をＦＡ設定部３２によって確認して、半角文字に対しては、半角文字であることを示すフラグ「０」をＦＡに格納する。

変更前の文字コード体系（例：Shift-JIS）では２桁で表現されていた全角文字「あ」に対しては、ＤＡを２つ用意し、「あ」の文字データを各ＤＡに冗長に格納することで、文字コード体系の変更前後における１文字の桁数を保持する。また、ＦＡ設定部３２は、左側のＤＡに格納された全角文字「あ」に対しては、全角文字の１桁目（左半分）を示す「１」をＦＡに格納するとともに、右側のＤＡに格納された全角文字「あ」に対しては、全角文字の２桁目（右半分）を示す「２」をＦＡに格納する。図４には、所定数並んだＤＡに「AB12あ9zzz」の文字列データを格納し、各文字にフラグ「０」、「１」、「２」が割り当てられた様子が示されている。
もし、変更前の文字コード体系が特定の１文字をｎ桁以上で表現していた場合には（ｎ＝１，２，３,・・・）、ＤＡをｎ個用意し、この特定の１文字の文字データをｎ個のＤＡに冗長に格納するとともに、この特定の１文字の桁順を表し、値がそれぞれ異なるｎ個のフラグをｎ個のＦＡに格納することができる。

したがって、ＦＡ読取部３３がＦＡからフラグを取得した場合、対応するＤＡ中の文字データが半角文字または全角文字であること、全角文字である場合何桁目であるかということがフラグを用いて判定することができる。よって、編集ライブラリ３は、ＦＡ読取部３３によってフラグを参照することで、ＤＡに格納された文字データの種類を高速に判定することができる。その結果、編集ライブラリ３は、編集ツール５に対して目的とする文字データを誤りなく送信することができる。

図４によれば、編集ライブラリ３が、左から６番目のＤＡに格納されている全角文字「あ」を取得しても、桁順までは（「あ」の１桁目であるか２桁目であるかは）わからない。桁順を知るには、左先頭からＤＡを順に調査する必要がある。本実施例では、左から６番目のＤＡに対応するＦＡのフラグ「２」を単独で取り出した時点で、ＤＡに格納されているデータは全角文字の２桁目であると、高速に判定することができる。また、文字列「あああああ」などのように同じ全角文字が連続する場合であっても、ＦＡのフラグを参照すれば、対応するＤＡ中の文字データ「あ」が１桁目（左半分）を表しているのか２桁目（右半分）を表しているのかを高速に判定することができる。

編集ツール５の編集処理において、テキストデータから読み出した文字データ「あ」の次の文字データ「い」を出力したい場合がある。例えば、文字コード体系がShift-JISである場合、「あ」の２桁目の値に２足す必要がある（「あ」の１桁目の値に２足すと別の文字を出力してしまう）。編集ライブラリ３は、まず、フラグ「２」のＦＡを取り出すことで、「あ」の２桁目（１桁目ではない）を高速に特定できるので、編集ツール５による文字データ「い」の出力を高速にすることができる。また、このような編集処理を行うプロゴラムコードのマイグレーションも容易にすることができる。

また、編集ライブラリ３が、左から５番目のＦＡに格納されているフラグ「１」を取得すれば、ＤＡに格納されているデータは全角文字の１桁目であることが高速に判定することができる。さらに、フラグ「１」の存在は、フラグ「２」の存在を高確率で約束するため、左から６番目のＤＡ中のデータ（２桁目）も取得する必要があると、高速に判定することができる。

［実施例３］
本実施形態のＤＡは、領域サイズを均一にし、データサイズの異なる文字データもバイナリデータも同様の格納形態をとることができ、変更後の文字コード体系においてデータの読み書きを容易にする利点を持つ。しかし、Unicodeは、Shift-JISやKEISと比較して、１文字を表現するバイト数が増大し、１文字あたりの平均データサイズが大きくなる。また、バイナリデータについては、領域サイズが複数バイト数に及ぶ１つのＤＡに１バイト分のデータを格納することになり、無駄が多い。このため、文字コード体系の変更前後で、同じデータを処理することになっても、文字コード体系の変更後は、編集ライブラリ３内でのＤＡへのアクセスバイト数が多くなり、多くのメモリ帯域リソースを使用してしまう。このことは、情報処理装置Ｐの性能の低下を招きかねない。

そこで、ＤＡに格納されるデータのうち、特定の値を有するデータについては、ＤＡ読取部３４によるそのデータへのアクセスを不要とし、対応するＦＡには、この特定の値を有するデータが格納されていることを示すフラグ（例えば「５」）を、ＦＡ設定部３２が格納するようにする。特定の値は編集処理上の頻出値とするのがよく、例えば、特定の値を有するデータとして、変数初期値としてよく用いられるバイナリデータ「0x00」を採り上げることができる。なお、変更後の文字コード体系は、例えばＵＴＦ−３２とし、ＤＡの領域サイズは、例えば４バイトとする。また、ＦＡの領域サイズおよびＦＡに格納されるフラグのデータサイズは４ビットとするが、フラグのデータサイズは、４ビットに限定されない。

図５に示すように、ＤＡ設定部３１によって２つのＤＡにバイナリデータ２つ分「0x00,0xAB」が格納されており、対応する２つのＦＡにはＦＡ設定部３２によってフラグ「５」が格納されている場合について説明する。ＦＡ読取部３３は、まず、ＦＡにアクセスし４ビットのフラグ「５」を取得する（図２のステップＳ０５参照）。この段階で、ＦＡ読取部３３は、フラグ「５」が格納されているＦＡに対応するＤＡには、バイナリデータ「0x00」が格納されているとみなし、ＤＡ読取部３４は、４バイトのＤＡにアクセスする処理を省略する（図２のステップＳ０６は省略する）。結果として、１つのＤＡにつき、アクセスバイト数を４バイトから４ビットに低減させることができる。なお、編集ライブラリ３は、バイナリデータ「0x00」を編集ツール５に送信する。

図５において、バイナリデータ「0xAB」が格納されているＤＡについても、対応するＦＡにフラグ「５」が格納されているため、ＦＡ読取部３３は、バイナリデータ「0x00」が格納されているとみなし、ＤＡ読取部３４によるＤＡへのアクセスは省略する。なお、編集ライブラリ３は、バイナリデータ「0x00」を編集ツール５に送信する。つまり、ＦＡ読取部３３は、実際に格納されているバイナリデータがどのようなものであれ、バイナリデータ「0x00」が格納されているとみなす。しかし、編集ツール５が行う編集処理には、バイナリデータの値そのものを問わない編集処理があり、そのような編集処理に対して、フラグ「５」を用いるという方法が有用である。前記編集処理としては、例えば、ＣＯＢＯＬのＩＮＩＴＩＡＬＩＺＥ命令などの、データ項目の値を特定の値に一度に大量に設定するものがある。また、特定の値として、ＣＯＢＯＬのLOW-VALUE（0x00）やHIGH-VALUE（0xFF）を採り上げることもできる。

したがって、実施例３によれば、特定の値を有するフラグをＦＡに格納することでＤＡにアクセスすることを省略することができる。このため、文字コード体系を変更して平均データサイズが大きくなったとしても、ＤＡへのアクセスバイト数の増大を抑えることができる。その結果、多くのメモリ帯域リソースを使用してしまい、情報処理装置Ｐの性能の低下を招くという事態を回避することができる。

なお、図５では、バイナリデータについて説明したが、文字データについても本実施例を適用することができる。例えば、上記した特定の値を半角の文字データ“0”（ＵＴＦ−３２では、「0x00000030」。ＵＴＦ−８では、「0x30」。）とすることができる。この場合、ＦＡにフラグ「５」が格納されているとき、対応するＤＡには、文字データ“0”が格納されているとみなし、ＤＡへのアクセスを省略することができる。

≪その他≫
（１）：本実施形態では、ＤＡ設定部３１によってＤＡに文字データが格納された場合には、ＤＡ読取部３４がＤＡから文字データを取得するようにし、ＤＡ設定部３１によってＤＡにバイナリデータが格納された場合には、ＤＡ読取部３４がＤＡからバイナリデータを取得するようにした。しかし、編集ツール５の編集処理の目的に応じて、ＤＡに文字データが格納された場合であっても、ＤＡからバイナリデータを取得することもできるし、ＤＡにバイナリデータが格納された場合であっても、ＤＡから文字データを取得することもできる。これらの場合であっても、対応するＦＡには、ＤＡに格納されたデータの種類を識別する正しいフラグが格納されているからである。

（２）：本実施形態では、Shift-JISなどの、１桁からなる半角文字を１バイトで表し、２桁からなる全角文字を２バイトで表す文字コード体系から、Unicodeなどに変更した場合において、ＦＡに格納するフラグとして、半角文字を示す「０」、全角文字の１桁目（左半分）を示す「１」、全角文字の２桁目（右半分）を示す「２」を用いた。しかし、各ＤＡに格納されている文字データ自体にアクセスすれば、半角文字を判定できることはできるし、全角文字を判定できることもできる（複数のＤＡに冗長に格納されるため、全角文字の桁順は不明）。よって、例えば、少なくとも全角文字の１桁目（左半分）または２桁目（右半分）にのみフラグを割り当てるようにし、他の文字データにはフラグを割り当てないようにすることで、ＤＡごとの文字データの分類を行うこともできる。

（３）：本実施形態では、実施例１〜３においてＦＡを、データの種類判定用（実施例１）、文字データの桁順の判定用（実施例２）、頻出する特定の値を有するデータの判定用（実施例３）として兼用し、作業領域４に設定した。しかし、例えば、ＦＡを実施例１〜３の用途に応じて個別に用意して作業領域４に設定することもできる。また、実施例１〜３のＦＡは、ＤＡに対応付けられていてもＤＡとは別体の格納領域として設定した。しかし、対応付けられたＤＡに含めるようにしてＦＡを設定することもできる。具体的には、文字コード体系をＵＴＦ−３２に変更した場合、４バイトの文字データの未使用分となる上位数ビットをＦＡとして活用し、フラグをその上位数ビットに格納してもよい。また、ＤＡの領域サイズを５バイトにし、４バイトの文字データを各ＤＡに格納するとともに、残りの１バイトをＦＡとして活用し、１バイト以下のフラグをその残りの１バイトに格納してもよい。このように、ＤＡおよびＦＡについてはさまざまな形態をとることができる。

（４）：ＤＡ設定部３１が作業領域４に設定する横並びのＤＡ（図１参照）について、図１の左側から右側に向かって、最上位のバイトから順に、該当するＤＡに格納したりＤＡから取得したりすることもできるし（ビッグエンディアン）、図１の左側から右側に向かって、最下位のバイトから順に、該当するＤＡに格納したりＤＡから取得したりすることもできる（リトルエンディアン）。よって、横並びのＤＡに対して、文字列データを格納したり取得したりする場合、全角文字を表すバイトの格納順序を、図４に示す全角文字「あ」のように、１桁目→２桁目という桁順と同じ順序にすることもできるし、２桁目→１桁目という桁順と逆の順序にすることもできる。上記説明は、ＦＡにも当てはまる。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

Ｐ 情報処理装置
１ 処理部
２ 記憶部
３ 編集ライブラリ
３１ ＤＡ設定部（データ格納領域設定部）
３２ ＦＡ設定部（フラグ格納領域設定部）
３３ ＦＡ読取部（フラグ格納領域読取部）
３４ ＤＡ読取部（データ格納領域読取部）
４ 作業領域
５ 編集ツール
ｆ ファイル
Ｔ 文字コード変換表

Claims (6)

1. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を設定するデータ格納領域設定部と、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて設定するフラグ格納領域設定部と、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取部と、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取部と、を備え、
   前記データは、前記変更後の文字コード体系において１文字を所定のデータサイズで表現する文字データ、または、バイナリデータであり、
   前記データ格納領域の前記領域サイズは、前記文字コード体系において表現され得る前記文字データのデータサイズの最大値と同じ値をとるサイズ、または、前記最大値よりも大きな値をとるサイズであり、
   前記フラグ格納領域に格納される前記フラグは、前記データ格納領域に格納されるデータが前記文字データであることを示すフラグ、および、前記データ格納領域に格納されるデータが前記バイナリデータであることを示すフラグ、を含む、
   ことを特徴とする情報処理装置。
2. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を設定するデータ格納領域設定部と、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて設定するフラグ格納領域設定部と、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取部と、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取部と、を備え、
   前記データが、前記変更後の文字コード体系において１文字を所定のデータサイズで表現する文字データである場合、
   前記データ格納領域設定部は、１文字を表現する前記文字データを、複数の前記データ格納領域の各々に冗長に格納することができ、
   前記フラグ格納領域に格納される前記フラグは、複数の前記データ格納領域の各々に冗長に格納された前記文字データの格納順序を識別するフラグを含む、
   ことを特徴とする情報処理装置。
3. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を設定するデータ格納領域設定部と、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて設定するフラグ格納領域設定部と、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取部と、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取部と、を備え、
   前記フラグ格納領域に格納される前記フラグは、前記データのうち特定の値を有するデータが、前記フラグ格納領域に対応付けられた前記データ格納領域に格納されているとみなすフラグ、を含む、
   ことを特徴とする情報処理装置。
4. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置における情報処理方法であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を、データ格納領域設定部が設定するステップと、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて、フラグ格納領域設定部が設定するステップと、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取ステップと、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取ステップと、を備え、
   前記データは、前記変更後の文字コード体系において１文字を所定のデータサイズで表現する文字データ、または、バイナリデータであり、
   前記データ格納領域の前記領域サイズは、前記文字コード体系において表現され得る前記文字データのデータサイズの最大値と同じ値をとるサイズ、または、前記最大値よりも大きな値をとるサイズであり、
   前記フラグ格納領域に格納される前記フラグは、前記データ格納領域に格納されるデータが前記文字データであることを示すフラグ、および、前記データ格納領域に格納されるデータが前記バイナリデータであることを示すフラグ、を含む、
   ことを特徴とする情報処理方法。
5. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置における情報処理方法であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を、データ格納領域設定部が設定するステップと、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて、フラグ格納領域設定部が設定するステップと、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取ステップと、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取ステップと、を備え、
   前記データが、前記変更後の文字コード体系において１文字を所定のデータサイズで表現する文字データである場合、
   前記データ格納領域設定部は、１文字を表現する前記文字データを、複数の前記データ格納領域の各々に冗長に格納することができ、
   前記フラグ格納領域に格納される前記フラグは、複数の前記データ格納領域の各々に冗長に格納された前記文字データの格納順序を識別するフラグを含む、
   ことを特徴とする情報処理方法。
6. 処理対象のデータの文字コード体系が変更され、変更後の文字コード体系を用いて前記データを処理する情報処理装置における情報処理方法であって、
   １データ分のデータを格納可能であり、各々で領域サイズが均一となるデータ格納領域を、データ格納領域設定部が設定するステップと、
   前記データ格納領域に格納されるデータの種類を識別するフラグを格納するフラグ格納領域を、前記データ格納領域に対応付けて、フラグ格納領域設定部が設定するステップと、
   前記フラグが格納された前記フラグ格納領域を読み取るフラグ格納領域読取ステップと、
   前記フラグ格納領域に対応付けて設定された前記データ格納領域を読み取るデータ格納領域読取ステップと、を備え、
   前記フラグ格納領域に格納される前記フラグは、前記データのうち特定の値を有するデータが、前記フラグ格納領域に対応付けられた前記データ格納領域に格納されているとみなすフラグ、を含む、
   ことを特徴とする情報処理方法。
   

Images