JP6524887B2 - 文字コード処理プログラム、情報処理装置、及び文字コード処理方法 - Google Patents

Description

本発明は、文字コード処理プログラム、情報処理装置、及び文字コード処理方法に関する。

プログラムで文字列が扱われる場合、文字列に使用する言語、文字の種類、１文字あたりのバイト数等の種々の条件に応じて適切な文字コード体系が選択される。

一例として、ＣＯＢＯＬ（Common Business Oriented Language）プログラムでは文字コード体系としてシフトＪＩＳ（Shift_JIS）が用いられることがある。シフトＪＩＳでは、ひらがな、カタカナ、及び漢字等の日本語文字が１文字２バイトで表現されるが、半角カナは１文字１バイトで表現される。シフトＪＩＳでは少ないバイト数で半角カナを表現できるため、ＣＯＢＯＬプログラムではこのような特性を利用するために半角カナが用いられることが多い。

なお、関連する技術として、シフトＪＩＳの１バイトコード表（図２９の左側参照）を固有の文字コード体系（図２９の右側参照）に変換して処理し、表示又は印刷の前に復元する技術も知られている。固有のコード体系では、半角英数字及び半角カナのコード域を移動して連続領域とし、さらに全角文字のコード域も移動し、シフトＪＩＳコードの文字範囲に加えて拡張文字も同時に扱うことができる。なお、図２９に例示する１バイトコード表において、縦軸は１バイトの上位４ビットを表し、横軸は１バイトの下位４ビットを表す。

特開平２−２５７２７６号公報

ところで、近年、表現可能な文字の種類を広げるために、シフトＪＩＳからＵｎｉｃｏｄｅへの移行が進んでいる。

Ｕｎｉｃｏｄｅ、例えばＵＴＦ−８（Unicode Transformation Format-8）では、半角カナは１文字３バイトで表現される。このため、プログラムで用いる文字コードをシフトＪＩＳからＵｎｉｃｏｄｅへ移行させるためには、文字コード体系における領域拡張や文字コードの認識のロジック変更を行なう。このように、文字コードの変更に伴い既存のプログラムを変更することになり、プログラムの改修コストが発生してしまう。

なお、図２９に例示する手法では、変換前の文字（例えば“A”）と変換後の文字（例えば“a”）とが同じ文字コード“0x41”で表される。また、図３０に例示するように、変換後の文字の文字コードの組み合わせが別の文字に割り当てられている場合もある。そこで、図２９に例示する手法では、処理対象となる文字コードが変換前後のいずれの文字であるかを管理する。

しかし、文字コードの変換前後の管理を行なったとしても、変換後の文字列をファイル等の記憶装置に保存した後、利用者が誤って変換後の文字列を変換前の文字列として入力してしまった場合、プログラムが誤動作し得る。

例えば図３１に示すように、圧縮前データに圧縮後の半角カナ文字“イ”（コード“0x72”）を挿入して混合データとした場合や、圧縮後データに圧縮前の半角カナ文字“イ”（コード“0xB2”）を挿入して混合データとした場合、圧縮又は復元によって文字列の少なくとも一部が破壊され得る。

上述した不都合の発生は、プログラムで用いる文字コードを他の文字コードへ移行させる場合に限定されるものではなく、プログラムの開発又は運用等における他の場面でも同様に生じ得る。また、上述した不都合の発生は、半角カナの文字コードを圧縮又は復元する場合に限定されるものではなく、他の文字種の文字コードを圧縮又は復元する場合においても同様に生じ得る。

１つの側面では、本発明は、文字コードのバイト数を削減することを目的とする。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

１つの態様では、本件の文字コード処理プログラムは、コンピュータに以下の処理を実行させる。前記処理は、記憶部に記憶された、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を参照することを含む。また、前記処理は、バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈することを含む。

１つの側面では、文字コードのバイト数を削減することができる。

ＥＵＣの１バイトコード表を示す図である。 比較例に係る圧縮手法を説明する図である。 比較例において圧縮後のバイト列が全角漢字のバイト列と混在する場合を示す図である。 比較例において圧縮後のバイト列が全角漢字のバイト列と混在する場合を示す図である。 ＵＴＦ−８の１バイトコード表を示す図である。 一実施形態に係るシステムの構成例を示す図である。 一実施形態に係る処理装置のハードウェア構成例を示す図である。 第１の手法の一例を示す図である。 第１の手法に係る圧縮情報の一例を示す図である。 第１の手法に係る復元情報の一例を示す図である。 第２の手法の一例を示す図である。 第２の手法に係る圧縮情報の一例を示す図である。 第２の手法に係る復元情報の一例を示す図である。 一実施形態に係る圧縮手法の一例を説明する図である。 一実施形態に係る変換前後の文字コードの一例を示す図である。 一実施形態において圧縮後のバイト列が全角漢字のバイト列と混在する場合を示す図である。 混合データが生成される場合の一例を示す図である。 混合データに対して圧縮又は復元を行なう場合の一例を示す図である。 コンパイラの処理の一例を説明するフローチャートである。 アプリケーションの処理の一例を説明するフローチャートである。 ランタイムシステムの処理の一例を説明するフローチャートである。 ランタイムシステムの処理の一例を説明するフローチャートである。 ランタイムシステムの処理の一例を説明するフローチャートである。 ランタイムシステムの処理の一例を説明するフローチャートである。 圧縮処理部による圧縮処理の一例を説明するフローチャートである。 圧縮処理部による圧縮処理の一例の詳細を説明するフローチャートである。 復元処理部による復元処理の一例を説明するフローチャートである。 復元処理部による復元処理の一例の詳細を説明するフローチャートである。 シフトＪＩＳの１バイトコード表を固有の文字コード体系に変換する手法の一例を説明する図である。 図２９に示す手法に係る変換前後の文字コードの一例を示す図である。 図２９に示す手法において混合データに対して圧縮又は復元を行なう場合の一例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。また、以下の説明では、“ア”のように全角カナをダブルクォーテーションで囲うことによって半角カナを表現する。

〔１〕比較例
はじめに、比較例について説明する。なお、以下の説明では、半角カナを２バイトで表現するＥＵＣ−ＪＰ（Extended UNIX（登録商標） Code Packed Format for Japanese）（以下、単にＥＵＣと表記する）の文字コード体系において、ＣＯＢＯＬプログラムの改修を行なわずに、半角カナを１バイトで扱う場合を例に挙げる。

ＥＵＣの１バイトコード表を図１に例示する。ＥＵＣの半角カナは、上位バイト“8E”（１６進表記、以下同様）に続き、下位バイト“A1”〜“DF”で表現されるという特性がある。比較例では、この特性を利用して、上位バイト“8E”を除いた１バイト“A1”〜“DF”を半角カナとみなす変換規則を採用する。なお、図１に例示する１バイトコード表において、縦軸は１バイトの上位４ビットを表し、横軸は１バイトの下位４ビットを表す。

一例として、ＥＵＣの半角カナ文字“テスト”に対して変換規則を適用し、文字コードを圧縮及び復元する場合を説明する。なお、文字コードの圧縮及び復元は、ＣＯＢＯＬプログラムの開発環境におけるコンパイラ又は運用環境におけるランタイムシステム等にそなえられる圧縮処理部及び復元処理部により行なうことができる。

図１に示すように、ＥＵＣにおける半角カナ“テスト”のそれぞれの文字は、“8E C3”、“8E BD”、“8E C4”の２バイトの文字コードで表現される。圧縮処理部は、比較例に係る変換規則によりこれらの２バイトの文字コードから上位バイト“8E”を除去し、それぞれ“C3”、“BD”、“C4”の１バイトの文字コードに圧縮することができる。

しかしながら、圧縮後の“テス”を表すバイト列“C3 BD”は、図２に示す全角漢字のコードと完全一致する。このため、圧縮後のバイト列からは“テス”であるのか図２に示す全角漢字であるのかの判断が困難となり、以下の（ａ）及び（ｂ）の不都合が生じ得る。

（ａ）同時に処理可能な文字の種類が制限される。
例えば図３に示すように、圧縮後のバイト列が全角漢字のバイト列と混在する場合、復元処理部によって正しく復元することが困難となる。上述のように、圧縮後のバイト列と全角漢字のバイト列とが完全一致する場合があり、復元の際に半角カナであるのか全角漢字であるのかの判断が困難となるからである。

