[PHP] Resize script doet raar

[Eijkb]

Het volgende script:

PHP:

$filename = $HTTP_POST_FILES[file][name][$i];
$extensie = substr($filename, -3); 

$filename = $lastid . $toe; 
$filename = $filename .".". $extensie; 

move_uploaded_file($file[$i], "site/auto/" .$filename);

## CREATE THUMBNAIL

$img = "site/auto/" . $filename;
$imgsize = getimagesize($img);
$img = imagecreatefromjpeg($img);
if ($imgsize[0] >> $imgsize[1]) {
    $ratio = ($imgsize[0] / 130);
    $breed = 130;
    $hoog = round($imgsize[1] / $ratio);
} else {
    $ratio = ($imgsize[1] / 130);
    $hoog = 130;
    $breed = round($imgsize[0] / $ratio);
}
                    
$thumb = imagecreate($breed,$hoog);
imagecopyresized($thumb,$img,0,0,0,0,$breed,$hoog,$imgsize[0],$imgsize[1]);
imagejpeg($thumb, "site/auto/t_".$filename, 80);

Opmerking: er is her en der geknipt in bovenstaand stukje code, maar wat er moet staan staat er... Verder is het handig te weten dat de server waarop het draait geen GD ondersteunt boven versie 1.8, vandaar de ouderwetse methode. Het gaat dus om het stukje over de hoogte en de breedte. Overige op- en aanmerkingen natuurlijk ook wel welkom. Kunnen jullie toch niet laten, duszzz.

Ik laad dus een fotootjes op. Een .JPG bestand wel te verstaan. Het script pakt het netjes op en zet het in de directory. Vervolgens resized bovenstaand stukje code het bestand naar een kleiner formaat. Dit gaat uitstekend, -tig foto´s geprobeerd. Dan komt de klant. De eerste de beste foto die hij opload wordt groter weergegeven dan de aangegeven waardes. Andere foto´s die hij heeft upgeload werken wel, maar die ene foto niet! Dat zul je dus altijd zien he. Hoeveel je ook test. Toch niet monkeyproof (de klant is autoverkoper, dus misschien nog een nivo onder een monkey).

Persoonlijk denk ik dat het aan het .jpg bestand ligt. Het gaat om foto´s uit een digicam en die ene foto had een net iets ander formaat dan de andere foto´s waardoor ik denk dat die specifieke foto ooit eens door een programma gehaald is welke interne jpg gegevens heeft veranderd ofzo (je ziet: ik word al aardig paranoïde hiervan).

Heeft iemand ervaring hiermee? Kan het zijn dat interne jpg. gegevens je script laten struikelen? Of doe ik gewoon iets verkeerd...

[ Voor 7% gewijzigd door Eijkb op 23-05-2003 09:40 ]

[Bosmonster]

$extensie = substr($filename, -3);

Ouf.. nu maar hopen dat mensen geen .jpeg ofzo gebruiken Handiger is hier een explode(".", $filename) en dan de laatste uit de array te nemen als extensie.

[ACM]

Bij mijn weten kunnen jpg-files de resolutie opgeven, dat staat dan verder los van de grootte in pixels, maar daarmee wordt het in een viewer die dat ondersteund netjes op de goede grootte getoond (terwijl het eigenlijk wat groter was).

Jouw php-script snapt dat dan weer niet en werkt gewoon met de afmetingen in pixels.

Echter zou dat, bij mijn weten, geen invloed op de werking van je script moeten hebben.

Wat wel een significante bug kan zijn is het verschil tussen > en >> ...
De eerste bepaald of de linker operand groter is dan de rechter en daar komt true of false uit, de tweede doet een bitwise (shift right, 'X maal delen door twee') operatie op de eerste grootte aan de hand van de tweede grootte en daar komt een getal uit wat altijd ongelijk aan 0 is dus altijd true oplevert voor de if.

[Eijkb]

$extensie = substr($filename, -3);

Ouf.. nu maar hopen dat mensen geen .jpeg ofzo gebruiken Handiger is hier een explode(".", $filename) en dan de laatste uit de array te nemen als extensie.

Dat kan inderdaad ook maar er wordt clientside gechecked ofdat het .jpg is. Met wat javascriptrommel. Er mogen namelijk geen .gif, .etc files worden upgeload.

Wat wel een significante bug kan zijn is het verschil tussen > en >> ...

Ik kan dus beter een enkele > gebruiken? Zal dat eens proberen inderdaad.

[ Voor 61% gewijzigd door Eijkb op 23-05-2003 09:59 ]

[ACM]

