Do bit ao significado

Situação concreta: uma ordem correta que chega errada

Uma equipe registra no sistema de manutenção o equipamento “Bomba de recalque — São José”, custo estimado de R$ 10,50 e abertura às 14h30 de Fortaleza. No sistema integrado, o nome aparece como São José, o custo vira 10.499999 e o horário é interpretado como 14h30 em outro fuso. Nenhum cabo “mudou a informação” sozinho. Cada componente aplicou um acordo diferente aos mesmos bytes ou recebeu um contrato incompleto.

Um computador armazena estados; pessoas atribuem significado. Para preservar o significado, emissor e receptor precisam concordar sobre codificação, formato, tipos, unidades, fuso, campos obrigatórios e versões. Este capítulo constrói esses acordos passo a passo.

Pré-requisitos e objetivos

Você precisa saber que arquivos contêm bytes e que processos leem e escrevem esses arquivos. Não precisa conhecer banco de dados. Ao final, deverá explicar por que “o arquivo abriu” não prova correção, executar uma serialização simples, distinguir ausência de nulo e planejar uma mudança de schema sem quebrar consumidores.

Vocabulário essencial

  • Bit representa dois estados, escritos convencionalmente como 0 e 1.
  • Byte costuma agrupar oito bits. Um byte pode representar 256 combinações, mas não possui significado universal.
  • Unicode atribui números chamados pontos de código a caracteres de muitos sistemas de escrita.
  • UTF-8 transforma esses pontos de código em sequências de um a quatro bytes.
  • Codificação define como uma informação, como texto, vira bytes e volta.
  • Serialização transforma uma estrutura de memória em uma representação armazenável ou transmissível.
  • JSON, JavaScript Object Notation, é um formato textual para objetos, listas, strings, números, booleanos e nulo.
  • CSV, comma-separated values, é uma família de convenções para dados tabulares separados por delimitadores.
  • Schema descreve estrutura, tipos, obrigatoriedade e restrições esperadas.
  • Proveniência registra origem, responsável, momento, finalidade e transformações do dado.
  • Linhagem conecta as etapas pelas quais o dado passou.
  • Checksum é um valor calculado sobre bytes para detectar alterações acidentais.

Modelo mental: caixa, etiqueta e manual

Imagine uma caixa fechada. Os bytes são o conteúdo físico; a codificação diz como ler símbolos; o formato organiza os itens; o schema funciona como o manual que declara campos e regras; o contexto empresarial explica para que servem. Receber a caixa intacta não garante que o destinatário possui o manual correto.

Fluxo: Evento do mundo real, Modelo e unidades, Schema e restrições, Serialização em formato, Codificação em bytes, Transporte ou armazenamento, Decodificação e validação, Decisão do consumidorEvento do mundo realModelo e unidadesSchema e restriçõesSerialização em formatoCodificação em bytesTransporte ouarmazenamentoDecodificação evalidaçãoDecisão do consumidor
Ler o fluxo em texto
  1. 1. Evento do mundo real
  2. 2. Modelo e unidades
  3. 3. Schema e restrições
  4. 4. Serialização em formato
  5. 5. Codificação em bytes
  6. 6. Transporte ou armazenamento
  7. 7. Decodificação e validação
  8. 8. Decisão do consumidor

O modelo é útil para localizar falhas, mas as etapas podem se misturar em bibliotecas. Ele também não garante que o evento foi medido corretamente. Um sensor pode produzir bytes válidos e um número dentro do schema, porém calibrado de forma errada.

Progressão 1 — os mesmos bytes, leituras diferentes

O caractere A ocupa um byte em UTF-8; ç ocupa dois; muitos emojis ocupam quatro. Contar caracteres não equivale a contar bytes. Se um programa grava UTF-8 e outro interpreta como uma codificação incompatível, surge mojibake, o texto aparentemente embaralhado. Tentar “corrigir” substituindo caracteres pode destruir a evidência; primeiro descubra bytes originais e codificação usada em cada fronteira.

Unicode também admite sequências diferentes que parecem o mesmo texto, como letra e acento combinados. Comparação de identidade pode exigir normalização explícita, mas normalizar nomes sem regra empresarial pode fundir valores distintos. Codificação resolve representação de caracteres; não resolve significado cultural, ordenação ou identidade.

Progressão 2 — formato não é schema

Um JSON sintaticamente válido pode ser inadequado:

{
  "schemaVersion": 1,
  "ordemId": "OS-1842",
  "abertaEm": "2026-08-02T14:30:00-03:00",
  "custoCentavos": 1050,
  "status": "aberta"
}

