Képfeltöltés és méretezés

Egyik kollegám jelezte, hogy az alábbi részlet/megoldás

1
2
3
4
5

$all_tomb['name'] = str_replace('é', 'e', $all_tomb['name']);
$all_tomb['name'] = str_replace('á', 'a', $all_tomb['name']);
$all_tomb['name'] = str_replace('í', 'i', $all_tomb['name']);
$all_tomb['name'] = str_replace('ű', 'u', $all_tomb['name']);
.......

helyett kicsit elegánsabb ez:

1
2

$mit=array(á', 'é');
$mire=array('a','e');

plusz

1

$all_tomb['name'] = str_replace($mit, $mire, $all_tomb['name']);

és a végére érdemes tenni még:

1

pregreplaceall("/[^a-zA-Z0-9]/", "_", )

Igen, erre gondoltam én is, mikor mondtam, hogy elegánsabban is lehetett volna. Hamarosan szerintem update-elem a scriptet, és ha van lehetőség, szerkesztem ezt a postot is.

Azért van még rajta javítani való, néhány tipp:
– Amit fentebb írt Harder, az összes magyar ékezetes mehet egy függvény-hívással
– Minden más nem szám és angol abc karatert én ezután egy regexp-el kiszednék ([^0-9a-zA-Z]) vagy lecserélnék pl. ‘_’-re. Itt figyelni kell a kiterjesztésre, ezzel a regexpel pl. eltűnne a .
– A move_uploaded_file előtt érdemes ellenőrizni, hogy létezik-e már, ha igen, akkor a fájl nevébe (a kiterjesztés előttre) be lehet szúrni a dátumot, ha az is létezik, akkor egy sorszámot (pl.: kép-2010-10-05-13.jpg ha 13 kép.jpg-et feltöltenék ma)
– Felvennék plusz két változót: $saveFunc és $extraParam. Ha van ez a két változód – és rendesen inicializálod őket, erről mindjárt – akkor a középső, fájltípustól függő részeket egy példánnyal helyettesítheted. A $saveFunc-ba beteszed az imagejpeg/imagepng/imagegif stringet, az $extraParam-be pedig egy 100-as értéket, ha jpg a típus. Ezután simán tudsz menteni a megfelelő formátumban egy $saveFunc($image_p2, $filename2, $extraParam) hívással.
– A képek betöltését is megoldhatod egy sorban: imagecreatefromstring(file_get_contents($location . $op)), ennek ráadásul az az előnye is megvan, hogy nem kell bíznod a böngészőben, ami olyan content-type-ot küld, amit nem szégyell.
– A getimagesize hasznos függvény, de ha a felette levő sorban már amúgy is be töltötted a képet, akkor ne használd, ez ugyanis újra be fogja tölteni, csak a méret lekérdezésére. Helyette az imagesx és imagesy függvények tökéletesek, azok csak simán belenéznek a – már meglévő – belső reprezentációba.
– Amikor a kis képet készíted, akkor felesleges újra megnyitni a nagy képet, egyszerűbb, ha nem zárod be addig, amíg a thumbnail el nem készült. Ráadásul szerintem jobb minőséget kapsz, ha az eredeti képből méretezel (itt viszont már figyelni kell, hogy a sorrend a nagy kép megnyit – új nagy kép készítés – úgy nagy kép bezár – kis kép készítés – bezárás legyen a sorrend, hogy minél több szabad memória maradjon)

Ezután pedig már csak saját vélemények:
– A kevert angol/magyar változókat nem illik csinálni. Legyenek angolok, úgyis az az informatika nyelve (ide tartozó anekdota: egyszer debugoltam valami joomla komponenst, aminek a szerzője francia (úgy emlékszem), ő is folyamatosan angol és francia változóneveket használt, azóta tudom, hogy „külföldiként” nagyon nehéz olvasni a kódot)
– A helyedben én szétkapnám a kódot több részletre, hogy a különböző feladatok jobban elkülönüljenek (code reuse). Mondjuk a kövi három függvényt hoznám létre első ránézésre:
– resizeAndCreateThumbnail($source, $target, $maxWidth, $maxThbWidth, $maxThbHeight) : a $source képet átméretezi $maxWidth-nek megfelelően és
– getFilename($location, $filename) : a fájlnévből kiszámítja a végleges fájlnevet (ékezetes és spec karakterek eltávolítása, dátumozás/számozás stb.)
– resizeAndCreateThumbnailUploadedFiles() : a fenti két függvényt használva a megcsinálja azt, amit a mostani függvényed. Fontos, hogy ez állítsa be a fájl jogosultságokat, ne a resizeAndCreateThumbnail(), hogy minél jobban elkülönüljenek a feladatok egymástól

BlackY
Ui.: A félreértések elkerülésére: tudom, hosszú lett, gyakorlatilag mindenbe belekötöttem, de építő jelleggel írtam.

Szerintem meg pont jó, hogy ha ennek a cikknek lesz egy 2-es verziója (és nem ez lesz átírva pl.), mert akkor sokkal jobban érhetővé válik, mi miért módosult, mik voltak az előzmények, milyen más lehetőségek vannak stb..

BlackY!

Köszönöm a tanácsokat. Igyekszem megfogadni (tanulni mindíg jó dolog :) ). Illetve ha időm lesz, akkor átírom/megpróbálom átírni olyan módon, ahogy javasoltad te is és Harder is.