なお、英数字を表すＡＳＣＩＩ（American Standard Code for Information Interchange）の文字コードの範囲（“20”〜“7F”）は、圧縮後のバイト列の文字コードの範囲（“A1”〜“DF”）とは重ならない。従って、比較例に係る手法では、圧縮処理部及び復元処理部により処理可能な文字は半角カナ及び英数字（ＡＳＣＩＩ）となる。換言すれば、半角カナ及び英数字については混在することが許容されるため、利用者による運用によっては比較例に係る手法を利用することも可能である。

（ｂ）各々の文字列に対して圧縮済か否かを管理する。
例えば図４に示すように、圧縮後のバイト列が全角漢字のバイト列と混在する場合、圧縮処理部による再圧縮（各文字コードからの“8E”の除去）又は復元処理部による復元（各文字コードへの“8E”の付加）によって、文字列が壊れる場合がある。このように、圧縮及び復元を行なう文字列に含める文字種を半角カナ及び英数字に制限したとしても、利用者の使用法誤解等によって「漢字との混在」、「圧縮前後の文字の混在」、「再圧縮又は再復元」等が生じた場合には、データ破壊に繋がる虞がある。

文字ごとに圧縮状態を管理することで、このような文字列の破壊を避けることはできるが、圧縮状態を管理するために処理性能の低下や記憶領域の圧迫等、利用可能なリソースの低下が生じ得る。

以上のように、比較例として挙げた手法では、半角カナ等の特定の文字種を圧縮及び復元する際に、同時に処理可能な文字が制限され、圧縮状態を管理するためのリソースを消費することになる。

〔２〕一実施形態
そこで、一実施形態では、以下の手法により、上述した不都合を解消しつつ文字コードのバイト数を削減する。なお、以下の説明では、半角カナを３バイトで表現するＵＴＦ−８の文字コード体系において半角カナを１バイトで扱う場合を例に挙げる。

図５はＵＴＦ−８のバイトコード表を例示する図である。なお、図５に例示する１バイトコード表において、縦軸は１バイトの上位４ビットを表し、横軸は１バイトの下位４ビットを表す。図５に例示するように、“00”〜“1F”（１６進表記、以下同様）は「制御コード」、“20”〜“7F”は「ＡＳＣＩＩ」、“80”〜“BF”は「多バイト文字の２バイト目以降のバイトコード」、“C0”〜“DF”は「２バイト文字の開始バイト」である。また、“E0”〜“EF”は「３バイト文字の開始バイト」、“F0”〜“F7”は「４バイト文字の開始バイト」、“F8”〜“FB”は「５バイト文字の開始バイト」、“FC”〜“FD”は「６バイト文字の開始バイト」である。

ここで、「多バイト文字の２バイト目以降のバイトコード」は、２バイト以上の文字の２バイト目以降で用いられるバイトコードであり、文字コードの先頭では用いられない。換言すれば、「多バイト文字の２バイト目以降のバイトコード」が文字コードの先頭で用いられる場合、当該文字コードと他の文字の文字コードとの混同が生じない。

そこで、一実施形態においては、半角カナの文字コードを変換規則に基づき「多バイト文字の２バイト目以降のバイトコード」域に割り当てることにより、３バイトの文字コードから１バイトの文字コードへの圧縮を行なう。

換言すれば、変換規則は、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報である。

これにより、半角カナ以外の他の文字種との混合を可能とし、圧縮及び復元において処理可能な文字種の制限を無くすことができる。また、圧縮済の文字コードを判別できるため、圧縮又は復元等を正しく行なうことができ、圧縮状態の管理が不要となることでリソースを効率的に利用することができる。従って、上述した不都合を解消しつつ文字コードのバイト数を削減することができる。

さらに、文字コード体系を例えばシフトＪＩＳからＵＴＦ−８に変更する場合、開発環境のコンパイラ及び運用環境のランタイムシステムに文字コードの圧縮及び復元に関する修正を加えればよい。このように、既存のプログラムの改修が不要であるため、改修コストを削減することができる。

〔２−１〕一実施形態に係るシステムの構成例
図６は一実施形態に係るシステム１の構成例を示す図である。システム１は、プログラム、例えばＣＯＢＯＬプログラムの開発環境及びコンパイルされたプログラムを利用して運用を行なう運用環境をそなえてよい。図６に示すように、情報処理システム１は、例示的に、少なくとも１つ（図６では２つ）の処理装置２及び３をそなえる。

処理装置２はプログラムの開発環境を提供する情報処理装置の一例であり、処理装置３はプログラムの運用環境を提供する情報処理装置の一例である。なお、システム１に複数の処理装置３がそなえられてもよい。また、処理装置２及び１以上の処理装置３の機能は、１以上の装置で実行されるアプリケーション又は仮想マシン（ＶＭ；Virtual Machine）として実現されてもよい。処理装置２及び３としては、例えばサーバやPersonal Computer（ＰＣ）等の装置が挙げられる。

処理装置２及び３の各々は、互いに同様のハードウェア構成をそなえることができる。以下、処理装置２及び３を区別しない場合には、処理装置５と表記する。処理装置５は、図７に例示するように、ＣＰＵ（Central Processing Unit）５ａ、メモリ５ｂ、記憶部５ｃ、インタフェース部５ｄ、入出力部５ｅ、及び読取部５ｆをそなえる。

ＣＰＵ５ａは、種々の制御や演算を行なう演算処理装置（プロセッサ）の一例である。ＣＰＵ５ａは、処理装置５内の各ブロックとバスで相互に通信可能に接続されてよい。なお、演算処理装置としては、ＣＰＵ５ａに代えて、電子回路、例えばＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路（ＩＣ）が用いられてもよい。

メモリ５ｂは、種々のデータやプログラムを格納するハードウェアの一例である。メモリ５ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。

記憶部５ｃは、種々のデータやプログラム等を格納するハードウェアの一例である。なお、図６に示す記憶装置４２及び４５は記憶部５ｃによって実現されてもよい。記憶部５ｃとしては、例えばＨＤＤ（Hard Disk Drive）等の磁気ディスク装置、ＳＳＤ（Solid State Drive）等の半導体ドライブ装置、フラッシュメモリやＲＯＭ（Read Only Memory）等の不揮発性メモリ等の各種記憶装置が挙げられる。

例えば記憶部５ｃは、処理装置２又は３の各種機能の全部若しくは一部を実現する処理プログラム５０を格納することができる。ＣＰＵ５ａは、例えば記憶部５ｃに格納された処理プログラム５０をメモリ５ｂに展開して実行することにより、処理装置２又は３の機能を実現することができる。なお、処理装置２及び３が別個の装置により実現される場合には、処理プログラム５０はこれらの機能に分割されてそれぞれ処理装置２及び３に提供されてもよいし、処理装置２及び３の双方に処理プログラム５０が提供されてもよい。

インタフェース部５ｄは、他の処理装置５や、図示しないネットワーク又は作業者の作業端末等との間の接続及び通信の制御等を行なう通信インタフェースの一例である。例えばインタフェース部５ｄは、ＬＡＮ（Local Area Network）、ＳＡＳ、ＦＣ（Fibre Channel）、インフィニバンド（InfiniBand）、ＵＳＢ（Universal Serial Bus）、ＢＬＵＥＴＯＯＴＨ（登録商標）、パラレルバス等に準拠したアダプタが挙げられる。なお、ＳＡＳはSerial Attached SCSI（Small Computer System Interface）の略称である。

なお、処理プログラム５０、プログラム２１、又はコンパイルされたプログラム２１（アプリケーション３１）は、図示しないネットワークからインタフェース部５ｄを介して処理装置５にダウンロードされてもよい。

入出力部５ｅは、マウス、キーボード、操作ボタン等の入力部（例えば図６の入力装置４１）、並びにディスプレイやプリンタ等の出力部（例えば図６の表示装置４３及び印刷装置４４）の少なくとも一部を含むことができる。例えば入力部は、利用者によるアプリケーション３１への設定の登録や変更、パラメータ入力等の各種操作に用いられてもよく、出力部は、アプリケーション３１からの出力結果の表示等に用いられてもよい。

読取部５ｆは、記録媒体５ｇに記録されたデータやプログラムを読み出すリーダの一例である。読取部５ｆは、コンピュータ読取可能な記録媒体５ｇを接続又は挿入可能な接続端子又は装置を含んでよい。読取部５ｆとしては、例えばＵＳＢ等に準拠したアダプタ、記録ディスクへのアクセスを行なうドライブ装置、ＳＤカード等のフラッシュメモリへのアクセスを行なうカードリーダ等が挙げられる。なお、記録媒体５ｇには処理プログラム５０が格納されてもよい。

