Do bit ao significado
Este capítulo mostra por que computadores não recebem “dados puros”: recebem bits e bytes cujo significado depende de acordos. Um cadastro de ordem de serviço conduz a explicação de Unicode, UTF-8, tipos, JSON, CSV, serialização, schema, precisão decimal, datas, valores ausentes, qualidade e proveniência. O leitor executa um exemplo Python que preserva dinheiro e distingue campo ausente de nulo, acompanha a evolução segura de um contrato e aprende a diagnosticar texto corrompido, arredondamento e incompatibilidade entre versões. Segurança, privacidade e integridade aparecem como propriedades de todo o caminho, da coleta à restauração, e não como acabamento aplicado ao arquivo final.
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
0e1. - 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.
Ler o fluxo em texto
- 1. Evento do mundo real
- 2. Modelo e unidades
- 3. Schema e restrições
- 4. Serialização em formato
- 5. Codificação em bytes
- 6. Transporte ou armazenamento
- 7. Decodificação e validação
- 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:
- Expandir: leitores aceitam os dois formatos; produtores mantêm o antigo e acrescentam o novo.
- Migrar: registros são preenchidos, resultados reconciliados e divergências corrigidas.
- 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
- Unicode Standard: repertório e codificação de caracteres.
- RFC 8259 — JSON: especificação do formato de intercâmbio.
- RFC 4180 — CSV: formato informativo amplamente usado para CSV.
- JSON Schema Draft 2020-12: vocabulários e metaschema atuais dessa edição.
- Python —
decimal: aritmética decimal usada no exemplo.
Comprove o que você aprendeu
Responda todas as questões. O gabarito comentado só aparece depois do envio.