Guia técnico

1 Introdução

nikpak é um compactador de linha de comando para o formato .nik. Ele foi projetado em torno de quatro ideias: compactar melhor do que as ferramentas consolidadas, fazer isso mais rápido, proteger os dados com criptografia moderna e rodar sem alterações no Windows, macOS e Linux como um único executável pequeno.

1.1 Objetivos de design

• Pequeno. Supera o RAR 7 nos dados que as pessoas de fato compactam em volume. Áudio, imagens e música de tracker são detectados pelo conteúdo e compactados com codecs sem perdas especializados; todo o resto usa um fluxo Zstandard multithread e ajustado.
• Rápido. A compactação e a extração devem ser limitadas pelo disco, não pela CPU. No nível rápido -m2, o nikpak compacta cerca de 200 MB de arquivos-fonte em menos de um segundo em um único núcleo.
• Seguro. Criptografia autenticada com uma função de derivação de chave que exige muita memória, nomes de arquivo sempre ocultos, adulterações sempre detectadas e um extrator que não pode ser enganado para gravar fora da pasta de destino.
• Resistente a computadores quânticos. Apenas criptografia simétrica de 256 bits é usada. Não há nenhum código RSA, de curvas elípticas nem Diffie-Hellman em lugar algum do nikpak, então não há nada que o algoritmo de Shor possa quebrar.
• Portátil e automatizável. Um único executável vinculado estaticamente, linha de comando compatível com RAR, códigos de saída previsíveis e um -help que documenta todas as opções.

1.2 Resultados em resumo

Medida	Resultado	Comparado com
Fotografias BMP	38.8 % menor	RAR 7.00 -m5
Música estéreo, 44.1 kHz 16-bit	14.6 % menor (equivalente ao FLAC -8)	RAR 7.00 -m5
Arquivos MOD do ProTracker	13.3 % menor	RAR 7.00 -m5
Áudio mono, 8-bit e 16-bit	12.2 % e 15.3 % menor	RAR 7.00 -m5
197 MB de arquivos-fonte, nível máximo	5.5 % menor (24.4 MB vs 25.9 MB)	RAR 7.00 -m5 -s -md256m
Mesmos dados, nível rápido -m2	0.9 s	RAR 7.00 -m3 sólido: 16.7 s
Criptografia	Argon2id + XChaCha20-Poly1305	RAR5: AES-256-CBC + PBKDF2
Todos os 10 conjuntos de teste, nível máximo, vs 7-Zip	2.4 a 31.7 % menor	7-Zip 23.01 -mx9 (seção 11.7)
Arquivos de escritório (doc, docx, xls, xlsx, csv, pdf)	31.7 % menor	7-Zip 23.01 -mx9 (seção 11.7)
Todos os 10 conjuntos de teste, nível máximo, vs ZIP	19.9 a 60.4 % menor	ZIP -9, Info-ZIP 3.0 (seção 11.7)
Executável	um arquivo, sem dependências; cerca de 9 MB com a janela, 2.3 MB somente linha de comando	Windows, macOS, Linux

Como os números foram obtidos Todas as medições vêm de uma única máquina (máquina virtual Linux x86-64, um núcleo de CPU) com RAR 7.00 e nikpak 1.1.0. Todos os arquivos compactados foram extraídos novamente e comparados com o original byte a byte. O método completo, os corpora e os casos em que o RAR é mais rápido são descritos no capítulo 11.

1.3 A quem se destina?

O nikpak é voltado para pessoas que compactam grandes quantidades de mídia ou código-fonte e se importam com tamanho e velocidade, para desenvolvedores que querem um compactador automatizável com códigos de saída sensatos e um formato documentado, e para qualquer pessoa que precise de criptografia forte sem confiar em uma implementação fechada. Como a linha de comando segue as convenções do RAR, front-ends como o Total Commander podem acioná-lo com pouca ou nenhuma reconfiguração.

1.4 Como ler este guia

Os capítulos 2 e 3 descrevem o que o nikpak faz e como usá-lo. Os capítulos 4 a 7 explicam a arquitetura, o formato de arquivo, o motor de compactação e os codecs de mídia. Os capítulos 8 a 10 tratam de criptografia, resistência quântica e robustecimento. O capítulo 11 apresenta os benchmarks, o capítulo 12 compara o nikpak com o RAR com honestidade, e os capítulos 13 a 15 tratam de compilação, testes e do roteiro.

1.5 Comunidade e contato

Novidades, dúvidas, ideias e relatos de bugs: o autor do nikpak pode ser contatado em

• Telegramhttps://t.me/cryptonikko
• Xhttps://x.com/cryptonikkoid
• Discordhttps://discord.com/users/1537826350759415811

Os mesmos três links são mostrados como botões redondos e coloridos na parte inferior da janela do nikpak, sob a pasta de destino (seção 3.7), e no final do nikpak -help.

2 Visão geral dos recursos

2.1 Capacidades

Área	O que o nikpak oferece
Compactação	Zstandard (multithread, sólido) de -m1 a -m4, com uma janela de 128 MiB e casamento de longa distância no -m4. No -m5, um corpo multi-motor: LZMA2 para dados binários e PPMd para texto, escolhidos por teste; arquivos ordenados por tipo como no 7-Zip.
Inteligência de mídia	Detecção por conteúdo de WAV, AIFF, MOD do ProTracker e BMP; teste por arquivo entre quatro filtros (NAC, Shuffle, Shuffle+Delta, MED); fallback automático para compactação simples.
Office, PDF, gzip	Recompactação Deflate (preflate): os fluxos Deflate dentro de arquivos docx, xlsx, pptx, odt, ods, epub, jar, zip, pdf e gz são decodificados, compactados muito melhor e reconstruídos bit a bit na extração (-m4, -m5).
Criptografia	Derivação de chave Argon2id (64 MiB), XChaCha20-Poly1305 em blocos autenticados de 64 KiB; nomes, tamanhos, datas e permissões são criptografados.
Senhas	Solicitação interativa com confirmação, variável de ambiente, stdin, linha de comando; geração automática de uma senha aleatória forte quando nenhuma é fornecida.
Integridade	CRC32 dos bytes originais de cada arquivo; autenticação AEAD para arquivos criptografados; marcador de fim com a contagem de entradas; codec de áudio autoverificador.
Linha de comando	Comandos no estilo RAR (a x e l v lb t p d), extração de arquivos individuais, pastas ou curingas, além de opções, apelidos no estilo zip, curingas, @listfiles, exclusões, políticas de sobrescrita, modo silencioso e códigos de saída explícitos.
Segurança	Proteção contra zip slip, recusa de links simbólicos, remoção do setuid, decodificadores limitados, gravações atômicas do arquivo compactado, segurança de memória do Rust.
Portabilidade	Windows (PowerShell, cmd), macOS, Linux; um único executável estático; resultados byte a byte idênticos em todas as plataformas.
Interface gráfica	Iniciado sem argumentos, o nikpak abre uma janela minimalista de arrastar e soltar: solte (ou escolha) arquivos ou pastas para compactá-los com a melhor compactação; anel de progresso, pasta de destino lembrada (seção 3.7).
Navegador de arquivos compactados	unNik.exe, gratuito para todos: navegue por pastas, pesquise, visualize arquivos de texto e binários, extraia uma seleção e exclua arquivos de pacotes .nik (seção 3.9).
Skins	55 skins de janela, incluindo 14 skins de cenas pintadas; uma caixa de skins que fica ao lado da janela com Aplicar skin e Cancelar; importe seus próprios arquivos .skin.json do Nikkomander (seção 3.10).
Menu do gerenciador de arquivos	Um submenu “NikPak” no Explorer, Dolphin, Nemo, Nautilus e Finder: Adicionar ao arquivo, Extrair aqui, Extrair para sua própria pasta, Abrir com o unNik; um único arquivo para uma seleção de vários itens (seção 3.11).

2.2 nikpak e RAR lado a lado

A tabela abaixo compara o nikpak 1.1 com o RAR 7 conforme medido neste projeto e declara claramente onde o RAR está à frente. O capítulo 12 discute cada ponto.

	nikpak 1.1	RAR 7
Compactação de mídia	Codecs sem perdas especializados escolhidos por arquivo por teste	Algoritmo geral com filtros embutidos
Código-fonte, nível máximo	24.4 MB (menor), 45.6 s	25.9 MB, 26.7 - 36.2 s
Velocidade em níveis rápidos	0.9 s para 197 MB (-m2)	9.7 - 16.7 s (-m3)
Criptografia	Argon2id + XChaCha20-Poly1305 (autenticado)	AES-256-CBC + PBKDF2-HMAC-SHA256
Nomes de arquivo sempre criptografados	Sim	Somente com -hp
Hash de senha que exige muita memória	Sim (64 MiB)	Não
Gerador de senha aleatória	Embutido	Não embutido
Código-fonte, linguagem	Código-fonte completo, Rust (seguro em memória)	Proprietário, C++
Registros de recuperação, volumes, SFX, atualização no lugar	Ainda não	Sim (WinRAR)
Histórico	Novo, ainda não auditado	Décadas

3 Referência da linha de comando

O nikpak segue a sintaxe que os usuários de RAR conhecem: nikpak [options] [files...]. As opções podem aparecer em qualquer lugar, antes do nome do arquivo ou depois dele; -- encerra a análise das opções.

3.1 Comandos

Comando	Significado
a	Cria um novo arquivo compactado. .nik é acrescentado quando o nome não tem extensão. As pastas são sempre percorridas recursivamente.
x	Extrai com caminhos completos: tudo, ou apenas os nomes, pastas e curingas fornecidos depois do nome do arquivo (nikpak x backup.nik Docs/report.pdf extrai um arquivo). Um separador de caminho no final (ou -d dir) seleciona o destino.
e	Extrai sem caminhos: cada arquivo vai direto para a pasta de destino.
l	Lista o conteúdo (tudo, ou apenas os nomes correspondentes): atributos, tamanho, data (UTC), nome, totais.
v	Lista detalhada: acrescenta o CRC32 de cada arquivo.
lb	Lista simples: um nome por linha, pensada para scripts e front-ends de interface gráfica.
t	Teste: descompacta tudo, verifica todos os CRC32 e, para arquivos criptografados, verifica a autenticação.
p	Imprime arquivos na saída padrão: todos eles, ou os nomeados (nikpak p notes.nik todo.txt | more).
d	Exclui arquivos ou pastas (uma pasta leva junto seu conteúdo) de um arquivo compactado. O arquivo é gravado novamente sem eles; arquivos criptografados mantêm sua senha. Os nomes são obrigatórios.
mt	Teste de mídia: detecta arquivos WAV/AIFF/MOD/BMP e mostra o tamanho que cada filtro de mídia alcança. Não grava nada.
(none)	Iniciado sem nenhum argumento (por exemplo, com um duplo clique em nikpak.exe), o nikpak abre sua janela em vez disso (seção 3.7).

3.2 Opções

Estilo RAR	estilo zip	Significado
-p	-e	Criptografa / descriptografa, pede a senha. Uma entrada vazia gera uma senha aleatória e a exibe.
-p	-P	Senha na linha de comando (visível para outros usuários da máquina).
-hp[password]		Igual a -p. Os nomes de arquivo são sempre criptografados no nikpak.
-m0 .. -m5	-0 .. -9	Armazenar, o mais rápido, rápido, bom, alto (adiciona recompactação Deflate), máximo (o padrão desde a 1.2.1; LZMA2/PPMd, seção 6.7). Use -m2 quando a velocidade importar mais que o tamanho.
-mt		Número de threads, de 1 a 256 (padrão: todos os núcleos).
-mc- / -mc+		Todos os filtros de conteúdo (codecs de mídia e recompactação Deflate) desligados / filtros de mídia sempre ligados. Padrão: teste automático por arquivo.
-r		Percorre pastas recursivamente (sempre ativo, aceito por compatibilidade).
-ep	-j	Armazena apenas o último componente do caminho de cada argumento.
-ep1		Não armazena o nome da pasta base de um argumento de pasta.
-o+	-o	Sobrescreve arquivos existentes sem perguntar.
-o-	-n	Ignora arquivos existentes sem perguntar.
-or		Renomeia arquivos extraídos que já existem: name (1).ext.
-y		Responde Sim a todas as perguntas.
-x	-x	Exclui arquivos; pode ser repetida.
-d	-d	Pasta de destino para x e e.
-inul -idq	-q	Silencioso: apenas os erros são impressos.
@listfile		Lê nomes de arquivo de um arquivo de texto, um por linha.
-h -help -?		Ajuda completa. -V imprime a versão.

Opções que os front-ends de RAR costumam enviar, mas que não têm significado aqui (-s, -ma5, -md64m, -ibck, -idp, -rr, -ts*, -w e similares), são aceitas e ignoradas, para que as configurações existentes de ferramentas continuem funcionando. Qualquer outra coisa produz uma mensagem de erro clara e o código de saída 7.

O menu do gerenciador de arquivos adiciona algumas opções longas (seção 3.11): nikpak --add e --add-here compactam os itens fornecidos em um novo arquivo compactado, nikpak --install-menu e --uninstall-menu adicionam ou removem o menu de clique direito (--all-users para uma instalação para todos os usuários), e unNik --extract, --extract-here e --extract-to acionam a extração a partir do menu.

3.3 Senhas em detalhes

Quando um arquivo compactado é criado com -p, o nikpak resolve a senha nesta ordem e nunca falha apenas porque nenhuma foi fornecida:

• -p ou -P na linha de comando: usada como está (mínimo de 8 caracteres).
• A variável de ambiente NIKPAK_PASSWORD, que mantém a senha fora da lista de processos.
• Uma solicitação interativa, pedida duas vezes para confirmação. Uma entrada vazia gera uma senha aleatória.
• Sem um terminal (por exemplo, dentro de uma interface gráfica), uma senha enviada pelo stdin; se não houver nenhuma, uma senha aleatória é gerada.

Uma senha gerada tem 24 caracteres de um alfabeto de 56 símbolos sem ambiguidade (sem 0/O, 1/l/I), cerca de 139 bits de entropia. Ela é impressa uma vez em uma caixa no console. Não há recuperação: um arquivo compactado cuja senha foi perdida não pode ser aberto por ninguém.

Ao abrir um arquivo compactado criptografado, o nikpak usa as mesmas fontes e então falha com o código de saída 11 e uma mensagem explicativa; ele nunca gera nada, porque uma senha gerada não poderia corresponder.

3.4 Códigos de saída

Código	Significado	Causa típica
0	Sucesso
1	Aviso	Alguns arquivos foram ignorados (ilegíveis, caminho inseguro, link simbólico)
2	Erro fatal	Não é possível criar ou ler um arquivo, erro interno
3	Arquivo corrompido ou erro de CRC	Arquivo danificado ou truncado, soma de verificação falhou
7	Erro de linha de comando	Opção desconhecida, nome do arquivo ausente
10	Nada correspondeu	Nenhum arquivo correspondeu aos nomes ou curingas
11	Senha errada ou ausente	Senha incorreta, ou um arquivo compactado criptografado adulterado

3.5 Exemplos

nikpak a backup.nik C:\Docs\*.txt Photos\ # create an archive

nikpak a -m5 -mt8 big.nik Projects\ # maximum, 8 threads

nikpak a -p secret.nik Taxes2026\ # encrypted, prompts

nikpak a -pMyLongPassw0rd s.nik f.pdf # password given

nikpak x backup.nik C:\Restore\ # extract with paths

nikpak e backup.nik *.jpg C:\Pics\ # only *.jpg, flat

nikpak x backup.nik Docs/report.pdf # extract ONE file

nikpak e backup.nik Docs/report.pdf -d C:\Out # one file, no path

nikpak x backup.nik Photos -d C:\Restore # one folder

nikpak l backup.nik *.pdf # list only PDFs

nikpak p backup.nik notes.txt # show a file

nikpak d backup.nik Temp *.bak # delete entries

nikpak l backup.nik # list

nikpak t secret.nik # test (asks password)

nikpak mt song.wav tracker.mod photo.bmp # which filter wins?

3.6 Integração com o Total Commander e outros front-ends

Como o nikpak aceita a sintaxe de comando do RAR (a, x, e, l, t, @listfile, -p, -ep1, -o+, -y, -m), um programa que consegue acionar um rar.exe externo consegue acionar o nikpak.exe. No Total Commander, registre a extensão nik em Configuration, Packer, Additional packer programs e aponte os comandos de empacotar e desempacotar para nikpak.exe. Use -o+ ou -y para extração sem supervisão, porque sem um console o nikpak não pode perguntar se deve sobrescrever e, em vez disso, ignorará os arquivos existentes. Os nomes dos menus variam entre as versões do Total Commander; consulte a ajuda embutida dele para saber os campos exatos.

Pastas com espaços no Windows Um caminho entre aspas que termina em barra invertida, como "C:\My Folder\", é interpretado incorretamente pelo Windows (a aspa final é tratada como escapada). Para destinos com espaços, use -d "C:\My Folder".

3.7 A interface gráfica

O nikpak iniciado sem argumentos, por exemplo com um duplo clique em nikpak.exe, abre uma pequena janela em vez de imprimir a ajuda de uso. Ele faz uma única coisa: compacta o que você soltar nele.