Eijkb schreef op 23 May 2003 @ 09:56:
Dat kan inderdaad ook maar er wordt clientside gechecked ofdat het .jpg is. Met wat javascriptrommel. Er mogen namelijk geen .gif, .etc files worden upgeload.

Dan moet je dat juist in je php-script testen, bijvoorbeeld met de get_imagesize functie (die ook het image type teruggeeft).
Javascript kan uitgeschakeld worden...

Ik zou nu zelfs een .php file kunnen uploaden naar je site die dan niet gethumbnailed kan worden, maar ach... dat boeit me niet

[Eijkb]

Ik zou nu zelfs een .php file kunnen uploaden naar je site die dan niet gethumbnailed kan worden, maar ach... dat boeit me niet.

Tja. Daar heb je gelijk in. Maar, standaard excuus, de site is niet gewild bij hackers of andersoortig gespuis. En ik heb vooralsnog geen zin om alles te gaan afvangen. Alhoewel ik dit verhaal uiteindelijk wel ga uitwerken tot een herbruikbare functie met meedere doeleinden, dus dan ga ik deze opmerking zeker meenemen. Overigens worden de plaatjes uitgelezen met een klein scriptje (als in [img]"im.php?id="[/img]). Geen idee wat hij met een php scriptje zou doen (wat je dan toch moet hernoemen naar .jpg alvorens de site het accepteerd). Misschien krijg je de code in een jpg-tje te zien. Als de im.php overigens constateerd dat het aangeroepen bestand geen .jpg is dan laat hij een standaard afbeelding zien.

offtopic:
Vet icoon trouwens, is dat realtime echte data? Ben op het werk en we beheren wat mainframes, zou handig zijn als ik aan mijn icoon kan aflezen ofdat er problemen zijn.... hoef ik de logging helemaal niet in de gaten te houden en kan ik rustig de focus op GoT richten...

[ Voor 16% gewijzigd door Eijkb op 23-05-2003 10:06 ]

[ACM]

Dus je image-files zijn verder niet rechtstreeks te benaderen met domweg een urlletje intikken? Dat scheelt iig weer.

Anyway ik had je bug al veel eerder gevonden, lostte dat het een en ander op?

offtopic:
Die data wordt elke vijf mins bijgewerkt ja, als het goed is

[ Voor 16% gewijzigd door ACM op 23-05-2003 10:09 ]

[Janoz]

Waarom ben je aan het bitshiften ipv vergelijken?

PHP:

if ($imgsize[0] >> $imgsize[1]) {

offtopic:
Hmm .. misschien volgende keer gewoon gelijk reageren ipv een dik kwartier wat anders lopen doen

[ Voor 37% gewijzigd door Janoz op 23-05-2003 10:12 ]

[ACM]

Eijkb schreef op 23 mei 2003 @ 09:56:
Ik kan dus beter een enkele > gebruiken? Zal dat eens proberen inderdaad.

Nee niet 'beter'...
De ene operator doet iets heel anders dan de andere, dus de dubbele is niet eens een optie

[Eijkb]

Lostte dat het een en ander op?

Nou, ben dus nu op het werk en we hebben hier van die standaard werkplekken met of zonder toegang tot internet via een proxy. Kan dus niet gemakkelijk proggen of FTP-en. Ben tegen 14:00 weer @ home, en het veranderen van >> naar > is dan het tweede wat ik ga doen (1st koffie zetten). Ik zal het laten weten hier.

Over >> of >....

Het is toch echt zo dat het script met >> dus wel 99% van de afbeeldingen gewoon netjes doet zoals het baasje dat wilt. Het is juist die ene foto die anders reageert. Die foto veranderd overigens wel van afmeting maar dus geheel verkeerd (de verhoudingen kloppen overigens wel). Ding 3 wat ik ga doen is php.net afpluizen naar bitshiften. Is wel een tof woord. Moet weten wat het doet. Heb het wel eens gedaan in C, maar dat is in mijn verre herinnering...

[ Voor 41% gewijzigd door Eijkb op 23-05-2003 10:16 ]

[Eijkb]

Inmiddels het aangepast en warempel. Die ene foto pakt tie nu wel. Hij maakt die afbeelding nu kleiner dan alle andere afbeeldingen:P In ieder geval is dat minder storend dan voorheen, dus het heeft iets opgeleverd! Bedankt.

[Edit]
Nog effe gechecked, en het werkt perfect. De foto is weliswaar kleiner maar dat komt omdat hij natuurlijk in verhouding geschaald wordt. Die bepaalde foto is minder hoog dan de andere foto's!

[ Voor 32% gewijzigd door Eijkb op 23-05-2003 19:49 ]