上述した処理装置５のハードウェア構成は例示である。従って、他の処理装置５間、又は、処理装置５内でのハードウェアの増減（例えば任意のブロックの追加や省略）、分割、任意の組み合わせでの統合、バスの追加又は省略等は適宜行なわれてもよい。

図６の説明に戻り、処理装置２は、例示的に、プログラム２１及びコンパイラ２２をそなえる。プログラム２１は所定の機能を実現するコンピュータプログラムの一例である。一実施形態において、プログラム２１は、例えば文字コード体系としてＵＴＦ−８を採用したＣＯＢＯＬプログラムである。プログラム２１は、圧縮及び復元対象となる所定の文字列、例えば半角カナの文字種の文字列をソースコード内に含んでもよく、当該所定の文字列が、プログラム２１に入力される文字列又はプログラム２１の出力する文字列として許容されてもよい。

コンパイラ２２は、プログラム２１のコンパイルを行なうソフトウェアの一例である。一実施形態において、コンパイラ２２は、例えばＣＯＢＯＬコンパイラである。

コンパイラ２２は、例示的に、定数取出部２３、圧縮処理部２４、及びオブジェクトファイル出力処理部２５をそなえる。

定数取出部２３は、プログラム２１から定数を取り出して圧縮処理部２４へ出力する。定数取出部２３がプログラム２１から取り出す定数には、例えば圧縮及び復元対象となる所定の文字列が含まれてよい。

圧縮処理部２４は、定数取出部２３から入力される定数を所定の変換規則に基づき圧縮し、圧縮した定数をプログラム２１とともにオブジェクトファイル出力処理部２５へ出力する。圧縮処理部２４による圧縮処理では、図６に示す圧縮情報２４ａが参照されてもよい。なお、圧縮処理部２４による圧縮処理の詳細については後述する。

オブジェクトファイル出力処理部２５は、圧縮処理部２４から入力されるプログラム２１をコンパイルし、コンパイルして得られるオブジェクトファイルに圧縮された定数を格納して処理装置３へ出力する。オブジェクトファイル出力処理部２５によるコンパイルでは、プログラム２１のソースコードを解析して、コンピュータにより実行可能な形式のオブジェクトファイルに変換する処理が行なわれる。なお、コンパイルは既知の種々の手法により行なうことが可能であり、その詳細な説明は省略する。

なお、上述したプログラム２１及びコンパイラ２２等のコンピュータプログラム、並びに圧縮情報２４ａ等の情報は、例えばメモリ５ｂ又は記憶部５ｃの記憶領域に記憶されてよい。

処理装置３は、例示的に、アプリケーション３１、ランタイムシステム３５、入力装置４１、記憶装置４２及び４５、表示装置４３、並びに印刷装置４４をそなえる。

アプリケーション３１は、ＣＰＵ５ａによって実行されることにより所定の機能を実現するソフトウェアの一例であり、コンパイラ２２から出力されるオブジェクトファイルの一例である。一実施形態において、アプリケーション３１は、例えばＣＯＢＯＬアプリケーションである。

アプリケーション３１は、例示的に、外部入力要求部３２、データ操作部３３、及び外部出力要求部３４をそなえる。

外部入力要求部３２は、ランタイムシステム３５に対してアプリケーション３１への種々の入力を要求する。入力の要求には、ディスプレイ等の表示装置に画面入力又は外部入力を促す表示を行なう入力画面の情報が含まれてもよい。なお、アプリケーション３１への入力には、利用者からの画面操作による指示やパラメータのほか、文字列やデータ等のファイルが含まれてよい。

データ操作部３３は、外部入力要求部３２により取得された入力情報に基づき所定の操作を行なうことにより、アプリケーション３１に設定された所定の機能を実現する。なお、データ操作部３３の処理の過程で新たな入力情報がリクエストされる場合には、外部入力要求部３２によってランタイムシステム３５に対して新たな入力が要求されてもよい。

外部出力要求部３４は、ランタイムシステム３５に対してデータ操作部３３の実行結果の出力を要求する。アプリケーション３１からの出力態様には、画面出力や印刷、データの格納等が含まれてよい。

ランタイムシステム３５は、アプリケーション３１の実行環境を提供するソフトウェアの一例である。ランタイムシステム３５は、例示的に、入力処理部３６、圧縮処理部３７、出力処理部３８、及び復元処理部３９をそなえる。

入力処理部３６は、アプリケーション３１からの要求に応じて入力情報を取得し、外部入力要求部３２へ応答する。一例として、入力処理部３６は、画面入力部３６ａ及び外部入力部３６ｂをそなえる。

画面入力部３６ａは、ディスプレイ等の出力装置に対して指示又はパラメータ等の入力情報の入力画面を表示させ、入力装置４１に入力された入力情報を取得することができる。外部入力部３６ｂは、記憶装置４２等から入力されるファイルを入力情報として取得することができる。

圧縮処理部３７は、入力処理部３６により入力装置４１又は記憶装置４２等から取得された入力情報に含まれる所定の文字列を所定の変換規則に基づき圧縮し、所定の文字列を圧縮した入力情報を入力処理部３６へ出力する。圧縮処理部３７による圧縮処理では、図６に示す圧縮情報３７ａが参照されてもよい。圧縮処理は、コンパイラ２２がそなえる圧縮処理部２４の圧縮処理と同様であってよい。なお、例えば記憶装置４２から取得された入力情報に含まれる所定の文字列が圧縮後の状態である場合には、圧縮処理部３７による圧縮処理が省略されてもよい。圧縮処理部３７による圧縮処理の詳細については後述する。

出力処理部３８は、アプリケーション３１からの要求に応じて、指定された態様で出力結果を含む出力情報を出力装置、例えば表示装置４３、印刷装置４４、及び記憶装置４５の少なくとも１つへ出力する。一例として、出力処理部３８は、画面出力部３８ａ、印刷出力部３８ｂ、外部出力部３８ｃをそなえる。

画面出力部３８ａは、出力結果を含む出力画面を生成してディスプレイ等の表示装置４３に対して出力画面を表示させることができる。印刷出力部３８ｂは、出力結果を含む印刷レイアウトを生成して印刷装置４４に印刷させることができる。外部出力部３８ｃは、出力結果を含む出力ファイルを生成して記憶装置４５に格納させることができる。

復元処理部３９は、出力処理部３８から出力された出力情報に含まれる所定の文字列を所定の変換規則に基づき復元し、所定の文字列を復元した出力情報を出力装置へ出力する。復元処理部３９による復元処理では、図６に示す復元情報３９ａが参照されてもよい。なお、例えば出力ファイルが記憶装置４５へ格納される場合であって、所定の文字列を圧縮状態で格納する場合には、復元処理部３９による復元処理が省略されてもよい。復元処理部３９による復元処理の詳細については後述する。

なお、上述したアプリケーション３１及びランタイムシステム３５等のコンピュータプログラム、並びに圧縮情報３７ａ及び復元情報３９ａ等の情報は、例えばメモリ５ｂ又は記憶部５ｃの記憶領域に記憶されてよい。

〔２−２〕圧縮処理及び復元処理の説明
以下、一実施形態に係る圧縮処理部２４及び３７による圧縮処理、並びに、復元処理部３９による復元処理の一例について説明する。

なお、以下に詳述する変換規則は、変換前後の文字コードの対応関係を示す情報を予め処理装置５のメモリ５ｂ等に記憶しておき、圧縮処理又は復元処理の際に圧縮処理部２４及び３７、又は、復元処理部３９が参照するようにしてもよい。この場合、対応関係を示す情報としては、例えば図６に示す圧縮情報２４ａ及び３７ａ並びに復元情報３９ａ（以下、これらをまとめて変換情報と表記する場合がある）、又は、変換規則の論理を含むモジュール等が挙げられる。

或いは、対応関係を示す情報として、変換規則の論理（ロジック）を予め圧縮処理部２４及び３７、又は、復元処理部３９に組み込んでもよい。この場合、処理装置２及び３は変換情報やモジュール等を保持しなくてもよい。

以下の説明において、圧縮処理部２４及び３７又は復元処理部３９が文字コードの対応関係を示す情報を参照することには、変換情報又はモジュールを読み込むこと、並びに、組み込まれた変換規則の論理を適用すること、の少なくとも１つが含まれるものとする。

ＵＴＦ−８の文字コード体系における半角カナの文字コードの圧縮及び復元は、種々の手法によって実現される。以下、２つの例を挙げて説明する。なお、ＵＴＦ−８における半角カナの文字コードの範囲は、“0xEFBDA1”〜“0xEFBDBF”及び“0xEFBE80”〜“0xEFBE9F”の２つのバイト域である。

