类型与类型定义

类型列表

基础类型的标签号

Tag Class（标签类别）

标签类别用于标识标签的上下文，共有 4 种类别：

• 如果标签是 通用类型（如 INTEGER、SEQUENCE），则 Tag Class = 0x00。
• 如果标签是 应用类型（如 [APPLICATION n]），则 Tag Class = 0x40。
• 如果标签是 上下文特定类型（如 [n]），则 Tag Class = 0x80。
• 如果标签是 私有类型，则 Tag Class = 0xC0。

Primitive/Constructed（原始/构造）

Primitive/Constructed 用于标识数据的编码方式：

• 如果数据类型是 原始类型（如 INTEGER、OCTET STRING），则 Primitive/Constructed = 0x00。
• 如果数据类型是 构造类型（如 SEQUENCE、SET），则 Primitive/Constructed = 0x20。

ASN.1中的类型

内建数据类型

组合类型

基本类型

字符串类型

Known-multiple Character String Type指字符串中每个字符编码所占字节数都一样。

字符串数据类型使用实例

对于以下ASN.1定义

MyHTTP
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
	Person ::= SEQUENCE {
		id [0] INTEGER,
		name UTF8String ,
		age INTEGER OPTIONAL,
		octelSTRING OCTET STRING,
		bitSTRING BIT STRING ,
		numericString NumericString ,
		printableString PrintableString ,
		teletexString TeletexString ,
		iA5String IA5String
	}
END

示例数据1

使用以下Java代码

Person person = new Person();
person.setId(1);
person.setName("张三");
person.setAge(18);
person.setOctelSTRING(new byte[]{0x01, 0x02, 0x03});
person.setBitSTRING(new BitSet(3));
person.setNumericString("123");
person.setPrintableString("345");
person.setTeletexString("78");
person.setIA5String("9");

生成的数据如下:

30 (27)
  80 (01) 01  # id [0] INTEGER :1
  0C (06) E5BCA0E4B889  # name UTF8String  :张三
  02 (01) 12   # age INTEGER OPTIONAL  :18
  04 (03) 010203  # octelSTRING OCTET STRING  :0x01, 0x02, 0x03
  03 (01) 00  # BIT STRING  :BitSet(3)
  12 (03) 313233  # NumericString  :123
  13 (03) 333435  # PrintableString :345
  14 (02) 3738  # TeletexString :78
  16 (01) 39  # IA5String :9

示例数据2

对于另一组数据

Person person = new Person();
person.setId(1);
person.setName("张三");
person.setAge(18);
person.setOctelSTRING(new byte[]{0x01, 0x02, 0x03});
person.setBitSTRING(new BitSet(3));
person.setNumericString("AAAA");
person.setPrintableString("BBB");
person.setTeletexString("CCCC");
person.setIA5String("GGGG");

得到的数据如下

原始的hex= 302D8001010C06E5BCA0E4B88902011204030102030301001204414141411303424242140443434343160447474747
格式化后的TLV结构:
30 (2D)
  80 (01) 01 # id [0] INTEGER :1
  0C (06) E5BCA0E4B889  # name UTF8String  :张三
  02 (01) 12 # age INTEGER OPTIONAL  :18
  04 (03) 010203 # octelSTRING OCTET STRING  :0x01, 0x02, 0x03
  03 (01) 00  # BIT STRING  :BitSet(3)
  12 (04) 41414141 # NumericString  :AAAA
  13 (03) 424242  # PrintableString :BBB
  14 (04) 43434343  # TeletexString :CCCC
  16 (04) 47474747 # IA5String :GGGG

示例数据3

Person person = new Person();
person.setId(1);
person.setName("张三");
person.setAge(18);
person.setOctelSTRING(new byte[]{0x01, 0x02, 0x03});
person.setBitSTRING(new BitSet(3));
person.setNumericString("数字字符串");
person.setPrintableString("可打印字符串");
person.setTeletexString("电传字符串");
person.setIA5String("IA5字符串");

得到的数据结果如下

原始的hex= 305A8001010C06E5BCA0E4B8890201120403010203030100120FE695B0E5AD97E5AD97E7ACA6E4B8B21312E58FAFE68993E58DB0E5AD97E7ACA6E4B8B2140FE794B5E4BCA0E5AD97E7ACA6E4B8B2160C494135E5AD97E7ACA6E4B8B2
格式化后的TLV结构:
30 (5A)
  80 (01) 01
  0C (06) E5BCA0E4B889
  02 (01) 12
  04 (03) 010203
  03 (01) 00
  12 (0F) E695B0E5AD97E5AD97E7ACA6E4B8B2
  13 (12) E58FAFE68993E58DB0E5AD97E7ACA6E4B8B2
  14 (0F) E794B5E4BCA0E5AD97E7ACA6E4B8B2
  16 (0C) 494135E5AD97E7ACA6E4B8B2

UTF8String

UTF8String “张三” 转换为 hex E5BCA0E4B889

• UTF8String 使用UTF-8编码，这是一种可变长度编码，支持所有Unicode字符。
• “张” 的UTF-8编码：
  • “张” 的Unicode码点是U+5F20。
  • UTF-8编码规则：对于U+0800到U+FFFF的字符，使用3字节：1110xxxx 10xxxxxx 10xxxxxx。
  • U+5F20的二进制：0101 1111 0010 0000。
  • 分割为三部分：0101、111100、100000（从高位到低位）。
  • 编码后：
    • 第一个字节：11100101 → 0xE5
    • 第二个字节：10111100 → 0xBC
    • 第三个字节：10100000 → 0xA0
  • 所以 “张” 的UTF-8编码为 E5 BC A0。
• “三” 的UTF-8编码：
  • “三” 的Unicode码点是U+4E09。
  • U+4E09的二进制：0100 1110 0000 1001。
  • 分割为三部分：0100、111000、001001。
  • 编码后：
    • 第一个字节：11100100 → 0xE4
    • 第二个字节：10111000 → 0xB8
    • 第三个字节：10001001 → 0x89
  • 所以 “三” 的UTF-8编码为 E4 B8 89。
• 因此，”张三” 的完整hex编码为 E5 BC A0 E4 B8 89，即 E5BCA0E4B889（长度6字节）。

NumericString

NumericString “AAAA” 转换为 hex 41414141

• NumericString 理论上只允许数字（0-9）和空格，但实际编码中有时会处理其他字符（如字母），但不符合标准。在您的示例中，”AAAA” 被编码为NumericString，这可能是一种简化或错误使用。

• 转换基于ASCII编码：每个字符的ASCII值直接转换为hex。

  • ‘A’ 的ASCII值为十进制65，十六进制41。
  • 因此，”AAAA” 的hex编码为 41 41 41 41，即 41414141（长度4字节）。

NumericString类型的数据123对应的hex值为313233

在ASN.1编码中，NumericString类型的数据使用ASCII编码来表示每个字符。ASCII（American Standard Code for Information Interchange）是一种常见的字符编码标准，其中每个字符对应一个唯一的数字值（十六进制）。

对于数字字符”123”：

• 字符 ‘1’ 的ASCII值为十进制49，十六进制31。
• 字符 ‘2’ 的ASCII值为十进制50，十六进制32。

• 字符 ‘3’ 的ASCII值为十进制51，十六进制33。

  因此，字符串”123”在编码为NumericString时，其值部分直接转换为hex值313233。

  详细转换过程：

1. NumericString类型定义：NumericString只允许包含数字（0-9）和空格。在ASN.1编码中，它使用标签0x12（但标签本身不包含在值部分中）。

2. 编码规则：当编码NumericString时，每个字符都使用其ASCII值的十六进制形式表示。

3. 示例”123”：

   • 取每个字符的ASCII值：’1’ → 0x31, ‘2’ → 0x32, ‘3’ → 0x33。
   • 组合这些值得到313233。

​ NumericString “数字字符串” 转换为 hex E695B0E5AD97E5AD97E7ACA6E4B8B2

• 字符串： “数字字符串”（注意：根据hex值解码，实际字符串可能为”数字符串”或包含重复字符，但这里以您提供的字符串为准）。
• 编码规则： NumericString标准只允许数字（0-9）和空格，但这里中文字符使用了UTF-8编码。
• 转换过程：
  • 每个中文字符转换为UTF-8字节序列：
    • “数” -> UTF-8: E6 95 B0
    • “字” -> UTF-8: E5 AD 97
    • “符” -> UTF-8: E7 AC A6
    • “串” -> UTF-8: E4 B8 B2
  • 最终hex值：E695B0 (数) + E5AD97 (字) + E5AD97 (字) + E7ACA6 (符) + E4B8B2 (串) = E695B0E5AD97E5AD97E7ACA6E4B8B2
• 说明： 这不符合NumericString标准，建议使用UTF8String中文字符。

PrintableString

PrintableString “BBB” 转换为 hex 424242

• PrintableString 允许特定的可打印字符，包括大写字母（A-Z）、数字（0-9）和某些符号（如空格、单引号、括号等）。
• 转换基于ASCII编码：每个字符的ASCII值直接转换为hex。
  • ‘B’ 的ASCII值为十进制66，十六进制42。
  • 因此，”BBB” 的hex编码为 42 42 42，即 424242（长度3字节）。

PrintableString “可打印字符串” 转换为 hex E58FAFE68993E58DB0E5AD97E7ACA6E4B8B2

• 字符串： “可打印字符串”
• 编码规则： PrintableString标准只允许可打印ASCII字符（如字母、数字、空格和特定符号），但这里中文字符使用了UTF-8编码。
• 转换过程：
  • 每个中文字符转换为UTF-8字节序列：
    • “可” -> UTF-8: E5 8F AF
    • “打” -> UTF-8: E6 89 93
    • “印” -> UTF-8: E5 8D B0
    • “字” -> UTF-8: E5 AD 97
    • “符” -> UTF-8: E7 AC A6
    • “串” -> UTF-8: E4 B8 B2
  • 最终hex值：E58FAF (可) + E68993 (打) + E58DB0 (印) + E5AD97 (字) + E7ACA6 (符) + E4B8B2 (串) = E58FAFE68993E58DB0E5AD97E7ACA6E4B8B2
• 说明： 这不符合PrintableString标准，建议使用UTF8String中文字符。

TeletexString

TeletexString “CCCC” 转换为 hex 43434343

• TeletexString 通常使用ISO/IEC 8859-1编码（Latin-1），这是一种8位编码，与ASCII兼容（前128字符相同）。
• 转换基于ASCII或Latin-1编码：每个字符的编码值直接转换为hex。
  • ‘C’ 的ASCII值为十进制67，十六进制43。
  • 因此，”CCCC” 的hex编码为 43 43 43 43，即 43434343（长度4字节）。

TeletexString “电传字符串” 转换为 hex E794B5E4BCA0E5AD97E7ACA6E4B8B2

• 字符串： “电传字符串”
• 编码规则： TeletexString标准通常使用T.61或ISO-8859-1编码，但这里中文字符使用了UTF-8编码。
• 转换过程：
  • 每个中文字符转换为UTF-8字节序列：
    • “电” -> UTF-8: E7 94 B5
    • “传” -> UTF-8: E4 BC A0
    • “字” -> UTF-8: E5 AD 97
    • “符” -> UTF-8: E7 AC A6
    • “串” -> UTF-8: E4 B8 B2
  • 最终hex值：E794B5 (电) + E4BCA0 (传) + E5AD97 (字) + E7ACA6 (符) + E4B8B2 (串) = E794B5E4BCA0E5AD97E7ACA6E4B8B2

IA5String

IA5String “GGGG” 转换为 hex 47474747

• IA5String 使用ASCII编码，支持国际字母数字字符（但实际是ASCII子集）。
• 转换基于ASCII编码：每个字符的ASCII值直接转换为hex。
  • ‘G’ 的ASCII值为十进制71，十六进制47。
  • 因此，”GGGG” 的hex编码为 47 47 47 47，即 47474747（长度4字节）。

IA5String “IA5字符串” 转换为 hex 494135E5AD97E7ACA6E4B8B2

• 字符串： “IA5字符串”
• 编码规则： IA5String标准只允许ASCII字符（0-127），但这里中文字符使用了UTF-8编码，而英文字符”IA5”使用ASCII编码。
• 转换过程：
  • 英文字符部分”IA5”使用ASCII编码：
    • “I” -> ASCII: 49 (hex)
    • “A” -> ASCII: 41 (hex)
    • “5” -> ASCII: 35 (hex)
  • 中文字符部分”字符串”使用UTF-8编码：
    • “字” -> UTF-8: E5 AD 97
    • “符” -> UTF-8: E7 AC A6
    • “串” -> UTF-8: E4 B8 B2
  • 最终hex值：49 (I) + 41 (A) + 35 (5) + E5AD97 (字) + E7ACA6 (符) + E4B8B2 (串) = 494135E5AD97E7ACA6E4B8B2
• 说明： 这不符合IA5String标准，因为中文字符不是ASCII。建议将整个字符串使用UTF8String编码

整体ASN.1数据实例解析

您提供的hex数据是一个SEQUENCE（标签30），总长度2D（十进制45字节）。内部字段包括：

• 80 01 01：上下文特定标签[0]，长度1，值01（整数1）。
• 0C 06 E5BCA0E4B889：UTF8String（标签0C），长度6，值”张三”的UTF-8编码。
• 02 01 12：INTEGER（标签02），长度1，值12（十进制18）。
• 04 03 010203：OCTET STRING（标签04），长度3，值010203。
• 03 01 00：BIT STRING（标签03），长度1，值00（表示3比特位，但值为0）。
• 12 04 41414141：NumericString（标签12），长度4，值”AAAA”的ASCII编码。
• 13 03 424242：PrintableString（标签13），长度3，值”BBB”的ASCII编码。
• 14 04 43434343：TeletexString（标签14），长度4，值”CCCC”的ASCII编码。
• 16 04 47474747：IA5String（标签16），长度4，值”GGGG”的ASCII编码。

总结

字符串到hex的转换依赖于字符的编码标准：

• UTF8String使用UTF-8编码。
• NumericString、PrintableString、TeletexString和IA5String通常使用ASCII编码（或Latin-1编码，但前128字符相同）。
• 每个字符的ASCII值直接转换为十六进制字节。

转换解析示例

package org.example;

import java.nio.charset.StandardCharsets;

public class Demo {

    public static void main(String[] args) {
        String txt = "IA5字符串";
        for (int i = 0; i < txt.length(); i++) {
            String e = String.valueOf(txt.charAt(i));
            byte[] bytes = e.getBytes(StandardCharsets.UTF_8);
            String hex = bytesToHex(bytes);
            System.out.println("字符=" + e + "  ASCII=" + bytes2String(bytes) + "  ASCII=" + bytes2ASCII(bytes) + "  HEX=" + hex);
        }

    }

    private static String bytes2String(byte[] bytes) {
        String val = "";
        for (byte b : bytes) {
            val += b + " , ";
        }
        return val;
    }

    private static String bytes2ASCII(byte[] bytes) {
        String val = "";
        for (byte b : bytes) {
            val += (b & 0xff) + " , ";
        }
        return val;
    }

    private static String bytesToHex(byte[] bytes) {
        if (bytes == null) {
            return null;
        }
        StringBuilder buff = new StringBuilder();
        int len = bytes.length;
        for (int j = 0; j < len; j++) {
            buff.append(String.format("%02X", bytes[j] & 0xff));
        }
        return buff.toString().toUpperCase();
    }
}

得到的运行结果为

字符=I  ASCII=73 ,   ASCII=73 ,   HEX=49
字符=A  ASCII=65 ,   ASCII=65 ,   HEX=41
字符=5  ASCII=53 ,   ASCII=53 ,   HEX=35
字符=字  ASCII=-27 , -83 , -105 ,   ASCII=229 , 173 , 151 ,   HEX=E5AD97
字符=符  ASCII=-25 , -84 , -90 ,   ASCII=231 , 172 , 166 ,   HEX=E7ACA6
字符=串  ASCII=-28 , -72 , -78 ,   ASCII=228 , 184 , 178 ,   HEX=E4B8B2

UTF-8编码原理

UTF-8是一种可变长度的字符编码标准，用于表示Unicode字符。汉字“字”的Unicode码点是U+5B57（十六进制），其二进制表示为：

• Unicode码点 U+5B57: 0101 1011 0101 0111（二进制）

根据UTF-8编码规则，对于U+0800到U+FFFF范围内的字符（如汉字），使用三字节编码模式：

• 第一字节以1110开头，后跟Unicode码点的前4位。
• 第二字节以10开头，后跟Unicode码点的中间6位。
• 第三字节以10开头，后跟Unicode码点的最后6位。

具体编码过程：

• Unicode码点 U+5B57 的二进制分割：前4位 0101，中间6位 101101，最后6位 010111。
• 第一字节：1110 + 0101 = 11100101（二进制） → 十六进制 0xE5，无符号十进制 229。
• 第二字节：10 + 101101 = 10101101（二进制） → 十六进制 0xAD，无符号十进制 173。
• 第三字节：10 + 010111 = 10010111（二进制） → 十六进制 0x97，无符号十进制 151。

因此，汉字“字”的UTF-8编码为三个字节：0xE5, 0xAD, 0x97（十六进制），对应无符号十进制值 229, 173, 151。

为什么显示为负数（-27, -83, -105）

在计算机系统中，字节（8位）通常可以被解释为无符号整数（范围0到255）或有符号整数（范围-128到127）。当您看到负数值时，通常是因为这些字节值被解释为有符号整数（采用二的补码表示法）。

转换规则：无符号字节值大于127时，在有符号表示中会变为负数。具体计算为：

• 有符号值 = 无符号值 - 256（因为256是模数）

应用到这里：

• 无符号值 229 → 有符号值: 229 - 256 = -27
• 无符号值 173 → 有符号值: 173 - 256 = -83
• 无符号值 151 → 有符号值: 151 - 256 = -105

因此，如果您在编程环境或工具中看到这些字节被作为有符号整数处理（例如在Java的byte类型中，默认是有符号的），它们就会显示为-27、-83、-105。但这并不影响实际的编码数据，因为存储时仍然是原始的字节值（0xE5, 0xAD, 0x97）。

为什么这些值不在ASCII码对照表中

ASCII码（American Standard Code for Information Interchange）是一种7位编码标准，只定义值从0到127的字符（包括英文字母、数字、标点符号和控制字符）。UTF-8编码的汉字使用多字节，且每个字节的值通常大于127（即超出ASCII范围），因此这些字节值不会出现在ASCII码对照表中。

• ASCII码只覆盖0-127的值，例如字母’A’的ASCII值是65（十六进制0x41）。

• UTF-8编码中，汉字使用三字节，每个字节的值都在128以上（如229、173、151），所以它们不是ASCII字符，而是UTF-8编码的一部分。

• 汉字“字”的UTF-8编码字节为无符号值229、173、151（十六进制E5、AD、97）。

• 当这些字节被解释为有符号整数时，它们显示为-27、-83、-105，这是数值表示方式的差异，并不改变实际编码。
• 这些值不在ASCII码对照表中，因为ASCII仅限于基本英文字符，而汉字需要多字节UTF-8编码。

日期时间类型

MyHTTP
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
	Person ::= SEQUENCE {
		id [0] INTEGER,
		uTCTime UTCTime ,
		generalizedTime GeneralizedTime
	}
END

java代码如下

Person person = new Person();
person.setId(1);
person.setUTCTime("230101120000Z");
person.setGeneralizedTime("20230101120000Z");

生成的数据如下：

30 (23)
  80 (01) 01
  17 (0D) 3233303130313132303030305A
  18 (0F) 32303233303130313132303030305A

上述数据相当于

person Person ::= {
    id 123,
    uTCTime "230101120000Z",  -- 表示2023年1月1日12:00:00 UTC
    generalizedTime "20230101120000Z"  -- 表示2023年1月1日12:00:00 UTC
}

• id: 这是一个整数字段，带有标签[0]。示例值为123，是一个任意选择的整数。
• uTCTime: 这是一个UTCTime类型的字段，表示时间。格式为YYMMDDhhmmssZ，其中YY是年份的后两位，MM是月份，DD是日期，hh是小时，mm是分钟，ss是秒，Z表示UTC时间。示例值"230101120000Z"对应2023年1月1日12:00:00 UTC。
• generalizedTime: 这是一个GeneralizedTime类型的字段，也表示时间。格式为YYYYMMDDhhmmssZ，其中YYYY是四位年份。示例值"20230101120000Z"同样对应2023年1月1日12:00:00 UTC。

例如 32 35 30 32 31 39 30 39 32 36 32 35 5A ；转换为ASCII字符串：250219092625Z按UTCTime格式YYMMDDHHMMSSZ

解析：

• 25 → 年份 2025
• 02 → 月份 2月
• 19 → 日期 19日
• 09 → 小时 09时
• 26 → 分钟 26分
• 25 → 秒 25秒
• Z → UTC时区
  最终时间：2025-02-19 09:26:25 UTC

非常好的问题！这涉及到 ASN.1 时间类型中一个非常重要且常见的细节。

Z 的含义

在 UTCTime 和 GeneralizedTime 类型中，后缀字母 Z 表示 “Zulu Time”。

• Zulu 是航空和军事领域中对 协调世界时（UTC） 的代号。
• 因此，Z 的含义是：该时间字符串所表示的时间是 UTC 时区 的时间，其相对于 UTC 的时区偏移量为 +00:00。

简单来说：Z 就等于 +00:00，代表零时区，即格林威治标准时间。

示例中的 "230101120000Z" 和 "20230101120000Z" 都明确表示这是一个 UTC 时间（2023年1月1日12:00:00 UTC）。

如何表示东八区时间（北京时间）

东八区（例如北京时间）比 UTC 时间 早8个小时。在 ASN.1 中，你不能使用 Z，而是需要使用一个 时区偏移量（Time Zone Offset） 来明确表示与 UTC 的差异。

时区偏移量有两种表示方式：

1. +HHMM (UTC之后，东区)
2. -HHMM (UTC之前，西区)

对于 东八区，偏移量为 +0800。

因此，你的示例数据如果要表示为本地东八区时间，需要做如下修改：

UTCTime 的表示

• 原始（UTC）: "230101120000Z"
• 东八区: "230101200000+0800"

解释：

• 因为东八区比 UTC 早8小时，所以本地时间 20:00:00 对应的是 UTC 时间 12:00:00。
• 将时间部分从 120000 (12:00:00 UTC) 改为 200000 (20:00:00 Local)。
• 将后缀从 Z 改为 +0800，明确指出这个 20:00:00 是东八区的本地时间。

GeneralizedTime 的表示

• 原始（UTC）: "20230101120000Z"
• 东八区: "20230101200000+0800"

解释：

• 同理，将时间从 120000 改为 200000。
• 将后缀 Z 替换为 +0800。

总结与关键点

重要注意事项：

1. UTCTime 的限制：UTCTime 只能表示年份后两位。按照最新的规范，YY 为 50-99 表示 1950-1999，YY 为 00-49 表示 2000-2049。如果你需要表示 2050 年之后的时间，必须使用 GeneralizedTime。
2. 可读性：使用 Z 是表示 UTC 时间最简洁、最清晰的方式。只要有可能，强烈推荐将时间转换为 UTC 并使用 Z 后缀进行存储和传输，这可以避免时区转换带来的所有歧义和错误。
3. 编码规则：在 DER（Distinguished Encoding Rules）编码中，UTCTime 必须使用 Z 格式，而不能使用本地时间加偏移量的格式。GeneralizedTime 则允许两种格式，但同样推荐使用 Z 格式以确保唯一性。

在你的代码或协议中，最佳实践是：
在内部处理和存储时，始终使用 UTC 时间。只在需要显示给用户时，才将其转换为本地时间。。

类型定义

<新类型的名字> ::= <类型描述>

其中：

• <新类型的名字>是一个以大写字母开头的标识符；
• <类型描述>是基于内建类型或在其它地方定义的类型。

如：

Married ::= BOOLEAN
Age ::= INTEGER
Picture ::= BIT STRING
Form ::= SEQUENCE
{
    name    PrintableString,
    age    Age,
    married    Married,
    marriage-certificate	Picture OPTIONAL
}

Payment-method ::= CHOICE 
{
    check	Check-number,
    credit-card	SEQUENCE
    {
        number	 Card-number,
        expiry-date   Date
    }
}

注意：在SEQUENCE和SET等(好像应该是所有组合类型的)定义中，最后一个成员结尾没有逗号“,”。

为了接收方能正确解码，发送方为每个值的类型附加一个数，称为tag，在描述中以“[]”标识。缺省情况下，编码器会使用universal的tag。很多时候，缺省情况下不能消除所有的模糊性，有必要明确指出各成员的tag。如：

Coordinates ::= SET
{
    x	[1] INTEGER,  //这证明好像也可以用类来直接声明变量
	y	[2] INTEGER,
	z	[3] INTEGER OPTIONAL
}
 
Afters ::= CHOICE
{
	cheese	[0] PrintableString,
	dessert	[1] PrintableString
}

注意：ASN.1允许递归式的类型分配(Assignment)，但我们应当保证其中包含至少一个非递归的值，因为编码规则无法处理无限的值。当然，绝大多数结构类型的成员都终结于简单类型。

为了准确描述一个类型，我们需要对值的集合进行一定的限制。这用到子类型约束，在类型之后用圆括号进行标识。

如：

Lottery-number ::= INTERGER(1..49)
Lottery-draw ::= SEQUENCE SIZE(6) OF Lottery-number
Upper-case-words ::= IA5String (FROM(“A”..”Z”))
Phone-number ::= NumericString (FROM(“0”..”9”))(SIZE(10))
Coordinates-in-plan ::= Coordinates (WITH COMPONENTS {…, z ABSENT})

有约束的类型当然还是类型，可以用在任何一个可以使用类型的地方。

最后，因为版本升级，在新的描述中，出现新的成员被加入到SEQUENCE、SET或者CHOICE或者在上述类型基础上添加约束而衍生的子类型时，两个连接的机器(特别是在开放网络中)不一定使用的是相同版本描述而生成的编解码器。为了防止一方因收到过多或者过少数据而出现错误，ASN.1中用符号“…”来标记可能以后是其它类型的地方。这样即使是旧的编解码器也不会因为描述扩充而导致编解码错误。如：

