Autor Zpráva
snazimse
Profil
Zdravím všechny,

měl bych prosbu, na někohoo kdo s tím má zkušenost,
potřeboval jsem si na webu pomocí php zazipovat složky a soubory, tak jsem si vybral základní php nativní třídu.
Vše ok nicméně, dvě věci, vytváří mi to v každé složce dva soubory prázdné.
s dvojtým podtržítkem. Další věc, že při rozbalování v nějakém programu to dělá problémy.

Háže errory apd.Takže v normálním programu jsem to nerozbalil, šlo mi to přes CMD.


Kód zde,

// increase script timeout value
ini_set('max_execution_time', 5000);

function show($str){
   echo $str . "<br/>\n";
   flush();
   ob_flush();
}

$date = getdate();
$splitNum = 0;

$archive = "backup_" . $date[0];
$currentArchive = $archive . "_" . $splitNum . ".zip";

$zip = new ZipArchive();
if ($zip->open($currentArchive, ZIPARCHIVE::CREATE) !== TRUE) {
    die ("Could not open archive");
}

$numFiles = 0;
$iterator = new RecursiveIteratorIterator(new RecursiveDirectoryIterator("./"));
foreach ($iterator as $key=>$value){
   $numFiles += 1;
}
show( "Will backup $numFiles to $archive.zip" );

$iterator = new RecursiveIteratorIterator(new RecursiveDirectoryIterator("./"));
$numFiles = 0;
$counter = 0;
$maxFilePerArchive = 1000000;
foreach ($iterator as $key=>$value){
   $counter += 1;
   if ($counter >= $maxFilePerArchive) {
      $currentArchive = $archive . "_" . $splitNum++ . ".zip";
      show( "Too many files: splitting archive, new archive is $currentArchive" ); 
      $zip->close();
      $zip = new ZipArchive();
      if ($zip->open($currentArchive, ZIPARCHIVE::CREATE) !== TRUE) {
          die ("Could not open archive");
      }
      $counter = 0;
   }
   //$i = $maxFilePerArchive*$splitNum + $counter; 
   if (! preg_match('/temporary\/backup_' . $date[0] . '/', $key)){
      $zip->addFile(realpath($key), $key) or die ("ERROR: Could not add file: $key");
      $numFiles += 1;
      if ($numFiles % 300 == 0) {
         show( "$numFiles" );
      }
   } else {
      show( "Not backuping this file -> $key" );
   }
}
// close and save archive
$zip->close();
show( "Archive created successfully with $numFiles files." );

můžete mě prosím nasměrovat, v kódu nic nevidím, možná jsem něco přehlídl. Je možné, že to je přímo chybně v té třídě?

Děkuji všem!

Moderátor Davex: Titulek „Používá někdo výchozí třídu ZipArchive pro zipování? Problém“ nevystihoval podstatu dotazu. Příště zkus prosím vymyslet lepší.
Davex
Profil
1) Možná bys do archivu neměl bezhlavě přidávat všechno, co ti přistane z DirectoryIterator, a alespoň mohl rozlišovat o co se jedná. Adresáře (isDir()) a soubory (isFile()) se přidávají různým způsobem a pokud zipuješ všechny soubory v podadresářích, tak je nutné vytvářet adresáře (addEmptyDir()) před přidáním souborů, které v nich mají být. Adresáře . a .. je vhodné přeskakovat.
2) Myslím, že se v cestě museli nahrazovat normální lomítka / zpětnými \, aby šel archiv rozbalit ve Windows XP v zipovátku integrovaném do Průzkumíka. Nevím, jestli to v novějších verzích Windows opravili nebo ne.
3) Také bys mohl ty proměnné $key a $value pojmenovat nějak smysluplně.
snazimse
Profil
Davex:

1)No možná, je vadný ten DirectoryIterator, no zkusím to nějak vylepšit. Ale nevím, jistě jestli to bude tím.

2) Windows moc nepoužívám. Toto mi nefungovalo konkrétně např v Archive Manageru.

3) upravím to :)

Díky za reakci!
Alphard
Profil
V Nejčastější potíže s PHP (FAQ) » Rekurzivní zipování je kdyžtak jeden hodně starý script. Neumí rozdělovat obsah do více archivů podle počtu souborů (u stromu není tak jednoduché to tam dopsat), ale myslím, že fungoval dobře.
snazimse
Profil
Alphard:

Děkuji za příspěvek, mám už ten svůj.

Podařilo se mi to nějak tento co jsem uvedl přepracovat ještě pro svoje potřeby mi to stačí, umí to vše co potřebuji.

