JP4718282B2 - 外字の処理システムおよび処理方法 - Google Patents

Description

本発明は、外字の処理システムおよび処理方法に関する。

氏名や住所等を扱うシステムでは、そのオペレーティングシステム（ＯＳ）が扱う文字コードで定義されていない文字を扱うことが必須であり、その文字コードのうち文字形状が定義されていない領域のコード、すなわち空いている領域のコードに、独自の文字の形状を登録して使用することが一般的である。これらの独自の文字のことをユーザ外字あるいは単に外字と読んでいる。これらの文字は、流通性がなく、そのシステム内の閉じた世界だけで使用できる文字である。

このような形式で構築されている複数のシステムから氏名や住所などのデータを受け取り、それを扱うシステムでは、それぞれのシステムごとに定義された外字データを受け取ることとなり、それらの異なる外字の同定作業を行い、当該システムで許容されている外字数の範囲内に収めなければならない。

このような問題を解決する手段として、特許文献１および２に開示される技術がある。特許文献１の文字処理装置は、コード体系変換テーブルおよび外字ファイルをそれぞれユーザごとに作成し、ユーザに応じてこれらを切り替えて使用するものである。また、特許文献２の外字拡張方式は、１つの文字コードに対して、ＯＳが持つ複数のフォントのそれぞれに異なる外字を定義し、固有の付加コードに応じてフォントを切り替えることにより、仮想的に外字数を拡張するものである。

特開平８―１７９９０５号公報 特開２０００―１８７６５４号公報

しかしながら、従来の方法においては、新しい外字を定義する際、関連するすべてのシステムおよび端末においてその外字を定義する必要、すなわち外字データをすべての表示用端末に対して流通させる作業を行う必要があり、ワークロードがかかるという問題があった。
たとえば、特許文献１の文字処理装置に端末を接続する場合は、文字処理装置と同様のコード体系変換テーブルおよび外字ファイルを、すべての端末に対してユーザごとに作成する必要がある。また、特許文献２の外字拡張方式では、付加コードの設定と、複数のフォントについての異なる外字の定義とを、すべての端末について行う必要がある。

この発明は、このような問題点を解決するためになされたものであり、新しい外字の定義に関連して各端末で発生する作業を不要とする外字の処理システムおよび処理方法を提供することを目的とする。

この発明に係る外字の処理システムは、複数の異なるシステムにおいてそれぞれ定義される固有外字コードを、共通外字コードに変換する、変換手段と、共通外字コードによって表される外字を含む文字列データを格納する、文字列データ格納手段と、外字に対応する画像データを格納する、画像データ格納手段と、外部から入力される、外字を含む文字列データと、外字に対応する画像データとを受け取り、それぞれを対応付けて、文字列データを文字列データ格納手段に、画像データを画像データ格納手段に格納する、データ取込手段と、外部からの出力要求に応じて、対応付けて格納された文字列データおよび画像データに基づき、表示用のデータを作成する、データ利用手段であって、表示用のデータは、文字列データのうち外字を除く部分の文字列データと、外字に対応する画像データとを含む、データ利用手段と、外部からの削除要求に応じて、対応付けて格納された文字列データおよび画像データを削除する、データ削除手段とを備え、文字列データ格納手段および画像データ格納手段は、それぞれレコードおよびカラムによって表される２次元表形式のテーブルを含む構造によって、文字列データおよび画像データを格納し、データ取込手段は、文字列データおよび画像データを対応付ける際に、文字列データ格納手段内で一意にテーブルを特定するテーブル名、テーブル内で一意にレコードを特定するＩＤ、レコード内で一意にカラムを特定するカラム名、および、カラムにおいて外字が含まれる文字位置を用いる。

外部からの出力要求は、テーブル名およびＩＤを含んでもよい。

