解释损坏的 NDEF Header
Interpreting Mangled NDEF Header
我正在修改我编写的一个 PC 软件，以从 NFC 标签读取多个 NDEF 记录。但是，我拥有的其中一个标签包含一条记录，其中似乎是损坏的 NDEF header。这是 6 个中的最后一个记录，其他 5 个按预期进入。我在下面列出了它。为简单起见，所有值均以十六进制列出，并且有效负载已被截断。
记录#6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
如您所见，在类型长度和有效负载长度之间插入了 3 个随机零字节。我仔细检查了 TLV 中的长度字段，发现它占了这 3 个字节。由于这些添加的字节，我没有从 TLV 的末尾截断任何数据。
我决定使用 NXP 的 TagInfo 应用程序进行健全性检查，以确保我没有错误地读取数据。通过全面扫描检查数据转储，我发现数据确实匹配。我在下面列出了内存扫描。仅列出相关数据点，有效载荷再次被截断。
内存转储
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
我们认为这可能是填充问题，因为在这种情况下，终结者 TLV 出现在页面 0x3D 的末尾。然而，由于以前记录的性质，情况并非总是如此。有时，终结者 TLV 会出现在页面中间。
但是奇怪的是，在同一个TagInfo应用的NDEF页面，报NDEF信息如下
NDEF 消息
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
不知何故，软件不仅删除了 3 个额外的字节，而且还正确设置了 NDEF header 中的 SR 位。我已经用 Android 上的另一个 NFC 应用程序仔细检查了这一点，并确认另一个应用程序也能够以这种方式读取 NDEF 消息。
我的问题是，应用程序不仅可以更正添加的字节，还可以更正 NDEF Header，这背后是否存在原因或逻辑？我不确定这是 Android 进行更正还是在 NDEF 消息结构中进行更深入的操作。无论哪种方式，我都在寻找进行更正的正确方法，同时不影响我读取此标签中保存的其他 5 条记录的方式。
那些字节也是有效载荷长度的一部分
如果记录没有设置 SR（短记录）位，则有效负载长度为 4 个字节而不是一个字节。
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
第一个字节是0x42，二进制是0100 0010。如果我们将其分开，我们可以看到该记录设置了 ME（或 'Message End'）位，以及 [=14] 的 TNF（'Type Name Format'） =] - 'MIME Media Record'。 SR 位是位 4，在本例中为零。
这也是它们在 TagInfo 应用程序更正的版本中消失的原因 - 它设置了 SR（这就是 header 跳转到 0x52 的原因）并删除了不必要的字节。
我正在修改我编写的一个 PC 软件，以从 NFC 标签读取多个 NDEF 记录。但是，我拥有的其中一个标签包含一条记录，其中似乎是损坏的 NDEF header。这是 6 个中的最后一个记录，其他 5 个按预期进入。我在下面列出了它。为简单起见，所有值均以十六进制列出，并且有效负载已被截断。
记录#6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
如您所见，在类型长度和有效负载长度之间插入了 3 个随机零字节。我仔细检查了 TLV 中的长度字段，发现它占了这 3 个字节。由于这些添加的字节，我没有从 TLV 的末尾截断任何数据。
我决定使用 NXP 的 TagInfo 应用程序进行健全性检查，以确保我没有错误地读取数据。通过全面扫描检查数据转储，我发现数据确实匹配。我在下面列出了内存扫描。仅列出相关数据点，有效载荷再次被截断。
内存转储
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
我们认为这可能是填充问题，因为在这种情况下，终结者 TLV 出现在页面 0x3D 的末尾。然而，由于以前记录的性质，情况并非总是如此。有时，终结者 TLV 会出现在页面中间。
但是奇怪的是，在同一个TagInfo应用的NDEF页面，报NDEF信息如下
NDEF 消息
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
不知何故，软件不仅删除了 3 个额外的字节，而且还正确设置了 NDEF header 中的 SR 位。我已经用 Android 上的另一个 NFC 应用程序仔细检查了这一点，并确认另一个应用程序也能够以这种方式读取 NDEF 消息。
我的问题是，应用程序不仅可以更正添加的字节，还可以更正 NDEF Header，这背后是否存在原因或逻辑？我不确定这是 Android 进行更正还是在 NDEF 消息结构中进行更深入的操作。无论哪种方式，我都在寻找进行更正的正确方法，同时不影响我读取此标签中保存的其他 5 条记录的方式。
那些字节也是有效载荷长度的一部分
如果记录没有设置 SR（短记录）位，则有效负载长度为 4 个字节而不是一个字节。
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
第一个字节是0x42，二进制是0100 0010。如果我们将其分开，我们可以看到该记录设置了 ME（或 'Message End'）位，以及 [=14] 的 TNF（'Type Name Format'） =] - 'MIME Media Record'。 SR 位是位 4，在本例中为零。
这也是它们在 TagInfo 应用程序更正的版本中消失的原因 - 它设置了 SR（这就是 header 跳转到 0x52 的原因）并删除了不必要的字节。