Bild aus Datenbank laden

[UnknownUser]

Hallo!
Das ist mein erster Post, da ich Probleme eigentlich immer über die Forumssuche lösen konnte. Nun verlässt mich das Glück.

Ich habe zwei Systeme. Zuhause einen XAMPP mit Apache/PHP5.5/MySQL als Testsystem und bei Hetzner Webhosting ebenfalls mit Apache/PHP5.5/MySQL

Ich möchte ein Bild (jpeg) automatisch croppen und mit Wasserzeichen versehen, anschließend wird es Base64_Encoded und in ein longblob-feld in die Datenbank geschrieben. - Auf dem Testsystem klappt alles. Dieses Testscript gibt das bild auch aus:

<?php
header("Content-type: image/jpeg");

require_once ('./dbconnect.php');
$strQuery= "SELECT *
FROM `images`
WHERE id=".$_GET['id'];
$result=@mysql_query($strQuery);
$row=@mysql_fetch_assoc($result);

echo base64_decode($row['imgdata']);
?>

Selbes Setup (identisches bild, datenbankstruktur) auf dem Hetznersystem bringt den Fehler: "Die grafik <pfad> kann nicht angezeigt werden, weil sie Fehler enthält".

Lässt man bei beiden Systemen den Header weg und vergleicht die Stringrepräsentationen sind beide Datensätze jeweils identisch. Sowohl Base64 Encoded als auch Decoded.

Wo liegt hier der Fehler? Irgendwas mit dem Zeichensatz?
Habe bereits unterschiedliche Bilder probiert 200kb bis 1Mb, Errorreporting E_ALL und Diverse Header.

hier der Code zum speichern der Bilder: (klappt auf beiden Systemen)

$type = 'image/jpeg';
$hndFile = fopen($dirname.'/'.$foto , "r"); 

$data = base64_encode(resize(fread($hndFile, filesize($dirname.'/'.$foto))));

$strQuery = "INSERT INTO images
  (imgdata,imgtype, AccountID) VALUES
  ('$data','$type', '$id')" ;

if (!mysql_query( $strQuery)) {
    die(mysql_error());
} 

Vielen dank schonmal!

[DMW007]

Warum denn überhaupt Base64? Das verursacht Overhead und ist daher imho hier nicht sinnvoll. Base64 ist gut um kleine Grafiken in ein Stylesheet zu packen, da man so die Anzahl an HTTP-Anfragen reduziert. Der Overhead durch Base64 ist hier minimal, wenn er nicht durch den so vermiedenen Overhead der zusätzlichen HTTP-Verbindung ausgeglichen wird.
Ich würde mir an deiner Stelle aber erst mal grundsätzlich die Frage stellen, ob es sinnvoll ist deine Bilder in eine Datenbank zu packen. Hat Vor- und Nachteile. Der Haupt-Vorteil ist, dass sich alle Daten zentral an einer Stelle befinden, sofern es noch weitere Daten gibt wie Texte, Meta-Infos zu den Bildern etc. die ebenfalls in die DB kommen. Effektiv ist das ganze aber rechenintensiver und damit langsamer, da bei jedem Aufruf eines Bildes die Last an den MySQL-Server und an PHP geht. Würdest du die Bilder alternativ statisch auf dem Dateisystem speichern, fällt im idealfall beides weg. Je nachdem was du konkret vor hast.
Wenn du sie tatsächlich in der Datenbank speichern willst, würde ich das binär machen. Beispielcode dazu findest du etwa hier: Bilder in MySQL-Datenbank speichern | Patrick Gotthard

Noch ein paar Worte generell zu den von dir geposteten Codeausschnitten:

$strQuery= "SELECT * 
FROM `images` 
WHERE id=".$_GET['id']; 

Öffnet SQL-Injections Tür und Tor, da über den id-Parameter so ziemlich alles in die Abfrage eingeschleust werden kann. Sollte escaped werden. Oder alternativ einfach als int casten, wenn es sich um einen Integer handelt.

$result=@mysql_query($strQuery); 

Solche Konstrukte sollte man vermeiden, das führt nur zu unerklärbaren Fehlern, an denen man sich nachher dumm und dämlich sucht. Besser gleich Errorhandling einbauen, zu Testzwecken reicht ja ein die(). Dann aber nicht vergessen den Content-Type Header erst im Erfolgsfall unmittelbar vor der Ausgabe zu setzen. Ansonsten geht das Schief, weil ein Bild erwartet wird aber Text ankommt. Produktiv wäre hier die Ausgabe eine entsprechenden Fehlergrafik eine sinnvolle Idee.
Desweiteren sollte mysql nicht mehr benutzt werden da veraltet, stattdessen lieber mysqli verwenden. Und ich würde nicht direkt die mysql(i)-Funktionen verwenden sondern stattdessen eine Datenbankklasse als Wrapper, ist flexibler. Wenn dir das klar ist und das nur ein paar Zeilen zu Testzwecken sind die so nicht produktiv eingesetzt werden sollen, kannst du das natürlich ignorieren.