ASN.1
ASN.1
抽象構文記法1
現状発効中。X.208およびX.209（1988年）に取って代わる
開始年1984
最新版（02/21）2021年2月
組織ITU-T
委員会研究グループ17
基本規格ASN.1
関連規格X.208、X.209、X.409、X.509、X.680、X.681、X.682、X.683
ドメイン暗号、電気通信
ウェブサイトhttps://www.itu.int/rec/T-REC-X.680/

抽象構文記法1（ASN.1 ）は、クロスプラットフォームでシリアル化およびデシリアル化可能なデータ構造を定義するための標準インターフェース記述言語（IDL）です。電気通信やコンピュータネットワーク、特に暗号化において広く使用されています。[ 1 ]

プロトコル開発者は、データ構造をASN.1モジュールで定義します。ASN.1モジュールは通常、ASN.1言語で記述されたより広範な標準文書の一部です。ASN.1モジュールの利点は、データエンコーディングの記述が特定のコンピュータやプログラミング言語に依存しないことです。ASN.1は人間と機械の両方が読めるため、ASN.1コンパイラはモジュールをコードライブラリ（コーデック）にコンパイルし、データ構造をデコードまたはエンコードすることができます。一部のASN.1コンパイラは、パックド、 BER、XMLなど、複数のエンコーディングをエンコードまたはデコードするコードを生成できます。

ASN.1は、国際電気通信連合電気通信標準化部門（ITU-T）のITU-T研究グループ17と国際標準化機構/国際電気標準会議（ISO/IEC）の共同標準であり、1984年にCCITT X.409 :1984の一部として最初に定義されました。 [ 2 ] ASN.1は1988年に、適用範囲の広さから独自の標準であるX.208に移行しました。1995年に大幅に改訂されたバージョンは、X.680 - X.683シリーズに含まれています。[ 3 ] X.680シリーズの勧告の最新版は、2021年に発行された6.0版です。[ 4 ]

構造

  • X.680は、ASN.1言語の基本的な語彙項目（特殊トークン、基本リテラル値の形式など）を定義します。プロトコル内のモジュールの定義である「モジュール定義」の構文を定義します。モジュール定義には、データ型、それらのデータ型で記述された定義済み情報オブジェクト（詳細な構文はX.681）、制約要素（詳細な構文はX.682）などを含めることができます
  • X.681は情報オブジェクトの構文を定義しており、これによりカスタムデータ型のオブジェクトをX.681言語で表現することが可能になります（他の言語におけるオブジェクトリテラルに類似）。また、ドット表記を用いてオブジェクト内の特定の値をテーブルのように参照する方法も定義しています。
  • X.682 は、モジュール内でより高度な制約を適用するために使用できる制約要素を定義します。
  • X.683 ( ASN.1 仕様のパラメータ化) では、パラメータに応じて割り当てと定義を変更できます。

言語サポート

ASN.1はデータ型宣言記法です。このような型の変数の操作方法は定義されていません。変数の操作は、実行可能モデリング用のSDL（仕様記述言語）や適合性テスト用のTTCN-3（テストおよびテスト制御記法）などの他の言語で定義されています。これらの言語はどちらもASN.1宣言をネイティブにサポートしています。ASN.1モジュールをインポートし、モジュールで宣言された任意のASN.1型の変数を宣言することができます

アプリケーション

ASN.1は多数のプロトコルの定義に使用されています。最も広範な用途は、電気通信、暗号化、生体認証です

