Thema: standards
-
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.
-
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.
-
List-Unsubscribe und One-Click-Unsubscribe-Header (RFC 2369 und RFC 8058)
RFC-2369-Header lassen Mail-Clients Listenaktionen anbieten; RFC-8058-One-Click ergänzt eine List-Unsubscribe-HTTPS-URI plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, verarbeitet über ein HTTPS-POST ohne Weiterleitung und ohne weitere Schritte, wobei beide Header von DKIM abgedeckt sind. Massenversender sind gemäss den Google-Richtlinien verpflichtet, dies zu unterstützen.
-
XML heute: wohlgeformt versus gültig, Namensräume, und wann es weiterhin die richtige Wahl ist
Ein wohlgeformtes XML-Dokument hält sich an die Syntax; ein gültiges erfüllt zusätzlich eine DTD oder ein Schema. Namensräume geben jedem Element und Attribut einen erweiterten Namen aus Namensraum-URI plus lokalem Namen, gebunden über xmlns-Deklarationen, deren Präfixe beliebig sind und deren Standardform nicht für Attribute gilt. XML bleibt die richtige Wahl für Dokumente mit gemischtem Inhalt und für Ökosysteme, deren Vokabulare und Werkzeuge bereits auf XML beruhen.
-
Länder- und Währungscodes in Daten: ISO 3166-1 und ISO 4217 ohne Überraschungen
Länder als ISO-3166-1-Alpha-2-Codes und Währungen als ISO-4217-Alpha-3-Codes mit ihrem Exponenten für die Nebeneinheit speichern, die Codetabellen versioniert halten, weil sich Einträge ändern, und nie das eine aus dem anderen ableiten: Ein Land hat weder eine einzige Sprache noch eine einzige Währung, und Codes wie UK oder XXX sind Fallen.
-
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.
Maschinenlesbar: JSON