JPH0798676A - 可変長入れ子構造のデータの編集方法 - Google Patents

Abstract

(57)【要約】 【目的】 可変長入れ子構造のプロトコルデータを容易
に編集すること。 【構成】 可変長入れ子構造のプロトコルデータを所定
の符号化規則の記述法に従って編集する場合、プロトコ
ルデータの最終位置から先頭に向かって「値」、「長
さ」、「タグ」の順序で各パラメタを編集する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、プロトコルデータにお
ける可変長入れ子構造のデータの編集方法に関し、特に
プロトコルデータを最終位置から先頭に向かって各パラ
メタを編集することによって、不定長形式を用いずに、
可変長入れ子構造のデータを容易に編集する方法に関す
るものである。

【０００２】

【従来の技術】従来、計算機間あるいは計算機と端末装
置間で送受されるプロトコルデータに関し、異機種ごと
に開発されたプロトコルでは、異機種計算機間の通信は
不可能であり、プロトコルの標準化が必要される。

【０００３】そこで、コンピュータネットワークにおい
て、異機種計算機間における通信を可能とするために、
国際標準ネットワークアーキテクチャとして、ＯＳＩ
（Ｏpen Ｓystems Ｉnterconnection：開放型システム
間相互接続：規約番号ＩＳＯ７４９８）がＩＳＯ（Ｉnt
ernational Ｏrganization for Ｓtandardization：国
際標準化機構）によって提唱されている。

【０００４】このＯＳＩでは、異機種計算機間でデータ
通信を行う場合、処理データの送受に先立って、この処
理データを送受する手順を取り決めたプロトコルデータ
と呼ばれるデータの交換を行う。このプロトコルデータ
の符号化規則の１つにＡＳＮ．１（Ａbstract Ｓyntax
Ｎotation．１：抽象構文記述法：規約番号ＩＳＯ８８
２４／８８２５）がある。

【０００５】このＯＳＩ環境下における情報処理システ
ムにおいて、プロトコルデータは前記ＡＳＮ．１記述法
で記述されており、プロトコルデータを構成しているパ
ラメタが可変長入れ子構造となっている。

【０００６】図７はＡＳＮ．１記述法によるＴＬＶ型
（Ｔag, Ｌength and Ｖalue)プロトコルデータの構造
図を示したものである。プロトコルデータ６０は「１」
以上のパラメタで構成されている。

【０００７】図７において、プロトコルデータ６０は、
パラメタ６１，６２で構成され、さらにパラメタ６１，
６２は、「タグ」６０１、「長さ」６０２および「値」
６０３の３項目のパラメタ要素から構成されている。

【０００８】「タグ」６０１はパラメタを識別するため
の識別子であり、「長さ」６０２はパラメタの「値」６
０３のバイト数を示し、「値」６０３は当該パラメタの
パラメタ値である。

【０００９】このパラメタには２つの型があり、「値」
６０３が構造を持たないものを「プリミティブ型」６１
といい、「値」６０３がパラメタの構造を持っており、
入れ子状になっているものを「コンストラクト型」６２
という。

【００１０】以下、プロトコルデータ６０の構造につい
て図７を用いて説明する。図７において、 （１）プロトコルデータ６０は、「タグ」６０１、「長
さ」６０２および、「値」６０３の３項目のパラメタ要
素の並びで構成され、「プリミティブ型」６１であれ
ば、「値」６０３は構造を持たず、「コンストラクト
型」６２であれば、この「値」６０３がパラメタの構造
となっており、さらに前記３項目の並びに従ったパラメ
タが入れ子の形で入っている。

【００１１】（２）「タグ」６０１、「長さ」６０２お
よび、「値」６０３それぞれのデータの長さは、全てそ
の長さが一定ではなく可変長である。

【００１２】図８は、「タグ」６０１の構造と内容を説
明するための説明図である。

【００１３】「タグ」６０１の先頭バイト７０の第３ビ
ット７０１が当該パラメタの型を示している。第３ビッ
ト７０１が「０」ならば「プリミティブ型」６１であ
り、「１」ならば「コンストラクト型」６２である。

