Dudas longitud cadena

[matake]

Hola,
Estuve muy ilusionado al encontrar en internet una librería para comprimir texto en javascript que se llama lz-string pero pasa algo que no entiendo. No se si hago algo mal o es algo que desconozco por esto pongo aquí un ejemplo:

Código Javascript:

var comprimido = LZString.compress('una prueba');
 
console.log(comprimido); //esto me da una cosa china no se si se vera bien aqui ⮃낆@ค怣㄀ que seria la cadena 'una prueba' comprimida
 
console.log(comprimido.length); //la longitud que me sale con lenght es 7
 

Lo que pasa es lo siguiente ... si intento copiar manualmente (o enviar por ajax) dicha cadena comprimida y guardarla no me sale de 7 caracteres sino de 19 o sea mas grande que el original ya que la cadena 'una prueba' tiene 10 caracteres

En el ejemplo que he puesto, la compresión casi no se ve pero (no quería llenar el post de texto ) pero he probado con cadenas de 60 000 caracteres y comprimido me sale como 15 000 caracteres lo que es un cuarto y no estaría mal.

pero al intentar guardarlo sale como 90 000 caracteres o sea mas grande que el original

Mi ilusión era guardar estos textos comprimidos en el servidor y la descompresión se hacia en el cliente ya que esta librería es javascript

¿Hago yo algo mal o no entiendo algunas (muchas) cosas ?

Gracias

[zerokilled]

buenas.
hay que analizarlo en varias partes, pues muchas cosas pueden pasar desde la compresion, envio, y recuperacion de los datos.

lo primero que tienes que comprender es el algoritmo de compresion en si y la naturaleza de javascript. los algoritmos de compresion (cualquiera que sea) juegan mucho a nivel binario. inicialmente, javscript no fue diseñado con la habilidad de manipular binarios de forma amena. de modo que la unica forma de poder visualizar el contenido binario son con los strings (cadenas).

segundo, no es lo mismo medir la longitud de caracteres en un string que la longitud de bytes que esta compuesto ese mismo string. por ejemplo, el string 'ካ' esta compuesto de un solo caracter, pero en realidad consume dos bytes. esto ultimo se debe mas bien porque internamente javascript maneja los string en UTF-16.

Código:

console.log('ካ'.length); // 1
console.log('ካ'.charCodeAt(0).toString(16)); // 12ab, cada dos digitos hexadecimal es un byte. 0x12, 0xAB

tercero, la forma como transfieres el string de un lugar a otro. diferentes mecanismos de comunicaciones tienen diferentes limitaciones. HTTP tiene dos formas (al menos son las unicas que conozco) de como codificar la informacion antes de ser transferrido al servidor: urlencoded y multipart. esta codificacion son necesaria debido al metodo de envio (GET y POST). comunmente, la data se envia formando una URL que a su vez tiene que cumplir por las normas de cómo se construye una URL. si un caracter de la data conflige con la sintaxis de la URL, ya sea porque hay un caracter especial o porque se sale del rango del charset, se tiene que transformar a un equivalente. esa transformacion implica que la longitud de bytes final sea mayor al original y por ende resulta impractico para datos realmente grande. por ese motivo existe multipart, la informacion binaria se envia tal cual es utilizando un esquema distinto (payloads). para efectos tuyo, desconozco si se puede enviar el string comprimido como multipart en ajax.

cuarto, la data en el servidor puede sufrir otra manipulacion dependiendo lo que hagas con el. mas aun, el metodo en que solicites ese dato en el cliente puede sufrir otra transformacion. por ejemplo, si haces una peticion ajax con GET, el string puede resultar mas largo. nuevamente por las limitaciones en la sintaxis de URLs. de modo que la compresion en el lado cliente perderia sentido y utilidad. en este caso quizas sea conveniente que en el servidor apliques algun metodo de compresion a las respuestas de las peticiones, por ejemplo gzip o deflate.

[matake]

Muchas gracias por responder

En principio he entendido tu explicación

lo que quería yo era justo esto ahorrar el tiempo que necesita deflate para comprimir ... guardarlos manualmente comprimidos ... servirlos comprimidos ... y que solo en el cliente se descomprimen así se había ahorrado el tiempo de comprimir en el servidor

Pero por lo visto no se puede ( me refiero a lz-string ) que me gustaba porque era una librería muy pequeña del lado cliente

Por lo del deflate ... no se porque me quedaba en la cabeza (lei por algun lado ) que al activar los módulos deflate y filter ... no se puede emplear flush() y lo necesito .... por esto estaba buscando una manera de comprimir manualmente en el servidor

Pero al hacer unas pruebas ahora con flush() con mod_deflate y filter activados en apache veo que funciona .... a no ser que me estoy engañando

he puesto esto en .htacces

Código:

AddOutputFilterByType DEFLATE text/html

y al mirar el network en el developer tools de chrome veo que un fichero de casi 300Kb (esta sin minificar y sin quitar comentarios .. ) me sale a 81kb .

¿Seria esto correcto? es asi que se puede ver si deflate funciona?
Si es asi me has quitado de encima una pesadilla de comprimir todo manualmente ..
Ademas funciona flush() tambien

Saludos y gracias.