ASN.1を使用するプロトコル
プロトコル 仕様 指定された、または慣習的な符号化規則 用途
インターレジャープロトコルILPV4仕様オクテット符号化規則
NTCIP 1103 - トランスポート管理プロトコルNTCIP 1103オクテット符号化規則交通、輸送、およびインフラ管理
X.500ディレクトリサービスITU X.500勧告シリーズ基本的なエンコードルール、区別されたエンコードルールLDAP、TLS（X.509）証明書、認証
軽量ディレクトリアクセスプロトコル(LDAP)RFC  4511基本的な符号化規則
PKCS暗号標準PKCS暗号化標準基本的なエンコードルールと区別されたエンコードルール非対称鍵、証明書バンドル
X.400メッセージ処理ITU X.400勧告シリーズ電子メールの初期の競合
EMVEMVCo出版物決済カード
T.120マルチメディア会議ITU T.120勧告シリーズ基本的なエンコーディングルール、パックされたエンコーディングルールMicrosoft のリモート デスクトップ プロトコル(RDP)
簡易ネットワーク管理プロトコル(SNMP)RFC  1157基本的な符号化規則ネットワークとコンピュータの管理と監視、特にパフォーマンスと信頼性に関する特性
共通管理情報プロトコル(CMIP)ITU勧告X.711SNMPの競合製品だが、より高性能だが、SNMPほど人気はない。
信号システム第7号（SS7）ITU Q.700勧告シリーズ公衆交換電話網（PSTN）を介した電話接続の管理
ITU H シリーズ マルチメディア プロトコルITU H.200、H.300、およびH.400勧告シリーズボイスオーバーインターネットプロトコル（VOIP）
BioAPIインターワーキングプロトコル (BIP)ISO/IEC 24708:2008
共通生体認証交換フォーマットフレームワーク（CBEFF）NIST IR 6529-A基本的な符号化規則
生体認証のための認証コンテキスト (ACBio)ISO/IEC 24761:2019
コンピュータ支援通信アプリケーション（CSTA）[1]基本的な符号化規則
狭域通信（DSRC）SAE J2735パック符号化規則車両通信
IEEE 802.11p (IEEE WAVE)IEEE 1609.2車両通信
高度道路交通システム（ETSI ITS）ETSI EN 302 637 2 (CAM) ETSI EN 302 637 3 (DENM)非整列パックエンコード規則車両通信
グローバル移動通信システム（GSM）[2]2G携帯電話通信
汎用パケット無線サービス（GPRS）/ GSM Evolution向け拡張データレート（EDGE）[3]2.5G携帯電話通信
ユニバーサルモバイルテレコミュニケーションシステム（UMTS）[4]3G携帯電話通信
ロングタームエボリューション（LTE）[5]4G携帯電話通信
5G[6]5G携帯電話通信
共通警報プロトコル（CAP）[7]XMLエンコーディングルールアンバーアラートなどの警報情報の交換
管制官・操縦士間データリンク通信（CPDLC）航空通信
スペースリンク拡張サービス（SLE）宇宙システム通信
製造メッセージ仕様（MMS）ISO 9506-1:2003製造
ファイル転送、アクセス、管理(FTAM)ファイル転送プロトコルの初期の、より有能な競合相手でしたが、現在ではほとんど使用されていません。
リモート操作サービス要素プロトコル(ROSE)ITU勧告X.880、X.881、およびX.882リモートプロシージャコールの初期の形式
アソシエーション制御サービス要素(ACSE)ITU勧告X.227
ビルオートメーションおよび制御ネットワークプロトコル（BACnet）ASHRAE 135-2020BACnetエンコーディング規則火災警報器、エレベーター、HVACシステムなどの建物の自動化と制御
ケルベロスRFC  4120基本的な符号化規則安全な認証
WiMAX 2広域ネットワーク
インテリジェントネットワークITU Q.1200勧告シリーズ電気通信およびコンピュータネットワーク
X2AP 基本アラインメントパック符号化規則
合法的傍受（LI）ハンドオーバーインターフェースETSI TS 102 232-1合法的傍受

エンコーディング

ASN.1は、データ構造を一連のバイトとして表現する方法を規定する一連のエンコーディング規則と密接に関連しています。標準的なASN.1エンコーディング規則には、以下が含まれます