また、この発明に係る外字の処理方法は、複数の異なるシステムにおいてそれぞれ定義される固有外字コードを、共通外字コードに変換し、共通外字コードによって表される外字を含む文字列データと、外字に対応する画像データとを受け取り、それぞれを対応付けて格納し、外部からの出力要求に応じて、対応付けて格納された文字列データおよび画像データに基づき、文字列データのうち外字を除く部分の文字列データと、外字に対応する画像データとを含む表示用のデータを作成し、外部からの削除要求に基づき、対応付けて格納された文字列データおよび画像データを削除する方法において、文字列データおよび画像データは、それぞれレコードおよびカラムによって表される２次元表形式のテーブルを含む構造によって格納され、文字列データおよび画像データを対応付ける際に、文字列データ格納手段内で一意にテーブルを特定するテーブル名、テーブル内で一意にレコードを特定するＩＤ、レコード内で一意にカラムを特定するカラム名、および、カラムにおいて外字が含まれる文字位置が用いられる方法である。

この発明によれば、外字の処理システムおよび処理方法は、外字を画像として扱うので、新しい外字の定義に関連して各端末で発生する作業を不要とすることができる。

以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１は、本発明の実施の形態１に係る、外字の処理システムである共同システム４を含む構成を示す。
共同システム４は、複数の自治体の住民情報を統合的に扱うシステムである。

ネットワーク１０を介して、共同システム４と電子的に通信可能に、それぞれ単一の自治体の住民情報を扱う個別システムである、Ａ市住民情報システム１、Ｂ市住民情報システム２、およびＣ市住民情報システム３が設置されている。
また、ネットワーク２０を介して、共同システム４と電子的に通信可能に、共同システム４を利用するための端末である、Ａ市端末５、Ｂ市端末６、およびＣ市端末７が設置されている。

住民情報システム１〜３、共同システム４、および端末５〜７は、それぞれ、演算手段であるＣＰＵと記憶手段であるメモリおよびＨＤＤ（ハードディスクドライブ）とを備え、周知の構成を有するコンピュータである。
また、住民情報システム１〜３、共同システム４、および端末５〜７は、それぞれ、平仮名・片仮名・および漢字を含む、日本語文字を表すコード体系であるＪＩＳコードを、文字コードとして扱う機能を有する。この機能は、たとえば、文字を表すコード体系に対応して、その文字の形状を現す文字パターンを、表示または印刷によって出力する機能である。
なお、住民情報システム１〜３、共同システム４、および端末５〜７は、周知のオペレーティングシステムを含むプログラムを実行することによって、上述の機能を実現するものであるが、文字を表すコードとしてＪＩＳコードを扱えるものであれば、オペレーティングシステムの種類に制限はなく、要件に応じて適宜選択されるものである。

また、住民情報システム１〜３、共同システム４、および端末５〜７が内部処理あるいは入出力に使用する文字コード体系は、たとえば、ＪＩＳコードである。ただし、これはＪＩＳコードの少なくとも一部と一対一に対応するコードを含む体系であれば他のものでもよく、いわゆるｕｎｉｃｏｄｅ等が使用されてもよい。住民情報システム１〜３、共同システム４、および端末５〜７のそれぞれにおいて、異なるコード体系が使用されてもよい。その際、住民情報システム１〜３、共同システム４、および端末５〜７は、あるコード体系においてある文字に対応するコードを、異なるコード体系において同一の文字に対応するコードに変換するものである。

住民情報システム１〜３は、それぞれ対応する自治体の住民情報を記憶している。住民情報には、各自治体の住民に関連する情報、たとえば氏名および住所が、各住民について含まれている。氏名および住所は、ＪＩＳコードによって表され、このコードを記憶手段に格納することにより、住民情報が記憶される。
また、共同システム４および端末５〜７は、それぞれ、ＪＩＳコードを含む文字コードによって表される文字および画像を含むデータ、たとえばＨＴＭＬ形式のデータの入出力を行う。また、ＨＴＭＬ形式のデータを、外部のネットワーク２０を介して送受信するためのプロトコル、たとえばＨＴＴＰプロトコルを使用可能である。

