(Gelösst) Fehler beim download erzwingen von *.epub dateien

fehler beim download erzwingen von *.epub dateien.

Fehler: Der fehler entsteht erst beim öffnen der heruntergeladenen Dateien

ziel: *.epub Dateien zum download anbieten und dabei das automatische offnen diese verhindern.

(Es handelt sich um ein bplaced Speicherplatz/ Lokal auf meinem apache hatte ich keine probleme)

meine Losungsansätze:
header(“Content-type: application/epub+zip”);
header(‘Content-Disposition: attachment; filename="’.$filename.’"’);
header(“Content-Transfer-Encoding: binary”);
$fp = fopen($filename, ‘rb’);
$data = fread($fp,filesize($filename));
fclose($fp);
print $data;
// filelist() und include ergaben auch fehler

Problem:
Da anscheinend der mime typ epub+zip nicht installiert ist kann ich diesen nicht korrekt übergeben

mit diesen header funktionierte es auch nicht
header(“Content-type: application/force-download”);
header(“Content-type: application/zip”);

andere Lösungswege: download erzwingen für verzeichniss mit .htacces

		<FilesMatch "\.(epub|PDF|zip|RAR)$" >
		ForceType application/octet-stream
		</FilesMatch>

Ergebniss => Dateien würden trotzdem im browser geöffnet

