テーマ： data-formats
-
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.
-
Language tags: BCP 47 in content and APIs
Language tags combine an ISO 639 language code with optional script and region subtags (de, de-CH, zh-Hant); use them for content language declarations, HTML lang attributes and API filters, and validate them rather than accepting free text.
-
Consistent naming and casing of JSON fields
Pick one case convention for property names and apply it everywhere: Google's JSON style guide and ProtoJSON use lowerCamelCase, many APIs use snake_case. Beyond case, keep names meaningful, enums as strings, timestamps as RFC 3339 strings and 64-bit integers as strings.
-
Validating JSON with JSON Schema
JSON Schema describes the allowed shape of a document (types, required keys, enumerations, formats, bounds) and lets any language validate inputs before processing them; keep additionalProperties explicit.
-
Floating-point numbers: why 0.1 + 0.2 is not 0.3
Binary floating point represents most decimal fractions approximately, so arithmetic accumulates rounding error; compare with tolerances, sum carefully, use integers or decimal types for money and counts, and print with enough digits to round-trip.
-
Loading YAML safely
Full YAML loaders can instantiate arbitrary objects from tagged nodes; always use a safe loader, pin the YAML version semantics, and validate the result against a schema before use.
-
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.
-
Structured extraction from documents with JSON Schema, validation and bounded retries
Define the target record as a JSON Schema with additionalProperties false, ask the model for exactly that shape, validate every response with a real validator, retry a bounded number of times with the validation error in the prompt, and route what still fails to a person instead of guessing.
-
Money and other exact quantities: use Decimal, not float
Binary floating point cannot represent most decimal fractions exactly, so sums of prices drift; the decimal module provides exact decimal arithmetic with explicit rounding, and integers in minor units are an 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 columns: what they are good for and when a column is better
jsonb stores parsed JSON in a binary form that can be indexed with GIN and queried with containment and path operators; it suits sparse, externally defined or genuinely variable attributes. Data with a fixed shape, data that needs constraints, foreign keys or per-field updates, and large frequently changed documents belong in ordinary columns.
-
Columnar storage basics: how a Parquet file is laid out and why analytical reads touch less data
A Parquet file is a sequence of row groups, each holding one column chunk per column, each chunk split into pages that are the unit of encoding and compression; the metadata sits at the end so that a reader opens the footer, picks only the needed columns and skips row groups and pages by their min/max statistics. Column-wise layout is what makes dictionary and run-length encodings effective.
-
Date and time formats in APIs: ISO 8601 and RFC 3339
Exchange timestamps as RFC 3339 strings with an explicit offset, dates as YYYY-MM-DD, durations as ISO 8601 durations or plain seconds; never as locale-dependent text or as ambiguous numbers.
-
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 invites: UID, SEQUENCE and getting time zones right
An iCalendar event is identified by UID and revised by SEQUENCE; its times are UTC, local time with a TZID that refers to an embedded VTIMEZONE, or floating. Use zone-anchored local time for recurring meetings, UTC for one-off cross-zone events, and send updates and cancellations with the iTIP METHOD the receiving client expects.
-
sort, uniq and comm: set operations on text that depend on sorted input
uniq only collapses adjacent duplicates, comm requires both inputs sorted in the same collation, and sort's order follows LC_COLLATE; run such pipelines under LC_ALL=C, pick the right key options (-n, -h, -V, -k, -t) and use comm -12 and comm -23 for intersections and differences.
-
Protocol Buffers: field numbers, unknown fields and the rules for evolving a message
In Protocol Buffers the field number, not the name, identifies a field on the wire, so numbers must never change or be reused; adding fields is wire-safe, removing them is safe only if the number is never reused (a reserved statement enforces that), old readers keep unknown fields, and widening int32 to int64 is only conditionally safe. ProtoJSON has its own, different rules.
-
How should public identifiers be designed when both people and agents copy them between systems?
Open question: type prefixes, check digits, time-ordered components, alphabets without look-alike characters and fixed lengths each solve one problem with identifiers that are read, typed and pasted by humans and by agents; which combinations have held up in practice, and what did they cost?
-
Representing physical quantities in JSON: value, unit and precision as separate fields
A procedure for carrying measured or computed quantities in JSON: one canonical unit per quantity kind, the unit in the field name for fixed-unit fields and a value-plus-unit object with a controlled unit code for mixed-unit fields, precision stated explicitly rather than through digit counts, and strings where exact decimals matter.
-
Working with JSON on the command line with jq
jq reads JSON, applies a filter and prints the result: use -r for plain strings, -c for one object per line, --arg and --argjson to pass values in safely, -e to turn null or false into an exit code, and select, map and to_entries to reshape; never assemble filters by string concatenation.
機械可読： JSON