〔２−２−１〕第１の手法
第１の手法では、圧縮処理部２４及び３７は、ＵＴＦ−８の文字コード体系において、半角カナを表す文字コードの先頭の２バイトを取り除く、換言すれば最下位バイト以外のバイトコードを削除することにより文字コードの圧縮を実現する。また、復元処理部３９は、圧縮済の半角カナを表す１バイトの文字コードに対して、圧縮処理において取り除いた２バイトを上位バイトとして付加又は加算することにより文字コードの復元を実現する。

一例として、図８に示すように、圧縮処理部２４及び３７は、ＵＴＦ−８の半角カナの文字コードについて、先頭の２バイトの“0xEFBD”又は“0xEFBE”を取り除くことにより、以下のように３バイトで表現される半角カナを１バイトに圧縮することができる。

変換前 ：変換後
“0xEFBDA1”〜“0xEFBDBF”（第１コード域） ：“0xA1”〜“0xBF”
“0xEFBE80”〜“0xEFBE9F”（第２コード域） ：“0x80”〜“0x9F”

第１の手法に係る変換規則の一例を図９及び図１０に示す。図９に示すように、変換後の半角カナの文字コードの範囲は“0xA1”〜“0xBF”及び“0x80”〜“0x9F”である。このように、変換後の文字コードの範囲が図８に例示する「多バイト文字の２バイト目以降のバイトコード」域に含まれることがわかる。

なお、圧縮処理部２４及び３７の各々は、圧縮処理において半角カナの３バイトの文字コードを認識した場合、図９にテーブル形式で例示する圧縮情報２４ａ及び３７ａを参照してもよい。又は、圧縮処理部２４及び３７の各々は、変換規則の論理に基づき、当該文字コードから上位２バイトを削除（例えば、単に“0xEFBD”若しくは“0xEFBE”を除去、又は、“0xEFBD00”若しくは“0xEFBE00”を減算）してもよい。

復元処理部３９は、復元処理において圧縮済の半角カナの１バイトの文字コードを認識した場合、図１０にテーブル形式で例示する復元情報３９ａに基づき変換を行なってもよい。又は、復元処理部３９は、変換規則の論理に基づき、当該文字コードに対して上位２バイトを付加（例えば、単に“0xEFBD”若しくは“0xEFBE”を付加、又は、“0xEFBD00”若しくは“0xEFBE00”を加算）してもよい。

なお、圧縮情報２４ａ及び３７ａと復元情報３９ａとは、変換前後の文字コードが入れ替わった情報であるため、ランタイムシステム３５は、圧縮情報３７ａ及び復元情報３９ａの一方を記憶してもよい。また、圧縮情報２４ａ及び３７ａ並びに復元情報３９ａの各々は、コード域ごとに別個の情報として管理されてもよい。

〔２−２−２〕第２の手法
第２の手法では、圧縮処理部２４及び３７は、ＵＴＦ−８の文字コード体系において、半角カナを表す２つのバイト域の文字コードを、文字の大小関係を保持した状態で「多バイト文字の２バイト目以降のバイトコード」域に収まるように割り当て、文字コードの圧縮を実現する。また、復元処理部３９は、圧縮済の半角カナを表す１バイトの文字コードに対して圧縮処理とは逆の変換を行ない、文字コードの復元を実現する。

一例として、図１１に示すように、圧縮処理部は、ＵＴＦ−８の半角カナの文字コードについて、以下のように３バイトで表現される半角カナを１バイトに圧縮することができる。

変換前 ：変換後
“0xEFBDA1”〜“0xEFBDBF”（第１コード域） ：“0x81”〜“0x9F”
“0xEFBE80”〜“0xEFBE9F”（第２コード域） ：“0xA0”〜“0xBF”

第２の手法に係る変換規則の一例を図１２及び図１３に示す。図１２に示すように、変換後の半角カナの文字コードの範囲は“0x81”〜“0x9F”及び“0xA0”〜“0xBF”である。このように、変換後の文字コードの範囲が図１１に例示する「多バイト文字の２バイト目以降のバイトコード」域に含まれることがわかる。

なお、圧縮処理部２４及び３７の各々は、圧縮処理において半角カナの３バイトの文字コードを認識した場合、図１２にテーブル形式で例示する圧縮情報２４ａ及び３７ａを参照してもよい。又は、圧縮処理部２４及び３７の各々は、変換規則の論理に基づき、以下の（１）及び（２）の処理を行なってもよい。

（１）当該文字コードから上位２バイトを削除（例えば、単に“0xEFBD”若しくは“0xEFBE”を除去、又は、“0xEFBD00”若しくは“0xEFBE00”を減算）する、換言すれば２バイト以上のバイトコードの最下位バイト以外のバイトコードを削除する。

（２）下位１バイトの“0xA1”〜“0xBF”から“0x20”を減算する、又は、下位バイトの“0x80”〜“0x9F”に“0x20”を加算する、換言すれば２バイト以上のバイトコードに所定の値を加算又は減算する。

なお、上位（１）において文字コードから“0xEFBD00”若しくは“0xEFBE00”を減算する場合には、上記（２）において減算又は加算する値を含めて、“0xEFBD20”（第１コード域の場合）又は“EFBDE0”（第２コード域の場合）を減算することとしてもよい。

復元処理部３９は、復元処理において圧縮済の半角カナの１バイトの文字コードを認識した場合、図１３にテーブル形式で例示する復元情報３９ａに基づき変換を行なってもよいし、変換規則の論理に基づき、以下の（３）及び（４）の処理を行なってもよい。

（３）当該文字コードの“0x81”〜“0x9F”に“0x20”を加算する、又は、当該文字コードの“0xA0”〜“0xBF”から“0x20”を減算する。

（４）当該文字コードに上位２バイトを付加（例えば、単に“0xEFBD”若しくは“0xEFBE”を付加、又は、“0xEFBD00”若しくは“0xEFBE00”を加算）する。

なお、上位（４）において文字コードに“0xEFBD00”若しくは“0xEFBE00”を加算する場合には、上記（３）において加算又は減算する値を含めて、“0xEFBD20”（第１コード域の場合）又は“EFBDE0”（第２コード域の場合）を加算することとしてもよい。

ここで、第２の手法において、変換前の半角カナの文字コードはコード値の昇順に“0xEFBDA1”〜“0xEFBDBF”（第１コード域）、“0xEFBE80”〜“0xEFBE9F”（第２コード域）である。対応する変換後の半角カナの文字コードは“0x81”〜“0x9F”、“0xA0”〜“0xBF”であり、コード値の順序が変換前と同様に昇順である。このように、第２の手法によれば、文字コードの順序が文字コードの圧縮前後で変化しない。

アプリケーション３１において、半角カナは文字列の読み仮名として利用される場合がある。半角カナが読み仮名として利用される場合、読み仮名の文字コードの大小に基づくソートが行なわれることがある。

一例として、半角カナ“ア”の文字コードを“0xEFBDB1”から“0xB1”に圧縮（“0xEFBD”を除去）し、半角カナ“タ”の文字コードを“0xEFBE80”から“0x80”に圧縮（“0xEFBE”を除去）した場合、以下のように圧縮前後で半角カナの文字コードの大小関係が崩れる。

変換前：ア[0xEFBDB1] ＜ タ[0xEFBE80]
変換後：ア[0xB1] ＞ タ[0x80]

このように、圧縮前後で半角カナの文字コードの大小関係が崩れると、コード域の異なる半角カナが混在する場合、圧縮前後で読み仮名のソート結果が異なる場合がある。

これに対し、第２の手法によれば、圧縮前後でも半角カナの文字コードの大小関係を保持できるため、読み仮名のソート結果に影響を与えず、利便性を損なわずに済む。

〔２−３〕一実施形態に係る圧縮前後の文字コードについて
次に、一実施形態に係る圧縮前後の文字コードの扱いについて説明する。なお、便宜上、圧縮及び復元の変換規則として第２の手法を用いて説明するが、第１の手法を用いる場合も圧縮後の文字コードが異なるものの基本的に同様の処理である。

一例として、半角カナの文字列“テスト”の文字コードをそれぞれ圧縮する場合、第２の手法によれば、図１４及び以下に示すように圧縮後のコード列は“0xA39DA4”となる。

変換前 ：変換後
“テ”：“0xEFBE83” ：“0xA3”
“ス”：“0xEFBDBD” ：“0x9D”
“ト”：“0xEFBE84” ：“0xA4”