És szerintem is kell majd ebből egy 2.0 verzió Legalább meglesz a kontraszt.

Alapvetően az fgv-vel még fő probléma szerintem, hogy a $_FILES tömböt maga járja be. Mi van akkor ha történetesen FTP-vel felküldök 3 file-t ami mondjuk összesen 6 MB. HTTP-n keresztül ugye ezt nem lehet mert tegyük fel 2 MB a feltöltési limit.

A függvény alapvetően még a Levente által javasolt megoldásnál is jobban szétszedném:
– File feltöltő függvény (feltölti a fájlokat egy tmp könyvtárba)
– File név generáló függvény (ez generálja az egyedi fájlnevet, megfelelő szabályokkal)
– Kép méretező függvény (általános). Ennek paraméterei: forrás fájl, cél fájl, méretre vonatkozó paraméterek. Ez hívja majd meg a konkrét típusra vonatkozó fgv-t.
– Kép méretező függvények (típusonként, azaz pl.: resizePNG, resizeJPG, resizeGIF)
– ezután csinálhatunk pár „nevesített” fgv-t is: pl createThumb, createBig, melyek a megfelelp paraméterrel hívják meg az általános képméretező függvényt.

Mit nyerünk egy ilyen struktúrával?
– ha a következő alkalommal DOC-ot akarunk feltölteni a fájl feltöltő fgv-nk már megvan
– ha FTP-vel töltöttem fel a képeim, akkor csak meg kell mondani a képátméretező fgv-nek, hogy melyik fájlt használja
– ha a háttérben újra akarom méretezni az összes képet, akkor is kész a függvényem
– stb…

Minek több típushoz átméretező, amikor az összes képtípusra (amin ugye értelmezni lehet az „átméretezés” műveletet) egy – típusfüggetlen – függvénnyel meg lehet oldani (a változó-függvényhívásos és fromstringes megoldással, amit fentebb írtam). A burkoló függvényekkel részben egyetértek, részben nem: ha esetleg a fő függvény változik, akkor marha jó test esetek kellenek, hogy az esetleges hibákat azonnal megtaláld.

Amivel egyetértek, hogy a feltöltő függvénybe kell valami típusfüggő elágazás. Pl.: egy callbackes megoldás, ami fájltípustól függően vagy lefuttatja az átméretező függvényt, vagy nem. Viszont akkor már egyszerűbb, ha – megintcsak – változó függvényeket (esetleg closure) használunk, amiket egy típus => függvény tömbben tárolunk, aztán simán meghívjuk a feltöltött fájl típusához tartozó függvényt, ha van ilyen. És mondjuk egy addCallback($type, $function) függvénnyel lehetne futási időben új fgv-ket felvinni. (Vagy áttérünk OOP-re, és ugyanezt a játékot eljátszuk interface-kkel, esetleg egy Chain of Responsibility pattern-nel stb.)

BlackY
Ui.: Ha az a Levente nekem szólt, akkor kérlek ne. Maradjunk a BlackY-nél ;)

BlackY,

igen, OOP lenne a helyes megoldás, de az sok plussz tudást igényelne. A függvények szétszedése csak egy kis plussz munkát az elején, ami valószínű hetek alatt megtérül.

