| 1. |
re: Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
4 sor |
 (cikkei) |
| 2. |
re: Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
12 sor |
 (cikkei) |
| 3. |
Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
12 sor |
 (cikkei) |
| 4. |
Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
39 sor |
 (cikkei) |
|
| + - | re: Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
VÁLASZ |
Feladó:  (cikkei)
|
A karakterek nyomtatásánál valószínűleg tömörebb a bitek nyomtatása,
kicsit hasonlóan mint a QR kód, csak a teljes lapra.
Üdv.: gyapo
|
| + - | re: Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
VÁLASZ |
Feladó:  (cikkei)
|
Egyszer legyártottam nagyon sok foldert egymásba ágyazva sok
mélységben, mindegyikben egy 1 byte-os file volt. A file-ok hossza
összesen lehetett mondjuk 100 kB. Azonban a cluster veszteség miatt a
foglalt hely volt 300-400 MB között. Sok tömörítő készített belőle 10
MB körülit, viszont akadt egy az ACB, ami 10 kB nagyságrendűre tudta
nyomni, mert észrevette, hogy rengeteg azonos foldernév és filenév
van.
Az 1000-szeres méretcsökkenés miatt pedig már érdemes megnézni több
tömörítőt is, ha fontos a kis méret, hátha valamelyik ügyesebb, és
ráadásul nem is egy ismert lett a nyerő.
Üdv.: gyapo
|
| + - | Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
VÁLASZ |
Feladó:  (cikkei)
|
> ,,,van egy hosszú szövegem, amit egyetlen lapra szeretnék kinyomtatni...
> ...binary-to-text encoding segítségével nyomtathatóvá kódolom...
Ezentúl én is inkább _papírlapra_ nyomtatom ki az átkódolt 007.mkv
Bond filmjeimet és játékprogramjaimat, és postai úton papírborítékban
küldöm majd a haveroknak ahelyett hogy DVD/HDD-re írnám.. =8-())
Egy DVDnyi hány papír-oldalon fér el? ez a védjük a fákat antiprogromja..?
Majd a cimzett a papírlapról egyesével begépeli notepadbe a karaktereket
hogy vissza tudja állítani a filet.. (vagy OCR is elboldogul a base64-el?)
:DD
|
| + - | Re: Text fajlok leghatekonyabb tomoritese mivel? (mind) |
VÁLASZ |
Feladó:  (cikkei)
|
Sziasztok!
> Alapvetoen vesztesegmentes tomoritesre nincsen altalanossagban vett optimalis
> algoritmus/parameter kombinacio. Pelda: leirod 1 millioszor, hogy
> "hello<sortores>".
> Tetszoleges tomoritovel betomoritve a fajl hosszabb lesz, mint
> "hello<sortores>1000000".
Írtam programot, ami egymilliószor beírta egy fájlba soremeléssel: hello
hello hossza: 7000000
hello.bz2 nálam 397 byte lett bzip2 maximális tömörítéssel és
szerintem bármely tömörítő letömörítené hasonlóan picire a normál
algoritmussal is, mert ezeket (szerintem) jól kiszűrik.
A rendszertelenül ismétlődő minták esetén van probléma a tömörítésnél.
> Az optimalis algoritmus/parameter kombinaciot (szotarmeret, stb.)
> minden egyes fajlra kulon-kulon ki kell kiserlezetni. (lasd zip bomb
ill.
> 42.zip kulcsszavakat)
Igen, valamennyi méretcsökkenést el lehet vele érni.
> Mas: Base64 helyett uuencode/uudecode kisebb overhead-et tud, mert hasznalja
> az osszes ASCII karaktert (ertsd a 0-127 kodokat). Viszont ASCII/EBCDIC
> konverzional nem nyero (a base64 ezt elkeruli).
EBCDIC hirtelen nem tudom mit jelent és mikor fordulnak elő ilyen
karakterek de majd utánanézek.
Mi lehet az oka, hogy háttérbe szorult az uuencode-decode és a Base64
lett a széleskörben használatos? (levelezők ezzel kódolják a
csatolmányokat például).
Elvileg ASCII kódtáblából 0..12, 15..31 közti karaktereket nem
használhatja mint ASCII krakter.
Egyébként nem olyan fontos kérdés ez a text tömörítés csak van hogy
néha foglalkoztatnak bizonyos dolgok amelyek másokat kevésbé. :-)
Üdv: G
|