圧縮後のバイト列に含まれる“A3 9D”（１６進表記、以下同様）は、図１４に示す全角漢字のコード“E3 A3 9D”の一部である。しかし、“テスト”の直前に最後が“E3”となるコードは、ＵＴＦ−８の文字コード体系の理論上、出現しない。図１４の１バイトコード表に示すように、“0xE3”は「3byte文字の開始バイト」として規定されており、多バイト文字の開始バイト（“0xC0”〜“0xFD”）はバイト列の末尾にはなり得ないからである。

なお、“0x00”〜“0x7F”に規定された制御コード及びＡＳＣＩＩは１バイト文字（コード）であり、圧縮後のバイト列の直前に出現しても１バイト文字（コード）と解釈されるため、圧縮後のバイト列と混在しても誤って解釈されずに済む。

例えば、図１５に示すように、変換後の“テストb”のコード列“A3 9D A4 62”のうちの変換対象である半角カナに相当する“A3 9D A4”は、その文字位置から、変換前の文字で該当する文字は存在しない。一方、変換対象ではないＡＳＣＩＩの“b”に相当する“62”は、同じ文字“b”に割り当てられている。

このように、圧縮後のバイト列と他のＵＴＦ−８の文字のバイト列とが混在しても、復元処理部３９は圧縮後のバイト列を正しく復元することができる。

また、上述のように、圧縮後のバイト列と圧縮前のバイト列及び圧縮非対象のバイト列との混在が許容される。従って、図１６に例示するように、圧縮処理部２４及び３７並びに復元処理部３９は、圧縮前後の文字及び圧縮非対象の文字が混合されたデータ（以下、混合データと表記する）に対して、圧縮又は復元を繰り返し実施しても正しく変換を行なうことができる。換言すれば、バイト列から文字の圧縮状態（圧縮対象、圧縮非対象（圧縮不要）、圧縮済等）を判別することが可能となり、文字ごとに圧縮状態を管理しなくてもよい。

なお、混合データが生成される場合としては、例えば図１７に示すケースが挙げられる。図１７の例では、以下の（ｉ）〜（iv）の処理が行なわれる。

（ｉ）アプリケーションＡ（アプリケーション３１）が、圧縮後の“Aアイ”という文字列を記憶するファイルＡ（例えば記憶装置４２が記憶する圧縮後データファイル）を開く。

（ii）アプリケーションＡが圧縮後の“Bカキ”という文字列をファイルＡのレコードＡに書き込み、混合データファイルとして上書きして閉じる。

（iii）アプリケーションＢ（アプリケーション３１）が、ファイルＡ（混合データファイル）を開き、読み込む。

（iv）アプリケーションＢが、レコードＡのデータを表示装置４３に表示させる。

ここで、上記（ii）の処理において、アプリケーションＡを操作する利用者が圧縮後データファイルであるファイルＡを開いたにもかかわらず、“Bカキ”のデータを追加する際に誤って“Bカキ”の復元指示をした場合を想定する。

復元処理部３９は、上記（ii）の過程で圧縮後の“Bカキ”のバイト列“42 86 87”（１６進表記、以下同様）を“42 EFBDB6 EFBDB7”に復元して、復元後のバイト列をファイルＡに追加する。これにより、圧縮前後のバイト列及び圧縮非対象のバイト列が混在した混合データが生成される。

このように混合データが生成された場合であっても、上記（iii）の過程でアプリケーションＢが混合データファイルであるファイルＡを開く際に、圧縮処理部３７は、“Bカキ”のバイト列を“42 86 87”に正しく圧縮する。また、上記（iv）の過程でアプリケーションＢがレコードＡのデータを表示装置４３に表示させる際にも、復元処理部３９は、“Aアイ”及び“Bカキ”のバイト列を“41 EFBDB1 EFBDB2”及び“42 EFBDB6 EFBDB7”に正しく復元する。

このように、圧縮処理部３７及び復元処理部３９は、圧縮前後のバイト列から文字の切れ目を判別することができるため、複数バイトの１つの圧縮対象外の文字であるのか、複数個の圧縮後の文字であるのかを判断することができる。このため、混合データに対して圧縮及び復元を正しく行なうことができる。

従って、図１７に例示した場合のほか、例えば図１８に示すように、圧縮前データに圧縮後の文字を挿入した場合や圧縮後データに圧縮前の文字を挿入した場合においても、混合データに対する圧縮又は復元の繰り返しによるデータ破壊を回避できる。

以上のように、一実施形態によれば、利用者による操作の誤りによってデータ破壊が生じることを回避できる。また、アプリケーション３１内で扱われる文字列が圧縮後のデータになるため、半角カナ等の圧縮対象の文字については領域サイズを１文字１バイトとすることができ、リソースの消費量を低減させることができる。

なお、他の文字コード体系、例えばシフトＪＩＳや、ＥＢＣＤＩＣ（Extended Binary Coded Decimal Interchange Code）（カナ）では半角カナを１バイトで表現できる。また、ＥＵＣは上述した比較例の手法により混在文字の制限があるものの２バイトの半角カナを１バイトで表現できる。

一実施形態によれば、ＣＯＢＯＬプログラム等のプログラム２１の改修を行なわずに、半角カナを３バイトで表現するＵＴＦ−８等のＵｎｉｃｏｄｅであっても、他の文字コード体系と同様に、半角カナを１文字１バイトで扱うことができる。従って、他の文字コード体系からＵｎｉｃｏｄｅへの移植性を向上させることができる。利用者におけるプログラム２１の改修コストが不要になる。

また、１文字１バイトで扱える文字、例えばＡＳＣＩＩ（“0x20”〜“0x7F”）と半角カナ（“81”〜“BF”）が連続域となることで、ＡＳＣＩＩ及び半角カナを含む文字の判定が容易となるという効果も奏することができる。

〔２−４〕動作例
次に、上述の如く構成されたシステム１の動作例について説明する。なお、便宜上、以下の動作例では第２の手法を用いて説明するが、第１の手法を用いる場合も圧縮又は復元の際の変換手法が異なるものの基本的に同様の動作である。

〔２−４−１〕開発環境の動作例
はじめに、図１９を参照して、開発環境の処理装置２による動作例について説明する。

図１９に示すように、コンパイラ２２の定数取出部２３は、プログラム２１から定数となる文字列、例えば半角カナの文字列を取り出す（ステップＳ１）。次いで、圧縮処理部２４が定数となる文字列に対して圧縮処理を行なう（ステップＳ２）。圧縮処理の詳細については後述する。

オブジェクトファイル出力処理部２５は、プログラム２１のコンパイルを行ない、コンパイルにより得られたオブジェクトファイル中に、圧縮処理部２４が圧縮した定数の値を格納する（ステップＳ３）。

以上によりコンパイラ２２の処理が終了する。なお、生成されたオブジェクトファイルは、例えばコンパイラ２２から処理装置２のメモリ５ｂ又は記憶部５ｃに格納されてよく、処理装置２からアプリケーション３１として処理装置３へ出力されてもよい。

〔２−４−２〕開発環境の動作例
次に、図２０〜図２４を参照して、運用環境の処理装置３による動作例について説明する。

はじめに、処理装置３のアプリケーション３１の動作例を説明する。図２０に示すように、アプリケーション３１が実行されると、アプリケーション３１の外部入力要求部３２は、ランタイムシステム３５に対して外部入力を要求する（ステップＳ１１）。外部入力の要求には、利用者に入力情報の入力を促す入力画面の情報が含まれてもよい。

ランタイムシステム３５から入力情報を取得すると、データ操作部３３は、入力情報に基づくデータ編集処理を行なう（ステップＳ１２）。なお、データ編集処理の過程で新たな外部入力がリクエストされる場合、データ操作部３３は外部入力要求部３２を介して新たな入力情報を取得してもよい。

データ操作部３３によるデータ編集処理が完了すると、外部出力要求部３４は、ランタイムシステム３５に対して処理結果を含む出力情報の外部出力を要求する（ステップＳ１３）。以上によりアプリケーション３１の処理が終了する。

次いで、処理装置３のランタイムシステム３５の動作例を説明する。ランタイムシステム３５の入力処理部３６は、アプリケーション３１から外部入力の要求を受け付けると、当該要求に応じて画面入力処理又は外部入力処理を行なう。

画面入力処理では、図２１に示すように、画面入力部３６ａが利用者により入力装置４１に入力された文字列を取得し（ステップＳ２１）、圧縮処理部３７は画面入力部３６ａが取得した文字列に対して圧縮処理を行なう（ステップＳ２２）。圧縮処理部３７による圧縮処理が完了すると、画面入力部３６ａは圧縮された文字列をアプリケーション３１に渡し（ステップＳ２３）、画面入力処理が終了する。

