PNG erzeugen - keine gültige Datei - Fehler?

[Dirk]

Hallo zusammen,

ich erzeuge per php dynamisch ein Bild. Im IE funktioniert es problemlos, Netscape und Irfan View meckern aber, daß es sich nicht um ein gültiges PNG handelt. Hier der Quelltext:

//Sicherheitsabfage
<?php
session_start();
if (...)
{
header('Location: index.html');
exit();
}

//Bilderzeugung
header("Content-type: image/png");
$datei = 'news'.time().'.png';
$bild = ImageCreateFromPNG("g.png");
imageInterlace($bild, 1);
$weiss = imageColorAllocate($bild, 255,255,255);
imagettftext($bild, 10, 0, 10, 20, $weiss, "arialbd.ttf", $news);
imagepng($bild, "/bilder/".$datei);
imagedestroy($bild);
?>

Danach kommt normaler Quelltext einer HTML Seite. Wie gesagt, das Bild wird erzeugt, alles so wie es sein soll, aber bestimmte Programme meckern. Kann es sein, daß ich was vergessen bzw. falsch deklariert habe? Die Seite kommt in einer Reihe von Webformularen, über die ich die Texte eingebe und das sollte eigentlich so bleiben. Bin für jeden Tip dankbar!

Grüße aus Wuppertal,
Dirk

[wahsaga]

hi,

Danach kommt normaler Quelltext einer HTML Seite.

warum gibst du denn dann vorher den header

header("Content-type: image/png");

aus?

ich würde als erstes mal das mit dem interlacing rausnehmen, also

imageInterlace($bild, 1);

auskommentieren.

gruss,
wahsaga

[Thomas Luethi]

Hallo,

header("Content-type: image/png");

Hier sagst Du dem Browser: Nun kommt ein PNG-Bild.

imagepng($bild, "/bilder/".$datei);

Hier schickst Du ihm diese Binaer-Daten fuer das Bild.

Und anschliessen offenbar noch Text-Daten:

Danach kommt normaler Quelltext einer HTML Seite.

Das kann nicht gut gehen.

Das Skript darf pro Aufruf nur

• entweder ein Bild ausliefern
• oder HTML-Text-Ausliefern.

IMHO ist es praktischer, wenn man ein Skript pro Aufgabe hat.
Also ein Skript, das Bilder ausgibt.
Und ein anderes Skript, das HTML-Text ausgibt.

mfg, Thomas

[Thomas Luethi]

Hallo,

imagepng($bild, "/bilder/".$datei);
Hier schickst Du ihm diese Binaer-Daten fuer das Bild.

Oops, sorry, hatte den zweiten Parameter uebersehen.
Damit schreibst Du die Binaerdaten offenbar in eine Datei.

Trotzdem: Der Content-type Header image/png ist natuerlich falsch,
wenn danach text/html ausgeliefert wird.

Gruesse,

Thomas

[Dirk]

Hmmmm,

wie ich das verstehe gilt das für die Seite. Diese würde dann als Bild gehandelt, hätte aber auch html in sich. Aber wo ist denn das Problem mit dem Bild selber, da dieses bevor irgenwas anderes kommt, geschlossen und gespeichert wird. Müßte doch dann folglich nur der Browser Probleme haben, wenn er die Seite anzeigen will?

Mmmh, Deine Lösung mit den 2 Skripten erscheint mir garnicht so schlecht. Allerdings steh ich auf dem Schlauch, weil ich ein Interface programmieren muß, in dem man erst Text eingibt, dann schaut, ob das Bild auch schön ist und erst dann das Bild gespeichert wird. Gibts außer sessions die Möglichkeit, Daten von einer Webseite in die darauffolgende zu transportieren, insbesondere, wenn die Bilder zwischendurch nicht solo angezeigt werden, sondern nur die html Seiten? Hatte das nämlich schonmal einfach an den Browser geschickt, da hat dann aber das html gefehlt und meine Seitenkette hat geändert?

Alternativ würde mir noch ein include des Bilderzeugungsskript in meine Ursprungsseite einfallen, aber ich bin mir nicht sicher, ob ich somit das Problem von 2 Headern umgehen kann.

Gruß, Dirk

[Cheatah]

Hi,

Diese würde dann als Bild gehandelt, hätte aber auch html in sich.

nein, nein, nein. *Jede* Ressource im gesamten Universum des World Wide Web hat *exakt* einen Content-Type - niemals mehr und niemals weniger. Was Du innerhalb eines text/html-Dokumentes tun kannst, ist weitere, von dieser _unabhängige_ Ressourcen einzubinden, etwa ein Bild. Dadurch hat das Bild aber noch immer *keinen* Zusammenhang zu jenem Dokument.

Betrachte Ressourcen also immer, immer, immer separat.

Gibts außer sessions die Möglichkeit, Daten von einer Webseite in die darauffolgende zu transportieren,