O formato informa onde começam strings e números. O schema precisa dizer que ordemId é obrigatório e textual, custoCentavos é inteiro não negativo, status pertence a um conjunto e abertaEm inclui deslocamento de fuso. JSON não possui um tipo nativo “data” nem “dinheiro”; esses conceitos são convenções do domínio.

CSV também precisa de contrato. Vírgula pode ser delimitador ou parte do valor; aspas e quebras de linha têm regras; uma planilha pode remover zeros à esquerda de 00123. O arquivo continua “abrindo”, mas o identificador mudou. Escolha formato conforme estrutura e consumidor, não pela aparência simples.

Progressão 3 — precisão, unidade e tempo

Números de ponto flutuante binário representam exatamente alguns valores e aproximam outros. Isso é adequado para muitas medições, mas operações financeiras exigem regra de precisão e arredondamento. Guardar R$ 10,50 como 1050 centavos preserva unidade inteira para real brasileiro, cujo código ISO é BRL; operações com várias moedas exigem código de moeda e conhecimento das unidades menores.

Datas precisam de instante, fuso ou intenção. 2026-08-02 pode representar uma data civil; 2026-08-02T14:30:00-03:00 inclui deslocamento; um agendamento “todo dia às 8h em Fortaleza” não deve ser reduzido apenas a um instante fixo. Declare o significado.

Identificadores como número patrimonial são rótulos, mesmo quando contêm dígitos. Somar, arredondar ou remover zeros deles não faz sentido. Tipos expressam operações permitidas, não somente aparência.

Progressão 4 — ausente, nulo, vazio e zero

Um campo ausente pode significar “produtor antigo não envia”. null pode significar “conhecido como inexistente”; string vazia, “formulário enviou sem conteúdo”; zero é um valor. Juntá-los perde informação.

Para qualidade, uma taxonomia mais rica pode distinguir não coletado, não aplicável, desconhecido, recusado e erro de sensor. Em análise, remover linhas altera a população; preencher um valor inventa uma hipótese. Registre essa transformação para que decisões posteriores não tratem imputação como observação.

Progressão 5 — qualidade e proveniência

Qualidade sempre depende do uso. Completude pergunta se valores necessários existem; validade, se obedecem regras; unicidade, se entidades não se repetem; consistência, se fontes concordam; atualidade, se o dado ainda representa o mundo; representatividade, se grupos e situações relevantes aparecem.

Proveniência responde quem coletou, quando, por qual método e finalidade. Linhagem registra normalização, união, filtro e cálculo. Dados podem estar formatados e completos, mas refletir processo discriminatório ou finalidade sem base legal. “Limpo” não significa justo, autorizado ou verdadeiro.

Progressão 6 — evolução sem quebra silenciosa

Imagine substituir custoCentavos por {moeda, unidadesMenores}. Publicar apenas o novo formato quebra leitores antigos. Uma migração segura usa expandir–migrar–contrair:

  1. Expandir: leitores aceitam os dois formatos; produtores mantêm o antigo e acrescentam o novo.
  2. Migrar: registros são preenchidos, resultados reconciliados e divergências corrigidas.
  3. Contrair: depois de provar que nenhum consumidor depende do antigo, ele é removido.

Adicionar campo opcional costuma ser compatível; mudar unidade mantendo o mesmo nome é quebra silenciosa. Versione contratos quando o significado muda e publique política para campos desconhecidos.

Antes e agora

Era comum depender da documentação implícita numa planilha ou de conversas entre duas equipes. O consumidor “tentava ler” e descartava linhas inválidas. Hoje, contratos versionados, validação nas fronteiras, restrições no banco, observabilidade e reconciliação automatizam parte do acordo. Ainda assim, schema não substitui dono e finalidade.

Sistemas de IA ampliaram o uso de texto, imagens, tokens, embeddings e dados sintéticos. Essas representações também perdem detalhes. Um embedding preserva relações úteis para busca, não o documento original nem uma prova. A recomendação atual é manter fonte, versão, transformação e avaliação próximas ao resultado derivado.

Exemplo executável, bloco a bloco

Crie representar.py. Primeiro compare ponto flutuante e decimal:

from decimal import Decimal

aproximado = 0.1 + 0.2
exato_no_contrato = Decimal("0.1") + Decimal("0.2")

print("float:", aproximado)
print("decimal:", exato_no_contrato)
assert exato_no_contrato == Decimal("0.3")

Decimal recebe strings para não herdar a aproximação de um float. Isso não elimina decisões: precisão, moeda e arredondamento continuam necessárias.

