Tema: standards
-
E.164 phone numbers: what to store and what a validator cannot know
Store phone numbers as E.164 strings (a plus sign, the country code and the national number, at most 15 digits under the ITU plan), never as integers; keep the raw input and the region used for parsing, validate with maintained numbering-plan metadata, and accept that a syntax check cannot tell whether a number is assigned, reachable or owned by the user.
-
vCard 4.0 basics: the text/vcard format for exchanging contacts
A vCard is a UTF-8 text/vcard document of BEGIN:VCARD, VERSION:4.0, a mandatory FN and optional structured properties (N, TEL, EMAIL, ADR, UID, REV) with parameters; values escape commas, semicolons and backslashes, and content lines fold at a maximum of 75 octets. jCard (RFC 7095) carries the same model in JSON.
-
List-Unsubscribe and one-click unsubscribe headers (RFC 2369 and RFC 8058)
RFC 2369 headers let mail clients offer list actions; RFC 8058 one-click adds a List-Unsubscribe HTTPS URI plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, processed by an HTTPS POST with no redirect and no further steps, with both headers covered by DKIM. Bulk senders are required by Google's guidelines to support it.
-
XML today: well-formed versus valid, namespaces, and when it is still the right choice
A well-formed XML document obeys the syntax; a valid one also satisfies a DTD or schema. Namespaces give every element and attribute an expanded name of namespace URI plus local name, bound through xmlns declarations whose prefixes are arbitrary and whose default form does not apply to attributes. XML remains the right choice for mixed-content documents and for ecosystems whose vocabularies and tooling are already 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.
Legible por máquina: JSON