住民の氏名および住所の一部には、ＪＩＳコードに含まれない文字が使用されている。たとえば図２に示す文字は、「吉」の異体字である。「吉」では上側部分（部首でない部分）が「士」に近い形であり、上の横線が下の横線より長いが、図２に示す異体字では該当部分が「土」のように上の横線が下の横線より短くなっている。
このような文字はＪＩＳコードに含まれる文字と対応しておらず、ＪＩＳコードによって表すことができない。すなわち、ＯＳが扱う文字コードにおいて、対応する定義がなされていない。このため、住民情報システム１〜３それぞれにおいて、個別にユーザ定義文字、すなわち外字として登録される。

外字は、それぞれのシステムにおいて、それぞれの文字に対応する外字コードを用いて定義される。この外字コードを、以下「固有外字コード」と称する。固有外字コードとして使用されるコード領域は、ＪＩＳコードにおいて文字が定義されていないコード領域の一部である。
外字の登録がなされる際は、まず、固有外字コードが１つ選択され、登録される文字に割り当てられる。次に、その文字を表す文字パターンが、その固有外字コードと対応するものとして定義される。文字パターンは、ビットマップ形式の画像データである。

固有外字コード領域は、上述のようにＪＩＳコードが文字コード体系として使用されている場合には、１６進表記で２９２１〜２Ｆ７Ｅの一部および７５２１〜７Ｅ７Ｅの一部となるコードを含む領域となる。また、その他の文字コード体系の場合には、それぞれ固有の領域が定義されている。

Ａ市住民情報システム１の記憶手段には、図示しないが、住民情報として住所テーブルが格納されている。これは、Ａ市の各住民について、氏名と住所とを対応付けるものである。この住所テーブルは、たとえば一部の住民、すなわち特定の団体等に登録されている住民のみを含むものであるが、これはＡ市のすべての住民を含むものであってもよい。
この住所テーブルでは、氏名または住所にＪＩＳコードに含まれない文字を有する住民の情報は、固有外字コードに対応する外字を用いて格納されている。

Ｂ市住民情報システム２およびＣ市住民情報システム３も、それぞれＢ市およびＣ市の住民について、Ａ市住民情報システム１と同様の住所テーブルを格納している。ただし、住民情報システム１〜３の間では、同一の固有外字コードが異なる文字に対して割り当てられる場合がある。たとえば、ある単一の固有外字コードに対して、住民情報システム１、住民情報システム２、および住民情報システム３ではそれぞれ異なる文字パターンが定義されている。
なお、住民情報は、住所テーブル以外のテーブルを含んでもよい。たとえば、住民の氏名と本籍地とを対応付ける本籍地テーブルや、その他のテーブルが格納されていてもよい。

図３は、共同システム４の内部構成を概念的に示す図である。共同システム４は、上述のようにＣＰＵおよび記憶手段（いずれも図示せず）を含む。
ＣＰＵは、データ取込プログラムを実行することにより、データ取込手段４１として機能する。データ取込手段４１は、ネットワーク１０を経由して住民情報システム１〜３からデータを受け取り、住民情報を表す文字列データと、外字の文字パターンを表す画像データとに分けて、記憶手段たとえばＨＤＤに格納する。ここで、記憶手段は、文字列データ格納手段である住民情報テーブル４４と、画像データ格納手段であるビットマップ情報テーブル４５とを含む。

また、ＣＰＵは、データ利用プログラムを実行することにより、データ利用手段４２として機能する。データ利用手段４２は、ネットワーク２０を経由して端末５〜７からデータ出力要求を受け取り、住民情報テーブル４４およびビットマップ情報テーブル４５に基づいて表示データを作成し、ネットワーク２０を経由して要求元の端末５〜７に送信する。
さらに、ＣＰＵは、データ削除プログラムを実行することにより、データ削除手段４３として機能する。データ削除手段４３は、外部からの削除要求に応じて、共同システム４の住民情報テーブル４４およびビットマップ情報テーブル４５に格納されている情報の一部を削除する。