Agora serialize uma ordem e preserve diferenças de ausência:

import json

ordem = {
    "schemaVersion": 1,
    "ordemId": "OS-1842",
    "custoCentavos": 1050,
    "observacao": None,
}

texto = json.dumps(ordem, ensure_ascii=False)
restaurada = json.loads(texto)

assert "observacao" in restaurada
assert restaurada["observacao"] is None
assert "responsavel" not in restaurada
print(texto.encode("utf-8").hex())

dumps serializa; loads restaura estruturas JSON. O primeiro assert prova presença com nulo; o segundo campo está ausente. hex() torna os bytes visíveis. Execute python representar.py.

Aplicação em manutenção e ERP

O sistema de planejamento de recursos empresariais (ERP, de enterprise resource planning) pode usar NUMOS inteiro enquanto a aplicação usa ordemId textual. Um contrato de integração deve mapear nomes, tipos, unidades, obrigatoriedade e dono. Registre versão do ERP e transformação. Não use descrições livres como chave de junção; prefira identificador estável aprovado.

Ao exportar custos, declare moeda. Ao importar horário, preserve offset e regra de negócio. Reconcilie quantidade, totais e invariantes antes de apagar o lote de origem. Um dashboard elegante sobre dados sem proveniência continua frágil.

Falhas e diagnóstico

  • Texto corrompido: preserve bytes e compare codificação declarada com a usada.
  • Custo divergente: verifique unidade, tipo, arredondamento e transformação.
  • Data deslocada: identifique se valor representa instante ou horário civil e onde o fuso foi perdido.
  • Campo sumiu: compare versões do schema e política de campos desconhecidos.
  • Duplicidade: verifique identidade, concorrência e restrição no armazenamento.
  • Checksum mudou: prova diferença de bytes, não autor nem intenção.

Diagnostique a primeira fronteira onde esperado e observado divergem. Não corrija somente a tela se o dado persistido já está errado.

Segurança, privacidade e integridade

Limite tamanho, profundidade e quantidade de campos antes de analisar payload. Não desserialize objetos executáveis de fonte não confiável. Valores iniciados por =, +, - ou @ podem ser interpretados como fórmula por planilhas; neutralize exportações conforme o consumidor. Valide no servidor, mesmo que a interface já valide.

Classifique sensibilidade, minimize coleta, restrinja acesso e defina retenção. Logs e backups também contêm dados pessoais. Criptografia protege confidencialidade conforme uma ameaça, mas exige gestão de chaves. Checksum detecta alteração acidental; assinatura ou autenticação apropriada é necessária contra adulteração maliciosa.

Exercício guiado

Modele uma leitura de medidor com medidorId, instante, valor, unidade e qualidade. Escreva três valores válidos, um ausente, um impossível e um com unidade diferente. Defina o que pode ser convertido e o que deve ser recusado. Depois transforme um caso em JSON e explique quais tipos do domínio viraram apenas strings ou números.

Desafio e evidência

Evolua a ordem para versão 2 com moeda e unidades menores. Entregue schemas v1/v2, dez casos, estratégia expandir–migrar–contrair e relatório de reconciliação. Outra pessoa deve implementar um leitor usando somente o contrato.

Critérios de aceite:

  • UTF-8 e formato estão declarados;
  • tipos, unidades, obrigatoriedade e ausência têm significado explícito;
  • casos positivos e negativos são executáveis;
  • evolução possui compatibilidade e rollback;
  • origem e transformações são rastreáveis;
  • evidência usa dados sintéticos e não expõe segredos.

Conclusão e transição

Bits viram dados apenas por acordos encadeados. Codificação preserva caracteres; formato organiza; schema restringe; modelo de domínio atribui significado; proveniência sustenta confiança. Feche o capítulo e explique por que JSON não possui “data”, por que null difere de ausente e por que checksum não prova autoria. No laboratório seguinte, você tornará esses limites visíveis em bytes e testes.

Fontes oficiais e primárias

Teste de fixação

Comprove o que você aprendeu

Responda todas as questões. O gabarito comentado só aparece depois do envio.

1. Por que os mesmos bytes podem aparecer como texto corrompido mesmo sem alteração física?
2. Uma API recebe JSON bem formado com `criticidade: 999`, embora o domínio aceite apenas 1 a 5. O que falta?
3. Um dashboard usa dados sem registro de origem, coleta ou transformações. Qual risco permanece mesmo se não houver valores ausentes?

Consulta universal

O que você quer encontrar?

Títulos, capítulos, conceitos, termos, laboratórios e ferramentas em uma única busca.

Digite pelo menos dois caracteres.