MySQL Blob data (jpeg) weer geven via javascript

[BoringDay]

Ik heb in een mysql tabel een vel met blob data (jpg base64 encoded).
Via javascript script post-request ik een php pagina die de data aflevert.

Nu wil ik een element voorzien van de blobdata (thumb is de encoded data van de image)

var source = "'data:image/jpg;base64,"+thumb;
Deze zet ik dan bij een image.src of een background image.

Echter krijg ik geen resultaat, je zou toch aannemen dit soort eenvoudige dingen wel eens een keer fatsoenlijk ondersteund wordt door javascript en php zonder allerlei fratsen.

Heeft iemand een idee hoe dit aan de praat te krijgen zonder allerlei rare alternatieve methodes?
Ik wil slecht een afbeelding uit de database uit kunnen lezen via javascript en weer kunnen geven bij de bijbehorende element.

[RobIII]

Bij mij werkt dat gewoon
Heb je al gekeken of je uberhaupt een/de juiste response terug krijgt van de server? Al eens de response naar je console window geschreven (console.log) om te zien of er ook in zit wat je verwacht dat er in zit? Post eens wat relevante(!) code?

[ Voor 68% gewijzigd door RobIII op 12-06-2013 17:36 ]

[BoringDay]

RobIII schreef op woensdag 12 juni 2013 @ 17:33:
Bij mij werkt dat gewoon
Heb je al gekeken of je uberhaupt een/de juiste response terug krijgt van de server? Al eens de response naar je console window geschreven (console.log) om te zien of er ook in zit wat je verwacht dat er in zit?

De data krijg ik correct toegezonden.
Request method gaat via post (get schijnt hier ook niet voor geschikt te zijn).
Mijn upload script encode de image met base64.

Ik ga ervan uit dat de data niet ge-decode moet worden omdat in de data al aangegeven wordt dat het om base64 gaat.

Mijn upload functie ziet er als volgt uit:

PHP:

private function upload_file($user_id,$tmpname,$filename,$type,$size,$caption) {
            
                
                $image    = file_get_contents($tmpname);
                $image    = mysql_real_escape_string(addslashes($image));
                $thumb    = $this->resizeImage($tmpname,300,300);
                
                $image    = base64_encode($image);
                $thumb    = base64_encode($thumb);
                            
                $caption  = mysql_real_escape_string($caption);
                $query    = "INSERT INTO files_".$user_id." (user_id,file,thumb,filename,type,size,caption,modifydate) VALUES ('".$user_id."','".$image."','".$thumb."','".$filename."','".$type."','".$size."','".$caption."',FROM_UNIXTIME(1299762201428))";
    
                $size   = strlen( $query ) + 1024;
                $this->run('SET @@global.max_allowed_packet = ' . $size, false);
                $result = $this->run($query,false);
                
                if (is_uploaded_file($tmpname)) { return true; } else { return false; }
                
}

[RobIII]

Euh, en heb je die base64 code ook al eens, zoals ik 't deed, getest in een image? Want aan je 'addslashes' te zien kon 't wel eens goed zijn dat je de binaire data gewoon vernacheld hebt. Er horen namelijk helemaal geen slashes toegevoegd te worden als je mysql_real_escape_string (ook) al gebruikt. Sterker; beide images base64-encode je al; dan hoef je, in principe, helemaal niks meer te escapen met addslashes/mysql_real_escape_string want in base64 komen enkel a-z, A-Z, 0-9, +, / en = (padding) voor. Neemt niet weg dat 't escapen wel gedaan dient te worden; maar normaliter doe je dat in een DBAL die ook weet voor welk specifiek RDBMS je zou moeten escapen. Nu is je implementatie redelijk vastgeklinkerd aan MySQL...

[ Voor 78% gewijzigd door RobIII op 12-06-2013 18:10 ]

[BoringDay]