ASN.1符号化規則
符号化規則 オブジェクト識別子 仕様 シリアル化の単位 仕様を事前に知らなくても識別可能なエンコードされた要素 オクテット整列 エンコード制御 説明
ドット付き IRI
基本符号化規則（BER）[ 5 ]2.1.1 ISO-ITU -T共同規格/ASN.1/基本符号化 ITU X.690 オクテット はい はい いいえ 最初に指定されたエンコード規則。要素をタグ-長さ-値（TLV）シーケンスとしてエンコードします。通常、データ値のエンコード方法についていくつかのオプションを提供します。これは最も柔軟なエンコード規則の1つです
識別符号化規則（DER）[ 6 ]2.1.2.1 ISO-ITU-T共同規格ASN.1 BER導出識別符号化 ITU X.690 オクテット はい はい いいえ BERの限定されたサブセット。DERではエンコードの選択肢が少なく、DERでエンコードされた値は同じバイト列に再エンコードされる可能性が高いため、特定の抽象値から生成されるデジタル署名は実装間で同一になり、DERでエンコードされたデータから生成されるデジタル署名は衝突攻撃の影響を受けにくくなるため、通常はデジタル署名に使用されます。
標準符号化規則（CER）[ 7 ]2.1.2.0 ISO-ITU-T共同規格ASN.1 BER導出標準符号化 ITU X.690 オクテット はい はい いいえ BER の制限付きサブセット。DER とほぼ同様の制限が適用されますが、注目すべき違いは、CER では、多くの大きな値（特に文字列）が 1000 バイトまたは 1000 文字（データ型によって異なります）ごとに個別の部分文字列要素に「分割」されることが規定されていることです。
パック符号化規則非整列（PER-U/UPER）[ 8 ]2.1.3.0.1 /Joint‑ISO‑ITU‑T/ASN.1/パックエンコーディング/基本/非整列 ITU X.691 ビット いいえ いいえ いいえ ビットに値を符号化します。単に「PER」と呼ばれることもあります。PERは一般的に非常にコンパクトな符号化を生成できますが、複雑さが増し、データ型に課せられた制約に大きく依存します
パック符号化規則整合（PER-A/APER）[ 8 ]2.1.3.0.0 /Joint-ISO-ITU-T/ASN.1/パック符号化/基本/アライン ITU X.691 ビット いいえ はい いいえ ビットに値をエンコードしますが、エンコードされたビットが8で割り切れない場合は、整数個のオクテットで値がエンコードされるまでパディングビットが追加されます
正規化パック符号化規則非整列（CPER-U）[ 8 ]2.1.3.1.1 ISO-ITU-T共同規格ASN.1パック符号化方式/標準/非整列 ITU X.691 ビット いいえ いいえ いいえ PER-Uの変種で、値のエンコード方法を1つだけ指定します。単に「CPER」と呼ばれることもあります。CPERは、DERとCERがBERに対して持つPERと同様の関係を持ちます。
正規パック符号化規則整合（CPER-A）[ 8 ]2.1.3.1.0 ISO-ITU-T共同規格ASN.1パック符号化方式/正規化/アラインメント ITU X.691 ビット いいえ はい いいえ 値をエンコードする単一の方法を指定する PER-A のバリアント。
基本XMLエンコーディングルール（XER）[ 9 ]2.1.5.0 ISO-ITU-T共同規格ASN.1 XMLエンコーディング基本 ITU X.693 文字 はい はい ECN ASN.1データをXMLとしてエンコードします
正規XMLエンコーディング規則（CXER）[ 9 ]2.1.5.1 ISO-ITU-T共同規格ASN.1 XMLエンコーディング標準 ITU X.693 文字 はい はい ECN 特定の値に対して 1 つの可能なエンコードのみを生成する XER のバリアント。
拡張XMLエンコーディング規則（EXER）[ 9 ]2.1.5.2 ISO-ITU-T共同ASN.1 XMLエンコーディング拡張 ITU X.693 文字 はい はい ECN エンコーダーのスタイルの選択を制御するオプションと命令を追加する XER のバリアント。
オクテット符号化規則（OER）[ 10 ]2.1.6.0 ISO-ITU-T共同規格ASN.1 OERエンコーディング基本 ITU X.696 オクテット いいえ はい いいえ 値をオクテットにエンコードする符号化規則のセット。BERのようにタグや長さの決定要素はエンコードしません。OERを使用してエンコードされたデータ値は、多くの場合、「レコードベース」プロトコルで見られる値に似ています。OERは実装が容易で、BERよりもコンパクトなエンコードを生成できるように設計されています。エンコーダ/デコーダの開発労力を軽減することに加えて、OERを使用すると、帯域幅の使用率（PERほどではありませんが）を削減し、CPUサイクルを節約し、エンコード/デコードの遅延を短縮できます

