Duda sobre compresion-descompresion ZIP

[OfTheVara]

¿sabeis si en el proceso compresion-descompresion con el algoritmo ZIP se puede producir algun fallo o es inequívoco?

[fran800m]

Hombre entiendo que cualquier proceso es factible de petar.
¿Y si hay error al leer de disco el contenido a comprimir?
¿Y si hay error al escribir en disco el contenido comprimido?

Si concretas algo más igual te podemos ayudar.

Un saludo,

[El Benjo]

Si tu duda es si hay posibilidad de que el algoritmo se equivoque, entonces descuida que el algoritmo por el que se lleva a cabo la compresión y la descompresión es inequívoco. Sin embargo, como te comentan arriba, siempre existe la posibilidad de errores en el disco o cosas imprevista como un apagón.

[HCK.]

¿sabeis si en el proceso compresion-descompresion con el algoritmo ZIP se puede producir algun fallo o es inequívoco?

Si te refieres a que la compresión quede corrupta, y que al descomprimirla futuramente el resultado sea un archivo dañado o diferente, es posible.

Siendo un simple .zip, con bajo ratio de compresión, (tipica compresion predeterminada) es muy poco probable... Pero según se aumenta el ratio o grado de compresión en un archivo comprimido, será mas propenso a errores por perdida de datos en el mismo.

Por ejemplo, hace tiempo se publicaban en la red juegos ultra comprimidos en archivos de pocos megas cuando en realidad ocupaban cientos.
3/4 de esos juegos al descargarlos y descomprimirlos, aparte de tardar siglos en descomprimirse, quedaban corruptos e injugables, por utilizar un ratio de compresión altos donde se han perdido datos del archivo original.

Espero haber sido técnico con la respuesta.

Un saludo

[fran800m]

HCK. me parece interesantísimo lo que has comentado.

Nunca me he interesado especialmente por algoritmos de compresión, más allá de lo que todos sabemos.

Tenía entendido que hay algoritmos de compresión con y sin pérdida.

MP3 y todos los relacionados con audio/video moderno son con pérdida (creo), y suponía que zip, rar, 7zip, etcétera, todos los destinados a datos en general operaban sin pérdida, pues si perdemos o desordenamos un bit en un binario ... Ya la hemos liado xD

Mi duda es, ¿por qué se produce la corrupción a altos ratios?

a) No son 100% sin pérdida.

b) En principio son 100% sin pérdida, pero cuando realizamos los cálculos son tan complejos que (por ejemplo) un double no tiene la suficiente precisión para almacenar un valor, se produce un ligerísimo redondeo .... Y ya tenemos un bonito zip corrupto.

Si me pudieras comentar este tema te lo agradecería mucho.

Un saludo,

[HCK.]

Bueno, te explico un poco comparando la manera matemática de como funcionan generalmente y luego como yo he llegado a entenderlo. Mi fuerte no son los algoritmos pero con los años y tras leer un poco, de lo poco que me ha llegado a interesar, he entendido la base creo. Y si estoy equivocado y alguien me corrige, será un conocimiento nuevo muy agradecido .

Todo algoritmo de compresión puede tener pérdidas... En algunos las pérdidas es la clave de la compresión, cuanto menos material, al ser posible el mas irrelevante, menos espacio ocupan... Es lo que sucede con el MP3, JPEG en imagen y demás... Que se basan en eliminar calidad ganando mas memoria. Esto da lugar a archivos apenas corruptos, puesto que en el proceso de compresión ves lo que se pierde y si te beneficia esa pérdida o no.

En cambio con los algoritmos de compresión sin pérdida es diferente. La condición de si se producirá una pérdida depende principalmente del contenido que vayas a comprimir (mas complejo como volúmenes virtuales, binarios... ) a simples textos... Y del ratio que quieras comprimirlo.

Explicándome mejor... Imaginemos que queremos comprimir un volumen cifrado de Truecrypt, y luego aparte un archivo de texto.
Hagamos el ejemplo de que lo abrimos con un editor en hexadecimal y el contenido es algo así:

"7y-#+€-72+%&38*+......"

El algoritmo de cifrado, al intentar comprimir esto, tendrá una tolerancia limitada a operaciones simples, por ejemplo si tenemos en una cadena siete sietes, o caracteres repetidos, se limitará ha hacer una operación que al descomprimirlo, el algoritmo pueda generar la misma cadena sin problemas.
En este punto, si aumentamos el ratio de compresión, se aplicarán operaciones mas complejas, operaciones que el algoritmo quizás no tolere dada la complejidad de lo que vas a comprimir y lo estipulado en el algoritmo... Arriesgando a que al comprimirlo, genere alguna cadena defectuosa corrompiendolo.

Un ejemplo es probando a comprimir al máximo con 7zip algo complejo... Lo que consigues en un archivo de 4GB es sacar solamente 200M de memoria menos, y si aumentas el diccionario del algoritmo, puede que logres 400M, pero al ser un archivo de composición compleja, lo mas probable es que quede corrupto al descomprimirlo.

En cambio, por contra, si comprimimos un archivo de texto (algo morfológicamente mas simple), y en el cual se produzcan muchas repeticiones de palabras, y demás... Aunque comprimamos con un ratio muy alto, tenemos menor probabilidad de que quede corrupto, puesto que el contenido a comprimir es mas simple y dispone de muchas repeticiones, funcionando el algoritmo mucho mejor.

Si comprimes un archivo de 4GB de texto, el resultado sera un archivo de aproximadamente 1GB o menos incluso, y con pocas probabilidades de corrupción.

El ejemplo que has dicho tu con una variable "double" es lo mas acertado a mi explicación.
Un pequeño fallo en una operación por exponer un valor no estipulado en el algoritmo, o que suceda un desbordamiento de alguna variable omitiendo algún dato, es suficiente para corromperlo.
Y ahí entra en juego mayormente la complejidad del archivo a comprimir, y el forzar un ratio mayor al que mas o menos por lógica, la morfología del archivo y el algoritmo toleren...

Por eso siempre viene la opción en los compresores, la mas básica como predeterminada... Las demás las dejan a elección porque dependiendo del archivo no te pueden asegurar mayormente lo que sucederá.

Mi deducción es si vas a usar un ratio alto, y es algo medianamente importante, cuando se comprima, descomprimelo y comprueba que tal funciona el resultado...

No se si me he explicado bien, si me he equivocado y alguien me corrige perfecto, pero con lo que he leído con el tiempo y demás es la deducción lógica que he encontrado, y por pruebas propias.

Espero te sirva. Cualquier cosa comenta.

Un saludo

[fran800m]

Muchas gracias HCK. !

Tenía una visión tan simplista que nunca había caído en nada de lo que has comentado. Lo que es no saber ....

Un saludo!

[HCK.]

Muchas gracias HCK. !

Tenía una visión tan simplista que nunca había caído en nada de lo que has comentado. Lo que es no saber ....

Un saludo!

Tranquilo, seguro que mucha gente te podría dar una explicación mucho mas explicita que yo en este campo.
Pero mas o menos funcionan así, sigue siendo matemáticas.
Por lo menos me alegra haberte aclarado un poco.

Un saludo!

[OfTheVara]

gracias por responder muchachos,

Me refería solo a fallos internos dentro del algoritmo, que por lo visto también puede fallar.

Necesitaré entonces un CRC

[HCK.]

gracias por responder muchachos,

Me refería solo a fallos internos dentro del algoritmo, que por lo visto también puede fallar.

Necesitaré entonces un CRC

CRC, MD5... La mayoría suele utilizar MD5, o SHA1 pero cualquiera sirve para comprobar si ha habido errores.

Un saludo!