【００１４】また、「タグ」６０１には２つの形式があ
り、「タグ」６０１の先頭バイト７０の下位５ビット７
０２によって示される。下位５ビット７０２が「１１１
１１」以外ならば短形式、「１１１１１」であれば長形
式である。

【００１５】短形式ならば、「タグ」６０１のデータ長
は先頭バイト７０のみの１バイトである。長形式ならば
先頭バイト７０からの後続バイトで先頭ビットが「０」
の最初のバイトを含めたバイトまでが「タグ」６０１で
ある。本例の長形式では「タグ」６０１は先頭バイト７
０からバイト７ｍまでである。

【００１６】図９は「長さ」６０２の構造と内容を説明
するための説明図である。

【００１７】「長さ」６０２には２つの形式があり、
「長さ」６０２の先頭バイト８０の先頭ビット８０１に
よって示される。先頭ビット８０１が「０」ならば短形
式であり、「１」であれば長形式である。

【００１８】また、長形式の場合は、定長と不定長とが
あり、「長さ」６０２の先頭バイト８０の下位７ビット
８０２によって示される。下位７ビット８０２が「００
０００００」以外ならば定長であり、「００００００
０」ならば不定長である。

【００１９】短形式の場合、「長さ」６０２は先頭バイ
ト８０のみの１バイトであり、下位７ビット８０２が当
該パラメタの「値」６０３のバイト数を示している。

【００２０】長形式の場合、定長ならば下位７ビット８
０２が継続するバイト８１から８ｍまでのバイト数を示
し、先頭バイト８０からバイト８ｍまでが「長さ」６０
２である。

【００２１】不定長ならば、「値」６０３のバイト数を
格納する部分は存在せず、先頭バイト８０の次のバイト
からＥＯＣ（Ｅnd Ｏf Ｃontents：「(0000)₁₆」で示さ
れる）８２までが「値」６０３である。

【００２２】前記のように、プロトコルデータ６０を編
集する場合、プロトコルデータ６０のパラメタ要素であ
る「タグ」６０１、「長さ」６０２および「値」６０３
のそれぞれのデータ長が可変長入れ子構造であるため、
入れ子構造の深い最終のパラメタ要素のデータ長によっ
て入れ子構造の浅いパラメタ要素のデータ長が決定す
る。

【００２３】このようなプロトコルデータ６０の編集に
は、データ長を全て固定にしておくか、データ長が固定
部分については定長形式、可変部分については不定長形
式の表現する方法が考えられる。

【００２４】しかし、不定長形式の場合は、ＥＯＣ（Ｅ
nd Ｏf Ｃontents：「(0000)₁₆」で示される）が「値」
６０３の途中にデータとして含まれていた場合、誤認識
されたり、また、不定長形式の構造解析には特別な処理
が必要であるため、不定長形式のデータを受信できない
接続先相手とは通信することができなくなる。

【００２５】このため、種々のプロトコルデータ６０の
編集方法が提案されている。例えば、特開平２−７９１
４６号公報（発明の名称：転送構文解析・生成処理方
式）に開示されているように、プロトコルデータ６０の
パラメタの入れ子の構造を解析し、各パラメタの上位パ
ラメタ、下位パラメタおよび同位パラメタを特定し、木
構造で表現して送信データ木構造表現テーブルに格納
し、「プリミティブ型」６１のパラメタの「値」６０３
を送信プリミティブプールに格納し、送信プリミティブ
索引テーブルに各パラメタのパラメタ要素である「タ
グ」６０１、「長さ」６０２および「値」６０３が格納
されている送信プリミティブプールのアドレス（「コン
ストラクト型」６２パラメタの場合はｎｕ１１値）を格
納し、これら２つのテーブルによってデータ構造とデー
タ内容とを別々に管理し、これらのデータに従って送信
プロトコルデータを編集する方法がある。

【００２６】

【発明が解決しようとする課題】しかしながら、前記従
来技術は、データの構造と内容とをそれぞれ別のテーブ
ルに格納し、データの「長さ」の編集とデータの「値」
の編集とを別々に行っているために、２回の編集処理を
行う結果となり、処理が複雑になるうえ、性能も低下す
るという問題がある。

