PHP: Výsledky srovnání funkcí file_(get)put_contents & f(read/write/flush)

[exkalibr]

Problém je v tom, že co je optimální nyní, nemusí být optimální zítra. Vývoj technologií a přístupy se furt mění. To na co dnes pohlížíte jako na optimální řešení, zítra být optimální nemusí. Jestliže to co nazýváte optimální je pomíjivé, pak to není nejoptimálnější (tj. absolutně dokonalé). Já ale míním ten nejoptimálnější stav, to jest více než sám můžete znát. Je to pomyslný stav, pomyslný pojem asi tak jako v elektronice a elektrice se můžeme bavit o supravodivých materiálech a supravodivosti - to jest taky stav, kterého běžně nedostahujete za normálních okolností, kromě těch nasimulovaných někde v laboratořích nebo speciálních vědeckých podmínkách. A žádný nejsupravodivější materiál taky vlastně neexistuje, protože by to musel být materiál, který nemusíte uměle ochlazovat .

[Reklama]

[František Ryšánek]

S tím se váže otázka na používání funkcí chr a ord. Když bych do souboru chtěl zapsat uživatelská idečka a je třeba to udělat binárně a bezpečně tj. zkopírovat dva bajty s daným id, jak to správně udělat? Já znám jen ty dvě funkce chr a ord mám obavy o to, že tyhle věci budou náročné na výkon. A neměl bych taky řešit endianness (česky endianita?) správnost přečtení z binárního souboru?

Popravdě mi teprve teď došlo, že nemáte k dispozici Céčkový typový systém, pointerovou aritmetiku apod. Prostě všechen ten bordel, který umožňuje koukat na data střídavě jako na buffer binárních bajtů, nulou zakončený řetězec znaků, integer o potřebné délce na nějaké adrese apod. Takže nevím, jak s tím bufferingem. Má PHP aspoň něco jako perlový "binmode" režim souborů? Datový typ "buffer binárních bajtů", nebo třeba jenom stringy co nesmí obsahovat nulové bajty?

Ohledně endianity... procesor při aritmetických operacích očekává data uložená v RAMce v souladu s endianitou Vaší instrukční sady. Formát uložení binárních dat v souboru (nebo na síti) může mít nějaký standard, který endianitu jasně stanoví = může být potřeba, konvertovat indiány mezi instrukční sadou a diskovým formátem.

Koukám, že PHP má jenom jeden integer podle architektury, a to se znaménkem... Tzn. 16bit unsigned hodnota se Vám do něj nejspíš vejde bez problému. Jak k tomu přistupovat po bajtech... jakožto PHP analfabet, bez pointerové aritmetiky, bych se to asi pokusil ohnout pomocí bitwise operátorů, ty jsou zřejmě k dispozici. Levý a pravý shift, stejně jako masky používané s operací "AND" fungují na úrovni zdrojového textu všude stejně, nezávisle na indiánech v instrukční sadě = tyto operace použité ve zdrojáku jsou multiplatformní. A funkce ord() a chr() jsou myslím použitelné jenom na zobrazitelné ASCII znaky. Pokud potřebujete 16bit čísla ukládat buď jako dva bajty v binárním souboru nebo jako číslo v ASCII textu, podle mého budete potřebovat spíš sprintf()/sscanf() nebo něco na ten způsob (pro konverzi do/z ASCII formátu).

[Kit]

Popravdě mi teprve teď došlo, že nemáte k dispozici Céčkový typový systém, pointerovou aritmetiku apod. Prostě všechen ten bordel, který umožňuje koukat na data střídavě jako na buffer binárních bajtů, nulou zakončený řetězec znaků, integer o potřebné délce na nějaké adrese apod. Takže nevím, jak s tím bufferingem. Má PHP aspoň něco jako perlový "binmode" režim souborů? Datový typ "buffer binárních bajtů", nebo třeba jenom stringy co nesmí obsahovat nulové bajty?

Ano, PHP má i binary-safe mode.

Ohledně endianity... procesor při aritmetických operacích očekává data uložená v RAMce v souladu s endianitou Vaší instrukční sady. Formát uložení binárních dat v souboru (nebo na síti) může mít nějaký standard, který endianitu jasně stanoví = může být potřeba, konvertovat indiány mezi instrukční sadou a diskovým formátem.

