PNG mit Endung .jpg ausgeben

hi

bin dabei ein script zu machen, welches mit GD lib fotos verkleinert, zuschneidet und mit einem rahmen überlagert (dass die ecken abgedrundet sind).
das script überprüft ob ein foto vorhanden ist und gibt dieses dann aus. zusätzlich speichert es das ergebnis ab, um ein weiteres mal nicht nochmal rechnen zu müssen.

jetzt ist es so, dass die bilder alles JPGs sind, wird aber eine falsche ID angegeben, wird ein standbild genommen, welches einfach ein helles blau ist. dieses habe ich vorbereitet als PNG.

die bilder werden aber mittels htaccess aufgerufen, zb "141.jpg". ist das 141 nicht vorhanden, wird das vorgegebene PNG ausgegeben, inklusive dem header image/png.
bei safari und firefox macht das kein problem, das bild wird korrekt angezeigt auch wenn die endung falsch ist.

ich will aber sicher sein, dass auch andere browser damit klar kommen, sprich der internet explorer (habe keinen windows mehr) und verschiedene betriebssysteme.

kurzum:
macht es irgendeinem browser/system probleme, ein PNG (mit image/png header) mit dateiendung .jpg darzustellen?

Konvertiere doch einfach das PNG in JPEG..

Das Browser mit png Schwierigkeiten haben wüßte ich momentan nicht! Der IE hat bei png nur Probleme mit Transparenz ... die kann er in Gegensatz zu FF und Opera nicht. Gibt da zwar son JS-Kit ... aber ist in Deinem Fall nicht nötig!

Gruß php_fussel

die PNGs sind schon normale PNGs, keine PNG24, auch ohne transparenz.
der einzige grund, weswegen es PNGs sind und keine JPG ist die dateigrösse.

dass der internet explorer PNG korrekt anzeigen kann (PNG8 und nicht 24) ist mir klar, ich frage aber spezifisch wie es ist, wenn die dateiendung eine andere ist als erwartet.

Eine Dateiendung sagt nichts über den Inhalt aus, und mir ist kein gängiger Browser bekannt, der den Header ignoriert und Eigenmächtig und anhand der Dateiendung handelt.

Der Sinn hinter deinem Vorgaben erschließt sich mir allerdings nicht. Wenn es sich um PNGs handelt, liefer sie doch auch so aus?!

Wir befinden uns im Umfeld "HTTP", und da gibt es ueberhaupt keine "Dateiendungen" - weil es keine "Dateien" gibt.

Was es gibt, das sind Ressourcen. Und was die enthalten, darueber gibt einzig und allein der Content-Type-Response-Header Auskunft.
Ob der Identifier der Ressource auf ".png" oder ".sfdglsdgh" endet, oder ueberhaupt keine "Punkte" enthaelt, ist auch vollkommen egal.

Original geschrieben von wahsaga oder ".sfdglsdgh" endet

was ist das denn für ne datei? ^^


gut wenn der header also höhere priorität als die endung hat ist gut, dann wird es überall klappen.

also um die frage "warum" noch aufzuklären:

ich binde bilder mit <img src='12.jpg'><img src='13.jpg'> ein. das generieren der tags erfolgt lediglich via ID.
mit einem htaccess script wird die "12.jpg" datei an /img/image.php?id=12 weitergeleitet.

das PHP script überprüft zuerst, ob eine datei 12.jpg bereits existiert (da bereits mit dem rahmen versehen und korrekte grösse) und gibt den jpg header aus und dann die datei.
ansonsten wird überprüft ob 12.png existiert (dann wäre es eine manuell von mir erstellte PNG weil besser für den einsatz, zb weil weniger platz oder keine jpgartefakte).

existiert weder die eine noch die andere datei, wird im "unbearbeitet" ordner nach der datei "12.jpg" (die unbearbeiteten sind immer jpgs) gesucht und diese ins GDlib geöffnet.
(existiert die 12.jpg auch im unbearbeitet nicht, wird einfach eine vorgefertigtes PNG ausgegeben.)

diese geöffnete 12.jpg wird jetzt verkleinert, an den seiten beschnitten dass es eine quadratische grösse ist (130x130px) und eine PNG mit transparenz ins GDlib geladen und diese darüber gelegt. (in dieser PNG sind die abgerundeten ecken weiss, so dass das skalierte foto weisse abgerundete ecken bekommt).

ist die datei fertig, wird sie ins "bearbeitet" verzeichnis mit 12.jpg gespeichert und danach mit jpeg header ausgegeben.

wenn das nächstemal das foto mit der ID 12 aufgerufen wird, kann die vorhin gespeicherte version ausgegeben werden, und GD lib muss nicht jedesmal "on-the-fly" erstellen.

taaadaa

Original geschrieben von fabio
was ist das denn für ne datei? ^^

gut wenn der header also höhere priorität als die endung hat ist gut, dann wird es überall klappen.

Bzgl. beidem: Lies meine Antwort noch mal.

Es gibt ueberhaupt keine "Datei".

ich weiss, das mit dem "was ist das den für ne datei", hätt ich wohl noch n <sarkasmus> tag rummachen sollen

aber ich hab schon verstanden dass header und endung nichts miteinander zu tun haben, die frage war lediglich, ob das auch jeder browser mitbekommen hat, weil hätte sein können, dass der internet explorer probleme hätte machen können
scheint aber doch nicht so, danke

Original geschrieben von fabio
das PHP script überprüft zuerst, ob eine datei 12.jpg bereits existiert (da bereits mit dem rahmen versehen und korrekte grösse) und gibt den jpg header aus und dann die datei.

Das kannst du auch mit mod_rewrite erschlagen.

Original geschrieben von fabio
aber ich hab schon verstanden dass header und endung nichts miteinander zu tun haben, die frage war lediglich, ob das auch jeder browser mitbekommen hat, weil hätte sein können, dass der internet explorer probleme hätte machen können
scheint aber doch nicht so, danke

Da wäre ich mir nicht so sicher, der IE rendert Bilder auch schonmal als HTML, unabhängig vom übermittelten MIME-Typ des Servers.

Internet Explorer führt Code in Bildern aus

wusst ichs doch, dass der IE mindestens einen sonderfall machen muss um für seinen ruf zu sorgen
ich denke aber, wenn der inhalt und header (und somit auch der MIME) stimmt, sollte die endung egal sein.

zumal ich es jetzt einfach mit parallels auf'm mac getestet hab, und dort hat der IE es korrekt dargestellt

Original geschrieben von phpguru42
Da wäre ich mir nicht so sicher, der IE rendert Bilder auch schonmal als HTML, unabhängig vom übermittelten MIME-Typ des Servers.

Internet Explorer führt Code in Bildern aus

Naja, der Artikel sagt eindeutig, dass es nicht "unabhängig" vom übermittelten MIME-Type geschieht, sondern wenn widersprüchliche Angaben vorliegen. Darüberhinaus würde die Kontrolle im konkreten Fall immer noch zu einer korrekten Anzeige des Bildes führen.