Bere mi to všechno již, chvíli to trvalo ale ok.Odstranit tam např: ty zipované tečky v adresářích, co to má znamenat vůbec?
Už to otevírám v Archive Manageru, vše perfekt, akorát jsem to dělal zbytečně http://php.net/manual/en/class.ziparchive.php#106062

Aspoň jsem se nenudil, udělal jsem to malinko jinak, ale jejich způsob, je pochopitelně lepší.Ale některé věci se mi tam hodily udělat jinak.
Ale spíše, by mě zajímal názor na rychlost a kompresi.

Nakompresoval jsem 203mb RAW, na 177mb v zipu. Není to málo, čekal jsem více :)

A rychlost komprese na tento objem je 43 sekund execution limit na sdíleném hostingu.
Při např 90 sekundách ,je to okolo 600mb+-.

Je to slabé, nebo ne ? Jinak jsem s výsledkem celkem spokojený kupodivu. Děkuji!
Martin2
Profil *
snazimse:
ty zipované tečky v adresářích, co to má znamenat vůbec?
Tečka a dvě tečky jsou speciální inody přítomné v každém adresáři. Fungují jako hard-linky na aktuální respektive nadřazený adresář. Není žádoucí (ani možné) je balit do archivu.

Aspoň jsem se nenudil
Nudit se možná nebudou ani návštěvníci s jen trochu ortodoxním zip-softwarem, kteří tvoje prasečí archivy nepřečtou. Soudím, že pokud nemáš dostatečné zkušenosti, je tohle ideální příklad, kdy máš sáhnout po hotovém řešení.
Keeehi
Profil
snazimse:
Nakompresoval jsem 203mb RAW, na 177mb v zipu. Není to málo, čekal jsem více :)
Záleží co komprimuješ. Na něco to může být výborný poměr, na něco zase špatný.

A rychlost komprese na tento objem je 43 sekund execution limit na sdíleném hostingu.
Při např 90 sekundách ,je to okolo 600mb+-.
To nejsou taky dostatečně konkrétní údaje. Může to být OK nebo taky ne.

Ale v důsledku záleží na tom, zda jsi s tím spokojený ty a jestli ne, zda s tím chceš něco dělat.
juriad
Profil
Martin2:
U anglického textu se tvrdí, že obsahuje 1 bit informace na znak. U textu můžeš očekávat zmenšení na osminu. U DNA (soubor obsahující jen znaky ACTG) bude poměr úžasný. U obrázků, videí, písniček se to zmenšit vůbec nemusí, ty už většinou bývají komprimované algoritmy určenými pro daný typ dat, obecný ZIP jim již nepomůže. Existují dokonce i soubory, které se zazipováním zvětší (musí existovat).
Martin2
Profil *
juriad:
U anglického textu se tvrdí, že obsahuje 1 bit informace na znak. U textu můžeš očekávat zmenšení na osminu
Což je pitomost už když se na dvě sekundy zamyslíš.

Předpokládejme základní latinku bez exotických symbolů, což je cca 65 znaků, plus mínus. Entropie jednoho znaku je pak cca 6 bitů. Je to míň než jeden bajt, takových 25% se dá tedy ušetřit prostým sesypáním textu do souvislého binárního proudu. Ale to není případ ZIPu - ten komprimuje většinou pomocí dynamicky generovaného slovníku. Jestli jsou data text nebo hudba je mu úplně jedno.
juriad
Profil
Martin2:
Není. Zapomínáš na predikci. Obvykle ti stačí z textu zachovat jen pár slov k tomu, abys mu porozuměl. A obdobně stačí ze slov zachovat jen pár pismen, abys mu porozuměl. Přečti si „Entropy of English text: Experiments with humans and a machine learning system based on rough sets“. Ty jako člověk v psaném textu nepotřebuješ rozlišovat velká a malá písmena (nebo extrémně zřídka), abys je dokázal opravit.

OK s tím 1 bitem jsem to přestřelil, ale kolem 2 už to bývá. Ale teď koukám, že bible má 1.56 bitu na znak. Viz Compression and Coding Algorithms, strana 255. Ale máš pravdu, že ZIP není tak efektivní.

Na vstupním souboru, který se snažíš zkomprimovat, extrémně záleží. Téměř vždy se snažíš predikovat následující část za pomoci té, kterou už znáš. Ve skutečnosti pak ukládáš do výstupu jen odchylky od predikované hodnoty a ty ještě prohnané nějakým dalším kódováním.

