zupa Posted July 1, 2004 Report Share Posted July 1, 2004 Sveiki! Savajadzējās skriptu, kurš noalasa no mysql tabulas bildi, izmaina taas izmeeru, uztaisa unsharp masku un pievieno attiecīgajam ierakstam thumbnailu. Viss darbojas izņemot thumbnaila ielikšanu tabulā - tur tiek ievietots strings "Reource #<kkāds cipars>". Kur varētu būt probza? Link to comment Share on other sites More sharing options...
bubu Posted July 1, 2004 Report Share Posted July 1, 2004 probza droši vien tāda, ka tu MySQL INSERT/UPDATE teikumā padod gd bibliotēkas image resource handli, a vajag pašus bildes datus bāzt iekšā! Link to comment Share on other sites More sharing options...
Venom Posted July 2, 2004 Report Share Posted July 2, 2004 labojums: bildes ieteicams tomēr glabāt failos, bet mysqlā tikai to nosaukumus un/vai norādes uz tipu/direktoriju. Es parasti izmantoju variantu ... type imagefile thumb.. sense ... 1 ... img001....1..........1 ....2 ... img002....0..........2 1. tips nozīmē jpg/gif/png/bmp utt. (parasti tikai 1ie 3) 2. - bildes nosaukums bez paplašinājuma 3. vai ir noģenerēts tumbnails 4. bildes "nozīme", resp. glabājamo direktoriju pārslēgs fs struktūra: sense\bildes fails sens_thumb\bildes thumbs ar tādu pašu nosaukumu plusi ir vairāki a) mazāka datu bāze (neglabājot failus iekš tās) - vieglāka portabilitāte (paskatīšos es uz tevi, kad vajadzēs gatavo db pārnest uz maksas hostingu, kur piekļue mysql tikai ar phpMyAdmin no localhost :blink: B) gribam nomainīt mapju struktūru - lūdzu (tikai skriptā jāieraksta $opt['sense'][1], piem.) c) gribam bildei nomainīt formātu? nomainam type d) uzreiz no mysql pieprasījuma var saprast, vai ir thumbs un attiecīgi ģenerēt ilustrācijas utml Link to comment Share on other sites More sharing options...
bubu Posted July 2, 2004 Report Share Posted July 2, 2004 type vietā nav labaak glabāt nevis 1/2/3, bet mimetype (image/png), tā uzreiz varēs headeri pareizo sūtīt, bez nekādiem ifiem vai masīviem, ne? un kāpēc bilde bez paplašinājuma jāglabā? lieka darbība tikai rodas norādot faila ceļu uz bildi. Link to comment Share on other sites More sharing options...
Aleksejs Posted July 2, 2004 Report Share Posted July 2, 2004 Ntie chari aizņem vairāk vietas datubāzē, nekā tinyint. Link to comment Share on other sites More sharing options...
Venom Posted July 2, 2004 Report Share Posted July 2, 2004 (edited) type vietā nav labaak glabāt nevis 1/2/3, bet mimetype (image/png), tā uzreiz varēs headeri pareizo sūtīt, bez nekādiem ifiem vai masīviem, ne? un kāpēc bilde bez paplašinājuma jāglabā? lieka darbība tikai rodas norādot faila ceļu uz bildi. att. uz 1/2/3 tabulu racionalizācija prasa tomēr likt 1/2/3 (pie tam column tips ir unsigned tinyint/char(1), nevis enum) 100 ieraksti ar image/png ~ 900B 100 ieraksti ar 1 ~ 100B failu nosaukumi bez .xxx dēļ tā paša iemesla (katram ierakstam tiek ietaupīti 4 baiti) imagetype switchot var pašā selektā - SELECT ELT(FIELD(`type`,1,2,3),'image/jpeg','image/png','image/gif') as `type` tāpat ar paplašinājumiem [ CONCAT(`imagefile`,'.',ELT(FIELD(`type`,1,2,3),'jpg','png',''gif)) ] vienīgais es visus jpeg pārsaucu par jpg (nu nepatīk man 4 burtu paplašinājumi) pie tam, visu vajadzīgo info, uploadu un apstrādi nodrošina pašveidota klase, tā kā būtībā viss tiek novest līdz $VenImage->upload('formas elt-ta name',1 (noģenerēt tumbnailu)); [NB: bet es sevi pieķeru pie tā, ka baigi visu optimizēju un universalizēju, piem. pēdējā CMS ko rakstīju (iLink Lite - ar rakstu, attēlu, piesaistņu piev./upd./thumbnailošanu; vairāku autoru autorizāciju; bezgalīgi atzarojamo izvēļņu (vairāku) radīšanu caur webu; ar wysiwg iespājām; mailu spam aizsardzību; pie tam viss vairākās valodās) neieskaitot standarta wysiwg js, kas nav manis paša rakstīts un pats par sevi ir ap 200kb (arī apgraizīts no liekā) - aizņem 65 Kb un pie tam apm. 2 minūtēs es varu nomainīt visu no dizaina līdz izvēļņu loģikai. Tādi traki esam] Edited July 2, 2004 by Venom Link to comment Share on other sites More sharing options...
bubu Posted July 2, 2004 Report Share Posted July 2, 2004 Labi, piekrītu. Man nebija taisnība ;) Link to comment Share on other sites More sharing options...
Venom Posted July 2, 2004 Report Share Posted July 2, 2004 te jau nav nebija runas kam taisnība, kam nē - vairāk "kā būtu labāk" Link to comment Share on other sites More sharing options...
zupa Posted July 2, 2004 Author Report Share Posted July 2, 2004 Šajā gadījumā serverim var pat anykey nospiest, tā ka DB pārvietošana ta tā. Anyway - izdomāju workaroundu - ar imagejpeg uztaisu to bildi failā, ielasu un pēc tam unlink... Link to comment Share on other sites More sharing options...
bubu Posted July 3, 2004 Report Share Posted July 3, 2004 Šajā gadījumā serverim var pat anykey nospiest, tā ka DB pārvietošana ta tā. Anyway - izdomāju workaroundu - ar imagejpeg uztaisu to bildi failā, ielasu un pēc tam unlink... var tak bez faila iztikt: <?php ob_start(); imagejpeg($image); $contents = ob_get_contents(); ob_end_clean(); // tagad to, ko satur $contents, liec iekšā DB ?> Link to comment Share on other sites More sharing options...
zupa Posted July 3, 2004 Author Report Share Posted July 3, 2004 Big thanks! Shis ir tas ko mekleeju! You're the man! Link to comment Share on other sites More sharing options...
zupa Posted July 3, 2004 Author Report Share Posted July 3, 2004 Šajā gadījumā serverim var pat anykey nospiest, tā ka DB pārvietošana ta tā. Anyway - izdomāju workaroundu - ar imagejpeg uztaisu to bildi failā, ielasu un pēc tam unlink... var tak bez faila iztikt: <?php ob_start(); imagejpeg($image); $contents = ob_get_contents(); ob_end_clean(); // tagad to, ko satur $contents, liec iekšā DB ?> Pilnai laimei šādi būtu (minor improvement): <?php ob_start(); imagejpeg($image); $contents = addslashes(ob_get_contents()); ob_end_clean(); // tagad to, ko satur $contents, liec iekšā DB ?> Link to comment Share on other sites More sharing options...
Recommended Posts