RobIII schreef op woensdag 12 juni 2013 @ 17:43:
Euh, en heb je die base64 code ook al eens, zoals ik 't deed, getest in een image? Want aan je 'addslashes' te zien kon 't wel eens goed zijn dat je de binaire data gewoon vernacheld hebt. Er horen namelijk helemaal geen slashes toegevoegd te worden als je mysql_real_escape_string (ook) al gebruikt.

Daar heb je idd een punt!
Dat ga ik meteen even aanpassen en testen
-----------------------------------------------

Nu krijg ik de volgende foutmelding:
Failed to load resource: the server responded with a status of 414 (Request-URI Too Large)
Dus er speelt nog iets meer ... maar wat?

[ Voor 18% gewijzigd door BoringDay op 12-06-2013 17:57 ]

[RobIII]

BoringDay schreef op woensdag 12 juni 2013 @ 17:46:
Dus er speelt nog iets meer ... maar wat?

Precies wat de foutmelding zegt: je stuurt een (veel) te lange request naar de server. Veel meer dan een http://domein.nl/foo/bar/imagethingy.php?id=abc123 hoef je toch niet te requesten? (Ik zie sowieso niet waarom dat met een POST zou moeten, iets met idempotency enzo, maar sod it). En die kan prima een platte tekst a-la iVBORw0KGg...rkJggg== returnen, of wat JSON o.i.d.:

JavaScript:

{
  "caption"   : "W00t!",
  "imagedata" : "iVBORw0KGg...rkJggg==",
  "type"      : "image/png"
}

Again: post eens een testcase of laat eens wat relevante(!) informatie zien (bijvoorbeeld uit je Firebug / IE F12 Dev.tools / Chrome Dev.tools / Safari Dev.tools / Opera Dragonfly -console)?

[ Voor 45% gewijzigd door RobIII op 12-06-2013 18:07 ]

[BoringDay]

RobIII schreef op woensdag 12 juni 2013 @ 18:00:
[...]

Precies wat de foutmelding zegt: je stuurt een (veel) te lange request naar de server. Veel meer dan een http://domein.nl/foo/bar/imagethingy.php?id=abc123 hoef je toch niet te requesten? (Ik zie sowieso niet waarom dat met een POST zou moeten, iets met idempotency enzo, maar sod it).

Mijn request voor de database gegevens voert slecht een query uit.
De resultaten worden terug gestuurd naar javascript.

