CoreNFC ne lira pas lorsque le champ TLV utilise un format de longueur de 3 octets

Question

Impossible d'obtenir une réponse de CoreNFC lorsque la longueur NDEF est supérieure à 256 octets et nécessite donc l'utilisation d'un champ de 3 octets par rapport à un champ de 1 octet. Je dois noter que les tags peuvent être lus sur Android.

Est-ce que quelqu'un d'autre peut confirmer ce comportement ou m'aider à comprendre comment spécifier le fichier afin que CoreNFC reconnaisse et lise le fichier?

Alors cela fonctionne,

// 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 

Mais cela ne,

// 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 

Answer 1

Il se trouve la question a été provoquée par un paramètre dans le conteneur de compatibilité. Apple peut lire les deux types de NDEF avec CoreNFC, si vous définissez le bit pour que "IC supporte la commande ReadMultipleBlocks" à false, cela fonctionne sans problème. Nous l'avons mis à vrai. Voici un exemple de CC qui fonctionne avec 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 

Lire plus de la documentation IC, bien qu'il commande ReadMultipleBlocks de soutien, il le fait en blocs de 128 octets. C'est peut-être ce qui a causé le comportement étrange que nous avons vu.

Je ne comprends toujours pas pourquoi Android gère sans problème, et Apple ne peut pas le lire. Mais changer le paramètre résout le problème pour CoreNFC.