外部入力処理では、図２２に示すように、外部入力部３６ｂが記憶装置４２から入力されたファイル又はＤＢ（Database）から文字列を取得し（ステップＳ３１）、圧縮処理部３７は外部入力部３６ｂが取得した文字列に対して圧縮処理を行なう（ステップＳ３２）。圧縮処理部３７による圧縮処理が完了すると、外部入力部３６ｂは圧縮された文字列をアプリケーション３１に渡し（ステップＳ３３）、外部入力処理が終了する。

また、ランタイムシステム３５の出力処理部３８は、アプリケーション３１から外部出力の要求を受け付けると、当該要求に応じて画面／印刷出力処理又は外部出力処理を行なう。

画面／印刷出力処理では、図２３に示すように、画面出力部３８ａ又は印刷出力部３８ｂがアプリケーション３１から文字列を含む出力情報を受け取り（ステップＳ４１）、復元処理部３９は当該文字列に対して復元処理を行なう（ステップＳ４２）。復元処理部３９による復元処理が完了すると、画面出力部３８ａは出力情報を表示装置４３へ出力して画面表示させる。又は、印刷出力部３８ｂが出力情報を印刷装置４４へ出力して印刷させる（ステップＳ４３）。以上により画面／印刷出力処理が終了する。

外部出力処理では、図２４に示すように、外部出力部３８ｃがアプリケーション３１から文字列を含む出力情報を受け取り（ステップＳ５１）、アプリケーション３１から復元を指示されているか否かを判定する（ステップＳ５２）。復元指示がない場合（ステップＳ５２のＮｏルート）、処理がステップＳ５４に移行する。一方、復元指示が有る場合（ステップＳ５２のＹｅｓルート）、復元処理部３９は当該文字列に対して復元処理を行ない（ステップＳ５３）、処理がステップＳ５４に移行する。

ステップＳ５４では、外部出力部３８ｃは、出力情報を記憶装置４５が記憶するファイル又はＤＢへ出力して格納する。以上により外部出力処理が終了する。

〔２−４−３〕圧縮処理の動作例
次に、図２５及び図２６を参照して、圧縮処理部２４又は３７による圧縮処理の動作例について説明する。

図２５に示すように、圧縮処理部２４又は３７は、文字列の先頭から１バイトの文字コードを取得し（ステップＳ６１）、取得した文字コードが半角カナの文字コードであるか否かを判定する（ステップＳ６２）。

取得した文字コードが半角カナの文字コードではない場合（ステップＳ６２のＮｏルート）、処理がステップＳ６４に移行する。一方、取得した文字コードが半角カナの文字コードである場合（ステップＳ６２のＹｅｓルート）、圧縮処理部２４又は３７は、半角カナを１バイトに圧縮し（ステップＳ６３）、取得した文字コードが最終バイトであるか否かを判定する（ステップＳ６４）。

取得した文字コードが最終バイトではない場合（ステップＳ６４のＮｏルート）、処理がステップＳ６１に移行し、圧縮処理部２４又は３７は次の１バイトを取得する。一方、取得した文字コードが最終バイトである場合（ステップＳ６４のＹｅｓルート）、圧縮処理が終了する。

図２６に圧縮処理のより詳細な動作例を示す。図２６に示すように、圧縮処理部２４又は３７は、文字列の先頭から１バイトの文字コードを取得すると（ステップＳ７１）、取得した文字コードが“0xF0”〜“0xFD”の範囲内であるか否かを判定する（ステップＳ７２）。

取得した文字コードが“0xF0”〜“0xFD”の範囲内である場合（ステップＳ７２のＹｅｓルート）、取得した文字コードは４〜６バイト文字の先頭の文字コードである（図５参照）。従って、圧縮処理部２４又は３７は、取得した文字コード（先頭の文字コード）を含む４〜６バイトについて、変換を行なわずに変換後の文字列に転記する（ステップＳ７３）。

次いで、圧縮処理部２４又は３７は、取得した文字コードが最終バイトであるか否かを判定する（ステップＳ７４）。取得した文字コードが最終バイトではない場合（ステップＳ７４のＮｏルート）、処理がステップＳ７１に移行し、圧縮処理部２４又は３７は次の１バイトを取得する。一方、取得した文字コードが最終バイトである場合（ステップＳ７４のＹｅｓルート）、圧縮処理が終了する。

ステップＳ７２において、取得した文字コードが“0xF0”〜“0xFD”の範囲外である場合（ステップＳ７２のＮｏルート）、圧縮処理部２４又は３７は、取得した文字コードが“0xE0”〜“0xEE”の範囲内であるか否かを判定する（ステップＳ７５）。

取得した文字コードが“0xE0”〜“0xEE”の範囲内である場合（ステップＳ７５のＹｅｓルート）、取得した文字コードは３バイト文字の先頭の文字コードである（図５参照）。従って、圧縮処理部２４又は３７は、取得した文字コード（先頭の文字コード）を含む３バイトについて、変換を行なわずに変換後の文字列に転記し（ステップＳ７６）、処理がステップＳ７４に移行する。

ステップＳ７５において、取得した文字コードが“0xE0”〜“0xEE”の範囲外である場合（ステップＳ７５のＮｏルート）、圧縮処理部２４又は３７は、取得した文字コードが“0xEF”であるか否かを判定する（ステップＳ７７）。

取得した文字コードが“0xEF”である場合（ステップＳ７７のＹｅｓルート）、圧縮処理部２４又は３７は、取得した文字コードよりも１つ下位のバイトの文字コードが“0xBD”であるか否かを判定する（ステップＳ７８）。１つ下位のバイトの文字コードが“0xBD”である場合（ステップＳ７８のＹｅｓルート）、圧縮処理部２４又は３７は、取得した文字コードよりも２つ下位のバイトの文字コードが“0xA1”〜“0xBF”の範囲内であるか否かを判定する（ステップＳ７９）。

ステップＳ７９において、２つ下位のバイトの文字コードが“0xA1”〜“0xBF”（第１コード域）の範囲外である場合（ステップＳ７９のＮｏルート）、処理がステップＳ７６に移行する。一方、２つ下位のバイトの文字コードが“0xA1”〜“0xBF”の範囲内である場合（ステップＳ７９のＹｅｓルート）、取得した文字コードは第１コード域における３バイトの半角カナの先頭の文字コードである（図５参照）。

従って、圧縮処理部２４又は３７は、例えば取得した文字コード（先頭の文字コード）を含む３バイトについて、圧縮情報２４ａ又は３７ａに基づき変換を行なう。そして、圧縮処理部２４又は３７は、変換により１バイトに圧縮された文字コードを変換後の文字列に転記し（ステップＳ８０）、処理がステップＳ７４に移行する。

一方、ステップＳ７８において、１つ下位のバイトの文字コードが“0xBD”ではない場合（ステップＳ７８のＮｏルート）、１つ下位のバイトの文字コードが“0xBE”であるか否かを判定する（ステップＳ８１）。１つ下位のバイトの文字コードが“0xBE”ではない場合（ステップＳ８１のＮｏルート）、処理がステップＳ７６に移行する。一方、１つ下位のバイトの文字コードが“0xBE”である場合（ステップＳ８１のＹｅｓルート）、圧縮処理部２４又は３７は、２つ下位のバイトの文字コードが“0x80”〜“0x9F”の範囲内であるか否かを判定する（ステップＳ８２）。

２つ下位のバイトの文字コードが“0x80”〜“0x9F”の範囲外である場合（ステップＳ８２のＮｏルート）、処理がステップＳ７６に移行する。一方、２つ下位のバイトの文字コードが“0x80”〜“0x9F”の範囲内である場合（ステップＳ８２のＹｅｓルート）、取得した文字コードは第２コード域における３バイトの半角カナの先頭の文字コードである（図５参照）。

従って、圧縮処理部２４又は３７は、例えば取得した文字コード（先頭の文字コード）を含む３バイトについて、圧縮情報２４ａ又は３７ａに基づき変換を行なう。そして、圧縮処理部２４又は３７は、変換により１バイトに圧縮された文字コードを変換後の文字列に転記し（ステップＳ８３）、処理がステップＳ７４に移行する。

ステップＳ７７において、取得した文字コードが“0xEF”ではない場合（ステップＳ７７のＮｏルート）、圧縮処理部２４又は３７は、取得した文字コードが“0xC0”〜“0xDF”の範囲内であるか否かを判定する（ステップＳ８４）。

