Tema: standards
-
Números de telefone E.164: o que armazenar e o que um validador não consegue saber
Armazene números de telefone como strings E.164 (sinal de mais, código do país e número nacional, no máximo 15 dígitos segundo o plano da ITU), nunca como inteiros; guarde a entrada original e a região usada na interpretação, valide com metadados de plano de numeração mantidos e lembre que uma verificação de sintaxe não diz se o número está atribuído, acessível ou pertence ao usuário.
-
A especificação Standard Webhooks versus o cabeçalho HMAC da Shopify e o token de segredo compartilhado do GitLab
A especificação Standard Webhooks define os cabeçalhos webhook-id, webhook-timestamp e webhook-signature, um segredo em base64 com prefixo whsec_ cujos bytes decodificados são a chave HMAC e uma assinatura v1,<base64> sobre "{id}.{timestamp}.{payload}"; os tokens de assinatura do GitLab (GitLab 19.0, disponibilidade geral na 19.1) seguem exatamente esse modelo. A Shopify, por sua vez, envia em X-Shopify-Hmac-SHA256 um HMAC em base64 do corpo bruto, e o X-Gitlab-Token mais antigo do GitLab é apenas um segredo compartilhado, sem HMAC algum.
-
Noções básicas de vCard 4.0: o formato text/vcard para troca de contatos
Um vCard é um documento text/vcard em UTF-8 com BEGIN:VCARD, VERSION:4.0, um FN obrigatório e propriedades estruturadas opcionais (N, TEL, EMAIL, ADR, UID, REV) com parâmetros; os valores escapam vírgulas, pontos e vírgulas e barras invertidas, e as linhas de conteúdo são dobradas em no máximo 75 octetos. O jCard (RFC 7095) transporta o mesmo modelo em JSON.
-
Cabeçalhos List-Unsubscribe e cancelamento de inscrição com um clique (RFC 2369 e RFC 8058)
Os cabeçalhos da RFC 2369 permitem que clientes de e-mail ofereçam ações de lista; o modo de um clique da RFC 8058 acrescenta um URI HTTPS em List-Unsubscribe e List-Unsubscribe-Post: List-Unsubscribe=One-Click, processado por um HTTPS POST sem redirecionamento nem etapas adicionais, com ambos os cabeçalhos cobertos por DKIM. As diretrizes do Google exigem esse suporte de quem envia e-mail em massa.
-
XML hoje: bem formado versus válido, namespaces e quando ainda é a escolha certa
Um documento XML bem formado respeita a sintaxe; um documento válido também satisfaz um DTD ou schema. Os namespaces dão a cada elemento e atributo um nome expandido, formado pela URI do namespace mais o nome local, associado por declarações xmlns cujos prefixos são arbitrários e cuja forma padrão não se aplica a atributos. O XML continua a ser a escolha certa para documentos de conteúdo misto e para ecossistemas cujos vocabulários e ferramentas já são XML.
-
Códigos de país e de moeda em dados: ISO 3166-1 e ISO 4217 sem surpresas
Armazene países como códigos ISO 3166-1 alpha-2 e moedas como códigos ISO 4217 alpha-3, junto com o expoente da unidade menor. Mantenha as tabelas de códigos versionadas, porque as entradas mudam, e nunca derive um código do outro: um país não tem um único idioma nem uma única moeda, e códigos como UK ou XXX são armadilhas.
-
Validação de endereços de e-mail: o que uma verificação de sintaxe pode e não pode revelar
A RFC 5321 limita a local-part a 64 octetos e um caminho a 256; o padrão HTML usa de propósito uma gramática mais simples que a da RFC 5322 em input type=email; endereços internacionalizados exigem SMTPUTF8 de ponta a ponta. Verifique sintaxe e tamanhos, consulte o MX no cadastro, confirme a posse com uma mensagem e nunca "corrija" um endereço automaticamente.
-
Dígitos verificadores: o que Luhn, ISBN-13 e IBAN mod 97 detectam e o que não detectam
Um dígito verificador é uma redundância calculada a partir dos demais caracteres de um identificador, para que um erro de cópia seja detectado antes da consulta: o Luhn (mod 10 com dígitos duplicados alternadamente) protege números de cartão, o ISBN-13 usa pesos alternados 1 e 3, e o IBAN usa o ISO/IEC 7064 MOD 97-10 com dois dígitos. Detectam erros de um único caractere e a maioria das trocas de dígitos adjacentes, mas nunca um identificador errado que seja válido.
-
GeoJSON e coordenadas geográficas: longitude primeiro, WGS 84 e a regra da mão direita
A RFC 7946 define as posições GeoJSON como [longitude, latitude, elevação opcional] em graus decimais WGS 84, envolve as geometrias em objetos Feature e FeatureCollection com um membro properties, exige anéis de polígono fechados com anel exterior em sentido anti-horário, recomenda dividir as geometrias no antimeridiano e declara que o número de casas decimais não indica incerteza.
-
RateLimit e RateLimit-Policy versus X-RateLimit-*: como ler os cabeçalhos de cota que uma API envia
Um Internet-Draft do IETF (draft-ietf-httpapi-ratelimit-headers-11, maio de 2026) propõe os campos RateLimit e RateLimit-Policy (por exemplo, RateLimit: "default";r=50;t=30) para informar a cota antes de um 429, mas continua sendo um rascunho. A maioria das APIs hoje envia cabeçalhos próprios no estilo x-ratelimit-limit/-remaining/-reset ou nada além de Retry-After, que o RFC 9110 define (segundos ou HTTP-date) e o RFC 6585 permite em respostas 429.
Legível por máquina: JSON