V tom také není problém, i když k binární reprezentaci čísla není přístup. Bitové posuny a maskování však umí.

Koukám, že PHP má jenom jeden integer podle architektury, a to se znaménkem... Tzn. 16bit unsigned hodnota se Vám do něj nejspíš vejde bez problému. Jak k tomu přistupovat po bajtech... jakožto PHP analfabet, bez pointerové aritmetiky, bych se to asi pokusil ohnout pomocí bitwise operátorů, ty jsou zřejmě k dispozici. Levý a pravý shift, stejně jako masky používané s operací "AND" fungují na úrovni zdrojového textu všude stejně, nezávisle na indiánech v instrukční sadě = tyto operace použité ve zdrojáku jsou multiplatformní. A funkce ord() a chr() jsou myslím použitelné jenom na zobrazitelné ASCII znaky. Pokud potřebujete 16bit čísla ukládat buď jako dva bajty v binárním souboru nebo jako číslo v ASCII textu, podle mého budete potřebovat spíš sprintf()/sscanf() nebo něco na ten způsob (pro konverzi do/z ASCII formátu).

Ano tohle všechno v PHP funguje, ale je zde zásadní otázka: Proč dělat tyhle binární opičky, když je to už hotové, v knihovnách, napsáno v C/C++, takže je to i rychlé?

[František Ryšánek]

Ano tohle všechno v PHP funguje, ale je zde zásadní otázka: Proč dělat tyhle binární opičky, když je to už hotové, v knihovnách, napsáno v C/C++, takže je to i rychlé?

Já věděl, že se mám tentokrát zdržet komentáře :-)

[exkalibr]

o jakých knihovnách je řeč?

[Reklama]

[Kit]

o jakých knihovnách je řeč?

O těch, které jsou součástí PHP.

[exkalibr]

Stále mi není jasné jak mám optimálně pracovat s těma číslama.
máms smyčku kde provádím zřetězování. Každý klíč je pár: dvě písmena (dva bajty) a číslo offset (toto číslo ukazuje, v které části souboru s emaily mám začít hledat email). Celý klíč musí mít pevnou délku 4 bajtů.

$keys .= $sub.$size;

Jak mám ale zajistit aby to číslo mělo pevnou délku.
extrakci plánuju udělat takto:

$offset = substr($key, 2,2);

Dva bajty na číslo považuji více než dost - 65025 adres v souboru nikdy nebude.

Jak mám php říct, že číslo chci zapsat dvěma bajtama?

[exkalibr]

Mám to.

Kód: [Vybrat]

$keys .= $sub.pack('S', $size);https://stackoverflow.com/questions/6453061/how-to-convert-integer-to-8bit-binary-data-by-using-php

S   unsigned short (always 16 bit, machine byte order)

[exkalibr]

Když stat() vrátí toto:
{
    [dev] => 64769
    [ino] => 13258558
    [mode] => 33188
    [nlink] => 1
    [uid] => 3333
    [gid] => 3333
    [rdev] => 0
    [size] => 20856
    [atime] => 1571853683
    [mtime] => 1571853683
    [ctime] => 1571853683
    [blksize] => 4096
    [blocks] => 48
)

Znamená to, že se tam používá velikost bloku 4096?

Taky dotaz, k čemu je dev, ino, rdev. Mohu tyto hodnoty nějak změnit? Jak?

Další dotaz. Když gid bych změnil gid (jak?) dostal bych se k souboru například příkazem stat() nebo nedostatl?

[Kit]

https://www.php.net/manual/en/function.stat.php

[exkalibr]

Už to mám.
$ss = stat();

'size'=>array(
  'size'=>$ss['size'], //Size of file, in bytes.
  'blocks'=>$ss['blocks'], //Number 512-byte blocks allocated
  'block_size'=> $ss['blksize'] //Optimal block size for I/O.
  ), 

Jak teda zjistím velikost blocku? Když mám  [size] => 20856 a  [blocks] => 48
size div blocks mi dává 434,5 ... Takže co je to za 512 byte blocky? Spočítal jsem 6 blocků (optimal) po 4096 B. Jen nechápu o jakých 512 bytových blocích je v tom statu řeč.