Ausgeschlossene fehler:
php-Datei ist ohne Bom
Dateien sind ok. (bei normalem download mit direktem Link funktionieren die Dateien

Fehlermeldung:
Beim öffnen der heruntergeladenen dateien durch den force download:
"xy.epub
Das Dokument enthält kleine Fehler und wird möglicherweise falsch angezeigt
— errorListChange —"
Danach wird nichts geöffnet.

Andere beobachteten Fehlermeldungen bei anderen download header:
“E/A-Fehler beim Öffnen der lokalen Datei
Ereignisdetails:
Error #2038
— Ende —”

Habe leider noch keine Lösung gefünden für dieses Problem und bin um jede hilfe dankbar
liebe grüsse Dregi

Mime-Types werden nicht “installiert”.
Das ist für den Server an der Stelle eine reine Zeichenkette, die er im HTTP-Header an den Client übergibt, mehr nicht.

Wo hast du denn den Wert “application/epub+zip” her? Wo steht geschrieben, dass dieser für "epub’-Dateien verwendet werden sollte? Und was sind das eigentlich für Dateien, mit welcher Anwendung werden sie geöffnet …?

[quote]Beim öffnen der heruntergeladenen dateien durch den force download:
“xy.epub
Das Dokument enthält kleine Fehler und wird möglicherweise falsch angezeigt
— errorListChange —”[/quote]
Und was hat dein Vergleich einer solchen Datei mit einem “Original” ergeben?
Bspw. mal in einem Hex-Editor anschauen, und schauen, wo die Unterschiede liegen.

Wie sieht es aus, wenn du bzgl. Mime-Type-Angabe etc. überhaupt nichts unternimmst, solch eine Datei stinknormal mit einem verlinkst, und dann über Rechtsklick -> “Ziel speichern unter …” abspeicherst - lässt sie sich dann anschliessend öffnen?

hi chrisb,

“epub+zip” ist der offizielle mime-Typ.
Ist eine Adobe Format endlich wie pdf (mit dem vorteil das sie Dateien kleiner und skalierbar sind). Epub ist ein gezipter Container mit xml,…
Der epubreader findest du hier: adobe.com/products/digitaleditions/

[quote]
stinknormal mit einem verlinkst, und dann über Rechtsklick -> “Ziel speichern unter …” abspeicherst - lässt sie sich dann anschliessend öffnen?[/quote]
Dann geht es, wie gesagt:[quote]
Dateien sind ok. (bei normalem download mit direktem Link funktionieren die Dateien[/quote]
Auch beim lokalen testen auf meinem windows-Apache-server gab es keine Probleme.

Werde das ganze mit dem Hex-Editor noch probieren sobald ich an meinem Computer bin.
hier geht es nicht:

<?php

$file = "datei.epub";

header('Content-Type application/octet-stream');
header('Content-Disposition: attachment; filename="datei.epub"');
header('Content-Lenght: '.filesize($file));

readfile($file);

Wird zwar verschiedentlich behauptet, daß das der
’content-type’ für das Format sei, bei IANA habe ich das aber
nicht gefunden. Die Spezifikation gibt soweit ich das gesehen
habe einen anderen (experimentellen) an, mag also sein, daß
die Anmeldung bei IANA noch nicht abgeschlossen ist, da muß
das Format auf dem server auch noch nicht bekannt sein.
Man sollte das aber per .htaccess setzen können.

Wenn dann der browser eine Zuordnung zu einem Programm
hat, kann er das auch damit automatisch öffnen.

Bei application/octet-stream sollte der browser das schon aus
Sicherheitsgründen nicht automatisch ausführen, mag aber sein,
daß man den browser anders konfigurieren kann.

Verwendet man sowas wie application/x-download sollte das
auf jeden Fall nicht ausgeführt werden, weil der browser dies
frei erfundene experimentelle Format wohl nicht kennen kann.

Dank dem hex-editor bin ich nun weiter gekommen:

Der Fehler liegt nicht am Anfang oder an der Datei sonder das letzte Zeichen verursacht den Fehler.

Hex Code 20 (SP) => ist das Leerzeichen (engl. space oder blank),
Lösche ich nun dieses Zeichen funktionieren die Dateien.
nicht wegen dem Zeichen sondern wegen der länge

Meiner Meinung nach ist das Programm auch ein bisschen sehr empfindlich :slight_smile:

so würde es funktionieren :slight_smile:
$fp = fopen($filename, ‘rb’);
$data = fread($fp,filesize($filename)-1);
fclose($fp);
print $data; //readfile() oder echo änderten nichts

Die Dateien lassen sich mit obigem Beispiel öffnen und man sieht auch kein unterschied (ausser im Hex-Editor sieht man ein 20 statt ein 00)

Wie kommt jedoch dieses Leerzeichen zustande? Und wie kann man verhindern das es gesendet wird???

Also wenn du explizit von dem Dateiinhalt, den du einliest, ein Zeichen abschneiden musst - dann würde ich ja erst mal vermuten, dass die Datei an sich schon korrupt ist. Denn PHP selber mogelt bei Nutzung der Dateisystem-Funktionen eigentlich nichts hinzu, was nicht schon da ist.

Andere Vermutung wäre sonst noch gewesen, dass sich das Leerzeichen am Ende deines PHP-Scriptes befindet - hinter dem abschliessenden “?>”. Aber das kann’s eigentlich nicht sein, wenn dein jetziger Workaround das Problem “löst”.

doch genau dort war der Fehler !haue
Hab es auch gemerkt nach dem ich das Exit gesetzt hatte!!

<?php header('HTTP/1.1 200 OK'); if($_GET['datei']){ $filename=$_GET['datei']; if (mb_detect_encoding($filename, "auto")=="UTF-8"){ $filename=iconv("UTF-8", 'ISO-8859-1', $filename); } if(file_exists($filename)){ header("Content-type: application/epub+zip"); header('Content-Disposition: attachment; filename="'.$filename.'"'); $fp = fopen($filename, 'rb'); $data = fread($fp,filesize($filename)); fclose($fp); print($data);[color=#FF0000]exit();[/color] } else{ } } else{ echo 'Fehler

FEHLER!


Kein Dateiname angegeben

'; } ?>

Fielen dank führ eure hilfe.
Liebe Grüsse Dregi

[quote=“dregi”]doch genau dort war der Fehler
Hab es auch gemerkt nach dem ich das Exit gesetzt hatte!![/quote]
Du kannst das ?> am Dateiende auch ganz weg lassen, PHP merkt automatisch, dass da Schluss ist.

Das wird in den Coding-Richtlinien von manchen Frameworks, wie bspw. dem von ZEND, sogar explizit gefordert - eben damit sich solche Fehler nicht einschleichen können. (Bspw. auch relevant bei include-Files, nach denen noch header-Aufrufe stattfinden können sollen.)

nimm bitte readfile

wenn du das mit variablen erledigst wird die gesamte Datei in den RAM geladen und dann erst an den User gesendet. Das mögen die Server wirklich nicht gern :wink:

Du kannst auch einfach mein Skript nehmen :slight_smile: