ASN.1 SET 类型限制答案

【问题标题】：ASN.1 SET type restrictionsASN.1 SET 类型限制
【发布时间】：2013-10-13 16:29:52
【问题描述】：

我对 ASN.1 SET 类型的限制感到困惑。一般来说，我意识到SET 类型与SEQUENCE 基本相同，只是组件的顺序无关紧要。

Olivier Dubuisson 撰写的关于 ASN.1 的开创性书籍"ASN.1 — Communication Between Heterogeneous Systems" 对 SET 有这样的看法：

如果 SEQUENCE 类型的组件顺序无关紧要，关键- SET 一词用于对这种无序结构进行建模：

 Description ::= SET {    
   surname IA5String,   
   first-name IA5String,  
   age INTEGER  }

在这种情况下，应用程序可以将组件提供给编码器的最佳顺序。

我在这里立即注意到的是，在 Dubuisson 的示例中，SET 中有两个 IA5String 类型。这似乎与我读过的 here in this tutorial 相矛盾，它明确表示：

SET 的类型和值表示法类似于 SEQUENCE，除了 每个组件的类型必须与所有组件不同 其他值可以按任意顺序排列。

那么SET 怎么能合法地拥有两个IA5String 类型呢？我倾向于相信 Olivier Dubuisson 的书而不是一些随机的 Internet 教程，但是，SET 类型可以具有多个相同类型的组件没有任何意义。原因是，在 ASN.1 中，类型标识符没有被编码，（至少对于最常见的编码，如 BER），所以解码器无法知道IA5String 应用哪个组件to - 是surname 还是firstname？没有办法判断顺序是否无关紧要。

那么 Olivier Dubuisson 在这里犯了大错吗？（在他对SET 类型的冗长描述中，他也没有提到任何关于SET 每种类型只能有一个的事实。）

【问题讨论】：

标签： encoding asn.1 ber

【解决方案1】：

标准（X.680, 27.3）要求一个SET类型的组件的类型都具有不同的标签。

如果封闭的 ASN.1 模块具有隐式标签或显式标签（因为组件姓氏和名字的类型具有相同的标签“通用 22”），则示例中的“描述”类型违反了此要求，但是如果封闭的 ASN.1 模块具有 AUTOMATIC TAGS 是合法的（因为这些组件的类型现在具有不同的标签——分别为“上下文特定 0”和“上下文特定 1”——自动分配给它们以替换“通用 22”标签）。

【讨论】：

【解决方案2】：

如果一个 SET 中有两个相同类型的组件，它们确实是无法区分的。如果该示例出现在具有自动标记的模块中，它仍然可以是正确的。

【讨论】：