Type ::= SEQUENCE
	{
		component1	INTERGER,
		component2	BOOLEAN, 	-- version 1
		…
	}

以后新的版本中，描述可能为：

Type ::= SEQUENCE
{
	component1	INTERGER,
	component2	BOOLEAN, 
	…,
	[[component3	 REAL]],		-- version 2
	…
}

注意：新加入的类型成员要嵌套在“[[]]”中。

自动标签AUTOMATIC TAGS

AUTOMATIC TAGS 的核心目的是自动化地为 SEQUENCE、SET 或 CHOICE 类型中的成员分配标签。它主要解决了两个问题：

1. 避免手动分配标签的繁琐和错误：当一个结构体中有大量可选字段时，手动为每个字段分配唯一的 [0], [1], [2]… 既枯燥又容易出错（如重复使用同一个标签号）。
2. 确保编码清晰无歧义：特别是在处理多个 OPTIONAL 或 DEFAULT 字段时，编码器（如 BER/DER）需要依靠唯一的上下文特定标签（Context-specific Tags） 来识别哪个字段存在，哪个字段不存在。AUTOMATIC TAGS 保证了这些标签的唯一性。

基本定义

可以在模块定义时，声明模块全局Tag模式。可以是EXPLICIT TAGS、IMPLICIT TAGS和AUTOMATIC TAGS。

IMPLICIT TAGS：模块内所有SEQUENCE、SET和CHOICE的成员都是IMPLICIT模式（除非它是CHOICE类型、开放类型或者一个参数类型）。但不影响IMPORTS的内容。

AUTOMATIC TAGS：模块内所有SEQUENCE、SET和CHOICE类型ASN.1编译器会自动从0开始，步长为1进行自动编码。而其中的成员则用IMPLICIT模式，除非它是CHOICE类型、开放类型或者一个参数类型。

下面两个定义是等效的：

M  DEFINITIONS  AUTOMATIC TAGS ::=
BEGIN
T ::= SEQUENCE 
{ 
    a  INTEGER,
    b  CHOICE 
    { 
        i  INTEGER,
        n  NULL 
    },
    c 	REAL 
}
END

M  DEFINITIONS ::=
BEGIN
T ::= SEQUENCE 
{
    a  [0] IMPLICIT INTEGER,
    b  [1] EXPLICIT CHOICE 
    { 
        i   [0] IMPLICIT INTEGER,
        n   [1] IMPLICIT NULL 
    },
    c  [2] IMPLICIT REAL 
}
END

如果使用全局AUTOMATIC TAGS模式时，在描述中给一个类型指定了一个Tag，那么对这个类型的AUTOMATIC TAGS就关闭。如果一个SEQUENCE或者SET类型包含COMPONENTS OF条目，而且这个条目在自动编号前展开；但自动标号又要求在展开前进行，ASN.1编译器要自己检查这种冲突。

对新的协议现在都推荐使用AUTOMATIC TAGS。

开启与关闭的触发条件

对于以下ASN.1定义

MyHTTP
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
	Person ::= SEQUENCE {
		name UTF8String,
		sex Sex,
		age INTEGER OPTIONAL,
		email  UTF8String OPTIONAL,
		phone  UTF8String OPTIONAL
	}
    Sex ::= SEQUENCE{
    	sexName UTF8String
    }	
END

使用如下java代码

Person person = new Person();
person.setName("张三");
person.setAge(18);
person.setEmail("email");
person.setPhone("phone");
Sex sex = new Sex();
sex.setSexName("男");
person.setSex(sex);

生成的数据为

原始的hex= 30208006E5BCA0E4B889A1058003E794B78201128305656D61696C840570686F6E65
格式化后的TLV结构:
30 (20)
  80 (06) E5BCA0E4B889
  A1 (05)
    80 (03) E794B7
  82 (01) 12
  83 (05) 656D61696C
  84 (05) 70686F6E65

修改上面的ASN.1定义为

MyHTTP
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
	Person ::= SEQUENCE {
		name UTF8String,
		sex Sex,
		age INTEGER OPTIONAL,
		email [1] UTF8String OPTIONAL,
		phone  UTF8String OPTIONAL
	}
    Sex ::= SEQUENCE{
    	sexName UTF8String
    }	
END

此时生成的数据为

30 (20)
  0C (06) E5BCA0E4B889
  30 (05)
    80 (03) E794B7
  02 (01) 12
  81 (05) 656D61696C
  0C (05) 70686F6E65

如果使用全局AUTOMATIC TAGS模式时，在描述中给一个类型指定了一个Tag，那么对这个类型的AUTOMATIC TAGS就关闭

工作机制

当你在模块定义中使用 AUTOMATIC TAGS 时，编译器或编码器会遵循一个简单的规则：

自动为 SEQUENCE、SET 或 CHOICE 类型中的每一个组件分配一个上下文特定的标签号，从 [0] 开始，按定义顺序依次递增。

重要的是，这种自动分配的本质是隐式标签（IMPLICIT）。这意味着在编码时，字段的原始通用标签（如 UNIVERSAL 2 for INTEGER）会被新分配的上下文特定标签所替换，从而产生更紧凑的编码。

示例 1：没有使用 AUTOMATIC TAGS (手动分配标签)

