问题标签 [ber]

我正在尝试构建一个格式正确的 GET PROCESSING OPTIONS 命令以发送到非接触式 EMV 卡。这篇文章非常有帮助，但我只需要了解更多细节。

在解析 PDOL 时，假设每个标签的长度为 2 个字节，然后是预期返回的数据的大小是否安全？

例如，PDOL9F66049F02069F37049F1A02分为 9F66 04、9F02 06等，每个都有 2 个字节标签和 1 个字节用于数据值的预期长度。

解析时假设每个标签的长度为 2 个字节是否安全？

1. 如何手动读取编码 asn 文件？
2. 什么是标签长度值，有好的教程吗？

在以下示例中，我阅读了每个示例，但没有为我清理，任何人都可以帮助阅读每个示例：

1. 30 82 02 10 04 01 56 …（更多字节）

第一个字节是二进制的 00110000。前两位是 00，所以类又是 0。第三位是 1，所以它是结构化的。最后五位是 10000，所以标签是十进制的 16。下一个字节是 82 十六进制，即 130 十进制，即 128 + 2，接下来的 2 个字节给出长度。它们是 02 10，以“大端”格式解释为 2*256 + 16 = 528。接下来的 528 个字节，从 04 01 56 开始，包含内容。

2. 东风82 02 05 12 34 56 78 90

第一个字节是二进制的 11011111。前两位是 11，所以这是第 3 类——私有。下一位是 0，所以这是原始的。其余五位全为 1，因此实际标签从第二个字节开始。第二个字节有一个前导，而第三个字节没有，所以标签是通过取这两个字节（二进制的 10000010 00000010），去掉它们的前导位得到十四位 00000100000010，并将其解释为二进制数来构造的. 因此，标签是十进制的 258。下一个字节是 05，小于 128，所以这是内容的实际长度。接下来的 5 个字节（12 34 56 78 90）是内容。

3. 30 80 04 03 56 78 90 00 00

第一个字节 30 是我们以前见过的。它是通用类，结构化，标签为 16。下一个字节是 80，所以长度一开始是未知的。内容是所有后续字节，直到（但不包括）前两个连续的零字节。所以内容是04 03 56 78 90，我们可以从内容中算出长度是5。

示例参考

我需要解码一些很长的BER消息，我有两种不同的情况。一个有几个没有特定标签的强制参数，还有很多带有隐式标签的可选参数。另一个只有可选的隐式标签，例如：

情况1：

等等，还有更多的参数，大约 40 个，其中一些是构造的，内部也构造了参数。

案例二：

关键是，我真的只需要这些消息中的 3 或 4 个参数。
我不关心其余的。如果我不需要它，我不希望我的解码器花费这么多处理时间来解码完整的消息。有没有标准的方法来做到这一点？
在第二种情况下，我提出了一个想法，将 ASN.1 定义从 SEQUENCE 更改为 SET，例如：

我的意思是，解析只会将这 3 个参数解码为 SET。当然，我必须在接收时修改二进制消息，将其从 SEQUENCE 转换为 SET（仅一位）。但我不能用第一个序列来做到这一点。
有没有办法指示“忽略未知标签”？
我已经阅读了“暗示的可扩展性”，但我不明白这是否是我需要的，或者它只是暗示在序列末尾的可扩展性，就好像我正在使用可扩展性标记“...”一样。

提前致谢，

路易斯

我正在使用卷积码和 QAM-16 调制方案来模拟 CDMA 中 2 个用户之间的 BER。从我附上的图表来看，用户 1 和用户 2 的 BER 相同且恒定。SNR 似乎不影响传输。无论如何我可以改进图表吗？这是我的代码：

误码率图

我是使用 ASN.1 编码流的新手，我很难找到免费的类编译器和解码器，最好是用于 Java。

我有一个编码的十六进制字符串：

下面是一个表示法的例子：

我开始使用 JAC：https ://sourceforge.net/projects/jac-asn1/ 但它不支持自动标签。

我接下来尝试了 jASN1：https ://www.openmuc.org/asn1/ 它没有说它是否支持自动标签。它似乎编译 Notation 没有抱怨，但我无法让它正确解码，如果错误，它看起来像标记。

如果我们以编码字符串的开头：30 82 02 74 80 02 00 a2...这是我的理解：

但是，如果我对“IntersectionSituationData”的测试进行编码，我会得到以下信息： 30 81 8a 0a 02 00 a2 即类型是 'x0a' == 10，即 ASN.1 Universal ENUMERATED。从他的通知来看，这是有道理的，但我猜想自动标签被 jASN1 忽略了。当我查看生成的 Java 类时，我们看到 SemiDialogID 扩展了 BerEnum，它使用通用类标识符：

我需要做些什么来让 jASN1 使用自动标签，还是我需要一个不同的库？如果是后者，人们会推荐什么？理想情况下，我正在寻找一个易于使用的开源 Java 解决方案。我想我可以使用 C 解决方案并使用 JNI 让它工作。