• Solte um arquivo ou uma pasta, ou vários de uma vez, na janela, ou clique no círculo (ou nos links escolher arquivos / escolher uma pasta) para selecioná-los em um diálogo; clicar no círculo mostra os dois botões Escolher arquivos e Escolher uma pasta dentro do anel. Eles são compactados com a melhor compactação (-m5) em um único arquivo nomeado a partir do arquivo (sem a extensão), da pasta ou, para vários itens, da pasta de onde vieram. Um arquivo existente nunca é sobrescrito: report.nik vira report (2).nik.
• O progresso é mostrado como uma grande porcentagem dentro de um medidor circular, com a fase (analisando, compactando, finalizando), a quantidade processada e o tempo. O botão Cancelar abaixo dele (ou a tecla Esc) interrompe imediatamente uma compactação longa e remove o arquivo inacabado; a janela permanece aberta para o próximo. Fechar a janela durante uma compactação faz o mesmo.
• Concluído: o anel fica verde e mostra o nome do arquivo, o tamanho dele em relação ao original e o tempo. Mostrar na pasta abre-o no Explorer, Finder ou no gerenciador de arquivos; Compactar mais (ou um clique no círculo) inicia o próximo.
• Salvar em: a pasta de destino na parte inferior pode ser digitada ou escolhida com Procurar. Ela é lembrada para a próxima vez (Windows: %APPDATA%\nikpak\settings.txt; macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak). Na primeira vez, é a Área de trabalho.
• Comunidade: os três botões redondos no canto inferior direito abrem as páginas de Telegram, X e Discord do nikpak (seção 1.5).
• Mudar para o unNik: o botão redondo com uma seta para cima, à esquerda do botão i, fecha o NikPak e inicia o unNik (seção 3.9). Após uma compactação, ele e o link Abrir no unNik na tela de conclusão abrem o novo arquivo imediatamente. O botão fica desabilitado durante a compactação.
• Abrir a pasta de destino: o botão de pasta entre o campo Salvar em e Procurar abre essa pasta no Explorer ou no Finder; após uma compactação, ele a abre com o novo arquivo selecionado.
• Sons: um clique suave para botões, links e opções, e um som curto para cada ação (início do trabalho, sucesso, erro, cancelamento, troca de programa, arquivos pairando sobre a janela). Eles são gerados pelo próprio programa, sem arquivos de som. O botão de alto-falante na barra de título os liga e desliga; eles ficam ligados por padrão, e a escolha é compartilhada com o unNik.
• Idioma: o botão no canto inferior esquerdo, com uma bandeira e o nome do idioma no próprio idioma, abre um menu com os dez idiomas mais falados do mundo (Ethnologue 2025): English, 中文 (chinês mandarim), हिन्दी (hindi), Español, العربية (árabe), Français, বাংলা (bengali), Português, Русский (russo) e Bahasa Indonesia. Escolher um deles salva a escolha e reinicia o nikpak nesse idioma. Na primeira vez, o nikpak segue o idioma do Windows (ou do sistema); caso contrário, usa o inglês. A linha de comando permanece em inglês.
• Executando como administrador: o Windows não permite arrastar arquivos do Explorer para um programa executado como administrador. Quando o nikpak.exe é iniciado como administrador (por exemplo, de um PowerShell de administrador), ele se reinicia uma vez como usuário normal por meio do Explorer para que o arrastar e soltar funcione. Se isso não for possível, a janela mostra um aviso; escolha os arquivos com os botões.
• Status e Sobre: o canto superior esquerdo mostra EVALUATION COPY · REGISTER (um clique abre a caixa de registro) ou REGISTERED TO e o titular da licença. O pequeno botão i no canto superior direito, ao lado de minimizar e fechar, abre a caixa Sobre: versão, © 2026 Nicolas Choukroun, distribuído pela Nikkoid LLC, o status da licença, o site e os termos da licença (LICENSE.txt).

A janela mede 500 × 560 pontos (cerca de 9:10), de modo que uma captura de tela da janela inteira cabe em uma postagem de imagem do X (Twitter) sem cortes. Ela é sem moldura: arraste-a pela área superior; os botões no canto superior direito abrem a caixa Sobre, minimizam e a fecham. Quando o nikpak.exe é iniciado pelo Explorer, a janela de console que o Windows abre para ele é fechada automaticamente; iniciado a partir de um prompt de comando, o prompt é deixado em paz. Sem um display gráfico (por exemplo, via SSH), o nikpak imprime a ajuda de uso como antes. A interface usa egui/eframe e incorpora subconjuntos das fontes Inter, Noto Sans SC, Noto Sans Devanagari, Noto Sans Bengali e Noto Sans Arabic (SIL Open Font License, veja assets/fonts/OFL.txt). Um executável somente de linha de comando é compilado com cargo build --release --no-default-features.

Hindi, bengali e árabe precisam de conformação (shaping): as letras mudam de forma e se unem, os sinais vocálicos se movem em torno da consoante, e o árabe corre da direita para a esquerda. O egui desenha um glifo por caractere, o que imprimiria esses idiomas de forma errada, então o nikpak ordena esses textos com o algoritmo bidirecional Unicode (unicode-bidi), conforma-os com rustybuzz (uma versão Rust do HarfBuzz), rasteriza-os com ab_glyph e pinta o resultado como uma imagem (textshape.rs). Palavras e números latinos dentro deles mantêm a fonte Inter. Traduções longas são reduzidas para caber nos botões, e as caixas crescem junto com o texto. As traduções (i18n.rs) foram escritas com auxílio de máquina; uma revisão por falantes nativos é bem-vinda.

3.8 Licença e registro (shareware)

O NikPak é shareware, © 2026 Nicolas Choukroun, distribuído pela Nikkoid LLC, e licenciado como o WinRAR: o mesmo pacote é a cópia de avaliação gratuita e, uma vez inserida uma chave de licença, a versão registrada. Nada é desabilitado na cópia de avaliação.

Quem	Termos
Pessoas físicas	Gratuito para uso pessoal e não comercial, sem limite de tempo. Uma licença pessoal ($19) remove o lembrete; ela cobre todos os computadores usados pelo titular.
Empresas e organizações	Uma licença de empresa por posto (seat), após uma avaliação gratuita de 40 dias; postos são computadores ou usuários, o que for maior. Preços por volume, por posto, modelados no WinRAR: 1–9 postos $19, 10–24 $15, 25–49 $12, 50–99 $9, 100–199 $7, 200–499 $6, 500 ou mais $5.
Distribuição	O pacote não modificado (com LICENSE.txt e THIRD-PARTY-NOTICES.txt) pode ser colocado em qualquer site de shareware ou downloads; adicionar chaves, arquivos de chave ou cracks é proibido. Os arquivos .nik são livres de royalties.

• O lembrete aparece quando uma cópia não registrada abre sua janela. Ele tem dois botões, Registrar e Testar gratuitamente, cuja ordem esquerda/direita muda aleatoriamente a cada inicialização. Testar gratuitamente (ou Esc) fecha-o; o nikpak então funciona sem restrições.
• A caixa de registro pede o nome, o endereço de e-mail e a chave de licença. Os três devem corresponder: a chave é uma assinatura do nome e do e-mail. Maiúsculas/minúsculas, espaços extras e os caracteres parecidos O/0 e I/L/1 não importam. Comprar uma licença abre https://nikpak.nikkoid.com/buy.php.
• Depois de registrado, o nikpak nunca mais pergunta naquele computador para aquele usuário. A licença é armazenada em %APPDATA%\nikpak\license.txt (macOS: ~/Library/Application Support/nikpak; Linux: ~/.config/nikpak). Uma empresa pode, em vez disso, colocar um arquivo nikpak.key ao lado do nikpak.exe, o que registra todos os usuários daquele PC.
• Linha de comando: nikpak register "Jane Doe" jane@example.com NPK1-… registra; nikpak license mostra o status; nikpak unregister remove a licença. nikpak -V e nikpak -help também mostram o status. Cópias não registradas imprimem um aviso de avaliação de uma linha na saída de erro (stderr), nunca na saída padrão; -q o suprime.

Como as chaves funcionam

Uma chave de licença começa com NPK1-, seguida de 108 caracteres em grupos de cinco (Crockford base32). Ela contém o tipo de licença (pessoal ou empresa), o número de postos e uma assinatura Ed25519 de NIKPAK-LICENSE-1, do tipo, dos postos, do nome e do endereço de e-mail, cada um normalizado (espaços reduzidos, minúsculas). O nikpak contém apenas a chave pública de 32 bytes, em src/license_pubkey.rs, então estudar o programa não permite que ninguém crie chaves.

As chaves são criadas com a chave privada, que nunca sai da Nikkoid LLC: ou com a ferramenta privada nikpak-keygen (cargo run --release --features keygen --bin nikpak-keygen -- make --name "Jane Doe" --email jane@example.com; --company --seats 25 para empresas; newkeys cria um novo par de chaves) ou no servidor web com o kit PHP em server/ (PHP 7.2+, MySQL 5.7), que emite uma chave por pagamento e produz exatamente as mesmas chaves. server/README.md descreve a configuração e o fluxo de pagamento.

3.9 unNik, o navegador gratuito de arquivos compactados

unNik (unNik.exe) é o segundo programa do pacote. Ele abre arquivos .nik, mostra o que há dentro e extrai o que você escolher. Ele é gratuito para todos, incluindo empresas, sem registro e sem lembrete (LICENSE.txt, seção 2a). O instalador o instala ao lado do nikpak.exe, adiciona-o ao menu Iniciar e o torna o programa padrão para arquivos .nik, de modo que um duplo clique em um arquivo compactado o abre no unNik; unNik archive.nik faz o mesmo a partir de um prompt de comando.

A janela vazia parece exatamente com a do NikPak, com uma seta para cima no anel. Solte um arquivo .nik nela, clique no anel ou escolha um dos arquivos recentes: a janela cresce para o navegador (1120 × 720, redimensionável pelas bordas, e pode ser maximizada). Arquivos criptografados pedem a senha primeiro.

• Navegue com a árvore de pastas, os breadcrumbs, Voltar, Avançar e Subir (Alt+Esquerda, Alt+Direita, Backspace) e com duplos cliques. Pesquisar (Ctrl+F) encontra arquivos pelo nome em todo o arquivo compactado; cada resultado mostra sua pasta.
• Selecione com um clique, Ctrl+clique, Shift+clique, as caixas de seleção, Ctrl+A ou as teclas de seta. Clique no título de uma coluna para ordenar por nome, tamanho, tipo ou data. Um clique direito abre um menu com todas as ações.
• Extrair tudo, ou a seleção (Ctrl+E): escolha o destino (por padrão, uma pasta com o nome do arquivo compactado, ao lado dele), mantenha as pastas ou não, e decida o que fazer quando um arquivo já existir: substituí-lo, manter ambos (name (1).ext) ou ignorá-lo. Arquivos retirados de dentro de uma pasta são criados sem o caminho dessa pasta, como no WinRAR. A leitura para logo após o último arquivo escolhido.
• Visualizar (F3, ou um duplo clique em um arquivo de texto): texto com números de linha, pesquisa com realce, quebra de linha e cópia; arquivos binários em hexadecimal. Os primeiros 16 MB são mostrados; Abrir no Bloco de Notas abre o arquivo inteiro. Abrir inicia um arquivo com seu próprio programa (ele é extraído primeiro para uma pasta temporária).
• Excluir (Del) remove arquivos e pastas do arquivo compactado após uma confirmação. O arquivo é sólido, então ele é gravado novamente sem eles, em um arquivo temporário que substitui o original apenas quando tudo deu certo. Arquivos criptografados mantêm sua senha; as outras entradas mantêm seu filtro de mídia ou Deflate e seu motor -m5.
• Testar descompacta todo o arquivo e verifica cada arquivo. O painel de detalhes mostra o tamanho, a data, a pasta, o CRC32, como o arquivo está armazenado e seus atributos; para o próprio arquivo compactado, seu tamanho, método e criptografia. O resumo sob a árvore mostra o espaço economizado.
• Os mesmos dez idiomas, o botão de idioma, a caixa Sobre (i) e os botões de comunidade do NikPak. Nomes de arquivo em qualquer escrita são desenhados com as fontes do sistema como fallback.
• Mudar para o NikPak: o botão redondo com uma seta para baixo, à esquerda do botão i, fecha o unNik e inicia o NikPak. Os dois programas ficam na mesma pasta. Eles compartilham um único arquivo de configurações, então o idioma escolhido em um é usado pelo outro, e uma janela já aberta acompanha a mudança em até dois segundos.
• Abrir a pasta de destino: o botão à esquerda do botão de ejetar abre a pasta da última extração no Explorer ou no Finder (antes de qualquer extração, a pasta do arquivo compactado). O unNik reproduz os mesmos sons do NikPak, com sons para abrir um arquivo compactado, extrair, excluir e testar; o botão de alto-falante dele e o do NikPak compartilham uma única configuração.

3.10 Skins

NikPak e unNik compartilham as mesmas 55 skins de janela: as 41 skins do Nikkomander — de Nikkoid Blue (a padrão) e Nikkoid Bright a Dracula, Nord, Solarized, Classic Blue, Matrix, Pizza, Christmas e 8-Bit Game — mais 14 skins pintadas cujos fundos são desenhados pelo próprio programa: Moon, America, Pattaya Neons, Burgers Tokyo, Sushi, Amiga, MSX, Colecovision, ZX Spectrum, Cat Life, Dog Life, Mario Bros, Counter Strike e Chess.

• Botão de skins (uma paleta, na barra de título dos dois programas): abre o menu de skins, onde cada skin é desenhada em suas próprias cores. Apontar para uma skin a mostra em toda a janela; um clique a mantém; Esc ou um clique fora volta para a skin que você tinha.
• Botão sol / lua ao lado dele alterna entre Nikkoid Blue (escuro) e Nikkoid Bright com um clique.
• A caixa de skins fica fora do programa. Enquanto a caixa está aberta, a janela alarga pela largura da caixa, à direita: o programa mantém seu painel de 500 × 560 e a caixa fica no espaço transparente extra ao lado dele, de modo que toda a interface permanece visível atrás da skin sendo testada. A caixa pode ser arrastada pela barra de título de volta sobre o programa ou para qualquer outro lugar da janela, e tem botões Aplicar skin e Cancelar. Um clique em uma skin a testa em toda a janela; Aplicar a mantém e a salva para os dois programas; Cancelar (ou Esc ou o ×) volta para a skin que você tinha. Um clique no programa não fecha mais a caixa. A janela do unNik não é alargada.
• A skin escolhida é salva (skin= no arquivo de configurações) e compartilhada: uma skin escolhida em um programa é adotada pelo outro em até dois segundos.
• Suas próprias skins: “Importar uma skin…” na parte inferior do menu lê um arquivo .skin.json do Nikkomander (um nome e uma lista de cores) e o copia para a pasta skins ao lado do arquivo de configurações; o × no bloco de uma skin importada a remove.
• As skins pintadas ficam atrás da interface. Os fundos pintados são desenhados por src/skin_scenes.rs, não por gradientes CSS, então eles se adaptam a qualquer tamanho de janela. Desde a 1.6.2, cada uma passa por uma etapa discreet() em src/skin.rs: a arte é puxada em direção à sua própria média local, levemente desfocada e esmaecida em direção à cor de fundo da skin — mais atrás do anel de soltar e da coluna de texto, um pouco mais sobre o logotipo — de modo que o título, o anel e o texto de status permanecem nítidos em todas as catorze.

3.11 O menu do gerenciador de arquivos

Um submenu “NikPak” no menu de clique direito do gerenciador de arquivos, como o do WinRAR, é instalado pelo instalador (Windows: uma opção marcada por padrão; Linux: nikpak --install-menu; macOS: Ações rápidas do Finder).

• Em arquivos e pastas: Adicionar ao arquivo… (pede o nome e a pasta e então compacta na janela do NikPak) e Adicionar ao arquivo aqui (o arquivo compactado fica ao lado dos itens, nomeado como se tivesse sido solto na janela).
• Em arquivos .nik: Abrir com o unNik, Extrair arquivos…, Extrair aqui e Extrair para sua própria pasta.
• Vários itens vão para um único arquivo compactado; vários arquivos compactados selecionados são extraídos um após o outro em uma única janela.
• Os comandos rodam pelo unNik.exe, então nenhuma janela de console pisca; os rótulos seguem o idioma do NikPak. O Windows 10 mostra o submenu diretamente; o Windows 11, em Mostrar mais opções (Shift+F10); o Linux adiciona menus de serviço do Dolphin do KDE, ações do Nemo e scripts do Nautilus, e o macOS adiciona Ações rápidas do Finder.
• Novas opções de linha de comando usadas pelo menu: nikpak --add e --add-here (compactam os itens fornecidos), nikpak --install-menu, --uninstall-menu e --all-users; unNik --extract, --extract-here e --extract-to. Extrair aqui / para sua própria pasta mostram a pequena janela do unNik com o anel de progresso (a caixa de senha para arquivos criptografados) e a fecham quando tudo é extraído; avisos e erros permanecem na tela.
• Um segundo instalador, unnik--setup.exe, instala o unNik sozinho (o navegador gratuito) para quem apenas recebe arquivos .nik; quando o NikPak já está instalado, ele instala somente o programa, para que os menus nunca apareçam em dobro.