Lustaság fél egézség. Ha már kijátszottátok magatokat, a fenti kódrészlettel akkor ajánlom a következtő átméretező library-t. http://phpthumb.gxdlabs.com/ OOP, exception-oket használ, és több fajta thumbnail gyártást is támogat, több különböző kép feldolgozó háttér rendszerrel.

A darabolással természtesen egyet értek. Ha jó elnevezésüek a fügvények akkor nagyon jól használható library-t kap az ember.

Igen, én is egyetértek azzal, hogy a képméretezés-részt külső PHP library-ra kell bízni. Bár nem saját kezűleg készítettük, ezeket az osztályokat általában kitesztelik, mielőtt közzéteszik, ezért megbízhatóan működnek.
A fájl-átnevezgetős dologgal viszont nem igazán értek egyet. Pontosabban, nem értem, hogy miért kell azzal foglalkozni, hogy részben megmaradjon az eredeti fájlnév?
Az esetek többségében, ha feltöltünk egy képet, annak adatait eltároljuk adatbázisban, és később, egy lekérdezéssel érjük el, és jelenítjük meg a képet a weboldalon. Én ilyenkor mindig azt szoktam csinálni, hogy adok a képnek egy teljesen új fájlnevet. Pl.: timestamp + „_” + 4-5 karakternyi random sztring. Ezzel az új névvel töltöm fel a fájlt, ezzel a névvel mentem el adatbázisban is. Ha nagyon akarom, adatbázisban tárolhatom a fájl eredeti nevét, ahol nem kell a karakterek válogatásával szórakozni…
Ez a megoldás akkor lehet rossz, ha a fájlrendszerben szeretnénk „nézegetni”, kézzel „pakolgatni” a képeket, ami szerintem elég ritka dolog.
És végül még annyit, hogy én soha nem szoktam külön kis bélyegképet menteni a nagy képből, helyette inkább egy PHP fájlon keresztül hívom meg a weboldalon, ami átméretezi nekem on-the-fly akkorára, amekkorára szeretném.

mrMiller: legtöbb esetben nem rossz megoldás a saját elnevezéses dolog, viszont ma már azért az on-line képkeresés is elég népszerű. A 182323122_foobar.jpg név speciel a Google-nek az égvilágon semmit nem fog mondani, ha megjelenik a találati listában, akkor a user a mellette levőre fog kattintani, aminek a fájlnevében vastaggal ki van emelve a kiscicak szó :) Szóval a fájlnév is tartalmaz információt, amit nem szabadna minden esetben eldobni.

A másik megoldással (on-the-fly thumbnail generálás). Ne tedd :) Feleslegesen nagyon leterheli a szervert, még ha nagyon jól meg is van írva. Próbáld ki, hogy – akár erre kijelölt Apache-al – php-ből kiszolgálva az on-the-fly készült thumbnail képeket és mondjuk egy lighttpd az előre elkészített képeket mennyi az egységnyi idő alatt kiszolgálható képek száma.

Ha a gond az, hogy a thumbnailek elkészítése a feltöltéskor sok időbe telik, akkor két kerülő megoldással lehet próbálkozni:
– feltöltéskor nem azonnal készíted el a méretezgetett verziókat, hanem bedobod egy queue-ba, egy daemon processz meg figyeli a sort, és dolgozik rajta (persze ehhez kell daemon futtatási jog a szerveren, és nagyon odafigyelve kell megírni a daemon kódját)
– feltöltéskor nem készítesz thumbnaileket, viszont be van állítva egy 404 kezelőd a képeket tartalmazó könyvtárra. Amikor a 404-es kódod meghívódik, akkor előállítod a szükséges thumbnailt, elmented a végleges helyére (hogy legközelebb már megtalálja a szerver), aztán readfile-al kiküldöd a kliensnek a megfelelő fejlécekkel)

BlackY

igen, valóban jobb lehet egy értelmes szó a kép nevében az indexelés miatt, bár ha helyesen kitöltjük az alt és title attribútomokat, akkor a Google már igenis tud vele mit kezdeni.
Vagy, ha mindenképpen szeretnénk értelmes nevet megjeleníteni fájlnévként, még mindig ott van a rewrite-rule lehetősége, amivel olyan tetszetős URL-t csinálhatunk, amilyet szeretnénk – miután adatbázisban úgyis eltárolunk adatokat a kép nevével, ill. eredeti nevével kapcsolatban.