在这种方式下，你必须手动为每个需要区分的可选字段分配唯一的标签号。

PersonManual DEFINITIONS EXPLICIT TAGS ::= BEGIN
    Person ::= SEQUENCE {
        name    UTF8String,
        age     [0] INTEGER OPTIONAL,  -- 手动分配标签 [0]
        email   [1] UTF8String OPTIONAL, -- 手动分配标签 [1]
        phone   [2] UTF8String OPTIONAL  -- 手动分配标签 [2]
    }
END

痛点：如果以后在 age 和 email 之间添加一个新的可选字段 nickname，你必须重新编排后面所有的标签号（email 变成 [2], phone 变成 [3]），这非常容易出错且难以维护。

示例 2：使用 AUTOMATIC TAGS (自动分配标签)

现在，我们让 ASN.1 编译器来自动处理标签分配。

PersonAuto DEFINITIONS AUTOMATIC TAGS ::= BEGIN
    Person ::= SEQUENCE {
        name    UTF8String,       -- 无OPTIONAL，通常不分配自动标签
        age     INTEGER OPTIONAL,  -- 自动分配标签 [0] IMPLICIT
        email   UTF8String OPTIONAL, -- 自动分配标签 [1] IMPLICIT
        phone   UTF8String OPTIONAL  -- 自动分配标签 [2] IMPLICIT
    }
END

优势：

• 无需手动管理：你不用再写 [0], [1]。编译器会自动完成。
• 易于扩展：在 age 和 email 之间插入 nickname UTF8String OPTIONAL，它会自动获得标签 [1]，而 email 和 phone 会自动变为 [2] 和 [3]。代码维护变得非常简单。
• 避免冲突：绝对保证不会出现标签号重复的错误。

示例 3：混合类型与CHOICE类型

AUTOMATIC TAGS 同样完美处理混合类型和选择类型。

ComplexExample DEFINITIONS AUTOMATIC TAGS ::= BEGIN

    Address ::= SEQUENCE {
        street  UTF8String,
        city    UTF8String,
        zipCode [0] INTEGER OPTIONAL, -- 手动覆盖：显式标签
        country UTF8String DEFAULT 'Earth'
    }

    ContactMethod ::= CHOICE {
        email       UTF8String,        -- 自动标签 [0]
        phone       UTF8String,        -- 自动标签 [1]
        postalMail  Address,           -- 自动标签 [2]
        fax         UTF8String     -- 自动标签 [3]
    }

    UserRecord ::= SEQUENCE {
        id          INTEGER,
        primaryContact ContactMethod,
        backupContact  ContactMethod OPTIONAL, -- 自动标签 [1]
        isVerified   BOOLEAN DEFAULT FALSE
    }

END

代码分析：

1. Address:
   • street, city：非可选字段，通常不需要标签。
   • zipCode：我们手动指定了显式标签 [0] EXPLICIT（因为模块是AUTOMATIC TAGS，但被[0]覆盖了规则）。
   • country：这是一个 DEFAULT 字段。注意：虽然 DEFAULT 字段在编码中通常可以省略（如果取默认值），但为了在出现时能够被识别，它也需要一个标签。AUTOMATIC TAGS 会为它自动分配一个标签（在这个例子中，由于 zipCode 是手动 [0]，country 可能会被分配到 [1]）。
2. ContactMethod (CHOICE):
   • email, phone, postalMail：自动获得标签 [0], [1], [2]。
   • fax：手动覆盖，使用显式标签 [5]。这意味着编码器会创建一个外层标签 [5]，里面再包裹 UTF8String 的通用标签和值。这打破了自动的连续性，但提供了灵活性。
3. UserRecord:
   • id, primaryContact：非可选字段。
   • backupContact：是一个可选字段，因此被自动分配了标签 [1]（因为它是序列中第一个可选/DEFAULT组件）。
   • isVerified：是一个 DEFAULT 字段，如果它被自动分配标签，会是 [2]。

使用以下java代码

UserRecord userRecord = new UserRecord();
    userRecord.setId(1);
    userRecord.setIsVerified(true);

    ContactMethod contactMethod=new ContactMethod();


    Address address=new Address();
    address.setStreet("street");
    address.setCity("city");
    address.setCountry("country");
    address.setZipCode(123456);
    contactMethod.setPostalMail(address);

    userRecord.setPrimaryContact(contactMethod);

生成的数据为

原始的hex= 3026800101A11EA21C0C067374726565740C0463697479800301E2400C07636F756E7472798301FF
格式化后的TLV结构:
30 (26)
  80 (01) 01
  A1 (1E)
    A2 (1C)
      0C (06) 737472656574
      0C (04) 63697479
      80 (03) 01E240
      0C (07) 636F756E747279
  83 (01) FF

简单来说：AUTOMATIC TAGS 是一个“一劳永逸”的配置，它通过让编译器接管繁琐的标签分配工作，使你能够更专注于数据结构的逻辑设计，从而编写出更清晰、更健壮、更易于扩展的 ASN.1 规范。

隐式编码与显式编码

隐式编码 (IMPLICIT Encoding)

核心思想：替换标签。 使用新的上下文特定标签直接替换数据类型的原始通用标签。