4 Arquitetura

O nikpak é um único programa Rust de cerca de 9.600 linhas (incluindo seus testes unitários) em dezesseis arquivos-fonte, além da ferramenta privada de licenças nikpak-keygen. Sua regra central de design é o streaming: os arquivos são lidos em pedaços de 256 KiB, empurrados por uma cadeia de gravadores e nunca mantidos inteiros na memória (as únicas exceções são os dados de pixels BMP, limitados a 256 MiB, e os buffers de trabalho de 64 KiB dos codecs).

4.1 Fluxo de dados ao criar um arquivo compactado

Cada etapa é uma implementação da trait padrão Write envolvendo a próxima, de modo que o mesmo caminho de código atende a um arquivo compactado simples, a um criptografado e ao teste de mídia.

4.2 Mapa do código-fonte

Arquivo	Responsabilidade
main.rs	Ponto de entrada. Analisa os argumentos, despacha o comando, converte erros em códigos de saída. Trata um pipe fechado silenciosamente (nikpak lb x | head).
cli.rs	Analisador de argumentos no estilo RAR/zip escrito à mão, as tabelas de opções e o texto completo de -help. Bibliotecas no estilo Clap não conseguem expressar opções como -pSECRET ou -m5 de forma limpa.
archive.rs	Criar, listar, testar, extrair (por filtros ou por uma escolha exata), excluir, imprimir e o teste de mídia; também o índice e a leitura de arquivo único usados pelo unNik. Contém o gravador e o leitor do fluxo de entradas, a política de sobrescrita e a lógica atômica de arquivo temporário.
media.rs	Detecção de conteúdo para WAV, AIFF, MOD e BMP; os filtros Shuffle, Delta e MED; seleção por teste; auxiliares de CRC e de enquadramento de blocos.
nac.rs	O codec de áudio sem perdas NAC: decorrelação estéreo, preditores, codificação de resíduos.
bits.rs	Gravador e leitor de bits MSB-first usados pelo NAC.
crypto.rs	Derivação de chave Argon2id e o gravador e leitor de blocos XChaCha20-Poly1305.
format.rs	Constantes do formato em disco: número mágico, versões, tipos de registro, limites de KDF.
util.rs	Solicitação e geração de senha, higienização de caminhos, correspondência de curingas, formatação de datas e tamanhos.
error.rs	O tipo de erro, seus códigos de saída e a classificação de erros de E/S (corrupção versus falha do sistema).
engine.rs	Corpo multi-motor do -m5: gravador e leitor de blocos, motores LZMA2 e PPMd, o teste de motores (seções 5.6, 6.7).
recomp.rs	Recompactação Deflate de contêineres ZIP, PDF e gzip com preflate (seção 7.9).
gui.rs	A interface gráfica: janela de arrastar e soltar, anel de progresso, configuração de destino, links da comunidade (seção 3.7).
unnik.rs	O unNik, o navegador de arquivos compactados: árvore, lista, pesquisa, visualizador, caixas de extração e exclusão (seção 3.9).
lib.rs, bin/unnik.rs	A biblioteca compartilhada pelo nikpak e pelo unNik, e o ponto de entrada do unNik.exe (um programa com janela, sem console).
license.rs	Licença shareware: formato da chave, verificação Ed25519, armazenamento da licença, registro (seção 3.8).
i18n.rs	Traduções da janela para os dez idiomas mais falados; configuração de idioma (seção 3.7).
textshape.rs	Texto conformado para hindi, bengali e árabe: ordenação bidi, conformação, rasterização (seção 3.7).

4.3 Criando um arquivo compactado, passo a passo

• Validar o local de saída. Um arquivo compactado existente só é substituído com -o+ (ou um sim interativo); caso contrário, o nikpak explica que acrescentar dados não é suportado.
• Coletar a entrada: os curingas são expandidos (o PowerShell não faz isso), os @listfiles são lidos, as exclusões aplicadas, os links simbólicos e arquivos especiais ignorados com um aviso, e o próprio arquivo compactado nunca é adicionado a si mesmo.
• Resolver a senha se a criptografia foi solicitada (seção 3.3) e derivar a chave com Argon2id.
• Gravar o cabeçalho e então montar a cadeia de gravadores: arquivo, gravador com buffer, criptografador de blocos opcional, codificador Zstandard.
• Gravar cada entrada. Arquivos de mídia passam por detecção e teste (capítulo 7); todo o resto é copiado em pedaços de 256 KiB enquanto um CRC32 é calculado.
• Gravar o marcador de fim com a contagem de entradas, finalizar o quadro Zstandard, selar o bloco criptografado final e descarregar no disco.
• Renomear name.nik.tmp para name.nik. Se algo falhar antes, um objeto de guarda exclui o arquivo temporário, de modo que um arquivo compactado escrito pela metade nunca substitui um bom.

4.4 Extraindo um arquivo compactado, passo a passo

• Ler e validar o cabeçalho: número mágico, versão, flags, método e, para arquivos criptografados, os parâmetros Argon2id, que são verificados quanto à faixa antes de qualquer memória ser alocada.
• Obter a senha e derivar a chave. O primeiro bloco autenticado então prova ou refuta a senha.
• Percorrer o fluxo de entradas. Cada nome de entrada é higienizado (seção 10.1) antes de qualquer acesso ao sistema de arquivos.
• Gravar arquivos com create_new, definir timestamps e permissões, e verificar o CRC32 dos bytes reconstruídos. Um arquivo cujo CRC falha é excluído em vez de ser mantido.
• Verificar o fim do arquivo compactado: após o marcador de fim, o fluxo deve realmente terminar e, se criptografado, o bloco autenticado final deve ter sido processado. Isso detecta truncamento e dados anexados.

4.5 Memória e threading

O Zstandard usa threads de trabalho para a compactação (todos os núcleos por padrão, -mt para limitar). A descompactação, o codec de áudio e a criptografia rodam na thread chamadora. O Argon2id precisa de 64 MiB para a derivação de chave, e os dois níveis mais altos usam uma janela de casamento de 128 MiB, então descompactar esses arquivos exige até esse tanto de memória.

5 O formato de contêiner .nik

Um arquivo .nik é um pequeno cabeçalho fixo seguido de um corpo. O corpo é um único fluxo sólido: todas as entradas são concatenadas, compactadas juntas e, opcionalmente, criptografadas. A versão 2 do formato adiciona registros de mídia; arquivos compactados da versão 1 permanecem legíveis.

5.1 Cabeçalho

Deslocamento	Tamanho	Campo	Observações
0	8	Número mágico	89 4E 49 4B 0D 0A 1A 0A (a ideia do PNG: detecta danos de transferência em modo texto)
8	1	Versão	3 (1 e 2 ainda são legíveis)
9	1	Flags	bit 0 = criptografado; os demais bits devem ser 0
10	1	Método	0 = armazenar, 1 = Zstandard, 2 = blocos multi-motor (5.6)
11	1	Reservado	0
12	4	Memória do Argon2id (KiB)	somente arquivos criptografados, little endian
16	4	Passes do Argon2id	somente criptografado
20	4	Lanes do Argon2id	somente criptografado
24	16	Sal	aleatório por arquivo, somente criptografado
40	19	Prefixo do nonce do fluxo	aleatório por arquivo, somente criptografado

O cabeçalho completo (12 bytes, ou 59 bytes quando criptografado) é autenticado depois como dado associado de cada bloco criptografado, de modo que não pode ser alterado sem detecção.

5.2 Registros de entrada

Dentro do fluxo (descriptografado, descompactado), cada entrada é um registro. Todos os inteiros são little endian.

Tipo	Estrutura
0 END	count:u64. Marca o fim e informa quantas entradas o precedem.
1 FILE	name_len:u16 name mtime:i64 mode:u32 size:u64 data[size] crc32:u32
2 DIR	name_len:u16 name mtime:i64 mode:u32
3 MEDIA	name_len:u16 name mtime:i64 mode:u32 size:u64 filter:u8 method:u8 params_len:u8 params framed_stream crc32:u32

• Os nomes são UTF-8 com separadores /, no máximo 4096 bytes.
• mtime são segundos Unix; mode é a palavra de permissão Unix (arquivos do Windows recebem 0644 ou 0755, 0444 quando somente leitura).
• O CRC32 sempre cobre os bytes originais, que é o que torna os filtros de mídia verificáveis.
• Em um registro MEDIA, size é o tamanho original. O framed_stream é uma série de blocos [u32 length][bytes] terminada por um comprimento zero, de modo que um leitor pode sempre pular uma entrada de mídia sem entender seu filtro.

Parâmetros de mídia

Filtro	Parâmetros	Conteúdo
1 Áudio	19 bytes	offset:u64 frames:u64 channels:u8 bits:u8 flags:u8 (flag bit 0 = big endian, bit 1 = com sinal)
2 Imagem	21 bytes	offset:u64 width:u32 rows:u32 bpp:u8 stride:u32
3 Deflate	0 bytes	none: o fluxo enquadrado contém segmentos brutos e fluxos Deflate recompactados (seção 7.9)

Tudo antes do offset (cabeçalhos, tags, paletas, padrões MOD) e tudo depois da região de amostras ou pixels (blocos finais) é armazenado inalterado ao redor dos dados filtrados.

5.3 Enquadramento do corpo criptografado

Quando a flag de criptografia está definida, a saída do zstd é cortada em blocos de 64 KiB de texto simples. Cada bloco é armazenado como um comprimento big-endian de 32 bits seguido do texto cifrado, que é 16 bytes maior por causa da tag Poly1305. Um bloco só é selado quando pelo menos mais um byte vem em seguida, de modo que o último bloco nunca fica vazio e pode ser marcado como final (seção 8.3).

5.4 Por que um fluxo sólido?

Compactar todos os arquivos como um único fluxo permite que o compactador encontre repetições entre arquivos, o que importa enormemente para árvores de código-fonte e coleções de documentos (o benchmark do capítulo 11 mostra a saída não sólida do RAR sendo quase duas vezes maior que a sólida em 10.949 arquivos). O preço é o acesso sequencial: extrair um único arquivo exige descompactar o que o precede. O nikpak reduz esse custo para entradas de mídia pulando por cima delas sem decodificar.

5.5 Versionamento

O byte de versão é comparado com a versão mais alta que o programa entende. Um arquivo compactado mais novo produz a mensagem Versão de arquivo não suportada N; atualize o nikpak em vez de um enganoso erro de corrupção. Flags, métodos ou filtros de mídia desconhecidos são rejeitados da mesma forma.

5.6 Corpo multi-motor (versão 3)

Arquivos compactados feitos com -m5 usam o método 2. O fluxo interno de registros descrito em 5.2 não muda, mas é cortado, apenas entre entradas, em blocos, e cada bloco é compactado com seu próprio motor. Concatenados, os blocos descompactados são exatamente o fluxo de registros de um arquivo de motor único, então listar, testar e extrair funcionam da mesma forma.

Elemento	Estrutura
body	block* seguido de um único byte 0
block	engine:u8 parâmetros, depois quadros [u32 length 1 .. 1 MiB][bytes compactados], terminados por um comprimento zero
motor 1	Zstandard (sem parâmetros)
motor 2	Fluxo LZMA2 bruto: tamanho do dicionário u32, lc u8, lp u8, pb u8
motor 3	PPMd variante I (PPMd8): ordem u8, tamanho do modelo u32, método de restauração u8 (0 = reiniciar)

O enquadramento permite que um leitor encontre o fim de cada bloco sem confiar no decodificador, e cada parâmetro é verificado quanto à faixa antes de a memória ser alocada (dicionário LZMA2 de no máximo 1.5 GiB, modelo PPMd de no máximo 1 GiB, ordem de 2 a 16). Quando criptografado, o corpo é protegido pelos mesmos blocos autenticados de qualquer outro arquivo compactado (capítulo 8).

6 O motor de compactação

6.1 Por que o Zstandard

O Zstandard combina casamento LZ77 com uma etapa de entropia construída com codificação de Huffman e entropia de estados finitos (FSE). Comparado ao algoritmo Deflate do ZIP, ele encontra casamentos em uma janela muito maior, modela literais e comprimentos de casamento com códigos de entropia mais justos e decodifica a gigabytes por segundo. Também é um formato aberto e amplamente auditado, o que mantém os dados do nikpak recuperáveis por ferramentas independentes.

6.2 Mapeamento de níveis

O nikpak aceita tanto níveis no estilo RAR (-m0 .. -m5) quanto no estilo zip (-0 .. -9) e os mapeia para níveis do Zstandard:

Opção	Nível Zstandard	Caráter
-m0	nenhum (armazenado)	Sem compactação, sem filtros de mídia
-m1	1	O mais rápido
-m2	3	Rápido; cerca de 0.9 s para 197 MB em um núcleo (o padrão até a 1.2.0)
-m3	9	Bom equilíbrio
-m4	15	Alto; janela de 128 MiB e casamento de longa distância; recompactação Deflate (7.9)
-m5 (default)	LZMA2 / PPMd	Máximo, e o padrão desde a 1.2.1: corpo multi-motor (6.7) e recompactação Deflate

Os níveis no estilo zip mapeiam da seguinte forma: -0 armazena, -1 a -6 usam Zstandard 1 a 6, -7 usa 9, -8 usa 12 e -9 é o mesmo que -m5.

6.3 Janela grande e casamento de longa distância

No nível 15 e acima do Zstandard, o nikpak habilita uma janela de casamento de 2^27 bytes (128 MiB) e o casamento de longa distância. Árvores de código-fonte, conjuntos de documentos e backups contêm muitos arquivos quase duplicados que ficam distantes no fluxo; uma janela normal de 8 MiB não consegue enxergar através deles. No conjunto de teste de 197 MB, isso reduziu a saída em -m5 de 26.3 MB para 24.4 MB e em -m4 de 29.5 MB para 26.8 MB, sem custo de velocidade para -m4 e um custo pequeno para -m5. Uma janela de 2^27 está dentro do limite padrão do decodificador do Zstandard, então qualquer decodificador padrão pode ler os dados.

6.4 Multithreading

O codificador divide a entrada em tarefas que rodam em threads de trabalho (todos os núcleos por padrão). A velocidade de compactação, portanto, escala com o número de núcleos, enquanto o formato permanece um único fluxo. Todos os números deste guia foram medidos em um núcleo; em uma máquina multicore típica, o nikpak é consideravelmente mais rápido do que o mostrado.

6.5 Integridade dentro do fluxo

O quadro Zstandard carrega sua própria soma de verificação de conteúdo; o nikpak adiciona um CRC32 por arquivo e um marcador de fim com a contagem de entradas. Um arquivo compactado simples danificado é, portanto, detectado em três níveis: a soma de verificação do quadro, o CRC por arquivo e o marcador de fim.

6.6 Modo armazenar

-m0 grava as entradas sem compactação. É útil para dados que já estão compactados, e também é o único modo em que os filtros de mídia são ignorados de propósito: um usuário que pede armazenar não espera que os dados sejam transformados.

6.7 O nível máximo: LZMA2 e PPMd

O Zstandard é o motor certo para velocidade, mas nas configurações mais fortes ele ainda fica alguns por cento atrás do LZMA2 em código-fonte e documentos, e bem atrás do PPMd em prosa. Desde a versão 1.2, o -m5, portanto, monta o arquivo compactado a partir de dois blocos (formato em 5.6):

• Bloco binário. Pastas, arquivos binários, entradas de mídia e entradas recompactadas com Deflate são compactados com LZMA2: preset 9, nice length 273, profundidade do localizador de casamentos 32 e um dicionário dimensionado para os dados (1 a 128 MiB).
• Bloco de texto. Arquivos cujos primeiros 64 KiB não contêm nenhum byte zero e quase nenhum caractere de controle (código-fonte, texto, CSV, HTML, XML ...) vão para um segundo bloco. Quatro trechos contíguos de 1 MiB desses arquivos são compactados por teste com PPMd variante I (ordem 8, modelo de 192 MiB) e com LZMA2 ajustado para texto (lc 4, pb 0), e o menor resultado vence. Prosa favorece o PPMd; grandes árvores de código-fonte com muitos arquivos quase idênticos favorecem o LZMA2, porque ele consegue copiar repetições longas entre arquivos.
• Ordem. Dentro de cada bloco, os arquivos são ordenados por extensão e depois por nome, como faz o 7-Zip, para que arquivos idênticos ou semelhantes fiquem vizinhos. Junto com a amostra de teste contíguo, isso tornou o conjunto de dados gerais 7.5 % menor.

Configurações LZMA2 "extremo" foram medidas e rejeitadas: em XML de planilhas, eram até dez vezes mais lentas e não menores. O -m5 roda em uma thread, independentemente de -mt.

7 Inteligência de mídia