Nem tudom, az on-the-fly képgenerálással nekem még nem volt problémám, jóllehet még nem csináltam olyan weboldalt, aminek több tízezer látogatója van naponta, és képek megjelenítésével foglalkozik – mert valljuk be, egy ilyen esetben tudom elképzelni az észrevehető lassulást.
A lényeg az, hogy pl. egy kisebb webshop esetében, ahol mondjuk egy termék találati oldalon van 10-15 bélyegkép összesen, ott nem lesz az emberi szemnek észrevehetően lassabb a rendszer.
Nyilván, BlackY, nem kérdőjelezem meg a tudásodat, csak megosztom a saját tapasztalataimat. :)

A google tud vele mit kezdeni, ki is fogja rakni a találati oldalra, viszont a felhasználónak nem mindegy, hogy „321.jpg” vagy „Desire HD.jpg” fájlnevet lát. (ráaádul most tesztként beütöttem Google képkeresőbe a „dog” szót, a 6. oldalon találtam meg az első képet, aminek a fájlnevében nincs benne a dog kifejezés).

A rewrite-os megoldás már jó, viszont ahhoz, hogy a rewrite-kor normális fájlnevet adhass (tehát egy név -> egy kép és egy kép -> egy név leképezések meg lehessenek), ahhoz gyakorlatilag megcsinálod a fájlátnevezgetést. Csak éppen beraksz plusz három lépést (apache -> mod_rewrite -> php -> mysql) a kiszolgáláshoz.

Persze lehetnek olyan esetek, amikor kell az on-the-fly átméretezés (pl. teljes képernyőn akarod mutatni a usereknek a termék képét, de nem bízod a böngészőre a mondjuk 2048*1466-os kép leskálázását, mert a gd többnyire szebb eredményt ad, viszont ott előre nem tudhatod, hogy a usernek mekkora a felbontása).

Csak ezeket érdemes kerülni, mert hiába van az, hogy többnyire alacsonyabb a látogatottságod, a Slashdot effekt (wikipedia megmondja, egyébként annyi, hogy egy híresebb oldalra kilinkelik, és hirtelen marha sok találatot kap az oldalad) könnyen átmehet egy DDoS támadásba, ha amit lehet nem gyorsítasz. A másik oldalra átesni sem szabad (napi 1000-es látogatottsághoz fenntartani Memcached szerverparkot, dedikált webkiszolgálóval, adatbázis clusterrel stb.), de ha ennyivel elérheted, hogy nagyobb terhelést bírj, akkor szerintem érdemes.

Egyetlen kivétel így azonnal: ha a webhosting szerződésedben a képeid számához mérten viszonylag kicsi a tárhely, tehát a több méret tárolása miatt mondjuk fél éven belül betelne a tárhelyed. (Bár akkor meg csomagot kell váltani :) )

BlackY

Engem egy olyan kód érdekelne egy olyan kép feltöltés amely a profilhoz kapcsolódik nem pedig egy sima képet tölt fel…ebben ki tud segíteni?

sziasztok.abban kéne segiteni hogy van egy oldalam külön én tudom feltölteni a képeket.de azt szeretném hogy egy keretbe rakja bele nekem és abban lehessen megtekinteni.előre is köszi

Véletlenül találtam a kódra, pont egy ilyenre van szükségem, kipróbálom. Köszönöm szépen.
Ildi

Egészségedre, ha kérdés van, keress nyugodtan.

Szia! Hogyan kell használni a progit? Van egy formom, ahol 2 képet és a hozzájuk tartozó szöveget lehet felvinni az adatbázisba – pontosabban a képnek csak az elérési útját. Mit hogyan kell megváltoztatni, hogy a képek 500*X, a kis képek 100*x px méretűek legyenek?
Köszönöm a választ!
Ildi

Egy form actionjében kell meghívni a függvényt, valahogy így:

picupload(‘/var/www/kepek/’, 500, 100);

De ez a script csak sajátgépről való feltöltséhez jó. URL-ről lementéshez nem. Csak némi módosítással.