ITU X.696 OERは、 NEMAのNTCIP 1102で定義されているほぼ互換性のある「OER」から派生したものです。NEMAのOERは、残念ながら名前が付けられているNEMA Packed Encoding Rules (NEMA PER)を明確化および拡張したバージョンです。[ 11 ]：27

標準オクテット符号化規則（COER）[ 10 ]2.1.6.1 /Joint-ISO-ITU-T/ASN.1/OER-Encoding/CanonicalITU X.696 オクテット いいえ はい いいえ OERの変形で、各値は1つのオクテット表現のみを持ちます
JSONエンコーディングルール（JER）[ 12 ]ITU X.697 文字 はい はい ECN ASN.1データをJSONとしてエンコードします。ASCIIのみのバージョンが正規化されており、各値は1つのオクテット表現のみを持ちます。残りはそうではありません
汎用文字列エンコード規則（GSER）[ 13 ]1.2.36. 79672281. 0.0 /ISO/Member‑Body/AU/Adacel/0/GSER RFC  3641文字 はい はい RFC 4792GSERは、ASN.1の値表記に似た非常に分かりやすい形式で、ユーザーへのエンコードされたデータ、またはユーザーからの入力データを表すことを目的としています。GSERは元々、Lightweight Directory Access Protocol（LDAP）用に設計されたもので、LDAP以外ではほとんど使用されていません。ASN.1でサポートされているすべての文字列エンコーディングをGSERで再現できるわけではないため、実際のプロトコルでGSERを使用することは推奨されません。エンコーディングのカスタマイズは、ECNではなくGSERを介して行われます。
堅牢な XMLエンコーディング ルール (RXER) 1.2.36. 79672281. 0.2 /ISO/Member‑Body/AU/Adacel/0/RXER RFC  4910文字 はい はい RFC 4911Lightweight Directory Access Protocol (LDAP) 用に設計された XML 形式。
BACnetエンコーディング ルール(BACnetER) ASHRAE 135 ISO 16484-5 オクテット はい はい ECN 基本符号化規則（BER）と同様に、要素をタグ・長さ・値（TLV）シーケンスとして符号化します。メッセージの例はKarg（2012）に記載されています。[ 14 ] KargはBACnetスタックのオープンソース実装も管理しており、この形式の読み書き用のコードが含まれています。[ 15 ]
シグナリング固有の符号化規則（SER） フランステレコムR&D内部文書 オクテット はい はい いいえ GSMやSS7などの通信関連プロトコルで主に使用されます。ASN.1で規定されていない既存のプロトコルが生成するのと同じエンコーディングをASN.1から生成するように設計されています。
軽量エンコーディングルール（LWER） INRIAによる内部文書。 記憶の言葉 はい いいえ INRIAが作成した「フラットツリー軽量構文」（FTLWS）の詳細を記した内部文書に由来する。 [ 16 ]パック符号化規則（PER）の優れた性能により1997年に廃止された。[ 17 ] : 319 ビッグエンディアンまたはリトルエンディアン伝送、および8ビット、16ビット、32ビットのメモリワードをオプションで選択可能。（これらのオプションの組み合わせが6つあるため、6つのバリエーションが存在する。）
最小ビット符号化規則（MBER） ビット いいえ いいえ いいえ 1980年代に提案されました。後のパック符号化規則（PER）のように、可能な限りコンパクトになることを目的としていました。すべてのASN.1データ型に拡張されたことはありません。[ 17 ]：319
高速コーディングルール 「高速ネットワークのコーディングルール」[ 18 ]いいえ これらのエンコード規則の定義は、INRIA の Flat Tree Light Weight Syntax (FTLWS) に関する作業の副産物でした。

符号化制御記法

ASN.1勧告では、いくつかの定義済み符号化規則が提供されています。既存の符号化規則がどれも適切でない場合、符号化制御記法（ECN、X.692）は、ユーザーが独自のカスタマイズされた符号化規則を定義する方法を提供します

プライバシー強化メール（PEM）エンコーディングとの関係