Um compactador de propósito geral enxerga bytes. Ele não sabe que um arquivo WAV é uma forma de onda cuja próxima amostra é previsível a partir das anteriores, nem que pixels vizinhos de uma fotografia são quase iguais. A camada de mídia do nikpak fornece esse conhecimento: ela reconhece esses arquivos, aplica uma transformação sem perdas que expõe a redundância e deixa o compactador (ou um codec dedicado) explorá-la. É aqui que o nikpak mais ganha sobre o RAR.

7.1 Detecção por conteúdo

A detecção olha os primeiros bytes de cada arquivo de pelo menos 8 KiB e nunca confia na extensão, então um WAV renomeado para .dat ainda é encontrado e um arquivo de texto chamado .wav não é.

Tipo	Como é reconhecido	O que é filtrado
WAV	RIFF..WAVE, um bloco fmt com PCM inteiro (formato 1, ou WAVE_FORMAT_EXTENSIBLE com o subformato PCM), 8/16/24/32 bits, 1 a 8 canais, alinhamento de bloco consistente; depois o bloco data	A região de amostras. Um comprimento de dados zero, grande demais ou inválido é limitado ao arquivo; bytes restantes e blocos finais são mantidos como estão.
AIFF / AIFC	FORM..AIFF ou AIFC (compactação NONE ou twos), blocos COMM e SSND, amostras com sinal big-endian	A região de dados de som.
ProTracker MOD	Assinatura no deslocamento 1080: M.K., M!K!, FLT4, 4CHN, 6CHN, 8CHN, FLT8, OCTA ou CD81	A área de amostras de 8-bit depois dos dados de padrão (seção 7.6).
BMP	BM, um cabeçalho DIB de 40 bytes ou mais, sem compactação, 8, 24 ou 32 bits por pixel, linhas de pixels que cabem no arquivo, região entre 4 KiB e 256 MiB	As linhas de pixels (seção 7.7).

Não tratados e, portanto, armazenados com compactação normal: WAV de ponto flutuante, ADPCM e outros áudios compactados, BMP com RLE ou campo de bits e formatos de tracker diferentes de ProTracker MOD. Mídias já compactadas, como MP3, JPEG, FLAC, PNG e MP4, não são reconhecidas e são deixadas como estão, já que transformá-las não ajudaria.

7.2 O teste: escolhendo o melhor filtro por arquivo

Nenhuma transformação isolada é a melhor para todo arquivo. A codificação preditiva vence em música gravada; a separação em planos de bytes vence em áudio vindo de uma fonte companding de 8-bit (onde ocorrem apenas cerca de mil valores de 16-bit distintos); a compactação simples vence em silêncio e em amostras de tracker altamente repetitivas. O nikpak, portanto, mede em vez de adivinhar.

• Tira uma amostra: toda a região de amostras quando ela tem até 3 MiB; caso contrário, três janelas de 768 KiB a 5 %, 45 % e 85 % do áudio. Para imagens, as primeiras linhas, até cerca de 4 MiB.
• Compacta a amostra com Zstandard simples de nível 3 (a linha de base) e com cada filtro que se aplica: NAC, Shuffle e Shuffle+Delta para áudio de 16/24/32 bits; NAC e Shuffle+Delta para áudio de 8 bits; MED para imagens.
• Mantém o filtro com a menor estimativa, mas apenas se ele superar a linha de base em pelo menos 2 %. Caso contrário, o arquivo é armazenado com compactação normal.
• Grava o arquivo com o vencedor. Tudo isso acontece por arquivo, então um único arquivo compactado pode conter WAVs codificados com métodos diferentes ao lado de arquivos comuns.

nikpak mt executa a mesma medição no arquivo inteiro e imprime uma tabela, que é como o benchmark do capítulo 11 foi explorado. Nas opções, -mc- desabilita os filtros e -mc+ força o filtro padrão sem teste.

Sem perdas, verificado e contornável Cada filtro é exatamente reversível. O CRC32 armazenado com cada entrada é calculado sobre os bytes originais e verificado na extração, o codificador NAC verifica cada bloco enquanto grava (seção 7.4), e -mc- desliga toda a camada.

7.3 O codec de áudio NAC

O NAC (codec de áudio do nikpak) é um codec sem perdas baseado em blocos para PCM inteiro. Ele pertence à mesma família do FLAC: predição linear seguida de codificação Rice. Ele tem seu próprio fluxo de bits, projetado para este arquivo compactado, e é usado para WAV, AIFF e os dados de amostra de arquivos MOD.

Blocos e decorrelação estéreo

O áudio é cortado em blocos de 4096 quadros de amostra, cada um codificado de forma independente, o que torna o codec robusto (um erro não pode se espalhar) e permite que o codificador se adapte a material variável. Para estéreo, o codificador escolhe uma de quatro representações por bloco:

Modo	Canais codificados	Reconstrução
0	Esquerdo, Direito	direto
1	Esquerdo, Lateral	R = L - S
2	Lateral, Direito	L = R + S
3	Médio, Lateral	sum = (M << 1) | (S & 1), L = (sum + S) >> 1, R = (sum - S) >> 1

com Side = L - R e Mid = (L + R) >> 1. O canal lateral precisa de um bit a mais que um canal normal e é codificado com bits + 1. O modo é escolhido de forma barata: o codificador soma os valores absolutos do resíduo do preditor fixo de ordem 2 de L, R, M e S e escolhe o par com o menor total. Para gravações cujos canais são fortemente correlacionados, Mid/Side normalmente economiza vários por cento.

Tipos de subquadro

Cada canal codificado de um bloco é armazenado como um de quatro subquadros, o menor deles:

Tipo	Uso	Custo
Constante	Todas as amostras iguais (silêncio digital)	2 + bits da largura da amostra para um bloco inteiro
Verbatim	Material semelhante a ruído, ou o fallback de segurança	n x bits de largura
Fixo	Preditor polinomial de ordem 0 a 4	amostras de aquecimento + resíduos
LPC	Preditor linear de ordem 1 a 32 com coeficientes transmitidos	coeficientes + aquecimento + resíduos

Bits desperdiçados. Se os bits baixos de cada amostra em um bloco forem sempre zero (uma gravação de 8 bits armazenada em contêineres de 16 bits, ou um sinal quantizado), eles são removidos e sua contagem é armazenada em 5 bits.

Preditores fixos

order 0: e[i] = x[i]

order 1: e[i] = x[i] - x[i-1]

order 2: e[i] = x[i] - 2*x[i-1] + x[i-2]

order 3: e[i] = x[i] - 3*x[i-1] + 3*x[i-2] - x[i-3]

order 4: e[i] = x[i] - 4*x[i-1] + 6*x[i-2] - 4*x[i-3] + x[i-4]

As primeiras order amostras de um bloco são armazenadas verbatim como valores de aquecimento.

Codificação preditiva linear (LPC)

Para música tonal e harmônica, um preditor cujos coeficientes são ajustados ao bloco é muito melhor que um polinômio fixo. O codificador os calcula da seguinte forma:

• Aplica uma janela de Tukey (atenuação no primeiro e no último quarto) ao bloco, para que suas bordas não distorçam as estatísticas.
• Calcula a autocorrelação r[0..32] do sinal janelado.
• Executa a recursão de Levinson-Durbin, que produz o conjunto ótimo de coeficientes para cada ordem de 1 a 32 em uma única passada: k = (r[i] - sum a[j] r[i-j]) / err, a[i] = k, a[j] = a[j] - k a[i-j], err = err (1 - k^2).
• Quantiza os coeficientes reais para inteiros com precisão de 12, 14 ou 15 bits (dependendo da largura da amostra), escolhendo uma escala de potência de dois (shift, de 0 a 20) para que o maior coeficiente caiba certinho. O arredondamento usa realimentação de erro, para que os erros de quantização não se acumulem entre os coeficientes.
• Avalia várias ordens (o conjunto depende do nível de esforço, abaixo), calcula o resíduo de cada uma e mantém a de menor tamanho total estimado, incluindo o custo de enviar seus coeficientes.

O preditor em si é aritmética inteira pura, que é o que o decodificador executa:

pred[i] = (q[0]*x[i-1] + q[1]*x[i-2] + ... + q[n-1]*x[i-n]) >> shift

e[i] = x[i] - pred[i] (n = order; the sum uses 64 bits)

Ponto flutuante é usado apenas pelo codificador para decidir quais coeficientes inteiros enviar. O decodificador nunca toca ponto flutuante, então a decodificação é bit a bit exata em todo processador e todo compilador.

Codificação de resíduos

Os erros de predição são mapeados para números sem sinal com a transformação zig-zag (u = (e << 1) XOR (e >> 63), para que valores positivos e negativos pequenos virem números pequenos) e codificados com códigos Rice particionados. O resíduo de um bloco é dividido em 2^p partições (p de 0 a 8, escolhido pelo codificador); cada partição recebe seu próprio parâmetro Rice k (5 bits). Um valor é escrito como u >> k em unário (essa quantidade de zeros e um um) seguido dos k bits baixos. O melhor k de uma partição é derivado da soma de seus valores, então o custo de cada preditor candidato pode ser estimado de forma barata a partir de somas acumuladas, em vez de codificá-lo.

Níveis de esforço

O nível do arquivo compactado (opção -m) seleciona quantas ordens LPC são testadas por bloco. Mais ordens significam um resultado ligeiramente menor e um codificador mais lento; a velocidade do decodificador é a mesma.

Nível do arquivo	Esforço do NAC	Ordens LPC testadas
-m1	0	8, 16
-m2, -m3	1	4, 8, 12, 16, 24, 32
-m4, -m5	2	2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 24, 28, 32

Preditores fixos de ordem 0 a 4 são sempre testados. No benchmark, o nível de esforço mudou o resultado da música estéreo em menos de 0.05 %: o grande ganho vem de usar predição de qualquer forma.

Estrutura de bits de um bloco

block := [stereo mode: 2 bits] sub-frame [sub-frame] (byte-padded)

sub-frame := type:2 ...

CONSTANT : value:width

VERBATIM : wasted:5 samples:(n x (width - wasted))

FIXED : wasted:5 order:3 warm-up residual

LPC : wasted:5 order-1:5 precision-1:4 shift:5

coefficients warm-up residual

residual := partition-order:4 per partition: k:5 Rice-coded values

Cada bloco é armazenado no arquivo compactado com um comprimento de 32 bits na frente, para que o decodificador sempre saiba onde o próximo bloco começa.

7.4 Autoverificação

Gravar um arquivo compactado é a única chance de detectar um bug do codificador, então o codificador NAC não confia em si mesmo. Após codificar cada bloco, ele decodifica o bloco novamente e compara o resultado com as amostras originais. Em qualquer diferença, ele recodifica o bloco como verbatim (o que não pode falhar) e verifica de novo; se até isso falhar, a compactação para com um erro explícito e a sugestão de usar -mc-. O caminho de fallback é exercitado pelos testes unitários, que forçam a codificação verbatim para cada combinação de profundidade de bits e número de canais, e o mecanismo transforma um possível bug silencioso de perda de dados em uma condição detectada e recuperável.

Além disso, o decodificador passa por fuzzing: milhares de blocos de bytes aleatórios e blocos com bits invertidos são enviados a ele nos testes unitários, e ele deve retornar um erro sem entrar em pânico nem alocar quantidades absurdas de memória. Durante o desenvolvimento, isso encontrou um bug real (para material de 32 bits, a busca do parâmetro Rice podia sair vazia e cair para um parâmetro que teria produzido um código de vários gigabytes); ele foi corrigido e coberto por um teste.

7.5 Shuffle e Shuffle+Delta

Alguns áudios não respondem à predição. Os arquivos WAV da galeria usados no benchmark são de 16 bits, mas contêm apenas cerca de mil valores de amostra distintos, porque foram produzidos de uma fonte companding de 8 bits. Um preditor não consegue explorar isso, e o FLAC os compacta para 84 % do original, enquanto o Zstandard simples precisa de 63 %. O que ajuda é organizar os bytes para que o compactador veja dados homogêneos:

• Shuffle separa os bytes das amostras em planos: todos os bytes menos significativos do canal 0, depois todos os bytes mais significativos do canal 0, depois o canal 1, e assim por diante, em blocos de 32768 quadros. O plano de bytes altos é suave e o plano de bytes baixos tem um alfabeto muito restrito; o codificador de entropia do Zstandard modela cada um muito melhor do que a mistura intercalada.
• Shuffle+Delta primeiro substitui cada amostra por sua diferença em relação à amostra anterior do mesmo canal (módulo a largura da amostra, para ser exatamente reversível, com estado carregado entre blocos) e depois embaralha. Isso ajuda quando o sinal é suave, mas não previsível o bastante para o NAC vencer.

Nos 35 arquivos da galeria, o arquivo compactado com o melhor filtro por arquivo (escolhido pelo teste) fica em 51 % do tamanho original em -m2 e 47 % em -m5, contra 63 % do Zstandard simples.

7.6 Arquivos MOD do ProTracker

Um módulo MOD é um cabeçalho de 1084 bytes (título, 31 descritores de amostra, uma tabela de ordem de padrões com 128 entradas e uma assinatura de 4 bytes no deslocamento 1080), depois os dados de padrão e depois as amostras brutas de 8 bits com sinal de todos os instrumentos. O nikpak calcula onde as amostras começam e qual é o comprimento delas:

patterns = max(order table) + 1

sample_start = 1084 + patterns * 256 * channels (4 ch: 1024 B per pattern)

sample_bytes = sum of (length in words * 2) over the 31 descriptors,

clamped to the end of the file

O cabeçalho e os padrões são armazenados como estão (o compactador lida bem com esses eventos de nota repetitivos) e a área de amostras é tratada como um único fluxo mono, com sinal, de 8 bits para o teste. Por arquivo, NAC, Shuffle+Delta ou compactação simples vencem: instrumentos amostrados favorecem, em sua maioria, o NAC, enquanto em alguns módulos (por exemplo, aqueles com amostras muito curtas ou altamente repetitivas) a compactação simples vence. Módulos truncados são tratados limitando a região aos dados realmente presentes.

7.7 Imagens BMP

Um BMP sem compactação armazena linhas de pixels preenchidas até um múltiplo de quatro bytes. O filtro funciona em quatro etapas:

• Dividir a região de pixels em um plano por canal (B, G, R e A para 32 bits), lembrando os bytes de preenchimento por linha separadamente.
• Decorrelacionar cor. Subtrair o plano verde dos planos azul e vermelho (módulo 256). Em fotografias, os três canais são fortemente correlacionados, então as diferenças são pequenas.
• Prever cada pixel a partir dos vizinhos com o preditor MED (detector de borda por mediana), o mesmo usado pelo codificador de imagens LOCO-I: para esquerda a, acima b e acima-à-esquerda c, a predição é min(a,b) se c >= max(a,b), max(a,b) se c <= min(a,b), e a + b - c caso contrário. O erro de predição substitui o pixel (módulo 256). Nas bordas, o preditor segue a borda; em gradientes suaves, ele extrapola o gradiente.
• Concatenar os planos de resíduos e os bytes de preenchimento e deixar o Zstandard compactá-los. Regiões suaves viram sequências de bytes quase zero.

O decodificador inverte as etapas exatamente. BMPs de 8 bits pulam a etapa de cor; o teste então decide se a predição ajuda naquela paleta, já que prever índices de paleta só faz sentido para paletas em tons de cinza ou suavemente ordenadas. Arquivos BMP acima de 256 MiB não são filtrados, para limitar o uso de memória.

7.8 Por que isso supera o RAR

O RAR compacta mídia com seu motor geral de casamento e Huffman mais um pequeno conjunto de filtros de bytes. O nikpak, em vez disso, dá ao áudio um codec preditivo de verdade com decorrelação estéreo por bloco e codificação Rice adaptativa, dá às imagens um preditor 2-D adequado com decorrelação de cor e escolhe por arquivo por meio de medição. A consequência é visível no benchmark: 12 a 15 % menor em áudio de todos os tipos, 13 % em música de tracker e 39 % em fotografias, e o resultado do NAC para a faixa estéreo fica a 0.2 % do codificador FLAC dedicado.

7.9 Documentos de escritório, PDF e gzip: recompactação Deflate

Arquivos de escritório modernos são arquivos ZIP de XML (docx, xlsx, pptx, odt, ods), e os arquivos PDF armazenam suas páginas em fluxos Deflate (FlateDecode). O conteúdo deles, portanto, já está compactado, e nenhum compactador consegue reduzi-lo muito: no benchmark da 1.1, 6.6 MB de arquivos .xlsx só baixaram para 5.6 MB com o 7-Zip. O nikpak 1.2 remove esse obstáculo.