Mijn javascript stelt het element nadat de gegevens al binnen zijn.
Het gaat bij mijn weten mis met var source = "'data:image/jpg;base64,"+thumb;
Hij plakt hier de hele binaire code aanwast met het domein url ervoor (http://10..../) (geen idee of dit normaal is).

JavaScript:

TPhotolist.createThumb = function(thumb) {

//  thumb = this.base64_decode(thumb);

    var obj = NewObject(TDiv);
        obj.parentId = this.id;
        obj.onInitialize();
        obj.createElement();

    this.thumblist.push(obj);
    var index = this.thumblist.length;
        index = index.toString();
            
        obj.id = this.id+'_thumb_'+index;
        obj.element.setAttribute('id',obj.id);
            
    this.element.appendChild(obj.element);
    
    var source = "'data:image/jpg;base64,"+thumb;
    
        obj.background.image = source;
        obj.position.top     = '1px';
        obj.position.left    = '1px';
        obj.position.width   = '48px';
        obj.position.height  = '50px';
        jQuery(obj).css('background-image',source);
        
/*  var img = document.createElement('img');
        img.src    = source;
        img.setAttribute('position', 'absolute');
        img.setAttribute('height','100%');
        img.setAttribute('width','100%');
        
    obj.element.appendChild(img);
        
    debug.console(obj); */
}

[RobIII]

Hadden we je
niet all méérmaals
op het gebruik van enters
gewezen? Wil je daar,
for the love of <random_deity>
mee stoppen?

Nogmaals: Wat zit er precies in thumb? Is dat base64 data? Is dat iets anders? Wat? We hebben geen glazen bol you know

[Edit]
Oh, en als je een background-image gebruikt dient daar url() omheen te staan (zie hier voor een aangepast voorbeeld a.d.h.v. de eerdere post); je zet dat ook geen .src maar een background-image En niet één keer maar meerdere keren btw. Als je een img gebruikt gewoon de .src zetten; voor een span, div oid. kun je een background-image setten.

Ik verwacht dan ook dat jQuery uiteindelijk, omdat je geen url() gebruikt, maar besluit om er http:// voor te mikken inc. je domein wat dan ook de foutmelding "Request-URI Too Large" verklaart; je request dan immers iets als http://mijndomein.nl/dataiVBORw0KGg...rkJggg==. Ik kan 't zo snel niet reproduceren, maar goed. Anyway; zoiets moet 't dus worden.

Ik weet niet welke grapjas revisie 2 en 3 heeft gemaakt, maar m'n browser b0rked er aardig op; u bent gewaarschuwd

[ Voor 80% gewijzigd door RobIII op 12-06-2013 18:33 ]

[BoringDay]

RobIII schreef op woensdag 12 juni 2013 @ 18:10:
[mbr]Hadden we je
niet all méérmaals
op het gebruik van enters
gewezen? Wil je daar,
for the love of <random_deity>
mee stoppen?[/]

Nogmaals: Wat zit er precies in thumb? Is dat base64 data? Is dat iets anders? Wat? We hebben geen glazen bol you know

Sorry ik krijg last altijd van dementerende verschijnselen bij het combineren van javascript en php. Maar idd er zit idd de encoded data in de thumb variabele.

[RobIII]

Zie mijn edit...

[BoringDay]

RobIII schreef op woensdag 12 juni 2013 @ 18:18:
Zie mijn edit...

obj.background.image is een oververfde object, op het moment ik een waarde aan deze property toeken
wordt de url/data automatisch ingekapseld url(' ').

Mijn thumb data is wel een flink stuk langer dan het voorbeeld van je link.
(jpeg van 300x300) , hier wordt dan een EOL expected melding gegeven.
Mijn data eindigt overigens niet met == maar met 1 = teken.

[RobIII]

BoringDay schreef op woensdag 12 juni 2013 @ 18:34:
Mijn thumb data is wel een flink stuk langer dan het voorbeeld van je link.

En incorrect

BoringDay schreef op woensdag 12 juni 2013 @ 18:34:
(jpeg van 300x300) , hier wordt dan een EOL expected melding gegeven.

Want incorrect

Ik zie in (naar ik aanneem jouw?) rev. 2 en rev. 3 namelijk het volgende:

JavaScript:

var thumb = '/9j/4FxcMBBKRklGXFwwAQFc...
debug.js:19/9j/4FxcMBBKRklGXFwwAQFcXDBcX...4vWL212/9k=';

Dat klopt natuurlijk sowieso niet. Dat zou zoiets moeten zijn:

JavaScript:

var thumb = '/9j/4FxcMBBKRklGXFwwAQFc......4vWL212/9k=';

Hoe die debug.js daar in terecht komt weet ik niet; maar dat moet je dus eens even nakijken.

BoringDay schreef op woensdag 12 juni 2013 @ 18:34:
Mijn data eindigt overigens niet met == maar met 1 = teken.

Padding (wat ik eerder ook al aangaf). Base64 strings eindigen doorgaans op 1 of 2 = tekens of helemaal geen. Niet relevant voor je probleem.

En ik zeg dit voor de aller-aller-allerlaatste keer: Hou nou eens op met die enters na elke zin. Het begint écht vervelend te worden. Gebruik gewoon alinea's en laat de tekstomloop aan 't forum over.

[ Voor 60% gewijzigd door RobIII op 12-06-2013 18:54 ]

[BoringDay]

Je hebt helemaal gelijk, inmiddels is het werkend. Bedank voor je praktische inzichten, jQuery gooide inderdaad de http ervoor.

Binnenkort kom ik nog even met een vraagstelling omtrent $_Files en javascript. Hoewel ik aardig eindje ben met het posten van FormData via xhr krijg ik nog geen $_FILES gegevens binnen. Maar dat is weer onderwerp apart! Anyway bedankt voor je hulp!

[Cartman!]

BoringDay schreef op woensdag 12 juni 2013 @ 17:42:

PHP:

$query    = "INSERT INTO files_".$user_id." (user_id,file,thumb,filename,type,size,caption,modifydate) VALUES ('".$user_id."','".$image."','".$thumb."','".$filename."','".$type."','".$size."','".$caption."',FROM_UNIXTIME(1299762201428))";

Wellicht off-topic voor jouw probleem, maar waarom heb je een tabel per gebruiker ipv. 1 tabel waar je het id van de gebruiker in opslaat?

[RobIII]

Die was me nog niet eens opgevallen

[BoringDay]

Deze tabel is meer als test, ik ben nog niet zo heel bekend met mysql als het gaat om grote hoeveelheid data van in de paar 100.000 den records. Maar het lijkt me wel efficiënter als je per gebruikers tabellen hebt.
Kan MySQL een beetje grote hoeveelheden aan zonder al teveel verlies van snelheid?

[bartbh]

Mist juist opgezet, ligt MySQL echt niet wakker van enkele 10.000en records hoor. Je haalt je veel meer werk op de hals als je met 10.000en tabellen aan komt zetten.

Wat is logischer, voor iederen klant een aparte multomap met 1 blaadje aanmaken of voor iedere klant 1 blaadje in 1 multomap?

[BoringDay]

Daar ben ik het wel mee eens, de database indeling was hier dan ook nog geen aspect. Daarbij heb ik mijn framework dusdanig opgesteld dat toepassingen voor mysql eenvoudig zijn aan te passen en uit te breiden.

[RobIII]

BoringDay schreef op woensdag 12 juni 2013 @ 23:38:
Daarbij heb ik mijn framework dusdanig opgesteld dat toepassingen voor mysql eenvoudig zijn aan te passen en uit te breiden.

Als je nu nog een framework (nog wel!) aan 't bouwen bent dat mysql_real_escape_string gebruikt... Tja... Was die grote

nog niet duidelijk genoeg ofzo? Lees dit anders even.

Los daarvan; ik zie in deze post behalve een $this->run weinig hint naar iets dat op framework lijkt en nou net die ene snippet impliceert dat je "whatever class" die de upload_file functie bevat tevens kennis heeft van je datalayer; sterker: het ding bevat gewoon de queries ervoor. Ik zie niet hoe dat strookt met "eenvoudig [...] aan te passen"; als je een ander RDBMS wil gebruiken zul je toch echt die queries moeten nagaan in alle classes of er geen MySQL specifieke zaken in zitten e.d. En, golly, in dat kleine stukje code dat we zien zie ik zo al 2 zéér MySQL-specifieke zaken: FROM_UNIXTIME en SET @@global.max_allowed_packet.

Ik bedoel dit met de beste intentie van de wereld en enkel als goedbedoeld advies: voordat je aan een framework gaat beginnen zorg dan eerst dat je 't een beetje onder de knie hebt; je tabel-per-user is ook zo'n klassieke beginnersfout.

[ Voor 66% gewijzigd door RobIII op 13-06-2013 00:03 ]

[BoringDay]

Oops nog niet eens naar gekeken. Wat raad je aan PDO of MySQLi? En wat doe je hierbij tegen sql injecties?

Upload_file is slechts om een image in de database te plaatsen. FROM_UNIXTIME mysql specifiek? wat is dan een goed alternatief voor timestamp die automatisch de tijdzone herkent?

@@global.max_allowed_packet deze had ik ergens weg geplukt omdat ik tegen limieten aanliep (maximaal geheugen, maximale grootte van een bestand, maximale aantal bestanden) hiervoor heb ik ook aantal settings in de php.ini aangepast. Als je hiervoor een al-in-one oplossing hebt, van harte welkom.

Betreft de database tabel, dat is niet een tabel die ik straks verder ga gebruiken. Daarbij weet ik wel hoe ik een database moet normaliseren, stored procedures, triggers, sleutels, geen dubbele gegevens blablbla. Het ging mij hier slechts om een blob bestand uit te wisselen met javascript. Maar daar begin ik aan zodra ik de $_FILES voor uploaden gereed heb.

[ Voor 23% gewijzigd door BoringDay op 13-06-2013 00:43 ]

[d.drenth]

Wat ik me afvraag waarom zet je in godsnaam afbeeldingen in een database, dit is per definitie al fout. Het opslaan van bestanden in een database geeft alleen maar extra overhead. Sla je afbeeldingen gewoon op en eventueel kan je een bestandsnaam in de database opslaan, maar zelfs dit zou niet nodig hoeven zijn indien je de afbeelding op slaat met een id in de bestandsnaam.

[BoringDay]

d.drenth schreef op donderdag 13 juni 2013 @ 00:48:
Wat ik me afvraag waarom zet je in godsnaam afbeeldingen in een database, dit is per definitie al fout. Het opslaan van bestanden in een database geeft alleen maar extra overhead. Sla je afbeeldingen gewoon op en eventueel kan je een bestandsnaam in de database opslaan, maar zelfs dit zou niet nodig hoeven zijn indien je de afbeelding op slaat met een id in de bestandsnaam.

Wat is er fout aan? Gezien ook een filesysteem limieten van aantal mappen en bestanden kent dan is een database tabel hiervoor een betere oplossing. Overigens doet men dit al jaren en behoort gewoon tot de mogelijkheden van een database.

[RobIII]

d.drenth schreef op donderdag 13 juni 2013 @ 00:48:
Wat ik me afvraag waarom zet je in godsnaam afbeeldingen in een database, dit is per definitie al fout.

(emphasis mine)
Onzin. Er zijn perfect valide redenen om een afbeelding (of andere blob) in de DB op te slaan. Al is 't maar om te voorkomen dat DB en FS "uit sync" raken of om te zorgen dat (om wat voor reden dan ook) de blobs in dezelfde backup staan. Of 't altijd gedaan moet worden is een tweede, maar het is niet per definitie fout.

BoringDay schreef op donderdag 13 juni 2013 @ 00:38:
Oops nog niet eens naar gekeken. Wat raad je aan PDO of MySQLi? En wat doe je hierbij tegen sql injecties?

Ikzelf gebruik graag MySQLi maar PDO doet 't ook goed verneem ik regelmatig. De link onder "dit" in mijn vorige post moet voldoende voer zijn voor je om zélf een onderbouwde keuze te maken voor MySQLi of PDO. Tegen SQL injections gebruik je (al sinds jaar-en-dag hoor ) Parametrized Queries.

Voor de rest van je vragen mag je ook zelf wel eens wat moeite doen; de meeste zijn prima zelf te beantwoorden als je even een paar minuten de moeite neemt. We zijn hier geen afhaalchinees of helpdesk

BoringDay schreef op donderdag 13 juni 2013 @ 00:38:
Betreft de database tabel, dat is niet een tabel die ik straks verder ga gebruiken.

Ik zie niet eens waarom je deze methode (tabel per user_id) zou gebruiken tijdens testen/ontwikkelen; het is alleen maar omslachtig en méér werk dan een enkele tabel en uiteindelijk gaat 't er toch weer uit volgens jou. Op het moment dat je de code $query = "INSERT INTO files_".$user_id." (user_id, ... schreef had er bij iemand die weet hoe hij/zij "moet normaliseren, stored procedures, triggers, sleutels, geen dubbele gegevens blablbla" een loeiende alarmbel moeten gaan rinkelen. Bij mij ontstaat er iig een kortsluiting tussen mijn twee hersenhelften als ik op 't punt sta zoiets te schrijven of zoiets bedenk

[ Voor 72% gewijzigd door RobIII op 13-06-2013 03:40 ]

[BoringDay]

Parametrized Queries, deze ken ik van andere databases was het alleen nog nergens tegen gekomen voor mysql. Zie her en der nog mysql_real_escape_string worden toegepast, iets wat ik dan ook per direct zal gaan afleren. Voor mij is het nu wel duidelijk maar je moet wel even weten wat en waar je de juiste methodes kan vinden.

[RobIII]

BoringDay schreef op donderdag 13 juni 2013 @ 11:41:
Zie her en der nog mysql_real_escape_string worden toegepast [...] maar je moet wel even weten wat en waar je de juiste methodes kan vinden.

Ik heb een hé-le-boel kritiek op de documentatie van PHP, maar in dit geval is 't toch écht je eigen "schuld" dat je niet even in de documentatie hebt gekeken; en daar is 'ie notebene voor

BoringDay schreef op donderdag 13 juni 2013 @ 11:41:
Parametrized Queries, deze ken ik van andere databases was het alleen nog nergens tegen gekomen voor mysql.

Again, dat is waar documentatie voor is Je hoeft 't niet 'ergens' tegen te komen behalve in de documentatie Pas als je 't daar niet tegen komt ga je 'elders' kijken of er misschien toch stiekem een oplossing / workaround is.

Je hebt, waarschijnlijk, je code gebaseerd op een van de miljoenen "tutorials" uit 't jaar knoop of een site/blog dat niet echt een betrouwbare bron is. Of erger: op de "wijsheden" in de comments van de PHP documentatie. Daar heeft PHP (je zou kunnen zeggen "helaas") wel erg veel last van (andere talen overigens uiteraard ook, maar, IMHO, vele malen minder dan PHP). Het is dan ook belangrijk, nee, noodzaak dat je je eigen inzicht/kennis/grijze_materie blijft gebruiken tijdens 't ontwikkelen en vooral, of zoveel mogelijk, afgaat op betrouwbare bronnen als product-eigen documentatie i.p.v. geblaat van derden.

[ Voor 9% gewijzigd door RobIII op 13-06-2013 12:05 ]

[BoringDay]

Wellicht, php.net ben ik al geen fan van. Daarbij mogen ze wel eens een keer 1 taal gaan ontwerpen voor websites. Persoonlijk vind ik het momenteel een complete zootje wat ze ervan gemaakt hebben. Alleen het feit al dat bijv. javascript een single thread taal is. PHP ook nog eens per server kan verschillen. En dan niet te vergeten dat geen enkele browser zich volledig aan de standaarden houdt.

[RobIII]

Dinsdag, blauw, spaghetti, nachtzwaluw. Makes about the same sense

[Janoz]

BoringDay schreef op donderdag 13 juni 2013 @ 11:41:
Parametrized Queries, deze ken ik van andere databases was het alleen nog nergens tegen gekomen voor mysql.....

Parametrized Queries heeft in principe helemaal niks met de database te maken. Parametrized queries is juist een feature van de taal die je gebruikt (in dit geval php).

[BoringDay]

Dat geloof ik allemaal wel, het is me inmiddels duidelijk php.net als leidraad te gebruiken zoals Rob al aangaf en flink opletten met de veel verspreide alternatieven die op het net rondzwerven. Maar van fouten leren we het best. Zal me nog even verdiepen welke kant ik op ga PDO of MySQLi.

Mijn excuses voor de vervelende enters en vragen maar zeker informatief en de kritieke punten die de moeite waard zijn om aandacht aan te besteden (corrigerend tikje).

[Verwijderd]

BoringDay schreef op woensdag 12 juni 2013 @ 18:34:
[...]


obj.background.image is een oververfde object

En wat voor kleur heeft hij nu dan?

kon het helaas niet laten

[Creepy]

Dus.......................... meer dan een jaar niet op het forum gepost en dit is je comeback post? Laat dit soort posts maar gewoon achterwege.

[ Voor 66% gewijzigd door Creepy op 15-07-2013 17:51 ]