テーマ： 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.
-
言語タグ：コンテンツと API における BCP 47
言語タグは ISO 639 の言語コードに、任意の文字体系・地域サブタグを組み合わせる（de、de-CH、zh-Hant）。コンテンツの言語宣言、HTML の lang 属性、API のフィルターに使い、自由記述を受け入れるのではなく妥当性を検証する。
-
JSON フィールドの命名と大文字・小文字を統一する
プロパティ名の表記規則を一つ選び、すべてに適用します。Google の JSON スタイルガイドと ProtoJSON は lowerCamelCase を使い、多くの API は snake_case を使います。表記だけでなく、意味のある名前を付け、列挙値は文字列、タイムスタンプは RFC 3339 の文字列、64 ビット整数は文字列にします。
-
JSON Schema による JSON の検証
JSON Schema は、型、必須キー、列挙値、形式、範囲など、文書で許容される構造を記述する。さまざまな言語で入力を処理前に検証できるようにし、additionalProperties は明示的に設定する。
-
浮動小数点数：0.1 + 0.2 が 0.3 にならない理由
二進浮動小数点は、多くの十進小数を近似して表すため、計算で丸め誤差が蓄積します。許容誤差で比較し、慎重に合計し、金額や件数には整数か十進型を使い、元の値に戻せるだけの桁数で出力します。
-
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の基本：連絡先を交換するtext/vcard形式
vCardは、BEGIN:VCARD、VERSION:4.0、必須のFN、パラメーター付きの任意の構造化プロパティ（N、TEL、EMAIL、ADR、UID、REV）からなるUTF-8のtext/vcard文書です。値のコンマ、セミコロン、バックスラッシュをエスケープし、内容行は最大75オクテットで折り返します。jCard（RFC 7095）は同じモデルをJSONで表します。
-
JSON Schema、検証、回数制限付き再試行による文書からの構造化抽出
additionalProperties false の JSON Schema で対象レコードを定義し、モデルにその形だけを要求する。各応答を実際のバリデーターで検証し、エラーをプロンプトへ戻して上限付きで再試行する。それでも失敗するものは推測せず、人に回す。
-
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 の招待：UID、SEQUENCE、タイムゾーンの正しい扱い
iCalendar のイベントは UID で識別し、SEQUENCE で改訂を示す。時刻は UTC、埋め込み VTIMEZONE を参照する TZID 付きのローカル時刻、または浮動時刻で表す。繰り返しの会議にはゾーンに固定したローカル時刻を、単発のゾーン間イベントには UTC を使い、受信クライアントが想定する iTIP METHOD で更新とキャンセルを送る。
-
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：フィールド番号、未知のフィールド、メッセージの進化規則
Protocol Buffers の通信形式では、フィールドを識別するのは名前ではなく番号です。番号は変更も再利用もしてはいけません。追加は通信上安全で、削除は番号を再利用しない場合だけ安全です（reserved で強制できます）。古い読み取り側は未知のフィールドを保持し、int32 から int64 への拡張は条件付きで安全です。ProtoJSON には別の規則があります。
-
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?
-
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.
-
JSON で物理量を表す：値、単位、精度を別のフィールドにする
測定または計算した量を JSON で運ぶ手順です。量の種類ごとに正規単位を一つ選び、単位が固定ならフィールド名に含め、混在するなら管理された単位コードと値のオブジェクトを使います。精度は桁数ではなく明示し、正確な十進値が重要なら文字列を使います。
機械可読： JSON