プライバシー強化メール (PEM)エンコーディングは ASN.1 およびそのコーデックとはまったく関係ありませんが、多くの場合バイナリであるエンコードされた ASN.1 データは、SMTP リレーやコピー/ペースト バッファなどを通じてテキスト データとして送信できるように PEM エンコードされることがよくあります。

コンピュータファイルとして

ASN.1言語およびエンコード仕様では、データの塊をコンピュータにファイルとして保存する際に使用するファイル名拡張子などの詳細は規定されていません。しかし、いくつかの規則が生まれています

  • ASN.1言語テキスト: .asn1[ 19 ]の拡張であり、.all一般的なファイルに使用されています。モジュール定義のみを含むファイルと値定義のみを含むファイル.asnに使用されています。 [ 20 ].prt
  • BERエンコードされたデータ:.berが使用されています。[ 21 ]また、関連するOIDを指定するパラメータを含むMIMEタイプ も提案されています。 [ 22 ]application/ber-streamprotocol
    • DER エンコード データ: .der。DER エンコードX.509証明書の場合、.cerに.crt加えて.der。MIME タイプはapplication/x-x509-ca-cert、一般的な DER データではなく、DER エンコード証明書専用です。
  • その他のエンコードされたデータ:asn1cサンプル ファイルは.xerXER、.perPER、および.coerCOER に使用されます。

例

モジュールと制約

これは、架空のFooプロトコルのメッセージ (データ構造) を定義する ASN.1 モジュールの例です。 

FooProtocol定義::=開始FooQuestion ::= SEQUENCE { trackingNumber INTEGER 、質問IA5String }FooAnswer ::= SEQUENCE {質問番号INTEGER 、回答BOOLEAN }終了

これはFooプロトコルの作成者によって公開された仕様である可能性があります。会話フロー、トランザクション交換、および状態はASN.1では定義されておらず、プロトコルの他の表記法とテキストによる記述に委ねられています

ASN.1は、値とサイズの制約、および拡張性をサポートしています。上記の仕様は次のように変更できます。 

FooProtocol定義::=開始FooQuestion ::= SEQUENCE { trackingNumber INTEGER ( 0. . 199 ), question IA5String }FooAnswer ::= SEQUENCE {質問番号INTEGER ( 10. . 20 ),回答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 )、... }終了

この変更により、trackingNumbers の値は 0 から 199 まで、questionNumbers の値は 10 から 20 までに制限されます。questions 配列のサイズは 0 から 10 要素まで、answers 配列の要素は 1 から 10 までです。anArray フィールドは、0 から 1000 までの範囲の整数の固定長 100 要素配列です。拡張性マーカー '...' は、FooHistory メッセージ仕様に将来のバージョンの仕様でフィールドが追加される可能性があることを意味します。つまり、あるバージョンに準拠しているシステムは、それより後のバージョンのトランザクションを送受信できますが、処理できるのは以前のバージョンで指定されたフィールドだけです。優れた ASN.1 コンパイラは、トランザクションがこれらの制約内に収まっていることを自動的にチェックするソース コード (C、C++、Java など) を生成します。制約に違反するトランザクションは、アプリケーションから受け入れたり、アプリケーションに提示したりしてはなりません。このレイヤーでの制約管理により、アプリケーションが制約違反から保護され、リスクとコストが削減されるため、プロトコル仕様が大幅に簡素化されます。

上記の例では、X.680の構文のみを使用しています。X.682のより高度な制約は使用されていません。

PDUの例

Fooプロトコルに準拠し、受信側に送信されるメッセージを想定すると、この特定のメッセージ（プロトコルデータユニット（PDU））は次のとおりです 

myQuestion FooQuestion ::= { trackingNumber 5 、質問「誰かいますか？」}

myQuestionメッセージをネットワーク経由で送信するために、メッセージはエンコード規則の1つを使用してバイト列としてシリアル化（エンコード）されます。Fooプロトコル仕様では、使用するエンコード規則のセットを明示的に指定する必要があります。これにより、Fooプロトコルのユーザーは、どのエンコード規則を使用すべきか、またどのような結果になるかを把握できます。

上記は X.681、具体的にはObjectAssignment構造の例です。

DERでエンコードされた例