Eine Session ist ein Weg, diesen Transport _nicht_ durchzuführen, weil die Daten nämlich serverseitig gespeichert _bleiben_. Transportiert wird lediglich ein Parameter zur Identifizierung der Session. Und damit hast Du auch bereits die Antwort auf Deine Frage: Parameter.

Alternativ würde mir noch ein include des Bilderzeugungsskript in meine Ursprungsseite einfallen,

Das ändert exakt gar nichts. Du hättest weiterhin innerhalb eines serverseitigen Erzeugungsflusses zwei unabhängige Ressourcen verquickt.

aber ich bin mir nicht sicher, ob ich somit das Problem von 2 Headern umgehen kann.

A propos Header:

header('Location: index.html');

Dies ist illegales HTTP. Ein Location-Header *muss* eine *absolute* URL beinhalten.

Cheatah

[Dirk]

Eine Session ist ein Weg, diesen Transport _nicht_ durchzuführen, weil die Daten nämlich serverseitig gespeichert _bleiben_. Transportiert wird lediglich ein Parameter zur Identifizierung der Session. Und damit hast Du auch bereits die Antwort auf Deine Frage: Parameter.

Deine Erklärung ist sehr gut. Vielen Dank. Allerdings stehe ich jetzt wieder auf dem Schlauch, was Du mit Parametern meinst. Ich dachte bis jetzt, Daten kann man zwischen verschiedenen Seiten über Formulare mittels get und post weiterleiten, aber ich hab ja auf einer reinen Skriptseite dann kein HTML mehr oder hab ich das wieder falsch verstanden? Lange Rede, kurzer Sinn, könntest Du mir vielleicht noch kurz sagen, was Du mit Parametern meinst?

A propos Header:

header('Location: index.html');

Dies ist illegales HTTP. Ein Location-Header *muss* eine *absolute* URL beinhalten.

Jo, im Originalskript ist das auch absolut. Habs für das Forum hier rausgenommen, muß ja nicht jeder gleich die Pfadangaben sehen.

Danke im voraus, ich hoffe, ich stelle gerade nicht zu doofe Fragen aber irgendwie hab ich grad Verständnisprobleme

Gruß, Dirk

[Thomas Luethi]

Hallo,

Allerdings stehe ich jetzt wieder auf dem Schlauch, was Du mit Parametern meinst. Ich dachte bis jetzt, Daten kann man zwischen verschiedenen Seiten über Formulare mittels get und post weiterleiten,

Er meint vermutlich die Session-ID.

Diese wird ueblicherweise im Browser als Cookie gespeichert.
Der Browser schickt dann mit jeder Seitenanfrage beim betreffenden
Server auch den Inhalt des Cookies.

Eine andere Moeglichkeit, um die Session-ID (oder beliebige
Parameter) von Seite zu Seite weiterzugeben, ist das Anhaengen
an die URL. Oder, bei Formularen, ein Hidden-Field.
PHP bietet dafuer gewisse Automatismen.
Genaueres siehe Manual, Kapitel Sessions,
Stichwort "session.use_trans_sid".
http://www.php.net/manual/de/ref.session.php

Siehe auch dclp-FAQ, z.B.
http://www.dclp-faq.de/q/q-variable-weitergeben.html
http://www.dclp-faq.de/ch/ch-version4_session.html

header('Location: index.html');
Jo, im Originalskript ist das auch absolut. Habs für das Forum hier rausgenommen, muß ja nicht jeder gleich die Pfadangaben sehen.

Es ist ein beliebter Anfaengerfehler, eine relative URL zu nehmen,
obwohl es sogar ausdruecklich im Manual steht, dass die URL
absolut sein muss. Deshalb die Kritik - hier offenbar unberechtigt.

Du koenntest in einem solchen Fall im Quellcode-Ausschnitt
Deine Domain durch "example.com" ersetzen:
header('Location: http://www.example.com/index.html');
Dann kommt niemand auf die Idee, dass Du eine relative
URL benuetzt...

HTH, mfg
Thomas

[Cheatah]

Hi,

Lange Rede, kurzer Sinn, könntest Du mir vielleicht noch kurz sagen, was Du mit Parametern meinst?

URL- oder POST-Parameter, also z.B. das Ergebnis eines <input>. Dazu gehört (vermutlich) auch, wie Thomas richtig bemerkt, die Session-ID.

header('Location: index.html');
Dies ist illegales HTTP. Ein Location-Header *muss* eine *absolute* URL beinhalten.
Jo, im Originalskript ist das auch absolut. Habs für das Forum hier rausgenommen, muß ja nicht jeder gleich die Pfadangaben sehen.

Verstehe. Kleiner Tipp: Bei z.B. "Location: http://..." hätte ich nichts gesagt, dem sieht man den Beispielcharakter gleich an ;-)

Cheatah