Resumo

  • O RFC 2083 atribuiu uma propriedade a cada letra do tipo PNG de quatro bytes: crítico/auxiliar, público/privado, reservado e inseguro/seguro para copiar.
  • O quarto bit governava a edição, não a verdade. Depois de mudar dados críticos, um chunk auxiliar desconhecido e inseguro precisava ser descartado; um marcado como seguro podia sobreviver.
  • A permanência do chunk e um CRC correto provavam custódia limitada de bytes, não unicidade do nome privado, validade semântica, autoria, permissão, privacidade ou exatidão da imagem.

Um editor altera a paleta e reescreve IDAT. Entre os chunks conhecidos aparece um tipo que ele nunca viu. O programa lê o comprimento, salta os dados e confere o CRC, mas não sabe se ali há histograma, calibração física, informação de direitos ou estado de um fluxo proprietário. Mesmo assim, precisa decidir se esses bytes pertencem ao novo arquivo.

O RFC 2083 criou uma rota honesta para a ignorância. Cada chunk contém comprimento, tipo de quatro bytes, dados e CRC. Os bytes do tipo usam as faixas de letras ASCII, mas devem ser tratados como valores binários fixos. O teste correto examina o bit 5 de cada byte, sem conversão de caixa dependente de idioma.

Quatro letras, quatro responsabilidades

A primeira letra distingue critical de ancillary. Maiúscula indica que um tipo desconhecido pode carregar informação necessária à interpretação; o decodificador não deve fingir sucesso. Minúscula permite ignorar um tipo auxiliar desconhecido e continuar exibindo a imagem. Auxiliar não é sinônimo de irrelevante: direitos, localização e calibração podem ser importantes para pessoas sem serem necessários para extrair pixels.

A segunda letra divide nomes públicos e privados. Trata-se de organização de namespace, não de autenticação. Uma atribuição pública futura não usará a forma privada, mas duas organizações ainda podem escolher o mesmo nome privado para significados incompatíveis. Por isso o RFC recomendou identificação adicional dentro dos dados privados.

A terceira letra ficou reservada. A versão 1.0 exigia maiúscula, embora orientasse decodificadores antigos a não falhar apenas diante de minúscula, pois uma especificação futura poderia dar significado ao bit.

A quarta letra orienta o editor: minúscula é safe-to-copy; maiúscula é unsafe-to-copy. O exemplo bLOb representa um chunk auxiliar, público, com o bit reservado em zero e seguro para copiar. TEXT e Text são tipos binários diferentes.

Seguro para copiar não era seguro para acreditar

Um chunk auxiliar desconhecido marcado como seguro pode ser copiado mesmo após uma edição ampla. Se estiver marcado como inseguro e o programa adicionar, apagar, modificar ou reordenar chunks críticos, ele não pode ir para a saída. Quando apenas chunks auxiliares mudam, pode ser preservado.

O autor da extensão declara a dependência; o editor sabe o que alterou. A regra também restringe o desenho: chunks auxiliares podem depender dos críticos, mas não deveriam depender uns dos outros. Dependência do datastream inteiro não cabe em um único bit.

A atual Terceira Edição de PNG do W3C mantém essa separação e explicita limites de ordem. Um chunk desconhecido e inseguro não pode mudar de posição em relação aos críticos; mesmo um seguro não pode atravessar livremente a fronteira de IDAT. Safe-to-copy nunca significou safe-to-move.

O CRC fechava uma pergunta sobre bytes, não sobre sentido

O CRC cobre o tipo e os dados de cada chunk e ajuda a detectar corrupção acidental. O RFC chegou a sugerir que um chunk privado guardasse o CRC de PLTE para perceber mudança na paleta da qual dependia.

Uma correspondência não autentica autor nem resolve colisão de nomes privados. Também não prova que uma calibração ainda descreve os pixels editados. Recalcular o CRC após uma alteração mostra apenas que os novos bytes estão coerentes com o algoritmo.

A fronteira aparece em privacidade. A Terceira Edição lembra que algumas ferramentas esconderam pixels apenas com transparência ou mudaram dimensões sem remover dados recuperáveis; eXIf também pode carregar GPS. Aparência limpa não comprova remoção. O bit safe-to-copy tampouco é classificação de privacidade: declara apenas dependência em relação aos dados críticos.

Compatibilidade por função, não por número global

O RFC 2083 omitiu deliberadamente um version number geral. Um número alto faria leitores antigos rejeitarem arquivos que não usavam nenhuma função crítica desconhecida e nada diria sobre extensões privadas.

Uma função auxiliar desconhecida podia ser ignorada; uma crítica desconhecida interrompia o processo. A compatibilidade era decidida pelos recursos presentes. O documento de extensões PNG do W3C continua listando chunks públicos adicionais separadamente. Registro, reconhecimento e compreensão são fatos diferentes.

O texto posterior de Lu Heng sobre especificação inicial mínima e decisão futura localizada oferece uma lente retrospectiva: uma gramática comum estreita deixou decisões futuras com o software em execução. Não implica influência de 2026 sobre o RFC de 1997.

A distinção entre camadas de realidade e poder simbólico ajuda a nomear a prova. O bit, a classe da alteração e a ação copiar/remover são executáveis. “Oficial”, “verdadeiro”, “autorizado” e “confiável” exigem evidência adicional.

Uma auditoria deve reter hash de entrada, inventário ordenado, bytes dos tipos, quatro propriedades, CRCs, tipos conhecidos pela ferramenta, mudanças críticas e auxiliares, decisão para cada desconhecido, ordem e hash de saída. Se metadados sustentam uma afirmação pública, precisam ainda de esquema, controlador do namespace, procedência e razão para continuarem aplicáveis.

A quarta letra não certificava metadados. Ela atribuía a responsabilidade pela decisão.

Fontes