Jednotlivé univerzální kompresní algoritmy se liší tím, zda pracují blokově nebo proudově, zda adaptují kódovací tabulku nebo si ji předpočítají a posílají spolu se zkomprimovaným výstupem.
Martin2
Profil *
Bavíme se pořád o neztrátové datové kompresi? Ty evidentně ne.
juriad
Profil
Martin2:
Ano bezztrátové. O ztrátové jsem se ani nezmínil, ta se pro univerzální kompresi nehodí ze zjevných důvodů.

Zkusím dokázat, že nemáš pravdu s tím, že na vstupu nezáleží.
Mějme vstup o délce M znaků nad abecedou o velikosti N. Celkem je tedy N^M možných vstupů.
Věta, že na vstupu nezáleží, znamená to samé jako, že pro každý vstup dostaneme stejně dobrý výsledek.
Nechť výsledkem je opět abeceda o velikosti N, ale tentokrát je potřeba jen K znaků, kde K < M.
Potom ale N^(M-K) vstupů dává identický výsledek a při dekódování je nedokážeš rozlišit.
Tedy by nešlo o neztrátovou kompresi.
Buď na vstupu záleží, nebo naše komprese vždy dává výsledek s K >= M, což lze ztěží považovat kompresi, kterou by někdo používal.
Na vstupu tedy záleží. Musí existovat vstupy, které se nám podaří zmenšit, a také vstupy, u kterých máme smůlu.

Zacházím docela daleko od ZIPu, ale i na ten se vztahuje předchozí tvrzení. Můžeš si prohlédnout, jak které algoritmy dokáží zkompimovat vstupní soubor podle jeho povahy vyjádřeno jako bity na znak. Odkázaná stránka obsahuje soubory, které se používají pro testování bezztrátových kompresních algoritmů. Můžeš si tam toho o tom přečíst víc.
Martin2
Profil *
juriad:
Obvykle ti stačí z textu zachovat jen pár slov k tomu, abys mu porozuměl. A obdobně stačí ze slov zachovat jen pár pismen, abys mu porozuměl“...„nepotřebuješ rozlišovat velká a malá písmena
Takže tomuhle říkáš neztrátová komprese?

Zkusím dokázat, že nemáš pravdu s tím, že na vstupu nezáleží.
Napsal jsem, že ZIP nerozlišuje druh dat (a to je pravda), ne že na vstupu nezáleží.
Alphard
Profil
Martin2:
Takže tomuhle říkáš neztrátová komprese?
To byl jen nevhodně zvolený příklad. Pokud se vzdáme nějakých znaků, tak pochopitelně jde o ztrátovou kompresi. Avšak na text se obvykle ztrátové algoritmy nepoužívají.

Napsal jsem, že ZIP nerozlišuje druh dat (a to je pravda), ne že na vstupu nezáleží.
Nerozlišuje ve smyslu, že může komprimovat jakákoliv data. Avšak výsledek komprimace na vstupu záleží.

Jestli jsou data text nebo hudba je mu úplně jedno.
Právěže pro výsledek to není jedno, byť se zabalí obojí. Jde o to, jestli mohu predikovat další znak. Pokud mám ideálně náhodnout sekvenci, neexistuje možnost, jak ji komprimovat. Naopak když budu mít sekvenci vzniklou opakováním nějakého vzoru, stačí mi jednou uložit vzor a k tomu jen počet opakování. A zrovna texty se většinou komprimují dobře, protože v nich lze najít opakující se vzory.
snazimse
Profil
Keeehi:

A jaké parametry, bych měl dodat, no tak kompiluje se vše co se na webu dá najít. Nejvíc obrázky(nejvíc mb samozřejmě), a php soubory.

Tak já s tím spokojený sem, protože mi šlo spíše o to, že jsem potřeboval všechny data v jednom souboru, komprimace byla v tomto případě až na druhém místě.

Díky za reakci!
Martin2
Profil *
Pánové moderátoři, končím tuhle debatu, protože nerozumíte psanému textu a pořád mi dáváte do úst něco co jsem neřekl. Plus se pořád bavíte vy o koze a já o voze.

Alphard:
Avšak výsledek komprimace na vstupu záleží.
Najdi mi prosím, kde píšu, že by výsledek nezaležel na vstupu.

Nerozlišuje ve smyslu, že může komprimovat jakákoliv data
Ne - nerozlišuje ve smyslu, že na všechno tupě používá jeden druh komprese.

To byl jen nevhodně zvolený příklad
To byl, ovšem ne mnou zvolený. juriad jím podpořil svůj výrok o textu s entropií 1bit na symbol. To u neztrátové komprese a běžného textu neplatí.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0