• Detecção por conteúdo. Um cabeçalho local ZIP (PK\x03\x04) no início do arquivo, %PDF- ou um cabeçalho gzip; a extensão nunca é usada.
• Decodificação. Cada fluxo Deflate é encontrado (entradas ZIP com método 8, fluxos PDF com cabeçalho zlib, cada membro gzip) e analisado com preflate (o preflate-rs da Microsoft). O preflate devolve os dados simples mais um pequeno registro de correções que descreve exatamente como o codificador original fez suas escolhas, qualquer que tenha sido o codificador.
• Armazenamento. O arquivo é armazenado como uma sequência de segmentos brutos e pares (simples, correções). O XML simples ou a descrição da página então entra no fluxo sólido, onde o LZMA2 o compacta para uma fração de seu tamanho Deflate.
• Verificação. Antes de o resultado ser usado, o nikpak reconstrói cada fluxo Deflate e compara o comprimento e o CRC32 do arquivo inteiro com o original. Se algo diferir, ou o preflate falhar ou entrar em pânico em um arquivo malformado, o arquivo é simplesmente armazenado de forma normal.
• Extração. Os fluxos Deflate são recriados bit a bit, então o .docx ou .pdf extraído é byte a byte idêntico, e seu CRC32 é verificado como para cada entrada.

No conjunto de escritório da seção 11.7, é isso que torna o nikpak menor que todos os outros compactadores. Os 6.6 MB de arquivos .xlsx contêm 71 MB de XML uma vez decodificados, e esse XML compacta muito melhor do que o Deflate fez. O custo é tempo: o preflate analisa cerca de 15 MB de dados simples por segundo. Por isso, a recompactação é usada apenas em -m4 e -m5, onde compensa (medido: -m3 ganhou 0.5 % por seis vezes o tempo). Limites: arquivos de até 512 MiB e, por fluxo, até 512 MiB de dados simples e 64 MiB de correções. -mc- desliga isso.

8 Criptografia

A criptografia do nikpak é construída inteiramente com componentes padrão e bem estudados (as implementações RustCrypto de Argon2id e XChaCha20-Poly1305). Nenhuma primitiva foi inventada para este projeto; o trabalho está em combiná-las corretamente.

8.1 Modelo de ameaça

O design assume um atacante que obtém o arquivo compactado e pode estudá-lo e modificá-lo à vontade, e que pode tentar infinitas senhas offline. O nikpak visa garantir:

• Confidencialidade do conteúdo dos arquivos e de tudo sobre eles: nomes, tamanhos, timestamps, permissões e o número de arquivos.
• Integridade e autenticidade: qualquer alteração no arquivo compactado, seja nos dados, no cabeçalho, na ordem dos dados ou em seu comprimento, é detectada antes de dados errados serem aceitos.
• Resistência a tentativas: cada tentativa de senha é feita o mais cara possível na prática.

Ele não esconde que um arquivo compactado existe, nem seu tamanho aproximado, e não pode proteger contra malware na máquina que cria ou abre o arquivo compactado, nem contra uma senha fraca.

8.2 Da senha à chave: Argon2id

Uma senha é uma chave ruim: curta, previsível e digitada por um humano. Ela é transformada em uma chave de 256 bits com Argon2id, o vencedor da Password Hashing Competition e o algoritmo padronizado na RFC 9106. O Argon2id é deliberadamente memory-hard: calcular uma chave exige um grande bloco de memória que é preenchido e depois lido repetidamente em um padrão dependente dos dados. O nikpak usa o perfil de baixa memória da RFC:

Parâmetro	Valor	Significado
Memória	64 MiB	Cada tentativa precisa de 64 MiB de memória rápida
Passes	3	A memória é processada três vezes
Lanes	4	Grau de paralelismo dentro de uma derivação
Sal	16 bytes aleatórios	Novo para cada arquivo compactado: senhas idênticas geram chaves diferentes, e tabelas pré-computadas são inúteis
Saída	32 bytes	A chave XChaCha20-Poly1305

A exigência de memória é o que separa o Argon2id do PBKDF2 mais antigo (usado pelo RAR5 e pelo modo AES do ZIP): o PBKDF2 quase não precisa de memória, então uma placa de vídeo ou um chip personalizado pode testar um número enorme de tentativas em paralelo. Com o Argon2id, o hardware do atacante precisa fornecer 64 MiB por tentativa paralela, o que remove a maior parte dessa vantagem. O custo para o usuário legítimo é uma fração de segundo, pago uma vez por arquivo compactado.

Os parâmetros são armazenados no cabeçalho, para que versões futuras possam aumentá-los sem quebrar arquivos antigos. Na leitura, eles são verificados quanto à faixa primeiro (memória 8 x lanes até 1 GiB, passes de 1 a 64, lanes de 1 a 64), de modo que um arquivo compactado malicioso não possa fazer o nikpak alocar quantidades absurdas de memória antes de a senha ser verificada.

8.3 XChaCha20-Poly1305 na construção STREAM

Os dados em massa são protegidos com XChaCha20-Poly1305, uma cifra de criptografia autenticada com dados associados (AEAD): o ChaCha20 fornece uma cifra de fluxo com chave de 256 bits, a variante X estende seu nonce para 192 bits (grande o suficiente para escolher aleatoriamente sem nunca repetir), e o Poly1305 adiciona uma tag de autenticação de 128 bits a cada mensagem selada. O ChaCha20 é rápido em toda CPU sem instruções especiais e, ao contrário do AES baseado em tabelas, é naturalmente livre de vazamentos por tempo de cache.

Um arquivo compactado é muito maior que uma única mensagem, então o nikpak usa a construção STREAM (a mesma usada por ferramentas modernas de criptografia de arquivos): os dados são cortados em blocos de 64 KiB e o bloco número i é selado sob o nonce

nonce (24 bytes) = random prefix (19 bytes)

| chunk counter (4 bytes, big endian)

| last-chunk flag (1 byte)

Isso dá três garantias de uma vez. Cada bloco tem um nonce único, o que é essencial para cifras de fluxo. Como o contador faz parte do nonce, reordenar ou duplicar blocos falha a autenticação. Como o bloco final carrega uma flag diferente, cortar o arquivo compactado, mesmo exatamente em um limite de bloco, falha a autenticação: o novo último bloco foi selado como não final. O prefixo de 19 bytes é aleatório por arquivo.

Além disso, o cabeçalho completo do arquivo (versão, flags, método, parâmetros Argon2id, sal e prefixo do nonce) é passado como dado associado a cada bloco. Ele é autenticado, mas não criptografado; inverter qualquer bit dele faz todos os blocos falharem. Isso também bloqueia ataques de downgrade que tentariam enfraquecer os parâmetros armazenados.

Item	Valor
Cifra	XChaCha20-Poly1305: chave de 256 bits, nonce de 192 bits, tag de 128 bits
Bloco	até 64 KiB de texto simples; armazenado como u32 length + texto cifrado + tag de 16 bytes
Sobrecarga de tamanho	cerca de 0.03 % (20 bytes por 64 KiB), medido 0.03 % em um conjunto de dados de 222 MB
Sobrecarga de velocidade	medido: +0.3 s no total em um conjunto de dados de 222 MB (0.92 s em vez de 0.64 s), incluindo a derivação de chave
Senha errada	Detectada no primeiro bloco; nenhum texto simples é produzido

8.4 O que um observador pode e não pode ver

Visível sem a senha	Protegido
O número mágico, a versão, as flags e o método de compactação	Nomes de arquivo e estrutura de pastas
Os parâmetros Argon2id, o sal e o prefixo do nonce	Tamanhos de arquivo, timestamps e permissões
O tamanho total do arquivo compactado e o número de blocos	O número de arquivos
O fato de ser um arquivo nikpak	Todo o conteúdo, inclusive se contém mídia

Uma consequência de compactar antes de criptografar é que o tamanho do arquivo reflete o quão compactáveis são os dados. Isso é inerente a todo compactador que compacta e criptografa; só importa se um atacante puder controlar parte dos dados e observar o tamanho, o que não se aplica ao ato de compactar arquivos.

8.5 Tratamento de senhas

• Comprimento mínimo. 8 caracteres ao criar um arquivo compactado; senhas mais curtas são recusadas com uma explicação.
• Confirmação. A solicitação interativa pergunta duas vezes, não ecoa os caracteres digitados e rejeita uma divergência.
• Geração. Sem senha, o nikpak sorteia 24 caracteres de um alfabeto de 56 símbolos que omite parecidos (0/O, 1/l/I), usando amostragem por rejeição no gerador aleatório criptograficamente seguro do sistema operacional, para que nenhum símbolo seja mais provável que outro. Isso dá 24 x log2(56), cerca de 139 bits de entropia, e é exibido uma vez, em uma caixa claramente marcada.
• Higiene de memória. A chave derivada e as strings de senha são apagadas da memória quando não são mais necessárias (o crate zeroize).
• Canais. Linha de comando (-p), variável de ambiente NIKPAK_PASSWORD, solicitação interativa ou stdin quando não há terminal. A forma de linha de comando é conveniente, mas visível na lista de processos; as outras formas são preferíveis.

8.6 Testes de ataque

As seguintes manipulações de arquivos criptografados foram executadas contra o programa finalizado. Todas foram detectadas antes de qualquer dado errado ser aceito:

Manipulação	Resultado
Inverte um único byte no meio do texto cifrado	Rejeitado: falha de autenticação (saída 11)
Inverte um byte do sal no cabeçalho	Rejeitado (o cabeçalho é dado associado e a chave muda)
Altera o byte de método no cabeçalho	Rejeitado
Trunca o arquivo em 100 bytes	Rejeitado como danificado (saída 3)
Exclui o bloco final exatamente em um limite de bloco	Rejeitado: o novo último bloco não tem a flag final
Troca dois blocos de lugar	Rejeitado: divergência de contador
Fornece a senha errada	Rejeitado no primeiro bloco (saída 11)
Envia um arquivo aleatório como se fosse um arquivo compactado	Rejeitado: assinatura inválida (saída 3)

Riscos residuais, declarados claramente Uma senha fraca sempre pode ser adivinhada; o Argon2id torna isso caro, mas não consegue salvar password123. O nikpak não foi auditado de forma independente. Ele não pode se defender de keyloggers, malware ou de alguém lendo a memória do processo em execução. Para dados cuja exposição seria seriamente prejudicial, peça primeiro a um criptógrafo para revisar a implementação.

9 Resistência quântica

Computadores quânticos ameaçam gravemente parte da criptografia e quase nada outra parte. O nikpak foi projetado no lado quase não afetado.

9.1 O que os computadores quânticos mudam

Algoritmo	Efeito	Quem é afetado
Shor (1994)	Fatora inteiros e calcula logaritmos discretos em tempo polinomial	RSA, Diffie-Hellman, DSA, criptografia de curvas elípticas: quebradas por um grande computador quântico
Grover (1996)	Pesquisa um espaço não estruturado de N itens em cerca da raiz quadrada de N passos	Chaves simétricas e funções de hash: o comprimento efetivo da chave é reduzido à metade

O algoritmo de Shor é o dramático: ele quebraria todo sistema que depende de matemática de chave pública, razão pela qual governos e órgãos de padronização estão migrando para algoritmos de chave pública pós-quânticos como o ML-KEM (FIPS 203). O algoritmo de Grover é o ameno: uma chave de 256 bits oferece cerca de 128 bits de segurança contra ele, e as iterações de Grover são inerentemente sequenciais, então espalhar o trabalho por muitas máquinas quânticas produz apenas a raiz quadrada do número delas como aceleração.

9.2 A posição do nikpak

Componente	Primitiva	Impacto quântico
Criptografia	XChaCha20, chave de 256 bits	Melhor ataque conhecido: Grover, cerca de 2^128 operações. Fora de alcance.
Autenticação	Poly1305, tag de 128 bits, derivada do segredo de 256 bits	Nenhuma matemática de chave pública envolvida
Da senha à chave	Argon2id, 64 MiB, 3 passes	Grover poderia, no máximo, reduzir à metade a entropia da senha, e cada iteração exigiria avaliar uma função que exige muita memória
Aleatoriedade	CSPRNG do sistema operacional	Não afetada
Criptografia de chave pública	Nenhuma	Nada para o algoritmo de Shor atacar

Uma chave simétrica de 256 bits é a referência para a categoria de segurança mais alta (categoria 5) da padronização pós-quântica do NIST: os algoritmos de chave pública padronizados pelo NIST são classificados pelo quão perto correspondem à dificuldade de uma busca exaustiva de uma chave AES de 256 bits. Em outras palavras, a criptografia de dados do nikpak já está na força que os padrões pós-quânticos almejam.

9.3 E a senha?

O espaço de chaves da cifra é de 256 bits, mas a chave é derivada de uma senha, então a força real é o menor entre a entropia da senha e 256 bits. Contra um adversário quântico, a entropia da senha é, no melhor caso para o atacante, reduzida à metade:

Senha	Entropia	Busca clássica	Busca de Grover (no melhor caso)
gerada pelo nikpak (24 símbolos)	cerca de 139 bits	cerca de 2^139 tentativas	cerca de 2^70 iterações, cada uma exigindo uma avaliação coerente de 64 MiB do Argon2id
Seis palavras Diceware aleatórias	cerca de 77 bits	cerca de 2^77 tentativas	cerca de 2^39 iterações do mesmo circuito caro
Uma senha de 10 caracteres escolhida por um humano	tipicamente 30 - 45 bits	viável	viável

A conclusão é a conhecida, dita de forma mais aguda: a senha é o ponto fraco, não a cifra. Use a senha gerada ou uma frase-senha longa e aleatória e o arquivo compactado resiste tanto a atacantes clássicos quanto quânticos por qualquer futuro previsível. O Argon2id ajuda nos dois mundos, porque o custo de cada tentativa é dominado pela memória, que o algoritmo de Grover não torna mais barata.

9.4 "Colher agora, descriptografar depois"

Uma ameaça quântica frequentemente citada é a de um adversário gravar dados criptografados hoje e descriptografá-los quando existir um computador quântico. Para sistemas que trocam chaves com RSA ou curvas elípticas, como conexões TLS ou criptografia de e-mail, isso é real. Um arquivo nikpak não tem troca de chaves: sua chave vem de um segredo que nunca sai da cabeça do usuário ou do gerenciador de senhas. Uma cópia armazenada só pode ser aberta mais tarde adivinhando esse segredo, e os computadores quânticos não tornam isso fundamentalmente mais fácil.

9.5 Limites honestos e o caminho à frente

• "Resistente a computadores quânticos" significa que nenhum algoritmo quântico conhecido vence a busca genérica contra essas primitivas. Não é uma prova; a criptoanálise do ChaCha20 e do Argon2 continua, e o formato é versionado para que parâmetros ou algoritmos possam ser alterados.
• Se o compartilhamento por chave pública um dia for adicionado (criptografar um arquivo compactado para a chave de um destinatário), ele usará um esquema híbrido, X25519 combinado com ML-KEM, para que fique seguro se qualquer um dos componentes resistir.
• A resistência quântica não protege contra erros de implementação. Veja as seções 8.6 e 10.

10 Robustecimento e robustez

Um compactador lê arquivos escritos por estranhos e grava arquivos no disco do usuário, o que o torna um alvo clássico. O nikpak trata todo arquivo compactado como entrada não confiável.

10.1 Extração segura

• Path traversal ("zip slip"). Cada nome de entrada é normalizado: barras invertidas viram barras normais, componentes vazios e . são descartados, e qualquer componente .. faz a entrada ser ignorada com um aviso. Nomes absolutos perdem a raiz, então /etc/passwd é extraído dentro da pasta de destino.
• Nomes do Windows. Ao rodar no Windows, componentes que contêm < > : " | ? * ou caracteres de controle, que terminam em espaço ou ponto, ou que são iguais a um nome de dispositivo reservado (CON, PRN, AUX, NUL, COM1-9, LPT1-9) são rejeitados.
• Links simbólicos. Antes de gravar, cada componente existente do caminho de destino abaixo do destino é verificado; um link nunca é seguido. Um arquivo existente é excluído primeiro e o novo é criado com create_new, que se recusa a abrir um caminho existente, então um link não pode ser usado para redirecionar a gravação.
• Bits privilegiados. Bits setuid, setgid e sticky nunca são restaurados; as permissões são mascaradas para os bits rwx comuns.
• Arquivos com falha. Um arquivo cujo CRC32 não corresponde é excluído, não deixado para trás.

Um arquivo compactado feito à mão contendo ../../evil.txt, /tmp/evil.txt, ..\..\evil.txt e ok/../../evil.txt foi extraído nos testes: nada escapou do destino, as entradas inseguras foram reportadas e ignoradas, e um link simbólico plantado no destino foi recusado.

10.2 Decodificadores limitados

• Os parâmetros Argon2id são verificados quanto à faixa antes de qualquer alocação (seção 8.2).
• Blocos criptografados devem ter comprimento entre 16 bytes e 64 KiB + 16; nomes de no máximo 4096 bytes; blocos de áudio devem declarar um comprimento plausível; regiões BMP são limitadas a 256 MiB; códigos Rice unários são limitados.
• Os decodificadores de áudio e mídia receberam milhares de entradas aleatórias e com bits invertidos nos testes unitários e devem retornar um erro, nunca entrar em pânico nem abortar.
• O código do próprio nikpak não contém blocos unsafe, e a verificação de limites do Rust transforma qualquer erro de lógica que seria um bug de corrupção de memória em C em uma falha limpa.

O nikpak não limita a taxa de expansão de um arquivo compactado, então, como todo compactador, uma "bomba de compactação" deliberadamente criada pode encher um disco ao ser extraída. Teste arquivos desconhecidos com t primeiro, se isso for relevante.