以上のように構成される共同システム４を含む構成における処理の流れを説明する。
まず、住民情報システム１〜３はそれぞれ、格納している住民情報を、共同システム４への入力ファイルとして、ネットワーク１０を経由して共同システム４に送信する。
この際、表形式のデータは、ＣＳＶ形式のファイルとして送信される。このＣＳＶ形式のファイルは、たとえば住所テーブルの場合、次のようなものである。
１行目：「住所テーブル」
２行目：「氏名，住所」
３行目：「Ｅ０００４５４４４２４０４Ｆ３Ａ，４５６Ｃ３５７Ｅ４５５４…，ＸＸＸＸＸＸ…」
４行目以降：（３行目と同様の形式）
入力ファイルの１行目の「住所テーブル」は、そのファイルが含む住民情報のテーブル名を表す文字列である。２行目の「氏名，住所」は、そのテーブルの各カラム名を表す文字列である。
なお、１行目および２行目の文字列は、上記のようにＣＳＶ形式のファイルの内容として含まれてもよいが、あらかじめ仕様として決められている場合には省かれてもよい。すなわち、上記ファイルの１行目および２行目を含まず、上記ファイルの３行目が１行目となるようなファイルでもよい。

３行目以降に各住民についての住民情報が含まれる。ここで、それぞれの住民情報は、文字列ではなく、１６進表記の文字コードに変換されている。さらに、固有外字コードについては、通常の文字を表さない所定のコードに変換されている。以下、この変換後の所定のコードを「共通外字コード」と称する。
たとえば、１６進４桁表記でＥ０００となるコードが共通外字コードとして使用される。この共通外字コードは、単一のコード、たとえばＥ０００のみが使用されてもよいし、複数のコード、たとえばＥ０００、Ｅ００１、Ｅ００２…が適宜使用されてもよい。
なお、住民情報は、このように文字列が１６進表記の文字コードに変換されたものでなく、該当の文字コードによって表される文字列そのものであってもよい。

さらに、住民情報に外字が含まれる場合は、該当する各行の末尾にビットマップを表すカラムが追加され、その文字パターンを表すビットマップのデータが含められる。このビットマップのデータは１６進表記の形式である。なお、外字が２文字以上含まれる場合は、その数に対応して追加されるカラムの数が増加する。

こうして作成される入力ファイルの３行目以降に含まれるデータの例は、上述のように「Ｅ０００４５４４４２４０４Ｆ３Ａ，４５６Ｃ３５７Ｅ４５５４…，ＸＸＸＸＸＸ…」となる。この行に該当する住民の氏名は４文字であるので、第１カラムは１６桁の１６進表記となる。なお、この住民の１文字目には外字が使用されていたため、１文字目の文字コードは共通外字コードＥ０００に変換されている。第２カラム「４５６Ｃ３５７Ｅ４５５４…」は住所に相当する１６進表記であるが、簡明のため後続の一部が省略されている。第３カラム「ＸＸＸＸＸＸ…」は実際には１６進表記のビットマップデータであり、たとえばこの住民の氏名の１文字目が図２に示す文字である場合、図２のパターンを表すビットマップデータとなる。なお、ビットマップデータは、ＢＤＦ形式などの統一された仕様を用いることを前提とする。
このように、入力ファイルは、外字を含む文字列データと、外字に対応する画像データとを含むデータとして作成される。

図４〜図６を用いて、上記のような入力ファイルを受信する際の、共同システム４のデータ取込手段４１の処理の流れを説明する。
図４は処理の流れを示すフローチャートであり、図５および図６は、それぞれ、データ取込手段４１によって作成される住民情報テーブル４４およびビットマップ情報テーブル４５の構造を示す図である。