以下は、上記の myQuestion をDER 形式でエンコードしたデータ構造です(すべての数値は 16 進数です)。 

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER は型、長さ、値のエンコーディングであるため、上記のシーケンスは、標準の SEQUENCE、INTEGER、および IA5String 型を参照して次のように解釈できます。 

30 — SEQUENCEを示す型タグ 13 — 後続の値のオクテット単位の長さ 02 — INTEGERを示す型タグ 01 — 後続の値のオクテット単位の長さ 05 — 値 (5) 16 — IA5Stringを示す型タグ （IA5は、バリアントを含む完全な7ビットISO 646セットを意味します。 ただし、通常は US-ASCII です) 0e — 後続の値のオクテット単位の長さ 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — 値 ("誰かいますか?")

XERでエンコードされた例

あるいは、同じASN.1データ構造をXMLエンコーディング規則（XER）でエンコードすることで、「ネットワーク経由」での可読性を向上させることも可能です。その場合、以下の108オクテットのようになります（スペース数にはインデント用のスペースも含まれます）。 

<FooQuestion> <trackingNumber> 5 </trackingNumber> <question>誰かいますか？</question> </FooQuestion>

PERでエンコードされた例（整列または非整列）

あるいは、Packed Encoding Rules Unaligned が採用されている場合、次の 122 ビット (16 オクテットは 128 ビットになりますが、ここでは 122 ビットのみが情報を伝達し、最後の 6 ビットは単なるパディングです) が生成されます。 

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

この形式では、必須要素の型タグはエンコードされないため、エンコードに使用される想定スキーマを知らなければ解析できません。さらに、IA5String の値のバイトは、8 ビット単位ではなく 7 ビット単位でパックされます。これは、エンコーダーが IA5String バイト値のエンコードには 7 ビットしか必要ないことを知っているためです。ただし、長さバイトは、最初の整数タグ 01 であっても、ここでエンコードされます（ただし、PER パッカーは、許容値の範囲が 8 ビットに収まることが分かっている場合はこれを省略することもできますし、許容値がより狭い範囲にしか収まらないことが分かっている場合は、単一の値バイト 05 を 8 ビット未満に圧縮することもできます）。

エンコードされた PER の最後の 6 ビットは、最後のバイト c0 の最下位 6 ビットのヌル ビットで埋め込まれます。このシーケンスがより長い非整列 PER シーケンスの一部として挿入される場合、これらの追加ビットは送信されず、他の何かをエンコードするためにも使用されません。

つまり、非整列 PER データは、本質的には整列 PER のような整列したバイト ストリームではなく、整列したビット ストリームです。また、通常のプロセッサでは、ソフトウェアによるデコードがやや複雑になります。これは、直接的なバイト アドレス指定ではなく、追加のコンテキスト ビット シフトとマスキングが必要になるためです (ただし、最小アドレス指定可能単位が 1 オクテットより大きい最新のプロセッサやメモリ/ストレージ ユニットでも同じことが言えます)。ただし、最新のプロセッサと信号プロセッサには、アドレス指定可能なストレージ ユニットの境界を越えるコンピューティング ユニットを自動的に処理するビット ストリームの内部デコードを高速に行うためのハードウェア サポートが含まれています (これは、圧縮/解凍用データ コーデックや、一部の暗号化/復号化アルゴリズムで効率的な処理を実行するために必要です)。

比較のために、Packed Encoding Rules Aligned では代わりに次のものが生成されます。 

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

このフォーマットはオクテット境界で整列されています。この場合、各オクテットの未使用の最上位ビットには、ヌルビットが個別に埋め込まれます。

ツール

ASN.1をサポートするツールのほとんどは、以下の機能を備えています。

  • ASN.1ファイルを解析する
  • プログラミング言語（CやC++など）で同等の宣言を生成します。
  • 以前の宣言に基づいてエンコードおよびデコード関数を生成します。

ASN.1 をサポートするツールのリストは、ITU-T ツール Web ページにあります。

オンラインツール

類似スキームとの比較

