CoreNFC не будет считываться, если поле TLV использует формат длины 3 байта.

Невозможно получить какой-либо ответ от CoreNFC, когда длина NDEF превышает 256 байтов и поэтому требует использования 3-байтового поля вместо 1-байтового поля. Я должен отметить, что теги могут быть прочитаны на Android.

Может ли кто-нибудь еще подтвердить это поведение или помочь мне понять, как указать файл, чтобы CoreNFC распознал и прочитал файл?

Так что это работает,

// TLV header
// Start of Type (T) field
0x03,         // This message contains an NDEF record
// End of Type (T) field

// Start of Length (L) field
// Length = payload length + length of value field
0xFE,         // Length field, adds 3 to account for length of value field when SR:1
// End of Length (L) field

// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:1,IL:0,TNF:101
0xD5,         // Short record false SR:1, 1-byte payload length, unknown type        
0x00,         // Type set to zero, as specified for unknown type
0xFB,         // Payload length
// End of Value (V) field
// End of TLV header

Но это не так,

// TLV header
// Start of Type (T) field
0x03,         // This message contains an NDEF record
// End of Type (T) field

// Start of Length (L) field
// Length = payload length + length of value field
0xFF,         // Always 0xFF for SR:0, indicates length is between 256 and 65535
0x01,         // MSB of length field
0xF2,         // LSB of length field, adds 6 to account for length of value field when SR:0
// End of Length (L) field

// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:0,IL:0,TNF:101
0xC5,         // Short record false SR:0, 4-byte payload length, unknown type        
0x00,         // Type set to zero, as specified for unknown type
0x00,         // MSB of payload length, should be the exact size of the payload (data)
0x00,
0x01,
0xEC,         // LSB of payload length
// End of Value (V) field
// End of TLV header

person navillus    schedule 02.10.2017    source источник


Ответы (1)


Оказывается, проблема была вызвана настройкой в ​​контейнере совместимости. Apple может читать оба типа NDEF с помощью CoreNFC, если вы установите для бита «IC supports ReadMultipleBlocks Command» значение false, он будет работать без проблем. У нас было установлено значение true. Вот пример CC, который работает с CoreNFC.

    // Start of Compatibility Container
0xE1,         // CC0, "Magic Number", NDEF message is present in memory
0x43,         // CC1, Version number 1.0, Read access enabled, Write access normally disabled
0x40,         // CC2, Memory size of data field and CC field in bytes divided by 8, 0x40 = 64, 64x8=512 Bytes
0x00,         // CC3, IC supports ReadMultipleBlocks Command
// End of Compatibility Container

Подробнее читайте в документации IC, хотя она и поддерживает команду ReadMultipleBlocks, она делает это блоками по 128 байт. Это могло быть причиной странного поведения, которое мы видели.

Я до сих пор не понимаю, почему Android справляется с этим без проблем, а Apple не может его прочитать. Но изменение настройки устраняет проблему для CoreNFC.

person navillus    schedule 09.10.2017