Newsgroup: it.comp.java
Titolo: Idee per semplice compressione testo ( OT)

immaginiamo due stringhe tipo queste, tenendo conto della lunghezza, fattore
credo importante per stabilire il tipo di compressione:
4b485a5545030f180a070309185340575618025b5c53485b4a5f0a140616020b14025b5850
111c06011f02011f040100021d0118000819071b000d1a041b000919071b0701140708060b
Qualcuno ha idea di un semplice algoritmo per comprimerle?... Immagino che
non ci sia... ma chiedere non costa nulla! (almeno spero:)
 Grazie Ciao
Oxy

Il modo piu' furbo e'
1) Trovare le frequenze dei simboli (che sono elementi esadecimali).
2) Costruire un albero di Huffman; non e' difficile, diremo che e' un albero 
binario in cui metti come radice il simbolo piu' frequente, e poi via via sotto 
gli altri. Poi codifichi l'albero in binario, con zero ed uno: una sequenza 
binaria identifica un nodo dell'albero.
3) Comprimere il tutto con Huffman e poi imacchettarci insieme l'albero (che 
serve per la decodifica).
Per maggiori informazioni consulta un libro di algoritmi

-- 
   [   [  [ JJ ]  ]   ]  | Proponi la tua professionalita' su
                         | 
http://www.siforge.org

 Per maggiori informazioni consulta un libro di algoritmi
grazie... ma considerando che non si tratta di un caso di studio ma di un
bisogno pratico nemmeno impellente, credo che cerchero' in rete, sicuramente
al riguardo e' piena di info:)
Ho anche un altro dubbio... mi sa che non sara' una funzione semplicissima
come quella trovata per cryptare.
Cmq grazie:)

 "Giovanni Giorgi"  ha scritto nel messaggio


 comprimere lo stesso.
Guarda cosa ho trovato:
http://www.cs.sfu.ca/CC/365/li/squeeze/Huffman.html
Una cosa non mi e' chiara: Ottenuta la stringa di byte.. a quel punto come
si dovrebbe procedere per trasformarla effetivamente in una stringa fatta
con quei byte?
( Spero di aver capito giusto e non aaver scritto cavolate!? )
Grazie Ciao

 effettivamente la stringa è corta, ma qualcosina dovrebbe riuscire a
effettivamente... funziona:)...
Mi stavo chiedendo se vale la pena comprimere un testo prima di trasmetterlo
via http.. non ci pensa gia' il modem automaticamente?
Ciao


Se il testo è breve sicuramente non ne vale la pena perché l'impatto in 
ogni caso sarebbe trascurabile.
Se parliamo di http con jsp/servlets comunque si può anche creare un 
filtro (filter) generico che comprime automaticamente tutte le pagine 
volute. Un esempio interessante è in "More Servlets and JavaServer 
Pages" di Marty Hall
 
http://www.moreservlets.com/
nel capitolo 9 (che è pure uno dei due capitoli scaricabili in pdf dal 
sito).
Ciao.
\mirko

    
http://www.moreservlets.com/
io non posso usarli... sul server posso usare solo Perl, posso comprimere
con quello....  Ma la mia era una domanda precisa serve o no comprimere un
testo diciamo di 40-50 kb considerando che credo comprima gia' il modem?...
non e' forse inutile?
Ciao

 wrote in message
news:GPWx9.120251$
RO.30...@twister1.libero.it

invii le stringhe ad uno stream tipo GZIPOutputStream, e lo concateni ad
un ByteArrayOutputStream. il gioco è fatto e la compressione è in
un formato standard GZIP con un fattore di compressione che nel tuo
caso supera 10. 
3 righe di codice.
correggetemi se ho capito male il problema...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Oxy wrote:

Il modem comprime ma non altrettanto bene. L'unico modo per avere dati 
precisi sarebbe, come sempre, fare dei test! ;)
Neanche questo report "The Benefits and Drawbacks of HTTP Compression" 
dà risposte definitive:
 
http://www.cse.lehigh.edu/techreports/2002/LU-CSE-02-002.pdf
Poi ovviamente dipendente dalle tue esigenze: il fatto che l'utente 
aspetti due secondi di meno la pagina vale le ore di lavoro che tu devi 
impiegare per realizzare la cosa?
Buonanotte.
\mirko

 impiegare per realizzare la cosa?
Si, potrebbe valerli... perderei anche giorni per due secondi in meno....
per farlo dovrei rifare molte cose (almeno credo) dovrei fare test in Perl e
forse farmi installare moduli da quelli del hosting..  poi dovrei sperare
che  il formato sia identico...
Gia' c'e' un problema:  con IE l'esempio postatomi sopra non va!... Ma forse
va solo modificato visto che lo zip c'e' anche nella 1.1.
Ciao
Oxy

 correggetemi se ho capito male il problema...
penso che hai capito... ma sicuramente non si puo' avere una compressione
simile su una stringa cosi' corta... al max un guadagno del 30-40%. A dir il
vero In Java  principalmnte le dovrei ricevere e scompattare... sempre a
patto che funzioni in java 1.1
Ciao Grazie


 
sul fatto di java 1.1 non ti so aiutare. ma secondo me la compressione 
č piů alta visto che usi stringe numeriche... dimmi qualcosa quando
l'hai testato.
comunque č meglio utilizzare un formato standard meno performante che
una propria sconosciuta implementazione. non reinventiamo la
ruota (IMHO)


 > Ciao Grazie
avevo gia' fatto dei test con delle applet rovate in rete... per quella
stringa si andava da una riduzione del 10 fino al 30% circa secondo
l'algoritmo usato.
Ciao

 va solo modificato visto che lo zip c'e' anche nella 1.1.
Riassumendo devi comprimere sul server usando Perl e decomprimere sul 
client con un'applet in java 1.1.
Nella jdk 1.1 c'erano già vari metodi di compressione, compreso il 
Deflater che si basa sulla diffusissima libreria zlib:
http://java.sun.com/products/jdk/1.1/docs/api/Package-java.util.zip.html
Per il lato server in Perl puoi usare ugualmente un modulo basato su 
zlib, tipo questo:
 
http://search.cpan.org/author/PMQS/Compress-Zlib-1.19/Zlib.pm
Ciao.
\mirko

l'algoritmo usato.
Se la stringa č di 3 righe e la devi spedire una sola volta non ha
molto senso comprimerla... (quanto ci vuole 1 millisecondo invece di
1.2 a trasferirla?) se invece le stnighe sono sě corte ma sono tante
(e ni quel caso oserei chiamarli "pacchetti"...) allora ha piů senso
comprimerli tutti assieme.. eventualmente forzando un flush lato
server per mandarli subito senza aspettare di riempire il buffer di
compressione.
--
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /

 compressione.
E' proprio quello che ho fatto...  grazie :)
Oxy

E' proprio quello che ho fatto...  grazie :)
BTW: se invece devi fare un flush da lato Java nno puoi usando
java.util.zip, devi usare la libreria non-nativa jzlib che supporta
tutte le opzioni della zlib e con lo stesso formato identico
all'originale.