ASN.1は、クロスプラットフォームのデータシリアル化のためのインターフェース記述言語であるGoogle Protocol BuffersやApache Thriftと目的と用途が似ています。これらの言語と同様に、スキーマ（ASN.1では「モジュール」と呼ばれます）と、通常は型・長さ・値のエンコーディングからなる一連のエンコーディングを備えています。これらの言語とは異なり、ASN.1は単一のすぐに使用できるオープンソース実装を提供しておらず、サードパーティベンダーが実装するための仕様として公開されています。しかし、1984年に定義されたASN.1は、それらよりも何年も前に遡ります。また、より多様な基本データ型（一部は廃止されています）が含まれており、拡張性のためのオプションも豊富です。1つのASN.1メッセージには、複数の標準で定義された複数のモジュールのデータを含めることができます。たとえ何年も離れて定義された標準であってもです

ASN.1には、値とサイズに対する制約のサポートも組み込まれています。例えば、モジュールは0から100の範囲でなければならない整数フィールドを指定できます。値のシーケンス（配列）の長さも、固定長または許容される長さの範囲で指定できます。また、制約は、基本制約セットの論理的な組み合わせとして指定することもできます。

制約として使用される値は、PDU 仕様で使用されるリテラル、またはスキーマ ファイルの他の場所で指定された ASN.1 値のいずれかです。一部の ASN.1 ツールでは、生成されたソース コードでプログラマがこれらの ASN.1 値を利用できるようになります。定義中のプロトコルの定数として使用することで、開発者はプロトコルのロジック実装でこれらの値を使用できます。したがって、すべての PDU とプロトコル定数をスキーマで定義でき、サポートされている任意の言語でのプロトコルのすべての実装でこれらの値を使用できます。これにより、開発者が実装のソース コードにプロトコル定数を手動でコーディングする必要がなくなります。これはプロトコル開発に大きく役立ちます。プロトコルの定数は ASN.1 スキーマで変更でき、すべての実装は再コンパイルするだけで更新されるため、迅速かつリスクの低い開発サイクルが促進されます。

ASN.1ツールが生成されたソースコードに制約チェックを適切に実装していれば、プログラム実行中にプロトコルデータが自動的に検証されます。一般的に、ASN.1ツールは生成されたシリアル化/デシリアル化ルーチンに制約チェックを組み込み、範囲外のデータが検出された場合はエラーまたは例外を発生させます。ASN.1コンパイラにASN.1制約のあらゆる側面を実装するのは複雑です。すべてのツールが可能な制約表現の全範囲をサポートしているわけではありません。XMLスキーマとJSONスキーマはどちらも同様の制約概念をサポートしています。制約のサポートはツールによって異なります。Microsoftのxsd.exeコンパイラは制約を無視します。

スキーマ変換

一部のASN.1ツールは、ASN.1とXMLスキーマ（XSD）間の変換が可能です。この変換はITUによって標準化されています。これにより、プロトコルをASN.1で定義し、自動的にXSDでも定義することが可能になります。したがって、プロジェクト内で、ASN.1ツールによってコンパイルされたXSDスキーマを使用して、オブジェクトをJSONワイヤフォーマット間でシリアル化するソースコードを生成することが可能です（ただし、おそらく賢明ではありません）。より実用的な使用法は、他のサブプロジェクトがASN.1スキーマではなくXSDスキーマを使用できるようにすることです。これは、サブプロジェクトで選択した言語に適したツールの可用性に合わせて、プロトコルのワイヤフォーマットとしてXERを使用することです

OSS Nokalvaは、JSONデータオブジェクトまたはJSONスキーマをASN.1定義に変換するためのツールを提供しています。[ 23 ] ASN.1データ構造のJERエンコード構造を記述するJSONスキーマを生成するツールはまだありません。

OSS NokalvaはプロトコルバッファスキーマをASN.1定義に変換するツールも提供しています。[ 24 ]

スキーマオプション形式

多くのプログラミング言語は、言語固有のシリアル化形式を定義しています。例えば、Pythonの「pickle」モジュールやRubyの「Marshal」モジュールなどです。これらの形式はスキーマを必要としません。一般的に言語固有であるため、アドホックなストレージシナリオでは使いやすくなりますが、通信プロトコルには適していません

