ASN.1 变得简单——为什么选择 ASN.1？

无论您是经验丰富的用户还是刚入门，可能很难从许多流行的替代方案（例如 ASN.1、JSON Schema 和 Google Protocol Buffers）中挑选出正确的模式技术。 有两个重要因素可以帮助您做出决定 - 模式表现力和模式权威。 两者都将允许您的解决方案在不损害其完整性的情况下发展并避免惩罚性成本。

模式表现力

编写模式需要在 under- 和 over-expressive 之间取得良好的平衡。 在这方面，编写 JSON Schema 可以很容易地包含这两个极端，一方面它允许只定义整个消息的一部分，另一方面它允许复杂的（算法）表达式（例如 if/then、not、anyOf/allOf 等）很难理解。

表现力不足 模式几乎完全没有模式，它缺乏要验证的数据的结构完整性。

过度表达模式可能难以解释并且容易出现人为错误，例如 它的语义很容易“在翻译中丢失”。

ASN.1 架构 提供了一个中间立场。 它需要对消息中的每个字段进行完整定义，并且人员/设计人员可以轻松阅读。

基本空对象的模式（示例）
JSON Schema ASN.1 Schema 
{
  "additionalProperties": false,
  "definitions": {},
  "description": "Empty Object",
  "properties": {},
  "type": [
    "object",
    "null"
  ]
}

-- Empty Object
EmptyObject ::= SEQUENCE {}

模式权威

模式演变是一个福音。 然而，过于宽松的技术，即提供过多的向后和向前兼容性，很容易在整个应用程序代码库中溢出数据验证。 最后，无论您是否愿意，当您选择与 Protobuf 或 JSON Schema 进行通信时，您必须利用更多的开发人员并花费更多的时间来确保数据的完整性。

ASN.1 模式 也允许可扩展性（进化），但它以可预测的方式在编译时（如在强类型数据中）做到这一点，确保模式权威和良好的 为验证逻辑定义边界。 ASN.1 技术提供了一种“正确的时间、正确的地点”解决方案，用于在不影响数据完整性的情况下扩展更大的应用程序。