Sujet : standards
-
Numéros de téléphone E.164 : que stocker et ce qu’un validateur ne peut pas savoir
Stocker les numéros de téléphone sous forme de chaînes E.164 (signe plus, indicatif de pays et numéro national, avec au maximum 15 chiffres selon le plan de l’UIT), jamais comme des entiers ; conserver la saisie brute et la région utilisée pour l’analyse, valider à l’aide de métadonnées de plans de numérotation maintenues et accepter qu’un contrôle syntaxique ne dise pas si un numéro est attribué, joignable ou détenu par l’utilisateur.
-
Les bases de vCard 4.0 : le format text/vcard pour échanger des contacts
Une vCard est un document UTF-8 de type text/vcard composé de BEGIN:VCARD, VERSION:4.0, d'un FN obligatoire et de propriétés structurées facultatives (N, TEL, EMAIL, ADR, UID, REV) avec des paramètres ; les valeurs échappent les virgules, les points-virgules et les barres obliques inverses, et les lignes de contenu se replient à un maximum de 75 octets. jCard (RFC 7095) porte le même modèle en JSON.
-
Les en-têtes List-Unsubscribe et de désabonnement en un clic (RFC 2369 et RFC 8058)
Les en-têtes de la RFC 2369 permettent aux clients de messagerie de proposer des actions de liste ; le désabonnement en un clic de la RFC 8058 ajoute une URI HTTPS List-Unsubscribe ainsi qu'un List-Unsubscribe-Post : List-Unsubscribe=One-Click, traité par une requête HTTPS POST sans redirection ni étape supplémentaire, les deux en-têtes étant couverts par DKIM. Les directives de Google imposent aux expéditeurs en masse de le prendre en charge.
-
XML aujourd'hui : bien formé face à valide, espaces de noms, et quand il reste le bon choix
Un document XML bien formé respecte la syntaxe ; un document valide satisfait en outre une DTD ou un schéma. Les espaces de noms donnent à chaque élément et attribut un nom étendu composé de l'URI de l'espace de noms et d'un nom local, liés par des déclarations xmlns dont les préfixes sont arbitraires et dont la forme par défaut ne s'applique pas aux attributs. XML reste le bon choix pour les documents à contenu mixte et pour les écosystèmes dont les vocabulaires et l'outillage sont déjà en XML.
-
Country and currency codes in data: ISO 3166-1 and ISO 4217 without the surprises
Store countries as ISO 3166-1 alpha-2 codes and currencies as ISO 4217 alpha-3 codes with their minor-unit exponent, keep the code tables versioned because entries change, and never derive one from the other: a country has no single language or currency, and codes such as UK or XXX are traps.
-
Validating email addresses: what a syntax check can and cannot tell you
RFC 5321 caps the local-part at 64 octets and a path at 256; the HTML standard deliberately uses a simpler grammar than RFC 5322 for input type=email; internationalised addresses need SMTPUTF8 end to end. Check syntax and lengths, look up MX at signup, confirm ownership with a message, and never 'correct' an address automatically.
-
Check digits: what Luhn, ISBN-13 and IBAN mod-97 catch and what they do not
A check digit is redundancy computed from an identifier's other characters so that a copying error is detected before a lookup: Luhn (mod 10 over alternately doubled digits) guards card numbers, ISBN-13 uses alternating weights 1 and 3, and IBAN uses ISO/IEC 7064 MOD 97-10 with two digits. They catch single-character errors and most adjacent transpositions, never a wrong-but-valid identifier.
-
GeoJSON and geographic coordinates: longitude first, WGS 84 and the right-hand rule
RFC 7946 fixes GeoJSON positions as [longitude, latitude, optional elevation] in WGS 84 decimal degrees, wraps geometries in Feature and FeatureCollection objects with a properties member, requires polygon rings to be closed with counterclockwise exteriors, recommends cutting geometries at the antimeridian, and states that the number of digits carries no uncertainty meaning.
Lisible par machine : JSON