10.3 Criação segura e erros honestos

• O arquivo compactado é gravado em name.nik.tmp e renomeado apenas quando completo; um guarda exclui o arquivo temporário em qualquer falha, então uma execução interrompida nunca deixa um arquivo escrito pela metade nem substitui um bom.
• Se um arquivo ficar mais curto enquanto está sendo compactado, o nikpak aborta com uma mensagem explícita em vez de gravar uma entrada inconsistente. Arquivos ilegíveis, links simbólicos e arquivos especiais são ignorados com um aviso (código de saída 1) e o arquivo compactado nunca é adicionado a si mesmo.
• Os erros são classificados para que scripts possam reagir: um erro de soma de verificação ou de quadro dentro de um arquivo compactado é corrupção (saída 3), uma falha de autenticação é senha errada ou adulteração (saída 11), uma gravação recusada é um erro fatal (saída 2).

11 Benchmarks

Este capítulo relata medições, não alegações. Ele descreve exatamente o que foi medido, inclui os resultados que não favorecem o nikpak e fornece os comandos necessários para repetir tudo.

As seções 11.1 a 11.6 foram medidas com o nikpak 1.1.0, cujo -m5 ainda usava Zstandard. A seção 11.7 compara o nikpak 1.2.0 com RAR, 7-Zip e ZIP em uma máquina.

11.1 Método

Item	Detalhe
Máquina	Máquina virtual Linux x86-64, um núcleo de CPU. Todos os tempos são segundos de relógio nesse único núcleo; máquinas multicore são mais rápidas para as duas ferramentas.
Software	RAR 7.00 (26 Fev 2024, build de avaliação para Linux, formato -ma5); nikpak 1.1.0 compilado em modo release com LTO; FLAC 1.x -8 como referência de áudio.
Configurações do RAR	-m3 (padrão do RAR) e -m5 (melhor). Para o teste de dados gerais, também -s (sólido) e -md256m (dicionário de 256 MB), porque os arquivos do nikpak são sempre sólidos e uma comparação justa exige permitir o mesmo ao RAR.
Verificação	Todos os arquivos compactados do nikpak foram extraídos e comparados com o original (cmp para arquivos de mídia, SHA-256 de todos os 10.949 arquivos para o conjunto geral).

O material de teste

Conjunto	Conteúdo
WAVs da galeria	35 arquivos de som da galeria do LibreOffice: mono de 16 bits, 23 a 11,025 Hz e 12 a 22,050 Hz. Eles contêm apenas cerca de mil valores de amostra distintos (fontes companding) e são um caso deliberadamente desfavorável para a codificação preditiva.
Música	Uma peça multi-instrumental de 100 segundos (piano, cordas, baixo, flauta, bateria) renderizada com TiMidity++ e o conjunto de sons Freepats a 44.1 kHz estéreo de 16 bits (17.4 MB). O SoX derivou uma versão mono de 16 bits a 22.05 kHz, uma mono de 8 bits a 22.05 kHz e uma estéreo de 24 bits a 48 kHz.
MOD	16 módulos do ProTracker da coleção de testes do libxmp.
BMP	6 imagens: cinco fotografias do conjunto de amostras do scikit-image (24 bits, mais uma conversão em tons de cinza de 8 bits de uma delas) e uma textura do TeX Live.
Dados gerais	197.6 MB em 10.949 arquivos: a biblioteca padrão e pacotes do Python, documentação e cabeçalhos C da máquina de teste, com links simbólicos removidos.

Limites deste material de teste A música é sintética: foi renderizada a partir de MIDI e contém passagens repetidas, o que ajuda toda ferramenta baseada em LZ, incluindo a etapa Zstandard depois do NAC. Gravações reais contêm menos repetições exatas, então os tamanhos absolutos serão diferentes. A comparação trata todas as ferramentas igualmente, e o resultado do FLAC no mesmo arquivo confirma que o codec de áudio em si é competitivo, mas leitores com material específico devem medi-lo: nikpak mt faz exatamente isso.

11.2 Arquivos de mídia

Conjunto	Original	RAR 7 -m5	nikpak -m2	nikpak -m5	m5 vs RAR
6 fotografias BMP	9,183,956	2,862,744	2,035,223	1,750,706	38.8 % menor
16 arquivos MOD do ProTracker	2,507,557	1,070,290	966,622	927,973	13.3 % menor
35 WAVs da galeria (mono 16-bit)	2,991,820	1,605,879	1,529,219	1,418,532	11.7 % menor
Música 44.1 kHz estéreo 16-bit	17,371,848	11,024,411	9,415,519	9,411,898	14.6 % menor
Música 22.05 kHz mono 16-bit	4,342,996	3,112,135	2,635,819	2,634,669	15.3 % menor
Música 22.05 kHz mono 8-bit	2,171,520	844,160	742,462	740,751	12.2 % menor
Música 48 kHz estéreo 24-bit	28,362,206	21,467,283 (-m3)	18,689,529	18,688,030	12.9 % menor

Todos os tamanhos estão em bytes. Para o arquivo de 24 bits, o RAR só foi medido em -m3, então essa linha é uma comparação mais fraca que as outras.

O que os filtros de mídia acrescentam

O mesmo nikpak sem os filtros de mídia (versão 1.0, Zstandard simples no nível padrão) é a régua certa para o valor da camada de mídia:

Conjunto	nikpak 1.0 (sem filtros)	nikpak 1.1 -m2	Redução
6 fotografias BMP	3,580,971	2,035,223	43.2 %
16 arquivos MOD do ProTracker	1,260,607	966,622	23.3 %
35 WAVs da galeria (mono 16-bit)	1,876,722	1,529,219	18.5 %
Música 44.1 kHz estéreo 16-bit	15,585,422	9,415,519	39.6 %
Música 22.05 kHz mono 16-bit	3,887,183	2,635,819	32.2 %
Música 22.05 kHz mono 8-bit	1,078,493	742,462	31.2 %

Comparação com o FLAC

Para a música estéreo a 44.1 kHz, o FLAC -8, o codificador de referência dedicado, produz 9,407,019 bytes. O fluxo NAC para o mesmo áudio tem 9,425,305 bytes, a 0.2 %, e o arquivo nikpak finalizado tem 9,415,519 bytes. Para as versões mono de 22 kHz e de 8 bits, o NAC é menor que o FLAC (2,635,446 contra 2,638,954, e 785,890 contra 798,810 apenas para a região de áudio), e para 24 bits o arquivo (18.69 MB) é menor que os 19.12 MB do FLAC. O FLAC é muito mais fraco nos arquivos da galeria (2.50 MB contra 1.61 MB do RAR), pela razão explicada na seção 7.5; é o caso em que os outros filtros justificam seu lugar.

11.3 Dados gerais

Código-fonte e documentos não são mídia, então este teste verifica se os ganhos do nikpak em outros lugares custam algo em arquivos comuns.

Ferramenta e nível	Tamanho (bytes)	Tempo	Extração
nikpak -m5	24,443,483	45.6 s	1.8 s
RAR 7 -m5 -s -md256m	25,862,475	36.2 s
RAR 7 -m5 -s	26,002,812	26.7 s
RAR 7 -m3 -s	26,536,863	16.7 s	1.5 s
nikpak -m4	26,814,023	13.5 s
nikpak -m3	30,329,965	2.0 s
nikpak -m2 (padrão da 1.1)	36,266,743	0.9 s	0.8 s
RAR 7 -m5 (padrão, não sólido)	50,851,230	14.8 s
RAR 7 -m3 (padrão, não sólido)	50,974,773	9.7 s	2.3 s

Lendo a tabela com honestidade:

• Nível máximo: o nikpak produz um arquivo compactado 5.5 % menor que o melhor do RAR (24.4 contra 25.9 MB). O RAR é mais rápido nesse nível (26.7 a 36.2 s contra 45.6 s).
• Tamanho igual: nikpak -m4 fica a cerca de 1 % do nível sólido padrão do RAR em 81 % do tempo (13.5 s contra 16.7 s).
• Níveis rápidos: -m2 troca taxa por velocidade: 18 vezes mais rápido que o -m3 sólido do RAR, e 37 % maior. É o nível para backups e pipelines em que o tempo importa mais que os últimos poucos megabytes.
• Não sólido: os arquivos padrão (não sólidos) do RAR têm quase o dobro do tamanho dos sólidos nesses dados com muitos arquivos pequenos. Quem comparar o nikpak com o RAR deve adicionar -s ao RAR.

11.4 Velocidade em um único arquivo de mídia grande

Operação	nikpak	RAR 7	Tamanho
Criar, rápido / padrão do RAR	1.45 s (-m2)	2.54 s (-m3)	9,415,519 vs 11,128,595
Criar, nível máximo	3.14 s (-m5)	5.87 s (-m5)	9,411,898 vs 11,024,411
Extrair	0.28 s	0.23 s	mesma saída

Em mídia, o nikpak é ao mesmo tempo menor e mais rápido de criar. O RAR extrai um pouco mais rápido; uma razão provável é que a decodificação NAC executa predição inteira para cada amostra, o que custa um pouco mais que a cópia de casamentos que domina a decodificação geral.

11.5 Sobrecarga da criptografia

No conjunto de dados de 222 MB, um arquivo compactado criptografado levou 0.92 s contra 0.64 s não criptografado, e ficou 11,087 bytes (0.03 %) maior. A diferença inclui a derivação Argon2id, então o custo é dominado por uma fração fixa de segundo.

11.6 Reproduzindo os resultados

# media: which filter wins, per file

nikpak mt song.wav tracker.mod photo.bmp

# archive with nikpak and RAR, then compare

nikpak a -q -ep -m2 test.nik *.wav

rar a -ep -m5 -ma5 test.rar *.wav

# fair comparison on many files: give RAR solid mode

rar a -r -s -m5 -ma5 -md256m data.rar data

nikpak a -m5 data.nik data

# verify

nikpak x -o+ test.nik restore\

11.7 Segunda rodada: nikpak, RAR 7, 7-Zip e ZIP

Atualizado para o nikpak 1.2.0. Na primeira versão desta rodada, com o nikpak 1.1.0, o 7-Zip -mx9 estava à frente em texto (por 1.4 %), arquivos de escritório (3.3 %) e código-fonte (8.5 %). O nikpak 1.2.0 adiciona a recompactação Deflate (7.9) e um novo nível máximo construído sobre LZMA2 e PPMd (6.7), e foi medido novamente na mesma máquina com os mesmos arquivos. Os números do RAR, 7-Zip e ZIP vêm da primeira rodada.

As seções 11.2 a 11.5 comparam o nikpak apenas com o RAR. Esta segunda rodada adiciona os dois compactadores que a maioria das pessoas já tem, 7-Zip e o clássico formato ZIP, e dois tipos de arquivos que são compactados todos os dias: texto simples e documentos de escritório (.doc, .docx, .xls, .xlsx, .csv, .pdf). As quatro ferramentas foram executadas uma após a outra na mesma máquina e nos mesmos arquivos, e o RAR foi medido novamente. Os corpora foram reconstruídos das mesmas fontes públicas, então os tamanhos e tempos absolutos diferem dos de 11.2 a 11.4. Compare números dentro desta seção, não entre seções.

Método

Item	Detalhe
Máquina	Máquina virtual Linux x86-64 (Intel Xeon, 2.8 GHz). Cada comando foi fixado em um núcleo de CPU com taskset e executado em uma única thread (nikpak -mt1, RAR -mt1, 7-Zip -mmt=1; o ZIP é single-threaded por design).
Software	nikpak 1.2.0 (build de release); RAR 7.00 (-ma5, sólido); 7-Zip 23.01 (formato .7z, LZMA2, sólido por padrão); Info-ZIP Zip 3.0 e UnZip 6.0 (Deflate).
Níveis	nikpak: o nível rápido -m2 e o máximo -m5, que é o padrão desde a 1.2.1 (e -m4). Outros: padrão e máximo, RAR -m3 -s / -m5 -s, 7-Zip -mx5 / -mx9, ZIP -6 / -9. O RAR recebeu o modo sólido (-s), porque os outros três são sólidos ou, no caso do ZIP, não podem ser.
Cronometragem	Segundos de relógio. Conjuntos abaixo de 50 MB: melhor de três execuções. O conjunto geral: uma execução.
Verificação	Todos os 92 arquivos compactados foram extraídos e comparados com o original usando diff -r. Todos eram idênticos.

O material de teste

Conjunto	Arquivos	Tamanho (bytes)	Conteúdo
Imagens BMP	8	6,987,840	Seis fotografias do conjunto de amostras do scikit-image como BMP de 24 bits, mais uma fotografia em tons de cinza de 8 bits e uma textura de cascalho de 8 bits.
ProTracker MOD	16	2,252,604	Os 16 maiores módulos do ProTracker na coleção de testes do libxmp.
WAVs da galeria	35	2,991,820	Os mesmos 35 sons da galeria do LibreOffice de 11.1.
Música, quatro formatos	4 × 1	53,417,226	Uma nova peça de 100 segundos (piano, cordas, baixo, flauta, bateria) renderizada com TiMidity++ e Freepats a 44.1 kHz estéreo de 16 bits, e então convertida pelo SoX para 22.05 kHz mono de 16 bits e 8 bits e 48 kHz estéreo de 24 bits.
Texto simples	18	11,793,318	Dezoito livros do Project Gutenberg como .txt (Austen, Melville, Shakespeare, a Bíblia King James e outros).
Arquivos de escritório	60	39,100,915	12 relatórios como .docx, .doc e .pdf (texto, títulos, tabelas e algumas fotos) e 8 planilhas de vendas de 500 a 30,000 linhas como .xlsx, .xls e .csv (com fórmulas), salvos pelo LibreOffice.
Dados gerais	11,473	190,454,632	Bibliotecas padrão do Python 3.12 e 3.13, pacotes Python do Debian, cabeçalhos C (/usr/include) e /usr/share/doc. Links simbólicos removidos.

Níveis máximos: tamanho do arquivo

Conjunto	Original	nikpak -m5	RAR 7 -m5	7-Zip -mx9	ZIP -9
8 imagens BMP	6,987,840	3,557,350	4,394,310	4,195,043	4,974,680
16 arquivos MOD do ProTracker	2,252,604	1,127,607	1,264,245	1,166,855	1,408,085
35 WAVs da galeria (mono 16-bit)	2,991,820	1,346,484	1,596,971	1,484,879	1,852,279
Música 44.1 kHz estéreo 16-bit	17,760,408	8,731,989	10,460,042	10,666,922	15,225,764
Música 22.05 kHz mono 16-bit	4,440,136	2,458,867	2,797,026	2,784,080	3,736,722
Música 22.05 kHz mono 8-bit	2,220,090	606,840	725,416	642,341	836,989
Música 48 kHz estéreo 24-bit	28,996,592	18,198,056	21,229,465	25,542,036	26,980,770
18 livros de texto simples (.txt)	11,793,318	2,741,898	3,519,622	3,259,868	4,223,579
60 arquivos de escritório	39,100,915	6,887,729	11,186,217	10,085,779	17,399,998
Dados gerais (11,473 arquivos)	190,454,632	28,175,618	33,606,893	28,879,398	62,198,510

Todos os tamanhos estão em bytes. O menor arquivo compactado em cada linha é mostrado em negrito.

Níveis rápidos: tamanho e tempo de criação

Conjunto	nikpak -m2	RAR 7 -m3	7-Zip -mx5	ZIP -6
8 imagens BMP	54.0 % · 0.39 s	63.0 % · 2.09 s	60.1 % · 3.51 s	71.2 % · 0.35 s
16 arquivos MOD do ProTracker	52.4 % · 0.61 s	56.2 % · 0.43 s	51.9 % · 0.69 s	62.7 % · 0.10 s
35 WAVs da galeria (mono 16-bit)	51.1 % · 0.41 s	53.6 % · 0.71 s	49.6 % · 1.96 s	61.9 % · 0.24 s
Música 44.1 kHz estéreo 16-bit	49.2 % · 1.72 s	59.9 % · 3.60 s	60.1 % · 14.03 s	85.7 % · 0.82 s
Música 22.05 kHz mono 16-bit	55.4 % · 0.58 s	64.1 % · 0.95 s	62.7 % · 2.14 s	84.2 % · 0.22 s
Música 22.05 kHz mono 8-bit	27.4 % · 0.77 s	33.3 % · 0.52 s	28.9 % · 2.13 s	38.2 % · 0.32 s
Música 48 kHz estéreo 24-bit	62.8 % · 2.06 s	73.6 % · 7.54 s	88.1 % · 13.54 s	93.0 % · 1.19 s
18 livros de texto simples (.txt)	35.2 % · 0.11 s	30.4 % · 5.53 s	27.7 % · 11.76 s	36.0 % · 0.89 s
60 arquivos de escritório	38.0 % · 0.22 s	29.5 % · 8.25 s	26.2 % · 21.85 s	44.7 % · 1.83 s
Dados gerais (11,473 arquivos)	25.3 % · 1.67 s	18.0 % · 48.19 s	17.0 % · 93.71 s	32.9 % · 7.32 s