【００２７】本発明の目的は、ＡＳＮ．１記述法に従っ
たプロトコルデータを簡単な処理で、かつ高速に編集す
ることができる可変長入れ子構造のデータの編集方法を
提供することにある。

【００２８】

【課題を解決するための手段】前記課題を解決するため
に、本発明は、プロトコルデータを所定の符号化規則の
記述法に従って編集するに際し、プロトコルデータの最
終位置から先頭に向かって「値」、「長さ」、「タグ」
の順序で編集することを特徴とする。

【００２９】

【作用】前記手段によれば、プロトコルデータを入れ子
構造の深い最終パラメタ要素から入れ子構造の浅い先頭
パラメタ要素に向かって編集するので、１回の編集処理
で可変長入れ子構造のプロトコルデータを編集すること
ができる。

【００３０】

【実施例】以下、本発明の一実施例を図面を用いて詳細
に説明する。なお、実施例を説明するための全図におい
て、同一機能を有するものは、同一符号を付け、その繰
り返しの説明は省略する。

【００３１】図１は本発明を適用した情報処理システム
の一実施例を示すブロック図であり、この実施例の情報
処理システム１０は、プロトコルデータ編集部１１と、
通信制御部１２とから構成されている。

【００３２】プロトコルデータ編集部１１は、本発明を
実現する部分であり、編集処理部１３、取込処理部１
４、送信データバッファ１５および入力データバッファ
１６とから構成される。

【００３３】取込処理部１４は、ディスプレイ１７や入
力データファイル１８から入力データを取り込み、入力
データバッファ１６に入力データを蓄積する。

【００３４】また、編集処理部１３は、入力データバッ
ファ１６に蓄積された入力データをプロトコルデータ６
０に編集し、送信データバッファ１５に蓄積する。

【００３５】通信制御部１２は相手側情報処理システム
２０との間で、通信回線１９を介して送信データバッフ
ァ１５に蓄積されたプロトコルデータ６０の送受信を制
御する。なお、図１には図示していないが、情報処理シ
ステム１０内には、ユーザ業務を行う業務プログラム等
が内蔵されている。

【００３６】図２は本実施例のプロトコルデータ６０の
編集処理手順を示すフローチャートである。図２に従っ
て本実施例の編集処理手順を説明する。なお、フローチ
ャート中のバッファとは送信データバッファ１５を示
す。

【００３７】まず、取込処理部１４は、ディスプレイ１
７や入力データファイル１８から入力データを取り込
み、入力データバッファ１６に蓄積する。そして、シス
テム設計者等の利用者によってプロトコルデータ６０の
編集指示がディスプレイ１７に接続されたキーボード等
から入力されると、プロトコルデータ編集部１１が起動
し、プロトコルデータ６０の編集処理を開始する。

【００３８】まず、カレントポインタを送信データバッ
ファ１５の最終に位置付ける（ステップ２０１）。カレ
ントポインタは、送信データバッファ１５中のデータ出
力位置を示すものである。

【００３９】次に、入力データバッファ１６に蓄積され
たデータのうち最後の「値」から順次読み込み（ステッ
プ２０２）、入力データが「プリミティブ型」６１か
「コンストラクト型」６２かを判定する（ステップ２０
３）。

【００４０】判定の結果はプロトコルデータ６０のパラ
メタ要素である「タグ」６０１の先頭バイト７０の第３
ビット７０１に反映し、「タグ」６０１の編集時に付加
する。

【００４１】これは図８に示したようにＡＳＮ．１記述
法に従い、「プリミティブ型」６１ならば第３ビット７
０１を「０」とし、「コンストラクト型」６２ならば
「１」とすることである。

【００４２】「プリミティブ型」６１であれば、カレン
トポインタを「値」６０３の「長さ」６０２分だけ先頭
に向かって戻すために「長さ」６０２分減算し（ステッ
プ２０４）、「値」６０３を送信データバッファ１５に
出力する（ステップ２０５）。

