Voor een betreffend klein projectje sla ik enkele afbeeldingen op in mijn database. (dat dit niet done is etc weet ik allemaal, maar heb dit gedaan omdat het toch maar enkel foto's zijn, dus dan weten jullie ookal waarom ik ze opslaag in mijn database.)
Nu tot over een week gebruikte ik dit stukje code om mijn foto's uit te lezen:
<?php
$connect = new mysqli('localhost', 'root', 'root', 'ioutfit');
$result = $connect->query('SELECT foto from tblFotos ORDER BY PK_fotoID');
while($row = $result->fetch_array()) {
echo '<img src="data:image/jpeg;base64,' . base64_encode($row['foto']) . '" width="100%" height="100%"/>';
echo '<br>';
//echo $seisoon;
}
?>
Nu wou ik vandaag verder werken aan mijn project blijkt nu dat deze code op mijn server iet meer werkt? lokaal toont hij nog enkele afbeeldingen maar online dus geen enkele meer. (wel toont hij een kader met een gebroken foto in zoals het geen je zou krijgen als je pad naar een image op de server niet gevonden is)
Iemand die ziet wat mijn fout is of hoe je dit op een andere manier kan uitlezen?
Bijkomende vraag, betreffende dezelfde app heb ik dus ook een upload scriptje geschreven, werkt perfect op de computer MAAR mobiel op iphone slaagt hij een blob op van 0 bytes? Android doet het dan weer wel goed. Iemand hier enige ervaring mee?
(dat dit niet done is etc weet ik allemaal, maar heb dit gedaan omdat het toch maar enkel foto's zijn, dus dan weten jullie ookal waarom ik ze opslaag in mijn database.)
Of het not done is of niet is op zich niet zo relevant. Dat is jouw keuze. De vraag die ik mezelf alleen wel zou stellen is 'Zou ik dit probleem ook hebben als ik het niet als BLOB zou opslaan?'. Het antwoord daarop is volgens mij nee. Met andere woorden, ik denk dat je je tijd nu bestaat aan een probleem wat je helemaal niet hoeft te hebben. Verkwanselde tijd en energie dus.
Verder kan ik je net als Aar niet echt helpen, want ik heb er, helaas voor jou, nooit mijn tijd aan besteed....
Bedankt voor jullie antwoorden!
Erwin, inderdaad ik heb mij hier serieus aan mispakt ben ik mezelf heel erg bewust van, probleem zit hem dus dat heel mijn mobile web app hier opgebasseerd is en en dus opnieuw beginnen geen optie is aangezien mijn deadline volgende week is.
Ik ben er net wel al achtergekomen dat het uitlezen volledig correct gebeurt, het is mijn upload die blijkbaar toch niet werkt op computer. Ik had net al mijn records verwijderd om wat represente data toe te voegen, dit toevoegen deed ik dus via mijn upload script. Blijkbaar had ik in een vorig statium mijn foto's dus via phpmyadmin toegevoegd, wat ik dus vergeten was (wel logisch want toen had ik dit script nog niet geschreven).
Ik weet nu toch al waar mijn fout zit en kan weer wat specifieker gaan zoeken op google, als er hier mensen zijn die ervaring hebben met het upload van een blob in de database, jullie hulp/tips wordt nog steeds erg geapreciërd!
[code]<?php
ob_start();
readfile($_FILES['myfile']['tmp_name']);
$file = ob_get_contents();
ob_end_clean();
// EN DAN NIET VERGETEN!!!!
// mysqli_real_escape_string($link, $file)
// geldt tevens voor alle overige user input
?>
als er hier mensen zijn die ervaring hebben met het upload van een blob in de database
Ja en nee. ;-) Ik heb verschillende databases waar foto's in worden opgeslagen als blobs, alleen bewerk ik die niet in PHP, maar in Perl. Het principe zou hetzelfde moeten zijn.
Een van de verschillen die me opvallen qua werkwijze is dat bij jou de foto's als binary data in de database staan, maar dat ze bij de invoer en uitvoer worden omgezet van of naar base64. Daar zou ik zelf niet per se voor kiezen. Als ze worden aangeleverd als base64 en ook als base64 weer worden aangeboden, zou ik ze ook als base64 opslaan in de database (en dan niet als blob, maar als text).
Zelf verwerk ik alles als binary. De plaatjes komen binnen als POST-data (binair) en gaan rechtstreeks de database in.
Bij het opvragen/tonen van de plaatjes worden ze niet als inline data in de img-tag opgenomen. In plaats daarvan verwijst de img tag naar een los script, dus iets als:
<img src="/getimage.php?id=42">
In dat getimage-script wordt het plaatje opgehaald uit de database. Het script genereert een image/jpeg-header en gooit daarna de (binaire) data erachteraan. Zoiets ongeveer:
<?php
header('content-type: image/jpeg');
include "dbconnect.php";
$rs = mysqli_query("select plaatje from tabel where id=$_POST[id]");
$rec = $rs->fetch_row();
print $rec[0];
?>
(disclaimer: dit is conceptuele code; ik garandeer niet dat het werkt en dingen als inputvalidatie en foutafhandeling zul je nog moeten toevoegen)
Ik was nog vergeten te melden dat de code in mijn vorige reactie gedeeltelijk uit een bestaand en werkend script komt. Het enige verschil is dat de output buffer wordt gevuld met imagejpeg ipv readfile.
En dan zoals Willem aangeeft de plaatjes ophalen met een script.
En Joren, je controleert nergens of het wel een image is, dus ik kan zomaar een bestand met malicious code erin gooien.
nadeel van de methode <img src="/getimage.php?id=42">
is dan weer dat je voor elk plaatje een apart script met een aparte database verbinding nodig hebt.
Nadeel van de inline-images is weer, dat je html file erg groot dan worden en je mogelijk per saldo weer meer data moet oversturen, ( al dan niet gezipt)
Dat van die database-verbindingen zal in de praktijk wel meevallen. Eventueel kun je een persistent connectie maken door in je mysqli_connect 'p:' voor je hostname te zetten.
technisch valt het wel mee, wat er gebeurt. Maar stel dat je een pagina hebt met 3 afbeeldingen.
Dan is het niet 1 aanroep naar PHP gevolgd door het opvragen van die 3 afbeeldingen,
maar nog een keer 3x php aanroepen. Elk script heeft zijn eigen database verbinding nodig. (desnoods uit een pool gehaald ja), voert een query uit op de database-server. Die draagt de data over aan php en php spuugt dat uit.
Zonder maatregelen met extra headers wordt dat niet gecacht. Dus waar een opgeslagen afbeelding bij het herladen van de pagina gewoon met een header "304 not changed" kan worden afgedaan, doe je dat proces opnieuw.
Voor 1 pagina is dat prima te overzien.
Maar als het een site betreft die vaak bezocht wordt, laten we zeggen 60 hits per minuut.
Dan heb je het niet over 1 php aanroep per seconde maar 4
Je afbeeldingen gaan elke keer over de lijn, dus meer data verkeer.
Daarnaast maak je heel regelmatig een backup van je database. (of dat doet je hoster.)
Binaire data neemt een hoop ruimte in in de database. Maar deze data is niet erg aan verandering onderhevig. Dus als file op hd had hij een datum gehad, en had een intelligent backup proces die file kunnen herkennen als oud en niet bij elke backup mee zullen pakken.
Het kan wel.
Maar er is ook een hoop als reden om het niet te doen aan te voeren.
eea hangt samen met hoeveel files en hoe druk je site bezocht is
