Thema: data-formats
-
E.164-Telefonnummern: was zu speichern ist und was ein Validator nicht wissen kann
Telefonnummern als E.164-Zeichenketten speichern (ein Pluszeichen, die Landesvorwahl und die nationale Nummer, nach dem ITU-Plan höchstens 15 Ziffern), nie als Ganzzahlen; die Rohangabe und die zum Parsen verwendete Region behalten, mit gepflegten Nummerierungsplan-Metadaten validieren und akzeptieren, dass eine Syntaxprüfung nicht sagen kann, ob eine Nummer vergeben, erreichbar oder im Besitz der nutzenden Person ist.
-
Sprachkennungen: BCP 47 in Inhalten und APIs
Sprachkennungen kombinieren einen ISO-639-Sprachcode mit optionalen Schrift- und Regions-Subtags (de, de-CH, zh-Hant); sie für Sprachdeklarationen von Inhalten, HTML-lang-Attribute und API-Filter verwenden und validieren, statt Freitext zu akzeptieren.
-
Konsistente Benennung und Schreibweise von JSON-Feldern
Eine einzige Schreibkonvention für Eigenschaftsnamen wählen und sie überall anwenden: Googles JSON-Style-Guide und ProtoJSON verwenden lowerCamelCase, viele APIs verwenden snake_case. Über die Schreibweise hinaus Namen bedeutungsvoll halten, Enums als Strings, Zeitstempel als RFC-3339-Strings und 64-Bit-Ganzzahlen als Strings.
-
JSON mit JSON Schema validieren
JSON Schema beschreibt die erlaubte Form eines Dokuments (Typen, Pflichtfelder, Aufzählungen, Formate, Grenzwerte) und lässt jede Sprache Eingaben vor der Verarbeitung validieren; additionalProperties sollte explizit gesetzt werden.
-
Gleitkommazahlen: warum 0.1 + 0.2 nicht 0.3 ergibt
Binäre Gleitkommazahlen stellen die meisten Dezimalbrüche nur näherungsweise dar, sodass sich bei Rechnungen Rundungsfehler ansammeln; mit Toleranzen vergleichen, sorgfältig summieren, für Geldbeträge und Zählwerte Ganzzahlen oder Decimal-Typen verwenden und mit genügend Nachkommastellen ausgeben, damit ein Roundtrip gelingt.
-
YAML sicher laden
Volle YAML-Loader können aus getaggten Knoten beliebige Objekte instanziieren; stets einen sicheren Loader verwenden, die YAML-Versionssemantik festnageln und das Ergebnis vor der Verwendung gegen ein Schema validieren.
-
vCard-4.0-Grundlagen: das Format text/vcard zum Austausch von Kontakten
Eine vCard ist ein UTF-8-Dokument vom Typ text/vcard mit BEGIN:VCARD, VERSION:4.0, einem verpflichtenden FN und optionalen strukturierten Eigenschaften (N, TEL, EMAIL, ADR, UID, REV) mit Parametern; Werte maskieren Kommas, Semikolons und Backslashes, und Inhaltszeilen werden bei maximal 75 Oktetten gefaltet. jCard (RFC 7095) trägt dasselbe Modell in JSON.
-
Strukturierte Extraktion aus Dokumenten mit JSON Schema, Validierung und begrenzten Wiederholungsversuchen
Den Zieldatensatz als JSON Schema mit additionalProperties false definieren, das Modell genau um diese Form bitten, jede Antwort mit einem echten Validator prüfen, mit der Validierungsfehlermeldung im Prompt eine begrenzte Anzahl Male erneut versuchen und weiterhin Fehlschlagendes an eine Person weiterleiten statt zu raten.
-
Geld und andere exakte Grössen: Decimal statt float verwenden
Binäre Gleitkommazahlen können die meisten dezimalen Brüche nicht exakt darstellen, sodass Summen von Preisen driften; das Modul decimal bietet exakte Dezimalarithmetik mit expliziter Rundung, und Ganzzahlen in Kleinsteinheiten sind eine Alternative.
-
Konfigurationsformate wählen: JSON, YAML oder TOML
JSON (RFC 8259) ist streng und überall lesbar, kennt aber keine Kommentare; YAML ist gut lesbar, doch unzitierte Werte werden nach Muster typisiert; TOML ist für Konfiguration entworfen, mit Kommentaren, expliziten Typen und Tabellen. Wer die Datei bearbeitet und was sie liest, entscheidet – und jedes Format braucht nach dem Parsen eine Prüfung gegen ein Schema.
-
JSONB-Spalten: wofür sie taugen und wann eine eigene Spalte besser ist
jsonb speichert geparstes JSON in einer binären Form, die sich mit GIN indexieren und über Containment- und Pfadoperatoren abfragen lässt; es eignet sich für spärliche, extern definierte oder tatsächlich variable Attribute. Daten mit fester Struktur, Daten, die Constraints, Fremdschlüssel oder Aktualisierungen einzelner Felder benötigen, sowie grosse, häufig geänderte Dokumente gehören in gewöhnliche Spalten.
-
Grundlagen spaltenorientierter Speicherung: wie eine Parquet-Datei aufgebaut ist und warum analytische Lesezugriffe weniger Daten berühren
Eine Parquet-Datei ist eine Folge von Row Groups, von denen jede pro Spalte einen Column Chunk enthält; jeder Chunk ist in Pages unterteilt, die die Einheit für Kodierung und Kompression bilden. Die Metadaten stehen am Ende, sodass eine lesende Stelle zunächst den Footer öffnet, nur die benötigten Spalten auswählt und Row Groups sowie Pages anhand ihrer Min/Max-Statistiken überspringt. Die spaltenweise Anordnung ist es, die Dictionary- und Lauflängenkodierungen wirksam macht.
-
Datums- und Zeitformate in APIs: ISO 8601 und RFC 3339
Zeitstempel als RFC-3339-Strings mit explizitem Offset austauschen, Datumsangaben als YYYY-MM-DD, Zeitdauern als ISO-8601-Dauern oder reine Sekunden; nie als sprachraumabhängigen Text oder als mehrdeutige Zahlen.
-
API-Fehlermeldungen nach RFC 9457 (Problem Details)
RFC 9457 definiert mit `application/problem+json` ein einheitliches Format für Fehlerantworten von HTTP-APIs: `type` als URI der Fehlerklasse, `title`, `status`, `detail` und `instance`, erweiterbar um eigene Felder. Clients – auch Agenten – können damit auf die Fehlerklasse verzweigen, statt Prosa zu deuten.
-
iCalendar-Einladungen: UID, SEQUENCE und korrekte Zeitzonen
Ein iCalendar-Ereignis wird über UID identifiziert und über SEQUENCE überarbeitet; seine Zeiten sind UTC, lokale Zeit mit einer TZID, die auf eine eingebettete VTIMEZONE verweist, oder frei schwebend. Zonengebundene lokale Zeit für wiederkehrende Termine verwenden, UTC für einmalige zeitzonenübergreifende Ereignisse, und Aktualisierungen sowie Absagen mit der iTIP-METHOD senden, die der empfangende Client erwartet.
-
sort, uniq und comm: Mengenoperationen auf Text, die sortierte Eingabe voraussetzen
uniq fasst nur benachbarte Duplikate zusammen, comm verlangt, dass beide Eingaben in derselben Kollationsreihenfolge sortiert sind, und die Reihenfolge von sort richtet sich nach LC_COLLATE; solche Pipelines unter LC_ALL=C ausführen, die richtigen Schlüsseloptionen wählen (-n, -h, -V, -k, -t) und comm -12 sowie comm -23 für Schnittmengen und Differenzen verwenden.
-
Protocol Buffers: Feldnummern, unbekannte Felder und die Regeln für die Weiterentwicklung einer Nachricht
In Protocol Buffers identifiziert die Feldnummer, nicht der Name, ein Feld auf der Leitung, weshalb Nummern nie geändert oder wiederverwendet werden dürfen; das Hinzufügen von Feldern ist unbedenklich, das Entfernen nur dann sicher, wenn die Nummer nie wiederverwendet wird (eine reserved-Anweisung erzwingt das), alte Leser behalten unbekannte Felder, und die Erweiterung von int32 zu int64 ist nur bedingt sicher. ProtoJSON hat eigene, davon abweichende Regeln.
-
Wie sollten öffentliche Identifikatoren gestaltet sein, wenn sowohl Menschen als auch Agenten sie zwischen Systemen kopieren?
Offene Frage: Typpräfixe, Prüfziffern, zeitlich geordnete Bestandteile, Alphabete ohne verwechselbare Zeichen und feste Längen lösen jeweils ein Problem bei Identifikatoren, die von Menschen und von Agenten gelesen, getippt und eingefügt werden; welche Kombinationen haben sich in der Praxis bewährt, und was haben sie gekostet?
-
Zeitangaben: UTC, ISO 8601 und Zeitzonen
Zeitpunkte in UTC speichern und als RFC-3339-Zeichenketten austauschen, im Code nur zeitzonenbewusste Objekte verwenden, erst zur Anzeige in eine benannte IANA-Zone umrechnen; Kalenderrechnung und Zeitpunktrechnung getrennt behandeln.
-
Physikalische Grössen in JSON darstellen: Wert, Einheit und Genauigkeit als getrennte Felder
Ein Vorgehen, um gemessene oder berechnete Grössen in JSON zu übertragen: eine kanonische Einheit pro Grössenart, die Einheit im Feldnamen für Felder mit fester Einheit und ein Objekt aus Wert und Einheit mit kontrolliertem Einheitscode für Felder mit wechselnder Einheit, Genauigkeit explizit angegeben statt über die Anzahl Nachkommastellen, sowie Strings dort, wo der exakte Dezimalwert zählt.
Maschinenlesbar: JSON