nikpak -m2 contra o nível padrão das outras ferramentas. Cada célula mostra o tamanho do arquivo compactado como porcentagem do original e o tempo de criação em um núcleo. O menor arquivo em cada linha está em negrito.

Dados gerais em detalhe

Ferramenta e nível	Tamanho (bytes)	% do original	Criação	Extração
nikpak -m5	28,175,618	14.8 %	154.3 s	5.6 s
7-Zip -mx9	28,879,398	15.2 %	120.9 s	6.0 s
RAR 7 -m5 -s -md256m	32,350,575	17.0 %	73.6 s	7.0 s
7-Zip -mx5	32,375,802	17.0 %	93.7 s	4.5 s
nikpak -m4	33,295,133	17.5 %	37.8 s	3.3 s
RAR 7 -m5 -s	33,606,893	17.6 %	72.4 s	6.7 s
RAR 7 -m3 -s	34,236,198	18.0 %	48.2 s	5.9 s
nikpak -m2	48,229,284	25.3 %	1.7 s	0.9 s
RAR 7 -m3 (não sólido)	56,038,351	29.4 %	20.2 s	6.9 s
ZIP -9	62,198,510	32.7 %	28.2 s	6.9 s
ZIP -6	62,672,415	32.9 %	7.3 s	5.4 s

Da 1.1.0 para a 1.2.0

Conjunto	nikpak 1.1.0 -m5	nikpak 1.2.0 -m5	7-Zip -mx9	1.2.0 vs 7-Zip
18 livros de texto simples	3,306,819	2,741,898	3,259,868	15.9 % menor
60 arquivos de escritório	10,417,750	6,887,729	10,085,779	31.7 % menor
Dados gerais	31,322,041	28,175,618	28,879,398	2.4 % menor

Lendo os resultados com honestidade

• O nikpak -m5 é o menor em todos os conjuntos. Contra o 7-Zip -mx9, ele é 2.4 a 31.7 % menor; contra o RAR 7 -m5, 10.8 a 38.4 %; e contra o ZIP -9, 19.9 a 60.4 %. Em áudio gravado, o NAC prevê o que compactadores baseados em LZ só conseguem casar: na música de 24 bits, o 7-Zip economiza 12 % e o nikpak 37 %.
• Arquivos de escritório: 31.7 % menores que o 7-Zip. A recompactação Deflate transforma 6.6 MB de .xlsx e 1.9 MB de .docx em XML simples que o LZMA2 compacta muito melhor do que o Deflate fez (6.89 MB contra 10.09 MB). Até o -m4 é 1.3 % menor que o 7-Zip -mx9 e mais rápido (16 s contra 26 s). O preço no -m5 é tempo: 81 s contra 26 s.
• Texto: 15.9 % menor, na metade do tempo. O PPMd vence em prosa (6.4 s contra 12.9 s para criar). Como o PPMd decodifica tão devagar quanto codifica, a extração leva 2.7 s em vez de 0.2 s.
• Código-fonte: 2.4 % menor, uma vantagem estreita. 28.2 MB contra 28.9 MB, em 154 s contra 121 s. Ordenar por tipo de arquivo e escolher o motor em amostras contíguas (6.7) fizeram a diferença.
• Nível rápido -m2: o mais rápido, não o menor. O nikpak -m2 precisa de 1.7 s para o conjunto geral, contra 93.7 s do 7-Zip -mx5 (56 vezes mais longo), 48.2 s do RAR e 7.3 s do ZIP. Ele é menor que o 7-Zip -mx5 em imagens e na maioria dos áudios (arquivos MOD e os WAVs da galeria são 1 a 3 % maiores), mas maior em texto, arquivos de escritório e código-fonte (49.0 % no conjunto geral). Por isso, desde a versão 1.2.1 o nikpak usa -m5 por padrão; o -m2 precisa ser pedido.
• O ZIP é rápido, mas o maior em toda parte. Até o nikpak -m2 vence o ZIP -9 em todos os conjuntos. O ZIP cria arquivos compactados de mídia pequenos mais rápido que o nikpak -m2, porque o Deflate faz muito menos trabalho que o codec NAC, mas é mais lento em texto, arquivos de escritório e código-fonte.
• Extração. O conjunto geral extrai em 0.9 s (nikpak -m2) ou 5.6 s (-m5), contra 6.0 s do 7-Zip, 6.7 s do RAR e 6.9 s do ZIP. Arquivos com fluxos Deflate recompactados extraem mais devagar, porque cada fluxo é reconstruído (2.1 s contra 0.7 s para o conjunto de escritório).
• O RAR nesta máquina. O RAR foi mais lento aqui do que em 11.3 (72 s em vez de 27 s para -m5 -s em uma quantidade semelhante de código-fonte). Máquina e dados diferem, então as duas seções não devem ser misturadas. Dentro desta rodada, cada ferramenta enfrentou as mesmas condições.

O que isso significa para o nikpak

No nível máximo, o nikpak 1.2.0 produz o menor arquivo compactado das quatro ferramentas em todos os conjuntos medidos, 2.4 a 31.7 % menor que o 7-Zip -mx9. O custo é velocidade: o -m5 é single-threaded e mais lento que o 7-Zip em arquivos de escritório e código-fonte. Torná-lo mais rápido está no roteiro (seção 15.2).

12 nikpak e RAR comparados

O RAR é um compactador excelente e amplamente usado, e este capítulo não finge o contrário. Ele expõe onde as medições e o design favorecem o nikpak, onde o RAR está à frente e quem deve escolher o quê.

12.1 Onde o nikpak está à frente

Área	nikpak	Evidência
Áudio, imagens, música de tracker	12 - 39 % menor que RAR 7 -m5 em todos os conjuntos de mídia medidos	Seção 11.2
Código-fonte, nível máximo	5.5 % menor que a melhor configuração sólida do RAR	Seção 11.3
Velocidade no nível rápido -m2	0.9 s contra 9.7 - 16.7 s para 197 MB; 1.45 s contra 2.54 s para um WAV	Seções 11.3, 11.4
Cifra e modo	XChaCha20-Poly1305, autenticada; o RAR5 usa AES-256 em modo CBC, que não é autenticado e depende de somas de verificação separadas	Capítulo 8
Hash de senha	Argon2id, memory-hard (64 MiB); o RAR5 usa PBKDF2-HMAC-SHA256, que é limitado pela CPU e paraleliza de forma barata em GPUs	Seção 8.2
Privacidade dos nomes de arquivo	Sempre criptografados; o RAR precisa da opção -hp	Seção 8.4
Geração de senha	Embutida: senha aleatória forte quando nenhuma é fornecida	Seção 3.3
Evidência de adulteração	Reordenação, truncamento e alterações de cabeçalho são detectados criptograficamente	Seção 8.6
Transparência	Código-fonte completo e formato documentado; implementação em Rust com segurança de memória	Capítulos 5, 10
Distribuição	Um executável estático (janela de arrastar e soltar e linha de comando; cerca de 2.3 MB sem a janela), ou um pequeno instalador para Windows; shareware, gratuito para uso pessoal (3.8)	Capítulo 13

12.2 Onde o RAR está à frente

Área	RAR 7	nikpak hoje
Registros de recuperação	Consegue reparar arquivos danificados	Detecta danos, não consegue repará-los
Arquivos multivolume	Sim	Não
Arquivos autoextraíveis	Sim	Não
Atualizar um arquivo	Adiciona, substitui e exclui arquivos no lugar	Apenas cria ou sobrescreve
Interface gráfica	WinRAR, com integração ao shell	Janela de arrastar e soltar para compactar (3.7); sem integração ao shell, extração pela linha de comando
Velocidade no nível máximo	26.7 - 36.2 s no conjunto geral	45.6 s
Velocidade de extração em mídia	0.23 s para o WAV de 17 MB	0.28 s
Maturidade e alcance	Décadas de testes em campo; milhões de arquivos .rar existentes	Novo; sem auditoria independente; lê apenas .nik

12.3 Resistência quântica em perspectiva

Tanto o nikpak quanto o RAR5 criptografam com uma chave simétrica de 256 bits, então ambos não são afetados pelo algoritmo de Shor e ambos mantêm cerca de 128 bits de segurança contra o de Grover. Nenhuma das duas alegações os distingue. O que o nikpak acrescenta por cima é uma etapa de senha memory-hard (que torna o ataque dominante do mundo real, adivinhar senhas, muito mais caro) e criptografia autenticada (que torna a adulteração detectável). Ele também foi projetado desde o início com a premissa de que nenhuma primitiva de chave pública jamais fará parte do formato do arquivo, e seu roteiro se compromete com um esquema pós-quântico híbrido se o compartilhamento por chave pública for adicionado.

12.4 Qual escolher

• Escolha o nikpak para arquivos de áudio, imagens, música de tracker e código-fonte em que tamanho e velocidade importam, para backups automatizados, para criptografia forte por padrão e quando um formato aberto e documentado é valioso.
• Escolha o RAR quando você precisa de registros de recuperação, arquivos multivolume ou autoextraíveis, atualizações no lugar, ou precisa trocar arquivos com pessoas que só têm ferramentas RAR.
• Use ambos: nada impede um fluxo de trabalho de usar o nikpak para mídia em massa e backups criptografados, mantendo o RAR para distribuição.

12.5 E o 7-Zip e o ZIP?

A seção 11.7 mede o nikpak 1.2 contra o 7-Zip 23.01 e o Info-ZIP 3.0 também. Em resumo:

• Escolha nikpak -m5 para o menor arquivo compactado. Ele é 2.4 a 31.7 % menor que o 7-Zip -mx9 em todos os conjuntos medidos: 31.7 % em arquivos de escritório, 15.9 % em texto e 2.4 % em código-fonte. Escolha nikpak -m2 para backups rápidos (56 vezes mais rápido que o padrão do 7-Zip em código-fonte). O nikpak também tem criptografia mais forte: o 7-Zip usa AES-256 com uma derivação de chave SHA-256 que não é memory-hard, e só oculta nomes de arquivo com -mhe.
• Escolha o 7-Zip quando o tempo importa mais no nível máximo (ele é mais rápido em grandes conjuntos de escritório e código-fonte), quando você precisa que o nível padrão dele seja pequeno em documentos, ou quando precisa abrir os muitos formatos que o 7-Zip lê.
• Escolha o ZIP apenas por compatibilidade. Todo sistema operacional o abre sem software extra, mas o nikpak -m5 é 19.9 a 60.4 % menor, e a criptografia tradicional do ZIP é fraca.

13 Compilando, implantando e integrando

13.1 Windows com PowerShell

O nikpak é escrito em Rust e compilado com Cargo. No Windows, o Rust precisa de um linker C/C++, que vem das Visual Studio Build Tools. Em um PowerShell de administrador, instale ambos uma vez e reabra o PowerShell:

winget install Rustlang.Rustup

$o = '--wait --passive --add Microsoft.VisualStudio.Workload.VCTools'

$o += ' --includeRecommended'

winget install Microsoft.VisualStudio.2022.BuildTools --override $o

Se o winget não estiver disponível, instale o Rust pelo rustup.rs e as Build Tools for Visual Studio com a carga de trabalho Desktop development with C++. Depois, na pasta que contém os fontes:

.\build.ps1 # builds dist\nikpak.exe and dist\unNik.exe

.\build.ps1 -Test # runs the unit tests first

# if PowerShell refuses to run scripts:

powershell -ExecutionPolicy Bypass -File .\build.ps1

O build.ps1 verifica se o Cargo está instalado (e diz como instalá-lo se não estiver), executa a compilação, explica a causa usual se falhar e copia o executável para dist\nikpak.exe.

O instalador do Windows

.\build.ps1 -Installer (ou npm run installer) também compila o programa de instalação dist\nikpak--setup.exe com Inno Setup 6.3 ou mais novo (instale-o uma vez com winget install JRSoftware.InnoSetup). O script é installer\nikpak.iss; a versão é tirada do Cargo.toml. É esse arquivo de instalação que é enviado para sites de shareware e downloads.

• Por padrão, ele instala apenas para o usuário atual, sem direitos de administrador nem prompt do UAC, em %LOCALAPPDATA%\Programs\NikPak. Sua primeira página oferece "instalar para todos os usuários" (Arquivos de Programas, exige direitos de administrador).
• Ele mostra o LICENSE.txt para aceitação e instala nikpak.exe, unNik.exe, os ícones, LICENSE.txt, THIRD-PARTY-NOTICES.txt e CHANGELOG.md. Adiciona uma entrada no menu Iniciar, um ícone opcional na área de trabalho e, se pedido, a pasta no PATH para a linha de comando. Registra um desinstalador em Configurações > Aplicativos.
• Atalhos: NikPak, unNik e a licença no menu Iniciar; NikPak na área de trabalho (sempre) e unNik na área de trabalho como opção.
• Arquivos .nik são sempre registrados (desde a 1.5.2): eles ganham seu próprio ícone (nikfile.ico, uma página com um zíper, como os arquivos .zip), o nome de tipo "Arquivo NikPak", e um duplo clique os abre no unNik ("Abrir com o unNik" no menu de clique direito). O unNik também é listado em "Abrir com" e em Aplicativos padrão. O desinstalador remove o registro. Se os arquivos .nik já estivessem definidos para abrir com outro programa, o Windows mantém essa escolha até o unNik ser escolhido uma vez em "Abrir com".
• A tela final "Iniciar o NikPak" inicia o NikPak como usuário normal, nunca como administrador, para que o arrastar e soltar funcione. Atualizações instalam sobre a versão anterior (AppId fixo). A licença em %APPDATA%\nikpak é mantida na atualização e na desinstalação. O instalador nunca contém chaves nem arquivos de chave.
• O instalador roda em inglês ou francês, acompanhando o Windows. Antes de publicar, assine o nikpak.exe e o instalador com um certificado de assinatura de código, para que o SmartScreen do Windows não avise sobre um editor desconhecido.

O buildall.ps1 compila tudo o que é publicado em uma execução — nikpak.exe, unNik.exe, os dois instaladores e SHA256SUMS.txt — copia-os para binaries\, reconstrói o site e o envia por FTP (-NoUpload pula o envio). O segundo instalador, unnik--setup.exe (installer\unnik.iss), instala o unNik sozinho, o navegador gratuito de arquivos compactados; quando o NikPak já está instalado, ele instala somente o programa, para que os menus nunca apareçam em dobro.

13.2 Compilando com npm

Projetos Rust não usam npm, então o npm nunca é necessário. Por conveniência, o projeto contém um pequeno package.json cujos scripts simplesmente chamam o Cargo, para que um desenvolvedor acostumado a um fluxo Node.js possa digitar comandos familiares:

npm run build # cargo build --release

npm run dist # build.ps1 -> dist\nikpak.exe

npm test # cargo test --release

npm run clean # cargo clean

13.3 Um executável autossuficiente

O arquivo .cargo/config.toml vincula o runtime C estaticamente para os alvos MSVC do Windows. O nikpak.exe resultante (vários MB com a interface gráfica, cerca de 2.3 MB sem ela) não tem, portanto, dependências de DLL e não precisa do Visual C++ Redistributable nas máquinas em que roda. Copie-o para uma pasta no PATH para usá-lo em qualquer lugar. O perfil de release habilita otimização completa, otimização de tempo de vinculação, uma única unidade de geração de código, remoção de símbolos e panic = abort para um binário pequeno e rápido.

13.4 macOS e Linux

./build.sh # builds and copies the result to dist/nikpak

# or: cargo build --release

sudo cp dist/nikpak /usr/local/bin/

No macOS, instale primeiro as ferramentas de linha de comando (xcode-select --install); no Debian ou Ubuntu, instale um compilador C (sudo apt install build-essential). O próprio Rust vem de curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh. A biblioteca de compactação é compilada a partir de seus fontes C pelo Cargo, então nenhuma biblioteca do sistema é necessária.

Os downloads de macOS e Linux do site são feitos por ./package-unix.sh, que compila o nikpak e o unNik e os empacota com um install.sh em binaries\nikpak--macos.zip (um binário universal: Intel + Apple silicon) ou binaries\nikpak--linux-.tar.gz. Defina ZIG=1 no Linux para compilar com cargo-zigbuild contra glibc 2.28, para que os programas também rodem em distribuições mais antigas.

13.5 Dependências

Desde a versão 1.2, o nikpak precisa de Rust 1.89 ou mais novo. O build.ps1 e o build.sh verificam a versão instalada e executam rustup update stable quando ela é mais antiga. Com npm, execute rustup update uma vez antes de npm run build.

O nikpak depende de um pequeno conjunto de crates maduros. As versões exatas deles são fixadas no Cargo.lock, que faz parte do pacote de fontes, então toda compilação usa o mesmo código.