まず、データ取込手段４１は、住民情報システム１〜３から送信される入力ファイルを受信する（ステップＳ１）。

次に、データ取込手段４１は、入力ファイルの３行目以降に基づき、該当のテーブルにレコードを追加する（ステップＳ２）。この際、住民ＩＤは、各テーブル内で固有となるよう、データ取込手段４１が採番する。
追加されるレコードには、ビットマップデータは含まれない。たとえば、図５のレコードＲ１は、上記の入力ファイルの３行目、すなわち「Ｅ０００４５４４４２４０４Ｆ３Ａ，４５６Ｃ３５７Ｅ４５５４…，ＸＸＸＸＸＸ…」というデータに相当するが、末尾のビットマップデータ「ＸＸＸＸＸＸ…」は削除されている。
なお、ここで追加されるレコードにおいて、１６進表記は図５に示すように４桁ごとに区切られ、データ取込手段４１、データ利用手段４２、およびデータ削除手段４３が、文字の区切りを認識できる形式となっている。
なお、データの形式は、このように文字列が１６進表記の文字コードに変換されたものでなく、該当の文字コードによって表される文字列そのものであってもよい。

次に、データ取込手段４１は、ステップＳ２において作成された住民情報テーブルおよび入力ファイルの３行目以降に基づき、ビットマップ情報テーブル４５にレコードを追加し、ビットマップデータに対応するバイナリ形式のデータを格納する（ステップＳ３）。ここで、ビットマップ情報テーブル４５自体は、図６に示されるようなレコードおよびカラムによって表される２次元表形式のテーブルを含むデータ構造として、あらかじめ作成されている。

たとえば、図５の住所テーブルのレコードＲ１には共通外字コードＥ０００を持つ文字が１つ含まれているので、これに対応して図６のビットマップ情報テーブル４５にレコードＲ２が１行追加される。レコードＲ２は、住民情報テーブル４４内におけるその外字の位置を示す情報、すなわち、テーブル名、住民ＩＤ、カラム名、および文字位置（該当カラムにおいて、その外字が何文字目かを表す自然数）と、その外字の文字パターンを表すバイナリ形式のビットマップデータとを対応付けるものである。
また、ビットマップ情報テーブル４５に格納される際に、ビットマップデータは１６進表記形式からバイナリ形式に変更されているが、これはデータ利用手段４２およびデータ削除手段４３が対応できる形式であればいかなるものでもよい。

なお、ここで、テーブル名は各テーブルに固有であり、住民ＩＤは各レコードに固有であり、カラム名は各カラムに固有である。すなわち、テーブル名は住民情報テーブル４４内で一意にテーブルを特定するものであり、住民ＩＤはテーブル内で一意にレコードを特定するものであり、カラム名はレコード内で一意にカラムを特定するものである。
また、以上の説明からわかるように、共通外字コードを含まない住民情報テーブルのレコードに対してはビットマップ情報テーブルのレコードは作成されず、共通外字コードを複数含む住民情報テーブルのレコードに対しては、その数に応じてビットマップ情報テーブルのレコードが複数作成される。

このようにして、データ取込手段４１は、入力ファイルに基づき、住民情報テーブル４４およびビットマップ情報テーブル４５にレコードを追加する。
図４に示すフローチャートは、入力ファイルの受信に応じて、既存のテーブルに新しいレコードが追加される場合に実行される。また、上記の説明からわかるように、新しいレコードに外字が含まれる場合でも、データ取込手段４１は共同システム４自身が使用する文字コード体系に対しては外字の定義を追加せず、住民情報テーブル４４およびビットマップ情報テーブル４５を更新するだけである。すなわち、入力ファイルにそれまで使用されていなかった新しい外字の定義が含まれていた場合であっても、入力ファイルの送信元であるシステムを除いて、その外字の定義はなされず、また必要とされない。