JSONとXMLも同様にスキーマを必要としないため、簡単に使用できます。また、どちらもクロスプラットフォーム標準であり、特にJSONスキーマやXMLスキーマと組み合わせると、通信プロトコルとして広く普及しています。

さまざまなレベルでのプロトコル定義

ASN.1は、 HTTPやSMTPなどの多くのインターネットプロトコルの定義に使用される拡張バッカスナウア記法（ABNF）と視覚的に似ています。しかし、実際には両者は全く異なります。ASN.1は、JSON、XML、バイナリなど、様々な方法でエンコード可能なデータ構造を定義します。一方、ABNFは、エンコード（「構文」）を定義すると同時に、データ構造（「セマンティクス」）も定義します。ABNFは、テキスト形式の人間が読めるプロトコルの定義に使用されることが多く、型・長さ・値のエンコードの定義には一般的に使用されません。

ASN.1 もCSN.1と見た目は似ていますが、CSN.1 はオブジェクトのエンコード、特にビットレベルにおけるエンコードも定義しています。

参照

参考文献

  1. ^ 「ASN.1入門」ITU。 2021年4月9日時点のオリジナルよりアーカイブ。2021年4月9日閲覧
  2. ^ 「ITU-T 勧告データベース」 . ITU 。2017-03-06に取得。
  3. ^ ITU-T X.680 - 基本表記法の仕様
  4. ^この記事は、2008 年 11 月 1 日より前の Free On-line Dictionary of Computing の ASN.1 から取得した資料に基づいており、GFDLバージョン1.3以降 の「再ライセンス」条件に基づいて組み込まれています。
  5. ^ ITU-T X.690 - 基本符号化規則（BER）
  6. ^ ITU-T X.690 - 識別符号化規則（DER）
  7. ^ ITU-T X.690 - 標準符号化規則（CER）
  8. ^ a b c d ITU-T X.691 - パック符号化規則（PER）
  9. ^ a b c ITU-T X.693 - XMLエンコーディング規則（XER）
  10. ^ a b ITU-T X.696 - オクテット符号化規則（OER）
  11. ^ NTCIP 1102:2004 ITS プロトコルの国家交通通信オクテット符号化規則 (OER) 基本プロトコル(PDF)。
  12. ^ ITU-T X.697 - JavaScript オブジェクト表記エンコーディング規則 (JER)
  13. ^ RFC 3641 - 汎用文字列エンコーディング規則 (GSER) 
  14. ^ Karg, S (2012). 「BACnet MS/TPエンコーディングの理解」(PDF) .
  15. ^ "bacnet-stack/bacnet-stack" . BACnetスタック. 2025年6月14日.
  16. ^ Huitema, C.; Doghri, A. (1989年10月). 「OSIプレゼンテーションプロトコルのための高速転送構文の定義」. ACM SIGCOMM Computer Communication Review . 19 (5): 44– 55. doi : 10.1145/74681.74685 .
  17. ^ a bラーマス、ジョン (1999). ASN.1 Complete . オープンシステムソリューション. ISBN 9780122334351。
  18. ^マーティン・ベバー、ウルリッヒ・シェーファー（1992年6月1日）「高速ネットワークのコーディング規則」。IFIP TC6/WG6.5上位層プロトコル、アーキテクチャ、およびアプリケーションに関する国際会議議事録。エルゼビア・サイエンス・パブリッシャーズBV：119～ 132。ISBN 978-0-444-89766-4。
  19. ^ 「第7章 ASN.1 ファイルデータフォーマット | Apache Camel コンポーネントリファレンス | Red Hat Fuse | 7.2 | Red Hat ドキュメント」 . docs.redhat.com
  20. ^ 「AsnLib: ASN.1処理」www.ncbi.nlm.nih.gov。
  21. ^ 「Ubuntu マニュアルページ: unber -- ASN.1 BER デコーダー」。manpages.ubuntu.com 。
  22. ^ Wahl, Mark (1996年3月13日). 「A MIME Con​​tent-Type for ASN.1 PDUs」 . インターネット技術タスクフォース.
  23. ^ "JSON2ASN " . asn1.io.
  24. ^ "Proto2ASN " . asn1.io.
「 https://en.wikipedia.org/w/index.php?title=ASN.1&oldid=1332699313」より取得