• 编码方式： 编码器直接使用新指定的标签（如 [5]）作为 T，数据的值作为 V 进行编码。原始数据类型的标识信息（通用标签）不会出现在编码字节流中。
• 解码要求： 解码器必须预先知道这个特定标签（如 [5]）对应的是什么数据类型。它无法从编码数据本身推断出类型。协议规范（ASN.1 模式）就是解码器所需的“说明书”。
• 优点： 编码更紧凑，体积更小，因为没有内层标签的额外开销。
• 缺点： 缺乏自描述性，灵活性差。如果协议变更（例如将 [5] 从 INTEGER 改为 STRING），新旧版本将无法兼容。

ASN.1 定义

MyModule DEFINITIONS IMPLICIT TAGS ::= BEGIN
    UserRecord ::= SEQUENCE {
        name    UTF8String,
        id      [0] IMPLICIT INTEGER,  -- 使用隐式编码的上下文标签
        level   [1] IMPLICIT INTEGER DEFAULT 1
    }
END

（注意：在 IMPLICIT TAGS 模块中，[0] 默认就是隐式的，这里的 IMPLICIT 关键字可写可不写，只是为了清晰）。
假设我们有数据：name = "Alice", id = 123。

对于 id 字段：

• 其原始类型是 INTEGER (通用标签 = UNIVERSAL 2)。
• 我们应用了隐式标签 [0]。

编码结果：

30 (0D)
  0C (05) 416C696365
  80 (01) 7B
  81 (01) 02

典型应用场景：

• 带宽或存储极其敏感的领域：例如早期的移动通信协议（如 GSM）、卫星通信、某些物联网（IoT）设备协议。每个字节都很宝贵，需要极力缩减开销。
• 封闭的、高度优化的系统：通信双方由同一实体严格控制，协议规范几乎不会变动，可以牺牲灵活性来换取性能。

显式编码 (EXPLICIT Encoding)

核心思想：包装标签。 新的上下文特定标签作为一个外壳，包裹住完整的原始数据类型的 TLV 结构。

• 编码方式： 编码器先像没有上下文标签一样，对数据进行正常编码（得到一个完整的 TLV）。然后，它再创建一个新的、外层的 TLV，其中 T 就是新的上下文特定标签（如 [5]），V 则是刚才编码得到的整个内层 TLV。
• 解码要求： 解码器看到外层标签 [5]，知道需要解码一个上下文特定的元素。它接着解码内层的 V 字段，而内层 V 字段本身又是一个完整的 TLV，包含了完整的类型信息。解码器可以检查内层标签是否符合预期，或者甚至处理未知的新类型（如果协议允许扩展）。
• 优点： 自我描述，灵活性强，向后兼容性好。数据类型信息完整地保存在编码中。
• 缺点： 编码体积更大，因为有额外的外层标签和长度字节。

ASN.1 定义：

MyModule DEFINITIONS EXPLICIT TAGS ::= BEGIN
    UserRecord ::= SEQUENCE {
        name    UTF8String,
        id      [0] EXPLICIT INTEGER,  -- 使用显式编码的上下文标签
        level   [1] EXPLICIT INTEGER DEFAULT 1
    }
END

（同样，在 EXPLICIT TAGS 模块中，[0] 默认就是显式的）。

2. 编码过程：
同样数据：name = "Alice", id = 123。

对于 id 字段：

• 先对值 123 进行编码： T_inner = UNIVERSAL 2, L_inner = 1, V_inner = 0x7B。
• 然后将整个 inner TLV 作为值，外面再套一个外壳：
  • T_outer = Context-Specific Tag [0]
  • L_outer = Length of the inner TLV
  • V_outer = The inner TLV (T_inner + L_inner + V_inner)

编码结果：

原始的hex= 30110C05416C696365A00302017BA103020102
格式化后的TLV结构:
30 (11)
  0C (05) 416C696365
  A0 (03)
    02 (01) 7B
  A1 (03)
    02 (01) 02

3. 典型应用场景：

• 需要强兼容性和扩展性的协议：例如 X.509 公钥证书、LDAP、SNMP。这些标准广泛使用显式编码。如果未来版本想将 id 字段从 INTEGER 改为 STRING，旧解码器虽然不认识新类型，但能看到内层的 STRING 标签，可以更好地处理错误或忽略未知字段。新解码器则能正确解析。
• 网络协议和加密标准：这些领域数据结构的复杂性高，且各方实现可能不同，显式编码提供的自描述特性大大降低了互操作性的难度。
• 绝大多数新项目：显式编码是 ASN.1 默认的标签设置，因为它更安全、更灵活。除非有极其严格的效率要求，否则首选显式编码。

对比总结表

AUTOMATIC TAGS 的作用是自动分配标签号，但它分配标签的方式是隐式的。这意味着：

MyModule DEFINITIONS AUTOMATIC TAGS ::= BEGIN
    Person ::= SEQUENCE {
        age INTEGER OPTIONAL -- 编译器自动分配标签 [0] IMPLICIT
    }
END

这个 age 字段将会使用隐式编码。AUTOMATIC TAGS 带来了标签管理的便利，但继承了隐式编码的优缺点（紧凑但不自描述）。

• 默认选择显式编码（EXPLICIT TAGS）：这是最安全、最通用的选择，适用于绝大多数应用场景，尤其是在开放系统和网络协议中。
• 仅在确有必要时选择隐式编码：只有当性能分析表明编码开销是主要瓶颈，并且你能够严格控制协议规范的演化和所有实现时，才考虑使用隐式编码。

标准 ASCII 码对照表

• ← Previous Post
• Next Post →