通信プロトコル
【課題】 多量の数値データを含むメッセージを送受信する通信システムにおいて、経済的かつ効率のよい通信を的確に行う。
【解決手段】 通信メッセージ１１を数値データが含まれるデータ列１２と、データ列１２の先頭に付加されるヘッダ１３とで構成する。データ列１２中の数値データを、ＡＳＣＩＩコードに変換することなく、そのまま１６進数の数値で表す。ただし、データ列１２で使用可能な数値に上限値を設定する。そして、ヘッダ１３にその上限値を超える特定の数値、例えば、２バイト１６進数の最大値である「０ｘＦＦ」を４回連続させて指定する。
【解決手段】 通信メッセージ１１を数値データが含まれるデータ列１２と、データ列１２の先頭に付加されるヘッダ１３とで構成する。データ列１２中の数値データを、ＡＳＣＩＩコードに変換することなく、そのまま１６進数の数値で表す。ただし、データ列１２で使用可能な数値に上限値を設定する。そして、ヘッダ１３にその上限値を超える特定の数値、例えば、２バイト１６進数の最大値である「０ｘＦＦ」を４回連続させて指定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信メッセージをコンピュータが認識可能な形式に変換するプログラム、特に、数値データを含むメッセージの通信に適した通信プロトコルに関する。
【背景技術】
【０００２】
従来、通信ソースをＡＳＣＩＩコードに変換し、多数のＡＳＣＩＩコードを並べて通信メッセージを構成する通信プロトコルが知られている。メッセージを送受信する上で、メッセージの始めと終わりを認識することは重要であり、特に、メッセージの始まりを認識できないと、コンピュータは受信したメッセージを解読することが困難となる。ＡＳＣＩＩコードでは、図５に示すように、メッセージの先頭に付される“ＳＴＸ”に「０ｘ０２」が用意され、メッセージの末尾に付される“ＥＴＸ”に「０ｘ０３」が用意されている。このため、コンピュータは“ＳＴＸ”，“ＥＴＸ”をデータ中の他の文字（数字：「０ｘ３＊」、英文字：「０ｘ４＊」，「０ｘ５＊」）と区別して認識できる。
【０００３】
しかし、ＡＳＣＩＩコード変換を行う通信プロトコルにおいて、１６進数の数値をそのまま１バイトで表すと、コンピュータが１６進数の数値データ「０ｘ０２」を“ＳＴＸ”として誤認する可能性がある。そこで、従来の通信プロトコルは、図６に示すように、メッセージ５１の先頭に“ＳＴＸ”を付加し、末尾に“ＥＴＸ”を付加し、データ列５２中の複数の数値データをそれぞれ二つのＡＳＣＩＩコードに変換している。この方式によれば、例えば、“データ１”の数値「０ｘ０２」が「０」を表すＡＳＣＩＩコード「０ｘ３０」と、「２」を表すＡＳＣＩＩコード「０ｘ３２」とに分割されるため、“ＳＴＸ”を“データ１”と混同する可能性がなくなる。
【０００４】
なお、特許文献１には、７ビットのＡＳＣＩＩコードを６ビットの短縮コードに変換することで、文字データを圧縮する方法が記載されている。特許文献２には、複数の文字列をＡＳＣＩＩコード中の制御コードに割り当てて符号化する方法が記載されている。
【特許文献１】特開２００５−３１８６８号公報
【特許文献２】特開平１１−８５４５９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところが、従来の通信プロトコルによると、データ列５２中の数値データを二つのＡＳＣＩＩコードに変換しているので、１バイトの数値データを送るのに２バイトの電文長が必要になる。このため、多量の数値データを含むメッセージ５１を送受信する際に、電文５３の全長がいたずらに長くなり、通信時間がかかり、有料回線を使用する場合にパケット料等の通信費が高くつく問題点があった。また、多量の数値データをＡＳＣＩＩコードに変換すると、制御プログラムの負担が重くなるため、コンピュータによる他の処理が遅くなる不都合もあった。
【０００６】
そこで、本発明の目的は、コンピュータが数値データを含むメッセージの通信を効率よく行うことができる通信プロトコルを提供することにある。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明の通信プロトコルは、通信メッセージをコンピュータが認識可能な形式に変換するプログラムであって、通信メッセージを数値データが含まれるデータ列と、データ列の先頭に付加されるヘッダとで構成し、データ列中の数値データを特定値を除く１６進数の数値で表し、ヘッダに該特定値を表す１６進数の数値を指定することを特徴とする。
【０００８】
ここで、ヘッダに指定する１６進数の数値は、データ列中に発生し得ない特定の数値である。該特定値の選定にあたり、好ましくは、次の手段を採用できる。
（１）データ列中で使用可能な数値に上限値を設定し、ヘッダにその上限値を超える特定値を指定する。この場合、上限値は、特定の数値や桁数に限定されず、通信プロトコルの適用分野、又は該プロトコルが扱う数値データの種類等に応じて適宜に設定できる。
（２）ヘッダに１６進数の特定値を複数回連続させて指定する。特定値及びこれを連続させる回数は、特に限定されず、通信プロトコルの適用分野、又は数値データの種類等に応じて適宜に選択できる。
（３）例えば、特定値に２バイト１６進数の最大値である「０ｘＦＦ」を用い、ヘッダに該数値を複数回連続させて指定することができる。
【０００９】
また、本発明は上記通信プロトコルに次の手段を加えて実施することも可能である。
（４）データ列中にメッセージの長さを示す指標となる１６進数の数値を付加する。
（５）データ列中にノイズ等による通信エラーを示す１６進数の数値を付加する。
【発明の効果】
【００１０】
本発明の通信プロトコルは、データ列中の数値データを１６進数の数値で表すので、１バイトの数値データを分割することなく１バイトのままで送受信できる。このため、メッセージの長さを短くし、通信時間を短縮して、通信費を節約できるとともに、ＡＳＣＩＩコードへの変換処理を不要にして、コンピュータの負担を軽減できる。また、データ列中に発生し得ない特定値をヘッダに指定するので、コンピュータが数値データをヘッダと誤認する可能性もなくなる。従って、本発明の通信プロトコルによれば、特に多量の数値データを含むメッセージを送る場合に、経済的かつ効率のよい通信を的確に行うことができるという効果がある。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を実施するための最良の形態を図面に基づいて説明する。図１に示すように、この実施形態の通信システム１は、ネットワーク２に接続された複数のコンピュータ３が通信プロトコル４を用いて主に数値データからなるビジネスメッセージの送受信を行うように構成されている。通信プロトコル４は、通信プログラムの一部として各コンピュータ３に実装され、受信したメッセージを該コンピュータ３の他のプログラムが認識可能な形式に変換する。以下に、通信プロトコル４の具体的な機能について幾つかの実施例をあげて詳細に説明する。
【実施例１】
【００１２】
図２に示すように、実施例１の通信プロトコルでは、メッセージ１１が多数の数値データを並べたデータ列１２と、データ列１２の先頭に位置するヘッダ１３とで構成されている。データ列１２の数値データは、ＡＳＣＩＩコード等への変換を行わずに、そのまま１６進数の数値で表されている。例えば、送信先の“アドレス”は「０ｘ８０」、“コマンド”は「０ｘＡ１」、“データ１”は「０ｘ０２」でそれぞれ表現されている。そして、ヘッダ１３に２バイト１６進数の最大値である「０ｘＦＦ」が指定されている。
【００１３】
しかし、「０ｘＦＦ」はデータ列１２の中に多数紛れ込んでいるはずであるから、実施例１の通信プロトコルは、データ列１２で使用可能な数値に上限値を設定し、ヘッダ１３にその上限値を超える特定の数値を指定する。具体的には、データ列１２中の数値を１０進数の８桁までに制限する。１０進数の「９９，９９９，９９９」は１６進数の「０ｘ５Ｆ５Ｅ０ＦＦ」である。これを上限値に設定すれば、データ列１２に「０ｘＦＦ」が連続して現れる最大値は「０ｘ４ＦＦＦＦＦＦ」（８３，８８６，０７９）であり、「ＦＦ」が３回連続する。従って、ヘッダ１３に「ＦＦ」が４回連続する特定の数値、つまり「０ｘＦＦＦＦＦＦＦＦ」を指定すれば、ヘッダ１３と数値データとの混同を回避できる。
【００１４】
この場合、実際の電文１４がヘッダ１３の表示に４バイトを必要とするため、“ＳＴＸ”にＡＳＣＩＩコードの「０ｘ０２」（図６参照）を指定する従来と比較し、ヘッダ１３の電文長が４倍となる。しかし、実施例１の通信プロトコルによれば、例えば、ＡＳＣＩＩコードで２００バイトを要したデータ列１２の電文長が半分の１００バイトまで圧縮される。このため、電文１４の全長が差し引き９６バイトに相当する長さだけ短くなる。従って、メッセージ１１に含まれる数値データの量が増えるほど、通信時間を短縮でき、有料回線を利用する場合にパケット料等の通信費を節約できて、経済的かつ効率のよい通信を的確に行うことができる。
【実施例２】
【００１５】
図３に示すように、実施例２の通信プロトコルでは、メッセージ２１がデータ列２２とヘッダ２３とで構成され、データ列２２の先頭付近に“データ長”を表すセル２５が設けられている。“データ長”はデータ列２２の全長をバイトで示すデータであり、データ列２２の他の数値データと同様、１６進数の数値でセル２５に表されている。例えば、データ列２２に９９の数値データが含まれている場合、セル２５に自身を含む“データ長”が「０ｘ６４」（１０進数の１００）で表記される。
【００１６】
こうすれば、セル２５のデータに基づいてコンピュータ３が受信した電文２４の終わりを正しく認識できる。従って、ＡＳＣＩＩコードの“ＥＴＸ”をメッセージ２１から省略したとしても、通信になんらの支障をきたさない。その他の構成、作用効果は実施例１と同じである。
【実施例３】
【００１７】
図４に示すように、実施例３の通信プロトコルでは、メッセージ３１がデータ列３２とヘッダ３３とで構成され、データ列３２の末尾に“ＢＣＣ”を表すセル３５が設けられている。“ＢＣＣ”は電文３４にノイズ等による通信エラーが生じていないかどうかを示すデータであり、データ列３２の他の数値データと同様、１６進数の数値でセル３５に表記されている。ここで、“ＢＣＣ”の計算結果が「０ｘＦＦ」となる可能性がある。さらに偶然に、“ＢＣＣ”直前の“データ９９”が「０ｘ４ＦＦＦＦＦＦ」であった場合、“ＢＣＣ”と合わせて「ＦＦ」が４回連続し、これをコンピュータ３がヘッダ３３と誤認するおそれがある。
【００１８】
従って、実施例３の通信プロトコルは、“ＢＣＣ”を付加する場合に、「ＦＦ」が５回連続する特定の数値、つまり「０ｘＦＦＦＦＦＦＦＦＦＦ」をヘッダ３３に指定する。こうすれば、“ＢＣＣ”によるエラー表示機能を備えた通信システム１において、ヘッダ３３と数値データとの混同を確実に回避することができる。その他の構成、作用効果は実施例１と同じである。
【図面の簡単な説明】
【００１９】
【図１】本発明の通信プロトコルが適用される通信システムの概略図である。
【図２】実施例１の通信プロトコルを示す機能図である。
【図３】実施例２の通信プロトコルを示す機能図である。
【図４】実施例３の通信プロトコルを示す機能図である。
【図５】従来の通信プロトコルが使用するＡＳＣＩＩコード表である。
【図６】従来の通信プロトコルを示す機能図である。
【符号の説明】
【００２０】
１ 通信システム
２ ネットワーク
３ コンピュータ
４ 通信プロトコル
１１，２１，３１ メッセージ
１２，２２，３２ データ列
１３，２３，３３ ヘッダ
１４，２４，３４ 電文
【技術分野】
【０００１】
本発明は、通信メッセージをコンピュータが認識可能な形式に変換するプログラム、特に、数値データを含むメッセージの通信に適した通信プロトコルに関する。
【背景技術】
【０００２】
従来、通信ソースをＡＳＣＩＩコードに変換し、多数のＡＳＣＩＩコードを並べて通信メッセージを構成する通信プロトコルが知られている。メッセージを送受信する上で、メッセージの始めと終わりを認識することは重要であり、特に、メッセージの始まりを認識できないと、コンピュータは受信したメッセージを解読することが困難となる。ＡＳＣＩＩコードでは、図５に示すように、メッセージの先頭に付される“ＳＴＸ”に「０ｘ０２」が用意され、メッセージの末尾に付される“ＥＴＸ”に「０ｘ０３」が用意されている。このため、コンピュータは“ＳＴＸ”，“ＥＴＸ”をデータ中の他の文字（数字：「０ｘ３＊」、英文字：「０ｘ４＊」，「０ｘ５＊」）と区別して認識できる。
【０００３】
しかし、ＡＳＣＩＩコード変換を行う通信プロトコルにおいて、１６進数の数値をそのまま１バイトで表すと、コンピュータが１６進数の数値データ「０ｘ０２」を“ＳＴＸ”として誤認する可能性がある。そこで、従来の通信プロトコルは、図６に示すように、メッセージ５１の先頭に“ＳＴＸ”を付加し、末尾に“ＥＴＸ”を付加し、データ列５２中の複数の数値データをそれぞれ二つのＡＳＣＩＩコードに変換している。この方式によれば、例えば、“データ１”の数値「０ｘ０２」が「０」を表すＡＳＣＩＩコード「０ｘ３０」と、「２」を表すＡＳＣＩＩコード「０ｘ３２」とに分割されるため、“ＳＴＸ”を“データ１”と混同する可能性がなくなる。
【０００４】
なお、特許文献１には、７ビットのＡＳＣＩＩコードを６ビットの短縮コードに変換することで、文字データを圧縮する方法が記載されている。特許文献２には、複数の文字列をＡＳＣＩＩコード中の制御コードに割り当てて符号化する方法が記載されている。
【特許文献１】特開２００５−３１８６８号公報
【特許文献２】特開平１１−８５４５９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところが、従来の通信プロトコルによると、データ列５２中の数値データを二つのＡＳＣＩＩコードに変換しているので、１バイトの数値データを送るのに２バイトの電文長が必要になる。このため、多量の数値データを含むメッセージ５１を送受信する際に、電文５３の全長がいたずらに長くなり、通信時間がかかり、有料回線を使用する場合にパケット料等の通信費が高くつく問題点があった。また、多量の数値データをＡＳＣＩＩコードに変換すると、制御プログラムの負担が重くなるため、コンピュータによる他の処理が遅くなる不都合もあった。
【０００６】
そこで、本発明の目的は、コンピュータが数値データを含むメッセージの通信を効率よく行うことができる通信プロトコルを提供することにある。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明の通信プロトコルは、通信メッセージをコンピュータが認識可能な形式に変換するプログラムであって、通信メッセージを数値データが含まれるデータ列と、データ列の先頭に付加されるヘッダとで構成し、データ列中の数値データを特定値を除く１６進数の数値で表し、ヘッダに該特定値を表す１６進数の数値を指定することを特徴とする。
【０００８】
ここで、ヘッダに指定する１６進数の数値は、データ列中に発生し得ない特定の数値である。該特定値の選定にあたり、好ましくは、次の手段を採用できる。
（１）データ列中で使用可能な数値に上限値を設定し、ヘッダにその上限値を超える特定値を指定する。この場合、上限値は、特定の数値や桁数に限定されず、通信プロトコルの適用分野、又は該プロトコルが扱う数値データの種類等に応じて適宜に設定できる。
（２）ヘッダに１６進数の特定値を複数回連続させて指定する。特定値及びこれを連続させる回数は、特に限定されず、通信プロトコルの適用分野、又は数値データの種類等に応じて適宜に選択できる。
（３）例えば、特定値に２バイト１６進数の最大値である「０ｘＦＦ」を用い、ヘッダに該数値を複数回連続させて指定することができる。
【０００９】
また、本発明は上記通信プロトコルに次の手段を加えて実施することも可能である。
（４）データ列中にメッセージの長さを示す指標となる１６進数の数値を付加する。
（５）データ列中にノイズ等による通信エラーを示す１６進数の数値を付加する。
【発明の効果】
【００１０】
本発明の通信プロトコルは、データ列中の数値データを１６進数の数値で表すので、１バイトの数値データを分割することなく１バイトのままで送受信できる。このため、メッセージの長さを短くし、通信時間を短縮して、通信費を節約できるとともに、ＡＳＣＩＩコードへの変換処理を不要にして、コンピュータの負担を軽減できる。また、データ列中に発生し得ない特定値をヘッダに指定するので、コンピュータが数値データをヘッダと誤認する可能性もなくなる。従って、本発明の通信プロトコルによれば、特に多量の数値データを含むメッセージを送る場合に、経済的かつ効率のよい通信を的確に行うことができるという効果がある。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を実施するための最良の形態を図面に基づいて説明する。図１に示すように、この実施形態の通信システム１は、ネットワーク２に接続された複数のコンピュータ３が通信プロトコル４を用いて主に数値データからなるビジネスメッセージの送受信を行うように構成されている。通信プロトコル４は、通信プログラムの一部として各コンピュータ３に実装され、受信したメッセージを該コンピュータ３の他のプログラムが認識可能な形式に変換する。以下に、通信プロトコル４の具体的な機能について幾つかの実施例をあげて詳細に説明する。
【実施例１】
【００１２】
図２に示すように、実施例１の通信プロトコルでは、メッセージ１１が多数の数値データを並べたデータ列１２と、データ列１２の先頭に位置するヘッダ１３とで構成されている。データ列１２の数値データは、ＡＳＣＩＩコード等への変換を行わずに、そのまま１６進数の数値で表されている。例えば、送信先の“アドレス”は「０ｘ８０」、“コマンド”は「０ｘＡ１」、“データ１”は「０ｘ０２」でそれぞれ表現されている。そして、ヘッダ１３に２バイト１６進数の最大値である「０ｘＦＦ」が指定されている。
【００１３】
しかし、「０ｘＦＦ」はデータ列１２の中に多数紛れ込んでいるはずであるから、実施例１の通信プロトコルは、データ列１２で使用可能な数値に上限値を設定し、ヘッダ１３にその上限値を超える特定の数値を指定する。具体的には、データ列１２中の数値を１０進数の８桁までに制限する。１０進数の「９９，９９９，９９９」は１６進数の「０ｘ５Ｆ５Ｅ０ＦＦ」である。これを上限値に設定すれば、データ列１２に「０ｘＦＦ」が連続して現れる最大値は「０ｘ４ＦＦＦＦＦＦ」（８３，８８６，０７９）であり、「ＦＦ」が３回連続する。従って、ヘッダ１３に「ＦＦ」が４回連続する特定の数値、つまり「０ｘＦＦＦＦＦＦＦＦ」を指定すれば、ヘッダ１３と数値データとの混同を回避できる。
【００１４】
この場合、実際の電文１４がヘッダ１３の表示に４バイトを必要とするため、“ＳＴＸ”にＡＳＣＩＩコードの「０ｘ０２」（図６参照）を指定する従来と比較し、ヘッダ１３の電文長が４倍となる。しかし、実施例１の通信プロトコルによれば、例えば、ＡＳＣＩＩコードで２００バイトを要したデータ列１２の電文長が半分の１００バイトまで圧縮される。このため、電文１４の全長が差し引き９６バイトに相当する長さだけ短くなる。従って、メッセージ１１に含まれる数値データの量が増えるほど、通信時間を短縮でき、有料回線を利用する場合にパケット料等の通信費を節約できて、経済的かつ効率のよい通信を的確に行うことができる。
【実施例２】
【００１５】
図３に示すように、実施例２の通信プロトコルでは、メッセージ２１がデータ列２２とヘッダ２３とで構成され、データ列２２の先頭付近に“データ長”を表すセル２５が設けられている。“データ長”はデータ列２２の全長をバイトで示すデータであり、データ列２２の他の数値データと同様、１６進数の数値でセル２５に表されている。例えば、データ列２２に９９の数値データが含まれている場合、セル２５に自身を含む“データ長”が「０ｘ６４」（１０進数の１００）で表記される。
【００１６】
こうすれば、セル２５のデータに基づいてコンピュータ３が受信した電文２４の終わりを正しく認識できる。従って、ＡＳＣＩＩコードの“ＥＴＸ”をメッセージ２１から省略したとしても、通信になんらの支障をきたさない。その他の構成、作用効果は実施例１と同じである。
【実施例３】
【００１７】
図４に示すように、実施例３の通信プロトコルでは、メッセージ３１がデータ列３２とヘッダ３３とで構成され、データ列３２の末尾に“ＢＣＣ”を表すセル３５が設けられている。“ＢＣＣ”は電文３４にノイズ等による通信エラーが生じていないかどうかを示すデータであり、データ列３２の他の数値データと同様、１６進数の数値でセル３５に表記されている。ここで、“ＢＣＣ”の計算結果が「０ｘＦＦ」となる可能性がある。さらに偶然に、“ＢＣＣ”直前の“データ９９”が「０ｘ４ＦＦＦＦＦＦ」であった場合、“ＢＣＣ”と合わせて「ＦＦ」が４回連続し、これをコンピュータ３がヘッダ３３と誤認するおそれがある。
【００１８】
従って、実施例３の通信プロトコルは、“ＢＣＣ”を付加する場合に、「ＦＦ」が５回連続する特定の数値、つまり「０ｘＦＦＦＦＦＦＦＦＦＦ」をヘッダ３３に指定する。こうすれば、“ＢＣＣ”によるエラー表示機能を備えた通信システム１において、ヘッダ３３と数値データとの混同を確実に回避することができる。その他の構成、作用効果は実施例１と同じである。
【図面の簡単な説明】
【００１９】
【図１】本発明の通信プロトコルが適用される通信システムの概略図である。
【図２】実施例１の通信プロトコルを示す機能図である。
【図３】実施例２の通信プロトコルを示す機能図である。
【図４】実施例３の通信プロトコルを示す機能図である。
【図５】従来の通信プロトコルが使用するＡＳＣＩＩコード表である。
【図６】従来の通信プロトコルを示す機能図である。
【符号の説明】
【００２０】
１ 通信システム
２ ネットワーク
３ コンピュータ
４ 通信プロトコル
１１，２１，３１ メッセージ
１２，２２，３２ データ列
１３，２３，３３ ヘッダ
１４，２４，３４ 電文
【特許請求の範囲】
【請求項１】
通信メッセージをコンピュータが認識可能な形式に変換するプログラムであって、通信メッセージを数値データが含まれるデータ列と、データ列の先頭に付加されるヘッダとで構成し、データ列中の数値データを特定値を除く１６進数の数値で表し、ヘッダに該特定値を表す１６進数の数値を指定することを特徴とする通信プロトコル。
【請求項１】
通信メッセージをコンピュータが認識可能な形式に変換するプログラムであって、通信メッセージを数値データが含まれるデータ列と、データ列の先頭に付加されるヘッダとで構成し、データ列中の数値データを特定値を除く１６進数の数値で表し、ヘッダに該特定値を表す１６進数の数値を指定することを特徴とする通信プロトコル。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００７−１４１１２７（Ｐ２００７−１４１１２７Ａ）
【公開日】平成１９年６月７日（２００７．６．７）
【国際特許分類】
【出願番号】特願２００５−３３６８６９（Ｐ２００５−３３６８６９）
【出願日】平成１７年１１月２２日（２００５．１１．２２）
【出願人】（０００１２４５９１）河村電器産業株式会社 (857)
【Ｆターム（参考）】
【公開日】平成１９年６月７日（２００７．６．７）
【国際特許分類】
【出願日】平成１７年１１月２２日（２００５．１１．２２）
【出願人】（０００１２４５９１）河村電器産業株式会社 (857)
【Ｆターム（参考）】
[ Back to top ]