なお、図４に示すフローチャートは、住民情報テーブルがすべて事前（システムインストール時等）に作成されており、追加は不要である場合を想定している。そうではなく、作成されていない住民情報テーブルに関連するデータが入力される可能性がある場合には、データ取込手段４１は、ステップＳ１の後、ステップＳ２との間に、新しい住民情報テーブルを作成する処理を行うものであってもよい。これはたとえば次のようにして行われる。
データ取込手段４１は、入力ファイルの１行目に示されるテーブル名「住所テーブル」が、すでに作成されている住民情報テーブル４４内に含まれるかどうか、すなわち新規のテーブルかどうかを判定する。
もし新規のテーブルである場合は、データ取込手段４１は、入力ファイルの１行目および２行目に基づき、住民情報テーブル４４内に、レコードおよびカラムによって表される２次元表形式のテーブルを含むデータ構造として、図５に示すテーブルの枠組みを作成する。ここで、テーブル名は１行目の「住所テーブル」である。
カラム名は、第１カラムがそのテーブル内で各レコードに固有のＩＤを記録する「住民ＩＤ」となり、第２カラム以降に入力ファイルのカラム名が順に設定される。すなわち、作成されるテーブルの第１カラムは常に「住民ＩＤ」となり、作成されるテーブルの第２カラムは入力ファイルの第１カラムに対応して「氏名」となり、作成されるテーブルの第３カラムは入力ファイルの第２カラムに対応して「住所」となる。

図７に示すフローチャートを用いて、端末５〜７から住民情報に関する出力要求を受けた際の、データ利用手段４２の処理の流れを説明する。
まず、データ利用手段４２は、端末５〜７から、検索対象となるテーブル名および住民ＩＤを入力として受け取る（ステップＳ２１）。ここでは例として、端末５からの要求として、テーブル名「住所テーブル」および住民ＩＤ「００００１」が入力されたとする。

次に、データ利用手段４２は、該当のテーブル名を持つ住民情報テーブルにおいて、該当の住民ＩＤを持つレコードを検索し、そのレコードを取得する（ステップＳ２２）。上記の例では、図５のレコードＲ１、すなわち住民ＩＤ「００００１」、氏名「Ｅ０００ ４５４４ ４２４０ ４Ｆ３Ａ」、および住所「４５６Ｃ ３５７Ｅ ４５５４…」を取得する。

次に、データ利用手段４２は、取得したレコードに共通外字コードが含まれるかどうかを判定する（ステップＳ２３）。上記の例では氏名の１文字目に共通外字コードが含まれる。
ステップＳ２３において共通外字コードが含まれる場合、データ利用手段４２は、ビットマップ情報テーブル４５を検索し、同一の住民ＩＤを持つレコードをすべて取得する（ステップＳ２４）。上記の例では、該当する住民ＩＤ「００００１」が検索され、該当するレコードとしてレコードＲ２が取得される。
ステップＳ２３において共通外字コードが含まれない場合は、ステップＳ２４は実行されず、処理はステップＳ２５に進む。

データ利用手段４２は、ステップＳ２３で取得された住民情報テーブル４４のレコードに基づき、または、ステップＳ２３で取得された住民情報テーブル４４のレコードおよびＳ２４で取得されたビットマップ情報テーブル４５のレコードに基づき、要求元である端末５〜７において表示に使用するための、表示用のデータをＨＴＭＬ形式で作成する（ステップＳ２５）。
ここで、住民情報テーブル４４のレコードに含まれる文字コードを表す１６進表記の文字列は、その文字コードによって表される文字に置き換えられる。また、共通外字コードは、その外字に対応した画像、すなわちその共通外字コードが含まれる位置に対応したビットマップ情報テーブルのレコードに含まれるビットマップデータに置き換えられる。