取得した文字コードが“0xC0”〜“0xDF”の範囲内である場合（ステップＳ８４のＹｅｓルート）、取得した文字コードは２バイト文字の先頭の文字コードである（図５参照）。従って、圧縮処理部２４又は３７は、取得した文字コード（先頭の文字コード）を含む２バイトについて、変換を行なわずに変換後の文字列に転記し（ステップＳ８５）、処理がステップＳ７４に移行する。

一方、取得した文字コードが“0xC0”〜“0xDF”の範囲外である場合（ステップＳ８４のＮｏルート）、取得した文字コードは１バイト文字の文字コードである（図５参照）。従って、圧縮処理部２４又は３７は、取得した文字コードについて、変換を行なわずに変換後の文字列に転記し（ステップＳ８６）、処理がステップＳ７４に移行する。

以上により、圧縮処理部２４又は３７による圧縮処理が終了する。なお、文字コードの圧縮の手法はステップＳ８０及びＳ８３における説明に限定されるものではない。例えば圧縮情報２４ａ又は３７ａを用いずに、予め圧縮処理部２４又は３７に設定された論理やモジュール等に基づき、取得した文字コード（先頭の文字コード）を含む３バイトに所定の値を減算又は加算して変換を行なってもよい。或いは、取得した文字コード（先頭の文字コード）を含む上位２バイト（１つ下位のバイトまで）を読み捨て、２つ下位のバイトに所定の値を減算又は加算してもよい。

このように、圧縮処理部２４又は３７は、バイトコードを変換する処理の際に、変換対象の２バイト以上のバイトコードが出現した場合には、出現した２バイト以上のバイトコードを、変換規則において、対応する２バイト目以降のバイトコードに用いられる１バイトのコードに変換する変換部の一例である。

従って、圧縮処理部２４又は３７によれば、アプリケーション３１のデータ操作部３３が文字列を扱う前にＵＴＦ−８で表現された文字列中の半角カナを１バイトで表現できるようになる。

〔２−４−４〕復元処理の動作例
次に、図２７及び図２８を参照して、復元処理部３９による復元処理の動作例について説明する。

図２７に示すように、復元処理部３９は、文字列の先頭から１バイトの文字コードを取得し（ステップＳ９１）、取得した文字コードが圧縮済の半角カナの文字コードであるか否かを判定する（ステップＳ９２）。

取得した文字コードが圧縮済の半角カナの文字コードではない場合（ステップＳ９２のＮｏルート）、処理がステップＳ９４に移行する。一方、取得した文字コードが圧縮済の半角カナの文字コードである場合（ステップＳ９２のＹｅｓルート）、復元処理部３９は、圧縮済の１バイトの半角カナを３バイトに復元し（ステップＳ９３）、取得した文字コードが最終バイトであるか否かを判定する（ステップＳ９４）。

取得した文字コードが最終バイトではない場合（ステップＳ９４のＮｏルート）、処理がステップＳ９１に移行し、復元処理部３９は次の１バイトを取得する。一方、取得した文字コードが最終バイトである場合（ステップＳ９４のＹｅｓルート）、復元処理が終了する。

図２８に復元処理のより詳細な動作例を示す。図２８に示すように、復元処理部３９は、文字列の先頭から１バイトの文字コードを取得すると（ステップＳ１０１）、取得した文字コードが“0xF0”〜“0xFD”の範囲内であるか否かを判定する（ステップＳ１０２）。

取得した文字コードが“0xF0”〜“0xFD”の範囲内である場合（ステップＳ１０２のＹｅｓルート）、取得した文字コードは４〜６バイト文字の先頭の文字コードである（図５参照）。従って、復元処理部３９は、取得した文字コード（先頭の文字コード）を含む４〜６バイトについて、変換を行なわずに変換後の文字列に転記する（ステップＳ１０３）。

次いで、復元処理部３９は、取得した文字コードが最終バイトであるか否かを判定する（ステップＳ１０４）。取得した文字コードが最終バイトではない場合（ステップＳ１０４のＮｏルート）、処理がステップＳ１０１に移行し、復元処理部３９は次の１バイトを取得する。一方、取得した文字コードが最終バイトである場合（ステップＳ１０４のＹｅｓルート）、復元処理が終了する。

ステップＳ１０２において、取得した文字コードが“0xF0”〜“0xFD”の範囲外である場合（ステップＳ１０２のＮｏルート）、復元処理部３９は、取得した文字コードが“0xE0”〜“0xEE”の範囲内であるか否かを判定する（ステップＳ１０５）。

取得した文字コードが“0xE0”〜“0xEE”の範囲内である場合（ステップＳ１０５のＹｅｓルート）、取得した文字コードは３バイト文字の先頭の文字コードである（図５参照）。従って、復元処理部３９は、取得した文字コード（先頭の文字コード）を含む３バイトについて、変換を行なわずに変換後の文字列に転記し（ステップＳ１０６）、処理がステップＳ１０４に移行する。

ステップＳ１０５において、取得した文字コードが“0xE0”〜“0xEE”の範囲外である場合（ステップＳ１０５のＮｏルート）、復元処理部３９は、取得した文字コードが“0xC0”〜“0xDF”の範囲内であるか否かを判定する（ステップＳ１０７）。

取得した文字コードが“0xC0”〜“0xDF”の範囲内である場合（ステップＳ１０７のＹｅｓルート）、取得した文字コードは２バイト文字の先頭の文字コードである（図５参照）。従って、復元処理部３９は、取得した文字コード（先頭の文字コード）を含む２バイトについて、変換を行なわずに変換後の文字列に転記し（ステップＳ１０８）、処理がステップＳ１０４に移行する。

一方、取得した文字コードが“0xC0”〜“0xDF”の範囲外である場合（ステップＳ１０７のＮｏルート）、復元処理部３９は、取得した文字コードが“0x81”〜“0xBF”の範囲内であるか否かを判定する（ステップＳ１０９）。

取得した文字コードが“0x81”〜“0xBF”の範囲内である場合（ステップＳ１０９のＹｅｓルート）、取得した文字コードは「多バイト文字の２バイト目以降のバイトコード」に割り当てられた圧縮済の半角カナの文字コードである（図５及び図１１参照）。従って、復元処理部３９は、取得した文字コードについて、復元情報３９ａに基づき変換を行なう（ステップＳ１１０）。そして、復元処理部３９は、変換により３バイトに復元された文字コードを変換後の文字列に転記し、処理がステップＳ１０４に移行する。

ステップＳ１０９において、取得した文字コードが“0x81”〜“0xBF”の範囲外である場合（ステップＳ１０９のＮｏルート）、取得した文字コードは１バイト文字の文字コードである（図５参照）。従って、復元処理部３９は、取得した文字コードについて、変換を行なわずに変換後の文字列に転記し（ステップＳ１１１）、処理がステップＳ１０４に移行する。

以上により、復元処理部３９による復元処理が終了する。なお、文字コードの復元の手法はステップＳ１１０における説明に限定されるものではない。例えば復元情報３９ａを用いずに、予め復元処理部３９に設定された論理やモジュール等に基づき、取得した文字コードに所定の値を加算又は減算して変換を行なってもよい。或いは、取得した文字コードに対して、復元後の上位２バイトとなる文字コードを付加して、取得した文字コードに所定の値を加算又は減算してもよい。

このように、復元処理部３９によれば、文字列に対応したバイトコードを解釈する際に、所定の条件を満たす場合に、変換規則に従い圧縮処理部２４又は３７が割り当てを行なった１バイト表現での半角カナの文字であると判定又は解釈することができる。ここで、所定の条件としては、１バイトコード表において「多バイト文字の２バイト目以降のバイトコード」の範囲に含まれる１バイトのコードが、その前に「複数バイト文字の開始バイト」に対応する１バイトコードが先に出現することなく出現した場合が挙げられる。

換言すれば、復元処理部３９は、バイトコードを解釈する処理の際に、２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、変換規則において、出現した２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する解釈部の一例である。

従って、復元処理部３９により、アプリケーション３１からの出力情報を表示装置４３や印刷装置４４等に出力する場合であっても、圧縮済の半角カナをＵＴＦ−８の表現（３バイト表現）に戻すことができ、文字を可読化することができる。

〔３〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。

例えば、図６に示す処理装置２又は３の各機能ブロックは、それぞれ任意の組み合わせで併合してもよく、分割してもよい。

また、一実施形態においてはＵＴＦ−８等のＵｎｉｃｏｄｅを例に挙げて説明したが、これに限定されるものではない。一実施形態に係る手法は、ＵＴＦ−８以外の文字コード体系であっても、１文字を可変バイトで表現し、「多バイト文字のｘ（ｘ；２以上の自然数）バイト目のバイトコード」、換言すれば２バイト目以降のバイトコードに用いられる１バイトのコードが他の文字コードの１バイト目に出現する文字コードと重複しない文字コード体系に対して適用可能である。