【００４３】「コンストラクト型」６２であれば、
「値」６０３は存在しないのでステップ２０６まで処理
をスキップする。

【００４４】次に、「値」６０３の「長さ」６０２が
「短形式」か「長形式」かを判定する（ステップ２０
６）。「長さ」６０２が「１２８」より小さいならば
「短形式」であり、「１２８」以上ならば「長形式」で
ある。

【００４５】「短形式」であれば、カレントポインタを
１バイト分先頭に向かって戻すために「１」減算し（ス
テップ２０７）、「長さ」６０２を送信データバッファ
１５に出力する（ステップ２０８）。

【００４６】「長形式」であれば、カレントポインタを
１バイトずつ先頭に向かって戻すために「１」減算し
（ステップ２０９）、「長形式」の「長さ」６０２を送
信データバッファ１５に出力する（ステップ２１０）。
この処理を「長さ」６０２のバイト数分繰り返す（ステ
ップ２１１）。これは、「長形式」ならば「長さ」６０
２の先頭バイト８０の下位７ビット８０２が「値」６０
３のバイト数を示す後続バイト数を示すので、カレント
ポインタを１バイトずつ先頭に向かって戻すために
「１」ずつ減算し、バイト８ｍからバイト８１まで
「値」６０３のバイト数を送信データバッファ１５に、
繰り返し出力するためである。

【００４７】次に、「タグ」６０１が「短形式」か「長
形式」かを判定する（ステップ２１２）。判定の方法
は、「タグ」６０１のコードが３１より小さいならば
「短形式」であり、「３１」以上ならば「長形式」であ
る。

【００４８】「短形式」であれば、カレントポインタを
１バイト分先頭に向かって戻すために「１」減算し（ス
テップ２１３）、「タグ」６０１を送信データバッファ
１５に出力する（ステップ２１４）。

【００４９】「長形式」であれば、カレントポインタを
１バイトずつ先頭に向かって戻すために「１」減算し
（ステップ２１５）、「長形式」の「タグ」６０１を送
信データバッファ１５に出力する（ステップ２１６）。
この処理を「タグ」６０１のバイト数分繰り返す（ステ
ップ２１７）。図８に示したようにＡＳＮ．１記述法に
従い、「タグ」６０１の先頭バイト７０の下位５ビット
が「１１１１１」であれば「長形式」であり、それ以外
は「短形式」である。ステップ２１５〜２１７の処理
は、「長形式」の場合に、カレントポインタを１バイト
ずつ先頭に向かって戻すために「１」ずつ減算し、バイ
ト７ｍからバイト７１までを送信データバッファ１５
に、繰り返し出力するためである。

【００５０】プロトコルデータ６０は、先頭パラメタが
後続パラメタを全て下位に従えているので、入力データ
の最終から順次読み込んで行くと、先頭の処理が終了し
た時点でプロトコルデータ６０の１単位分の編集処理が
終了したことになる（ステップ２１８）。

【００５１】以上の操作により、プロトコルデータが容
易に編集できることになる。

【００５２】図３は、編集結果であるプロトコルデータ
６０の原データ３０を表した例である。図４は、図３の
プロトコルデータ６０のデータ構造をわかりやすく表し
た例である。各行の先頭に「タグ」６０１、次に「長
さ」６０２、その次に「値」６０３を示している。入れ
子の深さがわかるようにインデント付けして表してあ
る。

【００５３】図４から明らかなように、プロトコルデー
タ６０のパラメタ要素である「タグ」６０１、「長さ」
６０２、「値」６０３のそれぞれのデータ長が可変長入
れ子構造であるため、入れ子構造の深い最終のパラメタ
要素のデータ長によって入れ子構造の浅いパラメタ要素
のデータが決定するので、プロトコルデータ６０を編集
する場合、複雑な処理を必要とし、性能的にも低下する
ことになる。

【００５４】図５は、本発明を適用してプロトコルデー
タ６０を編集する例である。カレントポインタを送信デ
ータバッファ１５の最終に位置付け、最終位置から先頭
に向かって「値」６０３、「長さ」６０２、「タグ」６
０１の順序で編集することを示している。

