Я модифицировал часть программного обеспечения для ПК, которую я написал, чтобы читать несколько записей NDEF из тега NFC. Тем не менее, один из моих тегов содержит запись с искаженным заголовком NDEF. Это последняя запись 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.
Я решил провести проверку работоспособности с помощью приложения TagInfo от NXP, чтобы убедиться, что я не просто неправильно прочитал данные. Проверяя дамп данных из полной проверки, я увидел, что данные на самом деле совпадают. Я перечислил сканирование памяти ниже. Перечислены только соответствующие точки данных, и полезная нагрузка опять усечена.
Дамп памяти
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 лишних байта, но и правильно установила бит SR в заголовке NDEF. Я дважды проверил это с помощью другого приложения NFC на Android и подтвердил, что другое приложение также может читать сообщение NDEF таким же образом.
У меня вопрос: есть ли причина или логика в том, как приложение может исправлять не только добавленные байты, но и заголовок NDEF? Я не уверен, исправляет ли это Android или что-то еще глубже в структуре сообщений NDEF. В любом случае, я смотрю на правильный способ сделать исправление, не влияя на то, как я читаю другие 5 записей, содержащихся в этом теге.