如果您通过将 NOCONSTRAIN 标志传递给运行时来关闭强约束检查，那么只要满足 PER 和 本地类型表示。 例如，假设您有以下内容，这意味着 Foo 的值可以介于 0 到 10 或 20-25 之间：
Foo ::= INTEGER (0..10 | 20..25)
通过强约束检查，如果接收到 15 的值，编码器/解码器将返回错误。 但是，如果通过传递 NOCONSTRAIN 关闭了强约束检查，则在所有支持的编码规则（如 BER/DER/CER/PER）中不会报告值 15 的错误 /UPER/XER/CXER/等）。
另一方面，如果没有强约束检查，编码器将始终正确编码值（就像严格的约束检查一样），但它不会总是捕获您可能传递给它进行编码的某些无效值，例如上面示例中的 15 . 在解码方面，解码器会成功解码一个值，例如上面的 15，但不会检测到它是无效的，因此您的应用程序需要对这种情况进行更严格的检查，以确保解码的数据确实有效并且不 违反 ASN.1 规范。
请注意，即使关闭了强约束检查，解码器也会检测 PER/UPER 中最常见的子类型约束违规。 例如，在上面的示例中，即使您将 NOCONSTRAIN 标志传递给运行时，PER 解码器也会检测到大于 25 的值。 实际上，在大多数情况下，您会注意到子类型约束比上面的更简单，看起来更像：
Bar ::= INTEGER (0..10)
在这种情况下，如果 PER 正在使用中，通过强约束检查您将一无所获，因为用于编码/解码的 PER 算法将导致大于 10 的值被标记为错误。
OSS 提供了这种强大的约束检查形式，以帮助我们的客户更快地检测到他们编码/解码的值的问题。
在运行时捕获内存违规也是如此。 如果您的应用程序已完全调试，那么在生产代码中捕获内存违规或在生产程序的编码器中进行严格的约束检查没有任何好处。 在解码方面，您需要添加到代码中以确保安全的检查数量很少，因为用于解码类型具有子类型约束的值的 PER 算法将导致在不使用强约束检查的情况下检测到大多数约束违规 .
强约束检查在编码之前和编码器/解码器内部解码之后完成。 因此，对于使用 BER/DER/CER 的应用程序而言，强约束检查比 PER/UPER 更为重要，因为子类型约束对 BER/DER/CER 编码的结构没有影响，因此 BER/CER/DER 提供 编码器/解码器无法在编码/解码时检测约束违规，而在 PER/UPER 中，由于 PER/UPER 的本质取决于 ASN.1 规范中施加的约束，编码器/解码器具有这种方法 .
一些知识中心答案中包含的示例旨在让您大致了解 OSS 产品。 不同版本的产品可能会产生略有不同的输出。 有关最新的产品信息和代码示例，请参阅产品文档和示例。
