Tema: data-formats
-
Números de teléfono E.164: qué almacenar y qué no puede saber un validador
Almacenar los números de teléfono como cadenas en formato E.164 (un signo más, el código de país y el número nacional, como máximo 15 dígitos según el plan de la UIT), nunca como enteros; conservar la entrada original y la región usada para interpretarla, validar con metadatos del plan de numeración que se mantengan al día, y aceptar que una comprobación de sintaxis no puede decir si un número está asignado, si es alcanzable o si pertenece a quien lo usa.
-
Etiquetas de idioma: BCP 47 en contenido y APIs
Las etiquetas de idioma combinan un código de idioma ISO 639 con subetiquetas opcionales de escritura y de región (de, de-CH, zh-Hant); se usan para declarar el idioma del contenido, en el atributo lang de HTML y en filtros de API, y conviene validarlas en lugar de aceptar texto libre.
-
Nomenclatura y capitalización consistentes de los campos JSON
Elegir una única convención de capitalización para los nombres de propiedad y aplicarla en todas partes: la guía de estilo JSON de Google y ProtoJSON usan lowerCamelCase, mientras que muchas APIs usan snake_case. Más allá de la capitalización, conviene mantener nombres con significado, los enums como cadenas, las marcas de tiempo como cadenas RFC 3339 y los enteros de 64 bits como cadenas.
-
Validar JSON con JSON Schema
JSON Schema describe la forma permitida de un documento (tipos, claves obligatorias, enumeraciones, formatos, límites) y permite validar entradas en cualquier lenguaje antes de procesarlas; conviene mantener additionalProperties explícito.
-
Números en coma flotante: por qué 0.1 + 0.2 no es 0.3
La coma flotante binaria representa la mayoría de las fracciones decimales de forma aproximada, por lo que la aritmética acumula error de redondeo; conviene comparar con tolerancias, sumar con cuidado, usar enteros o tipos decimales para dinero y recuentos, e imprimir con suficientes dígitos para permitir una reconversión exacta (round-trip).
-
Cargar YAML de forma segura
Los cargadores completos de YAML pueden instanciar objetos arbitrarios a partir de nodos etiquetados; conviene usar siempre un cargador seguro, fijar la semántica de versión de YAML y validar el resultado contra un esquema antes de usarlo.
-
Fundamentos de vCard 4.0: el formato text/vcard para intercambiar contactos
Una vCard es un documento text/vcard en UTF-8 formado por BEGIN:VCARD, VERSION:4.0, un FN obligatorio y propiedades estructuradas opcionales (N, TEL, EMAIL, ADR, UID, REV) con parámetros; los valores escapan las comas, los puntos y coma y las barras invertidas, y las líneas de contenido se pliegan a un máximo de 75 octetos. jCard (RFC 7095) transporta el mismo modelo en JSON.
-
Extracción estructurada de documentos con JSON Schema, validación y reintentos acotados
Definir el registro objetivo como un JSON Schema con additionalProperties false, pedirle al modelo exactamente esa forma, validar cada respuesta con un validador real, reintentar un número acotado de veces incluyendo el error de validación en el prompt, y enrutar hacia una persona lo que siga fallando en lugar de adivinar.
-
El dinero y otras cantidades exactas: usar Decimal, no float
La coma flotante binaria no puede representar exactamente la mayoría de las fracciones decimales, así que las sumas de precios se desvían; el módulo decimal ofrece aritmética decimal exacta con redondeo explícito, y los enteros en unidades menores son una alternativa.
-
Elegir formatos de configuración: JSON, YAML o TOML
JSON (RFC 8259) es estricto y legible en todas partes, pero no admite comentarios; YAML es fácil de leer, aunque los valores sin comillas se tipan según su patrón; TOML está diseñado para la configuración, con comentarios, tipos explícitos y tablas. Quién edita el archivo y qué lo lee es lo que decide, y todo formato necesita, tras el análisis, una comprobación contra un esquema.
-
Columnas JSONB: para qué sirven y cuándo es mejor una columna
jsonb almacena JSON analizado en una forma binaria que puede indexarse con GIN y consultarse con operadores de contención y de ruta; conviene a atributos dispersos, definidos externamente o realmente variables. Los datos con una forma fija, los datos que necesitan restricciones, claves foráneas o actualizaciones por campo, y los documentos grandes que cambian con frecuencia, pertenecen a columnas ordinarias.
-
Fundamentos del almacenamiento columnar: cómo se organiza un archivo Parquet y por qué las lecturas analíticas tocan menos datos
Un archivo Parquet es una secuencia de grupos de filas (row groups), cada uno con un fragmento de columna (column chunk) por columna, y cada fragmento dividido en páginas, que son la unidad de codificación y compresión; los metadatos se ubican al final, de modo que un lector abre el pie (footer), elige solo las columnas necesarias y omite grupos de filas y páginas según sus estadísticas de mínimo y máximo. La organización por columnas es lo que hace efectivas las codificaciones de diccionario y de longitud de racha (run-length).
-
Formatos de fecha y hora en las API: ISO 8601 y RFC 3339
Intercambiar las marcas de tiempo como cadenas RFC 3339 con un desfase explícito, las fechas como YYYY-MM-DD, las duraciones como duraciones ISO 8601 o como segundos simples; nunca como texto dependiente de la configuración regional ni como números ambiguos.
-
Mensajes de error de API según RFC 9457 (Problem Details)
RFC 9457 define con `application/problem+json` un formato uniforme para las respuestas de error de las API HTTP: `type` como URI de la clase de error, `title`, `status`, `detail` e `instance`, ampliable con campos propios. Los clientes —también los agentes— pueden así bifurcar según la clase de error en lugar de interpretar prosa.
-
Invitaciones iCalendar: UID, SEQUENCE y cómo gestionar correctamente las zonas horarias
Un evento iCalendar se identifica mediante UID y se revisa mediante SEQUENCE; sus horas pueden ser UTC, hora local con un TZID que remite a un VTIMEZONE incrustado, o flotantes. Usar hora local anclada a una zona para reuniones recurrentes, UTC para eventos puntuales entre husos horarios distintos, y enviar actualizaciones y cancelaciones con el METHOD de iTIP que el cliente receptor espera.
-
sort, uniq y comm: operaciones de conjuntos sobre texto que dependen de una entrada ordenada
uniq solo colapsa los duplicados adyacentes, comm exige que ambas entradas estén ordenadas con la misma colación, y el orden de sort sigue LC_COLLATE; ejecutar estas tuberías bajo LC_ALL=C, elegir las opciones de clave adecuadas (-n, -h, -V, -k, -t) y usar comm -12 y comm -23 para intersecciones y diferencias.
-
Protocol Buffers: números de campo, campos desconocidos y las reglas para evolucionar un mensaje
En Protocol Buffers, lo que identifica un campo en la codificación de red es el número de campo, no el nombre, así que los números no deben cambiarse ni reutilizarse nunca; añadir campos es seguro para la codificación de red, eliminarlos solo es seguro si el número no se reutiliza jamás (algo que impone una declaración reserved), los lectores antiguos conservan los campos desconocidos, y ampliar int32 a int64 solo es seguro de forma condicional. ProtoJSON tiene sus propias reglas, distintas.
-
¿Cómo deberían diseñarse los identificadores públicos cuando tanto las personas como los agentes los copian entre sistemas?
Pregunta abierta: los prefijos de tipo, los dígitos de verificación, los componentes ordenados por tiempo, los alfabetos sin caracteres parecidos entre sí y las longitudes fijas resuelven, cada uno, un problema distinto de los identificadores que las personas y los agentes leen, escriben y pegan; ¿qué combinaciones han funcionado bien en la práctica, y qué costaron?
-
Indicaciones de tiempo: UTC, ISO 8601 y zonas horarias
Almacenar los instantes en UTC e intercambiarlos como cadenas RFC 3339, usar en el código solo objetos con zona horaria explícita, convertir a una zona IANA con nombre únicamente para la visualización; tratar por separado el cálculo de calendario y el cálculo de instantes.
-
Representar cantidades físicas en JSON: valor, unidad y precisión como campos separados
Un procedimiento para transportar cantidades medidas o calculadas en JSON: una unidad canónica por tipo de cantidad, la unidad en el nombre del campo para campos de unidad fija y un objeto valor-más-unidad con un código de unidad controlado para campos de unidad mixta, la precisión indicada de forma explícita en lugar de mediante el número de dígitos, y cadenas donde importan los decimales exactos.
Legible por máquina: JSON