|
Abstract Syntax Notation OneAbstract Syntax Notation One（ASN.1）とは、電気通信やコンピュータネットワークでのデータ構造の表現・エンコード・転送・デコードを記述する標準的かつ柔軟な記法である。マシン固有の技法などに依存せず、曖昧さのない記述を可能とする形式規則を提供する。 1984年、CCITT X.409: 1984 の一部として、ISOとITU-Tが策定した。ASN.1 はその適用範囲の広さから、1988年に X.208 として独立することとなった。1995年、改訂版が X.680 シリーズとなっている。 データ転送における ASN.1ASN.1 は情報の抽象構文を定義するが、情報の符号化方法を限定するものではない。抽象構文をASN.1で記述されたデータを転送する際の ASN.1 符号化規則が各種用意されている。 ASN.1 の標準符号化規則として以下のものがある。
ASN.1記法と特定のASN.1符号化規則を使うことで、マシンのアーキテクチャや実装言語に依存しない形式で、ネットワーク上のアプリケーション間でやりとりするデータ構造を定めることができる。 X.400 電子メール、X.500 あるいは LDAP ディレクトリ・サービス、H.323（VoIP）、SNMP、BACnet といったアプリケーション層のプロトコルは ASN.1 を使ってProtocol Data Unitを規定する。UMTSでも使われている。他にも ASN.1 の応用範囲は様々である[1]。 例ASN.1 記法で FooProtocol のデータ構造を定義したものを以下に示す。 FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE {
trackingNumber INTEGER,
question VisibleString
}
FooAnswer ::= SEQUENCE {
questionNumber INTEGER,
answer BOOLEAN
}
END
これが Foo プロトコル作成者が公開する仕様となる。ASN.1 はプロトコルの手順（流れ）を定義しない。その部分は文章で説明される。 ここで、Foo プロトコル準拠のメッセージを他の誰かに送るとする。このメッセージ（PDU）は以下のようになっている。 myQuestion FooQuestion ::= {
trackingNumber 5,
question "Anybody there?"
}
ASN.1 は、値とサイズの制限および拡張性をサポートする。上記仕様は次のように変更可能である。 FooProtocol DEFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE {
trackingNumber INTEGER(0..199),
question IA5String
}
FooAnswer ::= SEQUENCE {
questionNumber INTEGER(10..20),
answer BOOLEAN
}
FooHistory ::= SEQUENCE {
questions SEQUENCE(SIZE(0..10)) OF FooQuestion,
answers SEQUENCE(SIZE(1..10)) OF FooAnswer,
anArray SEQUENCE(SIZE(100)) OF INTEGER(0..1000),
...
}
END
この変更は trackingNumber が持つ値を 0 から 199 までに、questionNumbers が持つ値を 10 から 20 までに制限する。questions 配列のサイズは 0個から10個であり、answers 配列の数は 1個から10個である。anArray フィールドは 0 から 1000 までの範囲の整数が常に100 個である。上記中の '...' は拡張性マーカーであり、将来バージョンのFooHistoryメッセージ仕様にフィールドが追加される可能性があることを示す。このバージョンに準拠するシステムは、処理の対象はこのバージョンのフィールドのみであっても、将来バージョンのトランザクションを受信および転送できる必要がある。 優れた ASN.1 コンパイラは、トランザクションがこれらの制約に従っていることを自動的にチェックするソースコードを (C, C++, Java 等) で生成する。制約に違反するトランザクションは、アプリケーションから受理されず、送信もされない。このレイヤにおける制約管理は、アプリケーションを制約違反から守り、プロトコル仕様を非常にシンプルにする。それにより、リスクとコストが削減される。
Foo プロトコル仕様では、どの符号化規則を採用するかを明確に決めておかなければならない。それによって、Foo プロトコルのユーザー間で（例えば）DER を使うという共通認識ができる。 DER による符号化例上掲のデータ構造（制約と拡張性の無いもの）を DER 形式に符号化すると次のようになる。
すなわち、DER での符号化パターンは「型-長さ-値」の組の羅列である。従って、符号化によって得られるのは以下の21オクテットのデータ列である。
ASN.1 と DER の関わる範囲はここまでである。これを実際に転送する方法は ASN.1 とは無関係に決められる（つまり、TCPを使おうと他のプロトコルを使おうと関係ない）。受信側は受信したオクテット列を DER に従ってデコードできる。 XER による符号化例同じ ASN.1 データ構造を XER (XML Encoding Rules) で符号化し、人間にも読める形式にすることもできる。例の場合、以下の108オクテットになる。 <FooQuestion>
<trackingNumber>5</trackingNumber>
<question>Anybody there?</question>
</FooQuestion>
PER による符号化例Packed Encoding Rules を使うと、以下のように 16 オクテット以内に符号化できる。
ASN.1 とその他のデータ構造定義通信プロトコルのメッセージを定義する場合、ASN.1 では主にバイナリ符号化規則が使われる。 他のインターネットでよく使われるアプリケーション層のプロトコル（HTTPやSMTP）では、メッセージ定義にはタグと値が使われ、時にはABNF記法が使われる。それらの定義には符号化も含まれるが、テキストによる符号化である。 これら2つの手法はそれぞれに利点があり、議論が数多く行われてきた。ASN.1 の手法は効率がよいとされており、Packed Encoding Rules ではさらにコンパクトな符号化を実現できる。テキストを使った手法は実装が容易でデバッグが容易とされている（人間が符号化されたメッセージを読めるため）。Megaco（H.248）プロトコルでは、どちらの符号化がよいかを決められず、ASN.1 に基づいた符号化と ABNF に基づいた符号化の両方が定義されている。 ASN.1 の XML Encoding Rules (XER) はこのギャップを埋めるべく、ASN.1 記法で定義された構造をテキスト符号化する方法を提供する。類似の Generic String Encoding Rules は特にユーザーとのやりとりのために定義された符号化規則である。 ASN.1 の実際の利用ASN.1 コンパイラを使って、ASN.1 記法によるコードから、等価なデータ構造を表現する適当なコード（例えばC言語のソースコード）を生成する場合もある。このコードとランタイムライブラリにより、符号化されたデータ構造と言語が理解できる表現の間で双方向の変換が可能となる。あるいは、人間の手でエンコード・デコードのルーチンを書く場合もある。 標準ASN.1記法を説明した標準 (free download from the ITU-T website):
ASN.1符号化規則を説明した標準 (free download from the ITU-T website):
対応する日本工業規格
関連項目参考文献この記事は2008年11月1日以前にFree On-line Dictionary of Computingから取得した項目の資料を元に、GFDL バージョン1.3以降の「RELICENSING」(再ライセンス) 条件に基づいて組み込まれている。 外部リンク
|