Crate	Finalidade
zstd	Compactação Zstandard, com multithreading
chacha20poly1305	XChaCha20-Poly1305 e a construção STREAM (RustCrypto)
argon2	Derivação de chave Argon2id (RustCrypto)
rand	Acesso ao gerador aleatório seguro do sistema operacional
zeroize	Apagar chaves e senhas da memória
rpassword	Ler uma senha sem eco, em todas as plataformas
crc32fast	CRC32 rápido
glob	Expansão de curingas (o PowerShell não expande curingas para programas nativos)
liblzma	Motor LZMA2 para o -m5 (liblzma, compilado estaticamente a partir de fontes C)
ppmd-rust	Motor PPMd variante I para texto no -m5
preflate-rs	Recompactação Deflate bit a bit exata (Microsoft, Apache-2.0); uma cópia vendored em vendor/preflate-rs cujo codificador de entropia LGPL (cabac) é substituído pelo range coder do próprio nikpak, para que o nikpak não contenha código LGPL. Exige Rust 1.89 ou mais novo
eframe / egui	A interface gráfica (feature cargo opcional gui, ativada por padrão)
rfd	Diálogo nativo de pasta para o Procurar
ed25519-dalek	Verificação de assinaturas de chaves de licença (seção 3.8)
rustybuzz, unicode-bidi	Conformação e ordenação da direita para a esquerda de hindi, bengali e árabe na janela (feature cargo opcional gui)

13.6 Automação por script

Códigos de saída previsíveis e a senha por variável de ambiente tornam o nikpak fácil de automatizar. Um backup em PowerShell que trata avisos como aceitáveis e qualquer coisa pior como falha:

$archive = "D:\Backups\docs-$(Get-Date -Format yyyy-MM-dd).nik"

# the password comes from a file or secret store, not from the script

$env:NIKPAK_PASSWORD = Get-Content "$env:USERPROFILE\.nikpak-secret"

nikpak a -p -m3 -inul $archive "$env:USERPROFILE\Documents"

if ($LASTEXITCODE -gt 1) { throw "nikpak failed: $LASTEXITCODE" }

nikpak t -inul $archive # verify what was written

if ($LASTEXITCODE -ne 0) { throw "archive verification failed" }

O mesmo em um script de shell, usando o comando de lista simples para alimentar outras ferramentas:

export NIKPAK_PASSWORD="$(cat ~/.nikpak-secret)"

nikpak a -p -m3 -inul "backup-$(date +%F).nik" ~/Documents || [ $? -eq 1 ]

nikpak lb backup-2026-10-16.nik | grep -i '\.wav$'

13.7 Total Commander

A integração descrita na seção 3.6 depende de o nikpak seguir a sintaxe do RAR. Uma lista de verificação curta: registre a extensão nik; use a para empacotar e x para desempacotar; deixe o front-end passar @listfile para listas longas de arquivos; forneça -o+ ou -y para extração sem supervisão; e passe a senha com -p ou a variável NIKPAK_PASSWORD, já que um front-end gráfico não tem console para perguntar.

14 Testes e verificação

Como um compactador guarda os dados das pessoas, o nikpak é testado em quatro níveis.

14.1 Testes unitários

Trinta e quatro testes automatizados rodam com cargo test --release:

Área	O que é verificado
Fluxo de criptografia	Viagens de ida e volta em 0, 1, 100, 65,535, 65,536, 65,537, 131,072, 131,077 e 327,803 bytes (ao redor dos limites de blocos de 64 KiB); um cabeçalho errado (dado associado), uma chave errada e truncamento devem todos falhar.
Limites da derivação de chave	Parâmetros Argon2id hostis (memória enorme, zero passes, zero lanes, passes excessivos) são recusados.
Codec de áudio NAC	Viagem de ida e volta sem perdas para áudio de 8/16/24/32 bits, 1, 2, 3 e 6 canais, nove tipos de sinal (silêncio, seno ruidoso, ruído branco, onda quadrada em escala total, rampa, impulso único, máximo constante, bits baixos desperdiçados, mínimo constante), oito comprimentos de bloco de 1 a 5000 amostras, três níveis de esforço e codificação verbatim forçada.
Métodos de áudio	NAC, Shuffle e Shuffle+Delta em todas as profundidades de bits, contagens de canais, ordens de bytes e sinais, incluindo blocos que não se dividem uniformemente.
Detecção e arquivos	WAV (mono, estéreo, 8/16/24/32 bits, extensible, seis canais, blocos finais, bytes restantes ímpares, comprimento de dados zero e grande demais), AIFF, MOD (também truncado) e BMP (8/24/32 bits, preenchimento de linha, dados finais); WAV de ponto flutuante, arquivos minúsculos e texto não devem ser detectados; cada arquivo faz viagem de ida e volta por cada filtro aplicável.
Robustez	Milhares de blocos aleatórios e com bits invertidos enviados ao decodificador de áudio e ao de mídia: eles devem retornar erros, nunca entrar em pânico nem esgotar a memória.
Enquadramento e auxiliares	Enquadramento de blocos com dados finais, higienização de caminhos, correspondência de curingas e filtros, formatação de datas, geração de senha.
Recompactação Deflate	Contêineres ZIP nos níveis Deflate 1, 3, 6 e 9, PDF com dois fluxos zlib, gzip com três membros, não contêineres; 400 fluxos recompactados danificados ou truncados devem falhar de forma limpa (os pânicos do preflate são capturados).
Blocos multi-motor	Viagens de ida e volta por blocos zstd, LZMA2 e PPMd ao redor do limite de quadro de 256 KiB; 300 corpos danificados ou truncados; parâmetros de motor hostis; o teste PPMd/LZMA2.
Interface gráfica	Executado em um display virtual (Xvfb): telas de inatividade, hover, progresso e conclusão verificadas visualmente; uma pasta solta é compactada e extraída byte a byte; Cancelar e fechar durante a compactação não deixam nenhum arquivo para trás; sem display, cai para o texto de uso.
Licença	Chaves feitas pelo nikpak-keygen e pelo kit PHP são idênticas e aceitas; nome, e-mail, tipo ou chave alterados, e chaves assinadas por outra chave, são rejeitados. Em um display virtual: lembrete em ambas as ordens de botões, erro de chave errada, registro bem-sucedido, reinício sem lembrete; o texto permanece dentro das caixas.
Idiomas	Cada idioma traduz cada texto com os mesmos placeholders; sinais vocálicos devanágari e junções árabes são conformados; em um display virtual, os dez idiomas foram verificados tela por tela (lembrete, inatividade, progresso, conclusão, Sobre, registro, menu de idioma); escolher um idioma o salva e reinicia o nikpak nele.
API de arquivo	Ler o índice, extrair um arquivo de dentro de uma pasta (ele chega sem o caminho da pasta), excluir uma pasta com seu conteúdo e excluir tudo, para arquivos -m5, zstd + criptografia e armazenados; uma senha errada é reportada como tal.
Navegador de arquivos compactados	Construção de árvore com pastas implícitas, detecção e decodificação de texto (UTF-8, UTF-16, Windows-1252), quebra de linha e pesquisa no visualizador. Em um display virtual: abrir, senha, navegação, seleção, pesquisa, visualizador, extrair, excluir e testar, em vários idiomas.
Skins e menu do gerenciador de arquivos	Os arquivos de menu do Linux são gerados e verificados; um arquivo para uma seleção iniciada como três programas; --add-here com três itens e --extract-here / --extract-to sob um display virtual; arquivos criptografados pedem sua senha e extraem arquivos idênticos; todo novo texto de interface é traduzido nos dez idiomas (a asserção de que cada idioma traduz cada texto).

14.2 Testes de ponta a ponta

• Todo arquivo compactado de benchmark foi extraído e comparado com sua fonte, byte a byte (SHA-256 para o conjunto de 10.949 arquivos), em vários níveis.
• Um arquivo misto (WAV, MODs, BMP, texto, dados aleatórios, subpastas) foi criado, listado, testado, extraído por completo, e um único arquivo foi extraído do meio dele.
• O mesmo arquivo foi criado com criptografia, testado com a senha certa e a errada, e extraído.
• Arquivos gravados pela versão anterior do formato (1.0) foram abertos pela 1.1.
• A entrada interativa de senha foi exercitada por um pseudo-terminal: senhas iguais, uma divergência, uma entrada vazia (geração), senhas certa e errada ao abrir.

14.3 Testes de ataque

Adulteração, truncamento, reordenação de blocos, manipulação de cabeçalho, arquivos-lixo e os arquivos de path traversal da seção 10.1 foram executados contra cada candidato a release. Os resultados estão tabulados nas seções 8.6 e 10.1; o resultado esperado em cada caso é uma recusa, uma mensagem clara e um código de saída diferente de zero, nunca um pânico e nunca uma gravação fora do destino.

14.4 Defeitos encontrados pelos testes

A campanha de testes é a razão de vários defeitos não existirem no programa lançado. Dois exemplos: uma busca de parâmetro Rice que falhava para áudio de 32 bits e teria gravado um código de vários gigabytes (encontrada pela matriz de testes unitários e corrigida), e uma falha de soma de verificação do zstd que era reportada com o código de saída genérico 2 em vez de 3 (encontrada nos testes de adulteração e corrigida). Um terceiro exemplo é a própria metodologia de benchmark: a primeira comparação com o RAR usou o padrão não sólido dele, o que favoreceu o nikpak em código-fonte; ela foi refeita em modo sólido, e os resultados do capítulo 11 são os corrigidos.

15 Limitações e roteiro

15.1 Limitações atuais

Limitação	Detalhe e solução alternativa
Sem registros de recuperação, volumes ou SFX	O dano é detectado, não reparado (mantenha uma segunda cópia dos arquivos importantes); divida arquivos grandes com uma ferramenta geral, se necessário.
Sem atualização no lugar	O formato é um único fluxo sólido. Excluir (nikpak d, ou Excluir no unNik) grava o arquivo novamente; adicionar arquivos a um arquivo existente não é suportado: crie um novo arquivo ou sobrescreva com -o+.
Acesso sequencial	Extrair um arquivo de um arquivo compactado muito grande lê o que o precede (entradas de mídia são puladas sem decodificação); o unNik para de ler após o último arquivo escolhido.
Cobertura de mídia	WAV e AIFF PCM inteiro, MOD do ProTracker, BMP sem compactação. WAV float, ADPCM, XM/S3M/IT e imagens compactadas são armazenados com compactação normal.
Memória em níveis altos	Arquivos -m4 e -m5 usam uma janela de 128 MiB; descompactá-los exige essa quantidade de memória.
Nível máximo -m5	Single-threaded e o nível mais lento. Criar exige até cerca de 1.1 GB de memória; extrair, até cerca de 350 MB.
Links simbólicos e datas	Links são ignorados ao compactar e recusados ao extrair; as datas são listadas em UTC.
Revisão de segurança	Não auditado de forma independente.
Builds para Windows e macOS	Desenvolvido, testado e avaliado em Linux. Os caminhos de código específicos de Windows e macOS foram revisados à mão, mas ainda não foram exercitados nesses sistemas: rode cargo test --release lá antes de confiar em um build.

15.2 Roteiro

Item	Finalidade
Registros de recuperação	Paridade Reed-Solomon para que arquivos danificados possam ser reparados, o principal recurso que falta aos usuários do RAR.
Arquivos multivolume e suporte a atualização	Dividir arquivos grandes, adicionar e substituir arquivos.
Compartilhamento por chave pública com esquema híbrido	Criptografar um arquivo compactado para a chave de um destinatário com X25519 combinado com ML-KEM, seguro se qualquer um dos componentes resistir.
Mais filtros de mídia	Áudio de ponto flutuante, trackers XM/S3M/IT, recompactação de PNG, um filtro 2-D para TGA e TIFF sem compactação.
Leitura de ZIP e RAR, integração ao shell	Desempacotar os formatos comuns no unNik e arrastar arquivos para fora do unNik, para que o nikpak possa ser a única ferramenta instalada. (Os menus de contexto do Explorer e do Finder chegaram na 1.5.5, seção 3.11.)
Nível máximo mais rápido	O -m5 é single-threaded e até três vezes mais lento que o 7-Zip -mx9 em arquivos de escritório: blocos LZMA2 e PPMd multithread, deduplicação de arquivos idênticos e um filtro BCJ para executáveis.
Revisão de segurança externa	Uma auditoria independente do código criptográfico e do extrator.

Licença: o NikPak é shareware de código fechado, © 2026 Nicolas Choukroun, distribuído pela Nikkoid LLC (LICENSE.txt, seção 3.8); o unNik é freeware (seção 3.9). Os componentes de código aberto que ele contém estão listados com suas licenças no THIRD-PARTY-NOTICES.txt, que deve acompanhar cada cópia. Mantenha a chave privada de licenças (keys/nikpak-private.key) fora de todo pacote publicado e da raiz web. Mantenha o Cargo.lock no repositório para que os builds sejam reproduzíveis, e rode cargo test --release no job de integração contínua de cada plataforma que você suporta.

A Apêndice A: constantes e limites do formato

Item	Valor
Número mágico	89 4E 49 4B 0D 0A 1A 0A
Versão do formato	3 (leitores aceitam 1, 2 e 3)
Tamanho do cabeçalho	12 bytes; 59 bytes quando criptografado
Tipos de registro	0 END, 1 FILE, 2 DIR, 3 MEDIA
Métodos de arquivo	0 armazenar, 1 Zstandard, 2 blocos multi-motor
Motores de bloco	1 Zstandard; 2 LZMA2 (dicionário de até 128 MiB gravado, 1.5 GiB aceito); 3 PPMd8 (ordem 8, 192 MiB gravado; ordem 2-16, 1 GiB aceito)
Recompactação Deflate	ZIP, PDF, gzip; arquivo de até 512 MiB; por fluxo, até 512 MiB de dados simples e 64 MiB de correções
Comprimento máximo do nome	4096 bytes
Bloco criptografado	64 KiB de texto simples + tag de 16 bytes, comprimento u32 big-endian na frente
Argon2id (gravado)	64 MiB, 3 passes, 4 lanes, sal de 16 bytes, chave de 32 bytes
Argon2id (aceito)	memória 8 x lanes .. 1 GiB, passes 1 .. 64, lanes 1 .. 64
Nonce do fluxo	prefixo aleatório de 19 bytes + contador de 32 bits + flag final de 1 byte = 24 bytes
Comprimento mínimo da senha	8 caracteres
Senha gerada	24 caracteres, alfabeto de 56 símbolos, cerca de 139 bits
Tamanho mínimo de arquivo de mídia	8 KiB (região de pelo menos 4 KiB)
Bloco NAC	4096 quadros de amostra; bloco Shuffle de 32768 quadros
Teste	até três janelas de 768 KiB (5 %, 45 %, 85 %); região inteira se até 3 MiB; margem de 2 %
Limite da região BMP	256 MiB
Janela Zstandard	padrão; 2^27 com casamento de longa distância em -m4 e -m5
Threads	1 .. 256 (-mt)

B Apêndice B: glossário

Termo	Significado
AEAD	Criptografia autenticada com dados associados: criptografa e detecta qualquer modificação, também de dados enviados em claro (como o cabeçalho).
Argon2id	Uma função de hash de senha memory-hard padronizada na RFC 9106; transforma uma senha em uma chave a um custo de memória deliberadamente alto.
CRC32	Uma soma de verificação de 32 bits que detecta danos acidentais. Não é um recurso de segurança.
FSE	Entropia de estados finitos: o codificador de entropia baseado em tabelas usado pelo Zstandard.
Algoritmo de Grover	Um algoritmo quântico de busca com aceleração quadrática; reduz à metade o comprimento efetivo das chaves simétricas.
LPC	Codificação preditiva linear: prever uma amostra a partir de uma soma ponderada das anteriores.
Levinson-Durbin	Uma recursão que calcula coeficientes ótimos de preditor de todas as ordens a partir da autocorrelação de um sinal.
LZMA2	O algoritmo de cadeia Lempel-Ziv-Markov usado pelo 7-Zip e pelo xz: casamento LZ77 com análise ótima e um range coder binário.
MED	Detector de borda por mediana: um preditor de pixel do codificador de imagens LOCO-I / JPEG-LS.
Memory-hard	Uma função cujo custo é dominado pela memória, o que limita a aceleração disponível em GPUs e chips personalizados.
NAC	O codec de áudio sem perdas do nikpak.
PPMd	Prediction by Partial Matching (variante I): prevê cada byte a partir dos até 8 bytes anteriores; muito forte em texto.
preflate	Um método (e biblioteca) que transforma um fluxo Deflate em seus dados simples mais pequenas correções, a partir dos quais o fluxo Deflate idêntico pode ser reconstruído.
Codificação Rice	Um código simples e rápido para números com distribuição aproximadamente geométrica: um quociente unário e um número fixo de bits baixos.
Algoritmo de Shor	Um algoritmo quântico que fatora inteiros e calcula logaritmos discretos, quebrando RSA e a criptografia de curvas elípticas.
Arquivo sólido	Um arquivo compactado como um único fluxo contínuo, para que a redundância entre arquivos possa ser explorada.
STREAM	Uma construção que criptografa uma mensagem longa como blocos autenticados com contador e flag de último bloco no nonce.
Mapeamento zig-zag	Mapear inteiros com sinal para sem sinal (0, -1, 1, -2 ... para 0, 1, 2, 3 ...), para que pequenas magnitudes virem números pequenos.
Zstandard	Um formato moderno de compactação aberto que combina casamento LZ77 com codificação de entropia Huffman e FSE.

Versão 1.6.2 · Outubro de 2026 Página 19