Essayer l’outil
L’essentiel
Choix initial d’une capacité NFC avant écriture d’un échantillon. L’encodage exact peut modifier le résultat.
Trois points à établir avant de conclure :
- contenu final à encoder
- taille NDEF après encodage
- marge conservée pour les changements et le verrouillage
L’estimation ajoute une marge simple, mais l’en-tête NDEF réel dépend du type d’enregistrement, de la longueur et de l’encodage. Utilisez-la pour écarter une capacité manifestement insuffisante, puis écrivez le contenu final sur un échantillon. La valeur décisive est l’espace encore disponible après une lecture réussie sur les appareils cibles.
Une estimation volontairement prudente
Le calculateur compte les octets de l’adresse en UTF-8, ajoute 12 octets forfaitaires pour les en-têtes et l’enveloppe, puis applique 20 % de marge, arrondis à l’entier supérieur. Il ne compresse pas le préfixe : « https:// » y compte pour 8 octets, alors qu’un véritable message NDEF le remplace par un seul. Le résultat s’exprime en octets, l’unité utilisée par les fiches techniques pour la mémoire utilisateur.
Exemple et comparaison avec l’encodage réel
Pour l’adresse proposée, https://example.com/produit, soit 27 caractères, l’estimation donne 39 octets, 47 avec la marge. Notre générateur de message NDEF, qui applique le préfixe abrégé, obtient pour la même adresse un message complet de 27 octets. L’écart représente la sécurité de l’estimation : si le résultat du calculateur tient dans la capacité visée, l’encodage réel y tiendra aussi. L’inverse n’est pas vrai : un résultat qui dépasse de peu une classe peut encore y tenir une fois l’adresse réellement encodée.
Choisir la capacité
Les étiquettes NFC courantes offrent environ 137, 492 ou 868 octets utiles pour un message. Une adresse de moins d’une centaine de caractères tient dans la plus petite classe, marge comprise ; ce sont les adresses chargées de paramètres de suivi, longues de plusieurs centaines de caractères, qui imposent une classe supérieure. Raccourcir l’adresse côté serveur est souvent plus simple que d’augmenter la capacité. Pour une série à adresses variables, faites l’estimation sur l’adresse la plus longue du fichier, pas sur la première. Le calculateur ignore aussi le miroir d’UID : un identifiant inséré automatiquement par la puce allonge l’adresse de 14 caractères pour un UID de 7 octets écrit en hexadécimal.



Sources primaires
Questions fréquentes
Pourquoi le calculateur de mémoire et le générateur NDEF donnent-ils des tailles différentes pour la même adresse ?
Le calculateur applique un forfait de 12 octets et compte le préfixe en entier, puis ajoute une marge. Le générateur construit le message exact, avec un préfixe réduit à un octet et 7 octets d’en-tête et d’enveloppe. Le premier sert à écarter une capacité insuffisante, le second donne la taille à encoder.
Faut-il garder de la mémoire libre si l’adresse encodée doit changer plus tard ?
Oui. La marge de 20 % couvre un allongement modéré de l’adresse, à condition que l’étiquette ne soit pas verrouillée : une page verrouillée ne se réécrit plus. Si une modification est probable, protégez plutôt l’étiquette par mot de passe et choisissez la classe qui accepte l’adresse la plus longue envisagée.
Les caractères accentués ou spéciaux d’une adresse augmentent-ils la mémoire nécessaire ?
Oui. En UTF-8, une lettre accentuée occupe deux octets et certains symboles jusqu’à quatre. Si l’adresse est encodée sous forme échappée, chaque octet devient trois caractères, par exemple %C3%A9 pour é. Une adresse limitée aux lettres non accentuées, chiffres et tirets reste la plus compacte.