.NET 的 System.DirectoryServices.Protocols 程序集指定了一个轻量级 ASN.1 BER 编码器，但文档不是很好：BerConverter.

您可以通过指定格式字符串和要编码的对象列表来调用它。

• INTEGERs 可以用格式字符编码i或e
• OCTET STRINGs 可以用o字符编码
• SEQUENCEs 可以用{和编码}
• 等等

我真的很想使用这个简单的转换器，所以我不必承担额外的依赖。接受依赖是不可取的，因为 C# 可以从 Powershell 调用，并且分发一个与 C# 做一些花哨的脚本是很好的，只要它不需要 .NET 不包含的程序集。

但是，BerConverter 似乎没有办法指定 Application 或 Context-Specific 标签，这些标签通常用于消除 ASN.1 中的歧义，例如当构造类型的组件被标记为OPTIONAL

因此，我可以对以下内容进行编码：

BerConverter.Encode("{i{i}}", 1, 2);

这使：

30 84 00 00 00 0c 02 01 01 30 84 00 00 00 03 02 01 02

但是，如果第二个序列需要[Application 1]或者61......我不确定在格式字符串中放入什么以在编码中发出它。

BerConverter 甚至有这个能力吗？

在以下示例中，我对显式和隐式标记有疑问

对于X，由于隐式标记将替换现有标记 on INTEGER，[APPLICATION 5]因此值 5 的 BER 中的编码将是十六进制的45 01 05。解码器如何知道来自的类型45 01 05？

我有以下 BERTLV： 61394F0BA00000030800001001234579074F05A000012345500E49442D4F6E65205049562042494F5F50107777772E6F626572746875722E636F6D7F66080202800002028000

我正在尝试以递归方式解析它，因此我将第一部分视为 TLV。

标签: 0x61, Len: 0x39, 值:4F0BA00000030800001001234579074F05A000012345500E49442D4F6E65205049562042494F5F50107777772E6F626572746875722E636F6D

然后我进一步分解它，得到

标签: 0x4F, Len: 0x0B, 值: A000000308000010012345

现在，我该如何停下来？在这一点上，我知道这个值是这个 TLV 的最后一段，而不是另一个嵌套的 TLV。

我正在解码 ASN.1 BER 编码数据，我想知道标签 31（特别是）和更大的正确处理应该是什么。我觉得 X.690 规范有点模棱两可，我没有任何数据的示例，它的标签为 31 或更大。

有问题的部分是 8.1.2.4 处理大于或等于 31 的标签；特别是 8.1.2.4.1 c) 它说：

c) 比特 5 到 1 应编码为 11111₂</p>

然后 8.1.2.4.2 说：

随后的八位字节应按如下方式对标签的编号进行编码：

a) 每个八位字节的第 8 位应设置为 1，除非它是标识符八位字节的最后一个八位字节；

b) 第一个后续八位字节的比特 7 到 1，随后是第二个后续八位字节的比特 7 到 1，然后依次是每个后续八位字节的比特 7 到 1，直到并包括标识符八位字节中的最后一个后续八位字节。是等于标记号的无符号二进制整数的编码，第一个后续八位字节的第 7 位作为最高有效位；

c) 第一个后续八位字节的第 7 到 1 位不应全部为零。

基于此，您如何对标签 31 进行编码？我认为这意味着，除了表示正在表示标签 31 或更大之外，就表示实际标签号而言，第一个八位字节的第 5 到 1 位应被忽略，并且实际标签号以八位字节编码2 从第 8.1.2.4.2 节开始。在此方案中，标签 31 将是：

所以; 在第一个八位字节中，位 5 到 1 设置为 1，但它们不构成标签编号的一部分。第二个八位字节的第 5 位到第 1 位也是 1，但这次它们确实代表正在编码的标签号。

谁能确认我的解释是否正确，或者当标签 >= 31 时，第一个八位字节的第 5 到 1 位是否应该被视为标签号的一部分？

我有这样的BER结构......

$ openssl asn1parse -inform der -in test.der -i -dump

...或以der2ascii风格...

我所知道的：不定长度编码必须包含构造类型，因为原始类型可能会引入歧义，例如在包含 0x0000 时。我想知道的是：解码器在解析这个 BER 结构时必须如何表现？两个 OCTET STRING 的标头字节是否包含在编码中？如果是，不定长字节数据是如何编码的？当第二个 OCTET STRING 是例如 INTEGER 时，应用程序如何解释标记为 [0] 的 TLV 字段的值？

我在问这个问题，因为在 CMS 标准中，一个字段被定义为单个 OCTET STRING，但在大多数 BER 编码中，我总是看到其中两个。这仅仅是由于不确定长度编码吗？我错过了什么吗？

来自 ITU-T X.690：

8.1.4 内容八位字节

内容八位字节应由零个、一个或多个八位字节组成，并应按照后续条款中的规定对数据值进行编码。

注 — 内容八位字节取决于数据值的类型；后续子句遵循与 ASN.1 中类型定义相同的顺序。

这是否意味着，我可以放置每个构造的类型，而应用程序必须只解释构造的 TLV 结构的值部分？