【００５５】ここで示されているプロトコルデータ６０
は、図６の入力データバッファ１６に〜で示すよう
にしてパラメタごとに区分されて格納された入力データ
に対応している。各パラメタの内容のうち、クラス１６
１、型１６２、タグコード１６３から「タグ」６０１が
作成される。また、「値」のバイト数１６４から「長
さ」６０２が作成される。「値」のバイト数１６４は、
プリミティブパラメタの場合は数値が格納され、コンス
トラクタパラメタの場合は、プロトコルデータ編集時
に、パラメタ最終ポインタ−カレントポインタの値によ
り計算される。「値」ポインタ１６５は、プリミティブ
パラメタの場合にのみ存在する。

【００５６】なお、ここでは入力データは「値」ポイン
タで示される値テーブルに格納されるようになってい
る。

【００５７】このようにして入力データの格納の後、編
集指示が与えられたならば、上述のように、カレントポ
インタを送信データバッファ１５の最終に位置付け、最
終位置から先頭に向かって「値」６０３、「長さ」６０
２、「タグ」６０１の順序で編集する。

【００５８】ここで、図５のｌは「値」６０３の長さを
示している。

【００５９】このように編集することによって、不定長
形式を用いずに、可変長入れ子構造のデータを、１回の
編集処理で簡単に編集することができる。そして、編集
処理が１回で済むことから処理速度も高速になり、性能
が向上する。

【００６０】

【発明の効果】以上説明したように本発明によれば、可
変長入れ子構造のプロトコルデータを所定の符号化規則
の記述法に従って編集するに際して、プロトコルデータ
の最終位置から先頭に向かって「値」、「長さ」、「タ
グ」の順序で編集するようにしたので、不定長形式を用
いずに、可変長入れ子構造のデータを１回の編集処理で
簡単に編集することができる。そして、編集処理が１回
で済むことから処理速度も高速にすることができる。

【００６１】この結果、計算機間あるいは計算機と端末
装置間の通信を行う場合、双方の情報処理システムにお
けるプロトコルデータの編集作業を効率良く行い、性能
を向上させることができるという効果がある。

【図面の簡単な説明】

【図１】本発明の一実施例を示すシステム構成図であ
る。

【図２】実施例の編集処理手順を示すフローチャートで
ある。

【図３】プロトコルデータの原データを示す図である。

【図４】プロトコルデータの構造例を示す図である。

【図５】実施例によるプロトコルデータの編集例を示す
図である。

【図６】図５のプロトコルデータの編集前の構造を示す
図である。

【図７】ＡＳＮ．１記述法によるプロトコルデータの構
造図である。

【図８】ＡＳＮ．１記述法による「タグ」の説明図であ
る。

【図９】ＡＳＮ．１記述法による「長さ」の説明図であ
る。

【符号の説明】

１０…情報処理システム、１１…プロトコルデータ編集
部、１２…通信制御部、１３…編集処理部、１４…取込
処理部、１５…送信データバッファ、１６…入力データ
バッファ、１７…ディスプレイ、１８…入力データファ
イル、１９…通信回線、２０…相手側情報処理システ
ム、３０…原データ、４０…データ構造の例、５０…編
集のデータ例、６０…プロトコルデータ、６１…プリミ
ティブ型のパラメタ、６２…コンストラクト型のパラメ
タ、６０１…タグ、６０２…長さ、６０３…値、７０…
「タグ」の先頭バイト、８０…「長さ」の先頭バイト。

Claims (1)

【特許請求の範囲】
1. 【請求項１】 計算機間あるいは計算機と端末装置間で
   送受されるプロトコルデータにおける可変長入れ子構造
   のデータの編集方法において、 前記プロトコルデータを所定の符号化規則の記述法に従
   って編集するに際し、前記プロトコルデータの最終位置
   から先頭に向かって「値」、「長さ」、「タグ」の順序
   で編集することを特徴とする可変長入れ子構造のデータ
   の編集方法。