Esta página responde às perguntas que surgem com mais frequência quando uma equipa quer integrar EEV num software sem se perder entre o contrato público, as escolhas de arquitetura, a compatibilidade legacy e o lançamento do produto.
Não. Uma primeira versão credível pode focar-se num subconjunto claro, por exemplo a leitura de ENTRY em .eev e .eevz, com validação honesta e um writer canónico limitado aos campos que o software realmente domina. O importante não é cobrir tudo de imediato, mas documentar exatamente o que é suportado.
O ponto de partida mais limpo é a rota textual simples: detetar o contentor, obter o texto bruto, analisar um ENTRY, construir um modelo interno e depois reemitir um texto estável. Compressão e certificação vêm depois como camadas adicionais, não como um segundo núcleo.
Na leitura, o parser pode manter-se tolerante e converter algumas formas legacy para o modelo interno moderno, emitindo avisos. Na escrita, o writer canónico não deve reciclar automaticamente essas formas antigas. Ler de forma ampla e escrever de forma limpa continua a ser a regra mais segura.
Não exatamente. São duas estruturas de contentor da mesma família. ENTRY descreve uma única impressão. LIB acrescenta uma moldura de biblioteca capaz de incluir várias entradas. O ideal é partilhar o máximo possível o tratamento dos blocos internos e depois acrescentar uma camada de biblioteca à volta.
Deve produzir um texto determinístico, ordenado, legível e coerente com a versão do contrato público visada. Duas exportações idênticas devem gerar a mesma saída. Os campos devem aparecer numa ordem estável, com normalização previsível de valores e secções.
Só se o produto realmente precisar delas para inspeção ou ferramentas de diff. Para a lógica principal, é melhor convergir rapidamente para um modelo interno limpo. Apoiar-se demasiado tempo em linhas brutas torna a evolução do parser e do writer muito mais frágil.
Não. A lógica do hash pertence à integridade documental, não ao transporte comprimido. Um ficheiro pode estar comprimido ou não; a questão é quais partes do documento estão protegidas e como verificar que não foram alteradas.
É útil suportar a leitura de ficheiros EEVC ou EEVCZ já emitidos se o seu produto precisar de inspecionar ou verificar material certificado. Este site não documenta a criação local de EEVC; para fluxos de verificação certificada, use eevc.link.
É melhor evitar apresentar o EEV como uma simples “nota enriquecida” ou como uma promessa mágica que, sozinha, diria o que um som “faz”. O formato descreve e estrutura de forma fina um comportamento vibratório; não substitui nem a escuta, nem o julgamento humano, nem os quadros interpretativos.
Não. O site entregue aqui é um site PHP leve com i18n simples. Pode ser copiado diretamente para o alojamento. Não é necessária qualquer base MySQL nem há comandos SQL a executar.