〔４〕付記
以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
コンピュータに、
記憶部に記憶された、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を参照し、
バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する、
処理を実行させることを特徴とする、文字コード処理プログラム。

（付記２）
コンピュータに、
バイトコードを変換する処理の際に、変換対象の２バイト以上のバイトコードが出現した場合には、出現した前記２バイト以上のバイトコードを、前記対応関係を示す情報において、対応する２バイト目以降のバイトコードに用いられる１バイトのコードに変換する、
処理を実行させることを特徴とする、付記１記載の文字コード処理プログラム。

（付記３）
前記変換は、前記２バイト以上のバイトコードの最下位バイト以外のバイトコードを削除することを含むことを特徴とする、付記２記載の文字コード処理プログラム。

（付記４）
前記変換は、前記２バイト以上のバイトコードに所定の値を加算又は減算することを含むことを特徴とする、付記２又は付記３記載の文字コード処理プログラム。

（付記５）
前記対応関係を示す情報において、複数の前記２バイト以上のバイトコードに対応する文字間のバイトコードの値の大小関係と、複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード間の大小関係とが等しいことを特徴とする、付記１〜４のいずれか１項記載の文字コード処理プログラム。

（付記６）
前記所定の文字コード体系において１バイトのバイトコードに対応する複数の文字の文字のコード域と、前記対応関係を示す情報における複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード域とが連続した領域であることを特徴とする、付記１〜５のいずれか１項記載の文字コード処理プログラム。

（付記７）
前記所定の文字コード体系は、１文字を可変バイトで表現し、前記２バイト目以降のバイトコードに用いられる１バイトのコードが他の文字のバイトコードの１バイト目に出現するバイトコードと重複しない文字コード体系であることを特徴とする、付記１〜６のいずれか１項記載の文字コード処理プログラム。

（付記８）
前記所定の文字コード体系は、ＵＴＦ−８（Unicode Transformation Format-8）であり、
前記２バイト以上のバイトコードに対応する文字は３バイトの半角カナ文字である、
ことを特徴とする、付記７記載の文字コード処理プログラム。

（付記９）
所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を記憶する記憶部と、
バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する解釈部と、
をそなえることを特徴とする、情報処理装置。

（付記１０）
バイトコードを変換する処理の際に、変換対象の２バイト以上のバイトコードが出現した場合には、出現した前記２バイト以上のバイトコードを、前記対応関係を示す情報において、対応する２バイト目以降のバイトコードに用いられる１バイトのコードに変換する変換部をさらにそなえることを特徴とする、付記９記載の情報処理装置。

（付記１１）
前記変換部は、前記２バイト以上のバイトコードの最下位バイト以外のバイトコードを削除することで前記変換を行なうことを特徴とする、付記１０記載の情報処理装置。

（付記１２）
前記変換部は、前記２バイト以上のバイトコードに所定の値を加算又は減算することで前記変換を行なうことを特徴とする、付記１０又は付記１１記載の情報処理装置。

（付記１３）
前記対応関係を示す情報において、複数の前記２バイト以上のバイトコードに対応する文字間のバイトコードの値の大小関係と、複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード間の大小関係とが等しいことを特徴とする、付記９〜１２のいずれか１項記載の情報処理装置。

（付記１４）
前記所定の文字コード体系において１バイトのバイトコードに対応する複数の文字の文字のコード域と、前記対応関係を示す情報における複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード域とが連続した領域であることを特徴とする、付記９〜１３のいずれか１項記載の情報処理装置。

（付記１５）
前記所定の文字コード体系は、１文字を可変バイトで表現し、前記２バイト目以降のバイトコードに用いられる１バイトのコードが他の文字のバイトコードの１バイト目に出現するバイトコードと重複しない文字コード体系であることを特徴とする、付記９〜１４のいずれか１項記載の情報処理装置。

（付記１６）
前記所定の文字コード体系は、ＵＴＦ−８（Unicode Transformation Format-8）であり、
前記２バイト以上のバイトコードに対応する文字は３バイトの半角カナ文字である、
ことを特徴とする、付記１５記載の情報処理装置。

（付記１７）
記憶部に記憶された、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を参照し、
バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する、
ことを特徴とする、文字コード処理方法。

（付記１８）
バイトコードを変換する処理の際に、変換対象の２バイト以上のバイトコードが出現した場合には、出現した前記２バイト以上のバイトコードを、前記対応関係を示す情報において、対応する２バイト目以降のバイトコードに用いられる１バイトのコードに変換する、
ことを特徴とする、付記１７記載の文字コード処理方法。

（付記１９）
前記変換は、前記２バイト以上のバイトコードの最下位バイト以外のバイトコードを削除することを含むことを特徴とする、付記１８記載の文字コード処理方法。

（付記２０）
前記変換は、前記２バイト以上のバイトコードに所定の値を加算又は減算することを含むことを特徴とする、付記１８又は付記１９記載の文字コード処理方法。

１ システム
２、３、５ 処理装置
２１ プログラム
２２ コンパイラ
２３ 定数取出部
２４、３７ 圧縮処理部
２５ オブジェクトファイル出力処理部
３１ アプリケーション
３２ 外部入力要求部
３３ データ操作部
３４ 外部出力要求部
３５ ランタイムシステム
３６ 入力処理部
３６ａ 画面入力部
３６ｂ 外部入力部
３８ 出力処理部
３８ａ 画面出力部
３８ｂ 印刷出力部
３８ｃ 外部出力部
３９ 復元処理部
４１ 入力装置
４２、４５ 記憶装置
４３ 表示装置
４４ 印刷装置

Claims (10)

1. コンピュータに、
   記憶部に記憶された、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を参照し、
   バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する、
   処理を実行させることを特徴とする、文字コード処理プログラム。
2. コンピュータに、
   バイトコードを変換する処理の際に、変換対象の２バイト以上のバイトコードが出現した場合には、出現した前記２バイト以上のバイトコードを、前記対応関係を示す情報において、対応する２バイト目以降のバイトコードに用いられる１バイトのコードに変換する、
   処理を実行させることを特徴とする、請求項１記載の文字コード処理プログラム。
3. 前記変換は、前記２バイト以上のバイトコードの最下位バイト以外のバイトコードを削除することを含むことを特徴とする、請求項２記載の文字コード処理プログラム。
4. 前記変換は、前記２バイト以上のバイトコードに所定の値を加算又は減算することを含むことを特徴とする、請求項２又は請求項３記載の文字コード処理プログラム。
5. 前記対応関係を示す情報において、複数の前記２バイト以上のバイトコードに対応する文字間のバイトコードの値の大小関係と、複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード間の大小関係とが等しいことを特徴とする、請求項１〜４のいずれか１項記載の文字コード処理プログラム。
6. 前記所定の文字コード体系において１バイトのバイトコードに対応する複数の文字の文字のコード域と、前記対応関係を示す情報における複数の前記２バイト目以降のバイトコードに用いられる１バイトのコード域とが連続した領域であることを特徴とする、請求項１〜５のいずれか１項記載の文字コード処理プログラム。
7. 前記所定の文字コード体系は、１文字を可変バイトで表現し、前記２バイト目以降のバイトコードに用いられる１バイトのコードが他の文字のバイトコードの１バイト目に出現するバイトコードと重複しない文字コード体系であることを特徴とする、請求項１〜６のいずれか１項記載の文字コード処理プログラム。
8. 前記所定の文字コード体系は、ＵＴＦ−８（Unicode Transformation Format-8）であり、
   前記２バイト以上のバイトコードに対応する文字は３バイトの半角カナ文字である、
   ことを特徴とする、請求項７記載の文字コード処理プログラム。
9. 所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を記憶する記憶部と、
   バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する解釈部と、
   をそなえることを特徴とする、情報処理装置。
10. 記憶部に記憶された、所定の文字コード体系において２バイト以上のバイトコードに対応する文字と前記所定の文字コード体系における多バイト文字の上位から２バイト目以降のバイトコードに用いられる１バイトのコードとの対応関係を示す情報を参照し、
    バイトコードを解釈する処理の際に、前記２バイト目以降のバイトコードに用いられる１バイトのコードが最上位バイトのバイトコードとして出現した場合には、前記対応関係を示す情報において、出現した前記２バイト目以降のバイトコードに用いられる１バイトのコードに対応する文字であると解釈する、
    ことを特徴とする、文字コード処理方法。

Images