上記の例では、表示用のデータに含まれる住民ＩＤは「００００１」という数字からなる文字列であり、住所は「４５６Ｃ ３５７Ｅ ４５５４ …」という文字コードにそれぞれ対応する文字からなる文字列である。また、氏名は、図２の文字パターンを表す画像、すなわち図６のレコードＲ２に含まれるビットマップデータ（ＨＴＭＬ形式においてＩＭＧタグによって記述される）の後に、「４５４４ ４２４０ ４Ｆ３Ａ」という文字コードに対応する文字からなる文字列が続く、画像と文字列とを組み合わせたデータとなる。

次に、データ利用手段４２は、ステップＳ２５で作成された表示用のデータを、要求元である端末５〜７に送信する（ステップＳ２６）。上記の例では、このデータは端末５に送信される。端末５はこのデータを受信し、これを表示または印刷等の方法によって出力する。

このようにして、データ利用手段４２は、テーブル名および住民ＩＤを入力として受け取り、これに該当する住民情報テーブル４４およびビットマップ情報テーブル４５のレコードに基づき、外字を画像として含む表示用のデータを作成して送信する。表示用のデータにおいて、文字列データは、外字に対応する部分を除いたものであり、画像データは、外字に相当する画像データである。これらを組み合わせて表示することにより、端末５〜７では、その端末に対してその外字が定義されていない場合であっても、外字が定義されている場合と同様の表示を行うことができる。

図８に示すフローチャートを用いて、住民情報の削除要求を受けた際の、データ削除手段４３の処理の流れを説明する。
まず、データ削除手段４３は、削除対象となるテーブル名および住民ＩＤを入力として受け取る（ステップＳ４１）。ここでは例として、テーブル名「住所テーブル」および住民ＩＤ「００００１」が入力されたとする。
なお、この削除対象の入力は、共同システム４において操作員が行うものであるが、これは他の手段による入力を受け付けるものであってもよい。たとえば、住民情報システム１〜３からの入力を受け付けてもよく、端末５〜７からの入力を受け付けても良い。

次に、データ削除手段４３は、住民情報テーブル４４内の該当のテーブルから、該当の住民ＩＤを持つレコードを削除する（ステップＳ４２）。上記の例では、図５において住民ＩＤ「００００１」を持つレコードＲ１が削除される。
次に、データ削除手段４３は、ビットマップ情報テーブル４５から、該当のテーブル名および住民ＩＤを持つレコードを削除する（ステップＳ４３）。上記の例では、図６においてテーブル名「住所テーブル」および住民ＩＤ「００００１」を持つレコードＲ２が削除される。
このように、データ削除手段４３は、テーブル名および住民ＩＤを入力として受け取り、これに該当する住民情報テーブル４４およびビットマップ情報テーブル４５のレコードを削除する。

以上説明したように、この発明によれば、共同システム４は、入力ファイルに含まれる外字を画像として記憶手段に格納し、その外字を出力する要求が外部のシステムからあった際には、外字に対応する画像と、外字以外の文字とを含む表示用のデータを作成する。このため、要求元の端末では、その画像および文字をそのまま表示すればよく、端末ごとの特別なフォントの定義や特別な機能の導入が不要となる。よって、この外字の処理システムおよび処理方法は、新しい外字の定義に関連して端末で発生する作業を不要とすることができる。
また、要求元の端末では外字の定義を追加する必要がないので、ＯＳの外字文字数の制限に依存せずに表示を行うことができるようになる。さらに、このため、異なる外字体系のシステムからデータを流用する際に、外字の同定作業を不要とすることができる。

上述の実施の形態１において、住民情報システム１〜３から共同システム４への入力ファイルの送信は、ネットワーク１０を介して行われている。これは他のファイル伝達手段が用いられてもよく、たとえば持ち運び可能な記憶媒体によってもよい。
また、入力ファイルは、外字に共通外字コードを使用した文字列データと、外字の画像データとが対応付けられた形式であれば、ＣＳＶ形式のファイルでなくともよい。
また、住民情報システム１〜３は、自治体に関連するものでなくともよく、たとえば企業等がその内部において、または外部に向けて使用するシステムであってもよい。

