Sujet : data-formats
-
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.
-
Balises de langue : BCP 47 dans le contenu et les API
Les balises de langue combinent un code de langue ISO 639 avec des sous-balises facultatives de script et de région (de, de-CH, zh-Hant) ; les utiliser pour les déclarations de langue du contenu, les attributs lang en HTML et les filtres d'API, et les valider plutôt que d'accepter du texte libre.
-
Nommage et casse cohérents des champs JSON
Choisir une seule convention de casse pour les noms de propriétés et l'appliquer partout : le guide de style JSON de Google et ProtoJSON utilisent le lowerCamelCase, de nombreuses API utilisent le snake_case. Au-delà de la casse, garder des noms porteurs de sens, des énumérations sous forme de chaînes, des horodatages en chaînes RFC 3339 et des entiers 64 bits en chaînes.
-
Valider du JSON avec JSON Schema
JSON Schema décrit la forme autorisée d'un document (types, clés requises, énumérations, formats, bornes) et permet à n'importe quel langage de valider des entrées avant de les traiter ; garder additionalProperties explicite.
-
Nombres à virgule flottante : pourquoi 0.1 + 0.2 n'égale pas 0.3
La virgule flottante binaire représente la plupart des fractions décimales de façon approximative, si bien que les calculs accumulent des erreurs d'arrondi ; comparer avec des tolérances, additionner avec soin, utiliser des entiers ou des types décimaux pour l'argent et les comptages, et afficher avec suffisamment de chiffres pour permettre un aller-retour exact.
-
Charger YAML en toute sécurité
Les chargeurs YAML complets peuvent instancier des objets arbitraires à partir de nœuds étiquetés ; toujours utiliser un chargeur sûr, figer la sémantique de version YAML, et valider le résultat par rapport à un schéma avant utilisation.
-
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.
-
Extraction structurée de documents avec JSON Schema, validation et nouvelles tentatives bornées
Définir l'enregistrement cible comme un JSON Schema avec additionalProperties à false, demander au modèle exactement cette forme, valider chaque réponse avec un véritable validateur, réessayer un nombre borné de fois en incluant l'erreur de validation dans le prompt, et orienter ce qui échoue encore vers une personne plutôt que de deviner.
-
Argent et autres quantités exactes : utiliser Decimal, pas float
La virgule flottante binaire ne peut pas représenter exactement la plupart des fractions décimales, si bien que les sommes de prix dérivent ; le module decimal fournit une arithmétique décimale exacte avec un arrondi explicite, et les entiers en unité mineure constituent une alternative.
-
Choisir un format de configuration : JSON, YAML ou TOML
JSON (RFC 8259) est strict et lisible partout, mais ne connaît pas les commentaires ; YAML est bien lisible, mais les valeurs non citées sont typées selon des motifs ; TOML est conçu pour la configuration, avec commentaires, types explicites et tables. Le choix dépend de qui modifie le fichier et de ce qui le lit — et chaque format nécessite, après l'analyse, une vérification par rapport à un schéma.
-
Colonnes JSONB : à quoi elles servent et quand une colonne classique vaut mieux
jsonb stocke du JSON analysé sous une forme binaire indexable avec GIN et interrogeable avec des opérateurs d'inclusion et de chemin ; il convient aux attributs épars, définis en externe ou réellement variables. Les données de forme fixe, celles qui nécessitent des contraintes, des clés étrangères ou des mises à jour champ par champ, ainsi que les documents volumineux fréquemment modifiés, ont leur place dans des colonnes ordinaires.
-
Bases du stockage en colonnes : comment un fichier Parquet est organisé et pourquoi les lectures analytiques touchent moins de données
Un fichier Parquet est une séquence de groupes de lignes, chacun contenant un bloc de colonne par colonne, chaque bloc étant découpé en pages qui constituent l'unité d'encodage et de compression ; les métadonnées se trouvent à la fin, si bien qu'un lecteur ouvre le pied de fichier, ne sélectionne que les colonnes nécessaires et saute des groupes de lignes et des pages grâce à leurs statistiques min/max. C'est l'organisation par colonne qui rend efficaces les encodages par dictionnaire et par plages répétées.
-
Formats de date et d'heure dans les API : ISO 8601 et RFC 3339
Échanger les horodatages sous forme de chaînes RFC 3339 avec un décalage explicite, les dates au format AAAA-MM-JJ, les durées comme des durées ISO 8601 ou de simples secondes ; jamais sous forme de texte dépendant de la locale ni de nombres ambigus.
-
Messages d'erreur d'API selon la RFC 9457 (Problem Details)
La RFC 9457 définit, avec `application/problem+json`, un format uniforme pour les réponses d'erreur des API HTTP : `type` comme URI de la classe d'erreur, `title`, `status`, `detail` et `instance`, extensible par des champs propres. Les clients — y compris les agents — peuvent ainsi orienter leur traitement selon la classe d'erreur, plutôt que d'interpréter un texte libre.
-
Invitations iCalendar : UID, SEQUENCE et bien gérer les fuseaux horaires
Un événement iCalendar est identifié par UID et révisé par SEQUENCE ; ses horaires sont en UTC, en heure locale avec un TZID renvoyant à un VTIMEZONE intégré, ou flottants. Utiliser une heure locale ancrée à un fuseau pour les réunions récurrentes, l'UTC pour les événements ponctuels traversant plusieurs fuseaux, et envoyer les mises à jour et annulations avec le METHOD iTIP attendu par le client destinataire.
-
sort, uniq et comm : des opérations d'ensembles sur du texte qui dépendent d'une entrée triée
uniq ne fusionne que les doublons adjacents, comm exige que les deux entrées soient triées selon le même ordre de collation, et l'ordre de sort suit LC_COLLATE ; exécuter ce type de pipeline sous LC_ALL=C, choisir les bonnes options de clé (-n, -h, -V, -k, -t), et utiliser comm -12 et comm -23 pour les intersections et les différences.
-
Protocol Buffers : numéros de champ, champs inconnus et règles d'évolution d'un message
Dans Protocol Buffers, c'est le numéro du champ, et non son nom, qui identifie le champ sur le fil ; ces numéros ne doivent donc jamais changer ni être réutilisés. Ajouter des champs est sans risque pour la compatibilité binaire, en supprimer ne l'est que si le numéro n'est jamais réutilisé (une déclaration reserved l'impose), les anciens lecteurs conservent les champs inconnus, et l'élargissement d'int32 vers int64 n'est sûr que sous conditions. ProtoJSON obéit à ses propres règles, différentes.
-
Comment concevoir des identifiants publics lorsque des personnes et des agents les recopient entre systèmes ?
Question ouverte : les préfixes de type, les chiffres de contrôle, les composants ordonnés dans le temps, les alphabets sans caractères ambigus et les longueurs fixes résolvent chacun un problème propre aux identifiants lus, tapés et collés par des personnes et par des agents ; quelles combinaisons ont fait leurs preuves en pratique, et qu'ont-elles coûté ?
-
Horodatages : UTC, ISO 8601 et fuseaux horaires
Stocker les instants en UTC et les échanger sous forme de chaînes RFC 3339, n'utiliser dans le code que des objets conscients du fuseau horaire, ne convertir vers une zone IANA nommée qu'au moment de l'affichage ; traiter séparément le calcul calendaire et le calcul sur les instants.
-
Représenter des grandeurs physiques en JSON : valeur, unité et précision en champs séparés
Une procédure pour transporter des grandeurs mesurées ou calculées en JSON : une unité canonique par type de grandeur, l'unité dans le nom du champ pour les champs à unité fixe, et un objet valeur-plus-unité avec un code d'unité contrôlé pour les champs à unité variable, une précision indiquée explicitement plutôt que par le nombre de chiffres, et des chaînes de caractères lorsque la valeur décimale exacte compte.
Lisible par machine : JSON