Usando a API de compactação

Muitos aplicativos precisam usar compactação e descompactação de dados sem perdas. A API de compactação simplifica isso expondo algoritmos de compactação do Windows por meio de uma API pública. Cada algoritmo de compressão tem um conjunto de propriedades que controla o seu comportamento. A API de compactação expõe uma interface que permite ao desenvolvedor definir ou consultar os valores dessas propriedades. Todas as propriedades para os algoritmos de compressão suportados têm valores padrão que representam valores comumente usados dessas propriedades. Se uma propriedade for necessária para compactação e descompressão, os valores padrão serão idênticos, garantindo que valores idênticos sejam usados para compactação e descompressão.

Seleção do algoritmo de compressão

Depois que um desenvolvedor decide que um aplicativo precisa compactar ou descompactar dados, a próxima etapa é escolher um algoritmo de compactação. Isso pode depender de testes para encontrar a combinação de melhor desempenho de velocidade, taxa de compressão e requisito de memória para um aplicativo específico. A lista a seguir fornece uma comparação relativa dos algoritmos de compactação atualmente suportados pela API de compactação. Nem todas as opções estão disponíveis para cada algoritmo de compactação, e a comparação é aproximada porque o desempenho pode depender dos dados de entrada.

XPRESS (COMPRESS_ALGORITHM_XPRESS)

• Muito rápido com baixos requisitos de recursos
• Taxa de compressão média
• Altas velocidades de compressão e descompressão
• Baixa necessidade de memória
• Suporta a opção COMPRESS_INFORMATION_CLASS_LEVEL disponível na enumeração COMPRESS_INFORMATION_CLASS. O valor padrão é (DWORD)0. Para alguns dados, o valor (DWORD)1 pode melhorar a taxa de compressão com uma velocidade de compressão ligeiramente mais lenta.

XPRESS com codificação Huffman (COMPRESS_ALGORITHM_XPRESS_HUFF)

• A taxa de compressão é superior a COMPRESS_ALGORITHM_XPRESS
• Taxa de compressão média
• Velocidades de compressão e descompressão médias a altas
• Baixa necessidade de memória
• Suporta a opção COMPRESS_INFORMATION_CLASS_LEVEL na enumeração COMPRESS_INFORMATION_CLASS. O valor padrão é (DWORD)0. Para alguns dados, o valor (DWORD)1 pode melhorar a taxa de compressão com uma velocidade de compressão ligeiramente mais lenta.

MSZIP (COMPRESS_ALGORITHM_MSZIP)

• Utiliza mais recursos do que COMPRESS_ALGORITHM_XPRESS_HUFF
• Gera um bloco compactado semelhante ao RFC 1951.
• Taxa de compressão média a alta
• Velocidade de compressão média e alta velocidade de descompressão
• Requisito de memória média

LZMS (COMPRESS_ALGORITHM_LZMS)

• Bom algoritmo se o tamanho dos dados a serem compactados for superior a 2MB.
• Alta taxa de compressão
• Baixa velocidade de compressão e alta velocidade de descompressão
• Requisito de memória médio a alto
• Suporta a opção COMPRESS_INFORMATION_CLASS_BLOCK_SIZE na enumeração COMPRESS_INFORMATION_CLASS. Um tamanho mínimo de 1 MB é sugerido para obter uma melhor taxa de compressão.

Decidindo qual modo de API de compactação usar

Depois que um desenvolvedor seleciona o algoritmo de compactação, a próxima decisão é qual dos dois modos da API de compactação usar: modo de buffer ou modo de bloco. O modo buffer foi desenvolvido para facilitar o uso e é recomendado para a maioria dos casos.

O modo de buffer divide automaticamente o buffer de entrada em blocos de um tamanho apropriado para o algoritmo de compactação selecionado. O modo de buffer formata e armazena automaticamente o tamanho do buffer não compactado no buffer compactado. O tamanho do buffer compactado não é salvo automaticamente e o aplicativo precisa salvá-lo para descompactação. Não inclua o sinal COMPRESS_RAW no parâmetro Algorithm ao chamar CreateCompressor e CreateDecompressor para usar o modo de buffer. Para obter um exemplo de código de um aplicativo de modo de buffer, consulte a seção Usando a API de compactação no modo de buffer.

O modo de bloco permite que o desenvolvedor controle o tamanho do bloco, mas requer mais trabalho a ser feito pelo aplicativo. Ao usar o modo de bloco, o aplicativo tem que quebrar os dados de entrada em partes de tamanho apropriado ao compactar e, em seguida, colocar as peças novamente juntas ao descompactar. O modo de bloco falhará se o tamanho do buffer de entrada for maior do que o tamanho do bloco interno do algoritmo de compactação. O tamanho do bloco interno é de 32KB para o MSZIP e 1GB para os algoritmos de compressão XPRESS. O tamanho do bloco interno para LZMS é configurável até 64GB com um aumento correspondente no uso de memória. O tamanho do buffer compactado não é salvo automaticamente e o aplicativo também precisa salvá-lo para descompactação. O valor do parâmetro UncompressedBufferSize de Descompactar deve ser exatamente igual ao tamanho original dos dados não compactados e não apenas ao tamanho do buffer de saída. Isso significa que seu aplicativo deve salvar o tamanho original exato dos dados não compactados, bem como os dados compactados e o tamanho compactado, ao usar o modo de bloco. Inclua o flag COMPRESS_RAW no parâmetro Algoritmo ao invocar CreateCompressor e CreateDecompressor para usar o modo de bloco. Para obter um exemplo de código de um aplicativo de modo de bloco, consulte a seção Usando a API de compactação no modo de bloco.

Alocação de memória personalizada

Os aplicativos de modo buffer e bloco têm a opção de especificar uma rotina de alocação de memória personalizada quando chamam CreateCompressor e CreateDecompressor. O parâmetro AllocationRoutines especifica a estrutura COMPRESS_ALLOCATION_ROUTINES que contém a rotina de alocação de memória. O aplicativo pode então definir o tamanho do bloco para o compressor usando SetCompressorInformation. Consulte a seção Usando a API de compactação no modo de bloco para obter um exemplo de uma rotina de alocação personalizada simples.