本発明の実施の形態１に係る共同システム４を含む構成を示す図である。 外字の例を示す図である。 本発明の実施の形態１に係る共同システム４の構成を示す図である。 本発明の実施の形態１に係るデータ取込手段４１の処理の流れを示すフローチャートである。 本発明の実施の形態１に係る住民情報テーブル４４の構造を示す図である。 本発明の実施の形態１に係るビットマップ情報テーブル４５の構造を示す図である。 本発明の実施の形態１に係るデータ利用手段４２の処理の流れを示すフローチャートである。 本発明の実施の形態１に係るデータ削除手段４３の処理の流れを示すフローチャートである。

符号の説明

４ 外字の処理システム（共同システム）、４１ データ取込手段、４２ データ利用手段、４３ データ削除手段、４４ 文字列データ格納手段（住民情報テーブル）、４５ 画像データ格納手段（ビットマップ情報テーブル）、Ｒ１，Ｒ２ レコード。

Claims (3)

1. 複数の異なるシステムにおいてそれぞれ定義される固有外字コードを、共通外字コードに変換する、変換手段と、
   前記共通外字コードによって表される外字を含む文字列データを格納する、文字列データ格納手段と、
   前記外字に対応する画像データを格納する、画像データ格納手段と、
   外部から入力される、前記外字を含む文字列データと、前記外字に対応する画像データとを受け取り、それぞれを対応付けて、前記文字列データを前記文字列データ格納手段に、前記画像データを前記画像データ格納手段に格納する、データ取込手段と、
   外部からの出力要求に応じて、前記対応付けて格納された前記文字列データおよび前記画像データに基づき、表示用のデータを作成する、データ利用手段であって、前記表示用のデータは、前記文字列データのうち外字を除く部分の文字列データと、前記外字に対応する画像データとを含む、データ利用手段と、
   外部からの削除要求に応じて、前記対応付けて格納された前記文字列データおよび前記画像データを削除する、データ削除手段と
   を備え、
   前記文字列データ格納手段および前記画像データ格納手段は、それぞれレコードおよびカラムによって表される２次元表形式のテーブルを含む構造によって、前記文字列データおよび前記画像データを格納し、
   前記データ取込手段は、前記文字列データおよび前記画像データを対応付ける際に、前記文字列データ格納手段内で一意に前記テーブルを特定するテーブル名、前記テーブル内で一意に前記レコードを特定するＩＤ、前記レコード内で一意に前記カラムを特定するカラム名、および、前記カラムにおいて前記外字が含まれる文字位置を用いる、外字の処理システム。
2. 前記外部からの出力要求は、前記テーブル名および前記ＩＤを含む、請求項１に記載の外字の処理システム。
3. 複数の異なるシステムにおいてそれぞれ定義される固有外字コードを、共通外字コードに変換し、
   前記共通外字コードによって表される外字を含む文字列データと、前記外字に対応する画像データとを受け取り、それぞれを対応付けて格納し、
   外部からの出力要求に応じて、前記対応付けて格納された前記文字列データおよび前記画像データに基づき、前記文字列データのうち外字を除く部分の文字列データと、前記外字に対応する画像データとを含む表示用のデータを作成し、
   外部からの削除要求に基づき、前記対応付けて格納された前記文字列データおよび前記画像データを削除する
   外字の処理方法において、
   前記文字列データおよび前記画像データは、それぞれレコードおよびカラムによって表される２次元表形式のテーブルを含む構造によって格納され、
   前記文字列データおよび前記画像データを対応付ける際に、前記文字列データ格納手段内で一意に前記テーブルを特定するテーブル名、前記テーブル内で一意に前記レコードを特定するＩＤ、前記レコード内で一意に前記カラムを特定するカラム名、および、前記カラムにおいて前記外字が含まれる文字位置が用いられる
   外字の処理方法。

Images