HTM/HTML zum Download anbieten

[W. Wolf]

Hallo,

ich möchte eine html-Datei zum Download anbieten.
Wenn ich diese direkt verlinke, dann wird die Datei
im Browser dargestellt. Gibt es irgend eine Möglichkeit
per Link oder Script die Download-Funktion des Browsers
zu starten, so dass die html-Datei lokal gespeichert werden
kann, z.B. wie eine verlinkte Zip-Datei?
(Datei / Speichern unter ist zu umständlich für den Anwender)

Ich habe ein bißchen mit unterschiedlichen MIME-Typen
experimentiert. Mache würden ja Ihren Dienst erfüllen, wie
zum Beispiel:
<a href="my.html" type="multipart/form-data">Download</a>
oder
<a href="my.html" type="multipart/alternative">Download</a>

Die Frage ist, ob das auch der richtige Weg ist und ob es
dafür nicht eine viel bessere Alternative gibt?

Schönen Gruß
W. Wolf

[Christoph Schneegans]

"W. Wolf" schrieb:

> Wenn ich diese direkt verlinke, dann wird die Datei im Browser
> dargestellt. Gibt es irgend eine Möglichkeit per Link oder Script
> die Download-Funktion des Browsers zu starten, so dass die html-
> Datei lokal gespeichert werden kann, z.B. wie eine verlinkte Zip-
> Datei?

Sorg dafür, daß dein Webserver folgenden HTTP-Header mitschickt:

Content-Disposition: attachment; filename=example.html

Wie man das anstellt, hängt vom Webserver ab; bei Apache ist es
üblicherweise trivial, bei älteren IIS-Versionen für Nicht-
Administratoren praktisch unmöglich.

Wird deine HTML-Seite von einem Server-seitigen Skript generiert
(PHP, ASP.NET o.ä.), ist das Setzen eines HTTP-Headers wiederum
trivial.

> Ich habe ein bißchen mit unterschiedlichen MIME-Typen
> experimentiert.

Dieser Ansatz ist unsauber.

--
<http://schneegans.de/sv/> · Schema-Validator für XML

[W. Wolf]

"Christoph Schneegans" <Chri...@Schneegans.de> schrieb

>
> Sorg dafür, daß dein Webserver folgenden HTTP-Header mitschickt:
> Content-Disposition: attachment; filename=example.html
> Wie man das anstellt, hängt vom Webserver ab; bei Apache ist es
> üblicherweise trivial, bei älteren IIS-Versionen für Nicht-
> Administratoren praktisch unmöglich.
>
> Wird deine HTML-Seite von einem Server-seitigen Skript generiert
> (PHP, ASP.NET o.ä.), ist das Setzen eines HTTP-Headers wiederum
> trivial.

Also müsste ich mir so was wie ein zentrales download.php basteln
und dieses dann per Link
<a href="download.php?my.html">Download</a>
aufrufen? Ist ja einfach, jetzt muss ich nur noch ein bißchen php lernen...
:-(
Da wird sich schon was finden. Danke für den Tipp!

>> Ich habe ein bißchen mit unterschiedlichen MIME-Typen
>> experimentiert.
>
> Dieser Ansatz ist unsauber.
>

Das habe ich bereits vermutet. Mangels Alternativen habe ich
das halt so versucht.

Schönen Gruß
W. Wolf

[Christoph Schneegans]

"W. Wolf" schrieb:

> Also müsste ich mir so was wie ein zentrales download.php basteln

> (...)?

Mach es lieber über den Webserver, wenn es irgendwie geht. Frag ggf.
deinen Webspace-Provider, welche Server-Software in welcher Version
mit welchen Konfigurationsmöglichkeiten zur Verfügung steht.

> Ist ja einfach, jetzt muss ich nur noch ein bißchen php lernen...

Es ist durchaus nicht einfach, dabei alles richtig zu machen. Ein
Webserver unterstützt etwa die Request-Header 'Accept', 'Range' und
'If-Modified-Since' – kann dein PHP-Skript das auch?

--
<http://schneegans.de/web/kanonische-adressen/> · Gute URLs

[W. Wolf]

Am 08.01.2012 15:37, schrieb Christoph Schneegans:

>
> Mach es lieber über den Webserver, wenn es irgendwie geht. Frag ggf.
> deinen Webspace-Provider, welche Server-Software in welcher Version
> mit welchen Konfigurationsmöglichkeiten zur Verfügung steht.
>
>> Ist ja einfach, jetzt muss ich nur noch ein bißchen php lernen...
>
> Es ist durchaus nicht einfach, dabei alles richtig zu machen. Ein
> Webserver unterstützt etwa die Request-Header 'Accept', 'Range' und
> 'If-Modified-Since' – kann dein PHP-Skript das auch?
>

Das sind alles Fremdwörter für mich. Ich habe ein bisschen nach PHP und
Download gesucht und da finden sich schon einige freie und kommerzielle
"Download-Manager" die genau das machen was ich auch benötige. Jetzt
muss ich "nur noch" das für mich geeignete Script identifizieren.
Z.B. das hier: http://www.php-free.de/Datei-Management/Datei-Download/
Die Beschreibung von LATEdownload würde meinen Bedarf wunderbar decken,
leider ist gerade dieser Link tot.

Am Webserver kann und will ich gar nicht so viel ändern um mir die
Unabhängigkeit vom Provider möglichst zu erhalten. Sehe ich das so falsch?

Schönen Gruß
W. Wolf

[Thomas 'PointedEars' Lahn]

W. Wolf wrote:
^^
Bitte trag an dieser Stelle Deinen Vornamen ein.

> Am 08.01.2012 15:37, schrieb Christoph Schneegans:
>> Mach es lieber über den Webserver, wenn es irgendwie geht. Frag ggf.
>> deinen Webspace-Provider, welche Server-Software in welcher Version
>> mit welchen Konfigurationsmöglichkeiten zur Verfügung steht.
>>
>>> Ist ja einfach, jetzt muss ich nur noch ein bißchen php lernen...
>>
>> Es ist durchaus nicht einfach, dabei alles richtig zu machen. Ein
>> Webserver unterstützt etwa die Request-Header 'Accept', 'Range' und
>> 'If-Modified-Since' – kann dein PHP-Skript das auch?
>
> Das sind alles Fremdwörter für mich.

Google ist Dein Freund. [psf 6.1]

> Ich habe ein bisschen nach PHP und Download gesucht und da finden sich
> schon einige freie und kommerzielle "Download-Manager" die genau das
> machen was ich auch benötige. Jetzt muss ich "nur noch" das für mich
> geeignete Script identifizieren.
> Z.B. das hier: http://www.php-free.de/Datei-Management/Datei-Download/
> Die Beschreibung von LATEdownload würde meinen Bedarf wunderbar decken,
> leider ist gerade dieser Link tot.
>
> Am Webserver kann und will ich gar nicht so viel ändern um mir die
> Unabhängigkeit vom Provider möglichst zu erhalten. Sehe ich das so falsch?

Ja. Statt in eine Abhängigkeit zum Provider willst Du Dich anscheinend in
eine Abhängigkeit zu einem Script(-Autor) begeben. Das muss böse enden.


PointedEars
--
Nein. Bei zwei nebeneinander angeordneten Bildschirmen ist der rechte
Rand des linken Bildschirms die Mitte des Desktops. Der rechte Rand des
Desktops ist der rechte Rand des rechten Bildschirms, und da geht es
nicht mehr weiter. (Lars Trebing in darw <3E1C9AC9...@ltrebing.de>)

[Hannes Kuhnert]

W. Wolf schrieb:

> Also m�sste ich mir so was wie ein zentrales download.php basteln

> und dieses dann per Link
> <a href="download.php?my.html">Download</a>
> aufrufen?

Sowas ist für Nutzer, die gerne Drag’n’Drop nutzen, gar nicht schön.

Wenn ich eine Datei aus dem Web lokal speichern möchte, klicke ich bevorzugt
mit der linken Maustaste auf die Datei und ziehe sie in das Verzeichnis, wo
ich sie haben möchte.

Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine Datei
namens „download.php“ an. Das ist hässlich, besonders, wenn das System
lokale Dateien (nur) anhand der Endung identifiziert oder man mehrere
Dateien einer Reihe herunterladen möchte.
--
Hannes Kuhnert, Chemnitz

[W. Wolf]

Am 10.01.2012 10:59, schrieb Hannes Kuhnert:
> W. Wolf schrieb:
>
[...]

>
> Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine Datei
> namens „download.php“ an. Das ist hässlich, besonders, wenn das System
> lokale Dateien (nur) anhand der Endung identifiziert oder man mehrere
> Dateien einer Reihe herunterladen möchte.

Machst Du das wirklich so? Auch dann, wenn irgendwo ein Link mit der
Beschriftung "Download" steht?

Wenn ich einen Link auf eine downloadbare Datei sehe, klicke ich rechts
und wähle "Speichern unter" - was natürlich auch nicht funktioniert,
wenn sich irgend ein Script hinter dem Link verbirgt.

<a href="download.php?my.pdf">my.pdf</a

Mich ärgert es, wenn sich in der Linkbeschriftung der Dateiname befindet
und so der Eindruck entsteht dass die Datei direkt verlinkt ist.

So wie ich das machen will, also
<a href="download.php?my.pdf">Download</a>
sollte die Versuchung nach D&D oder Rechtsklick eher gering sein, oder?

Schönen Gruß
W. Wolf

[Peter J. Holzer]

On 2012-01-10 09:59, Hannes Kuhnert <hannes....@gmx.de> wrote:
> W. Wolf schrieb:
>> Also m�sste ich mir so was wie ein zentrales download.php basteln
>> und dieses dann per Link
>> <a href="download.php?my.html">Download</a>
>> aufrufen?
>
> Sowas ist für Nutzer, die gerne Drag’n’Drop nutzen, gar nicht schön.
>
> Wenn ich eine Datei aus dem Web lokal speichern möchte, klicke ich
> bevorzugt mit der linken Maustaste auf die Datei und ziehe sie in das
> Verzeichnis, wo ich sie haben möchte.
>
> Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine
> Datei namens „download.php“ an. Das ist hässlich, besonders, wenn das
> System lokale Dateien (nur) anhand der Endung identifiziert

Ich dachte, Browser hätten mittlerweile gelernt, auf solchen Systemen
eine lokal aussagekräftige Endung anzuhängen? Dass der Dateityp nicht
aus den Teilen des URLs zu erraten ist, sondern im Content-Type steht,
sollte sich inzwischen herumgesprochen haben.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Peter J. Holzer]

On 2012-01-10 14:12, W. Wolf <w.w...@dommel.de> wrote:
> Wenn ich einen Link auf eine downloadbare Datei sehe, klicke ich rechts
> und wähle "Speichern unter" - was natürlich auch nicht funktioniert,
> wenn sich irgend ein Script hinter dem Link verbirgt.

Keine Ahnung, warum das nicht funktionieren sollte - der Client kann das
gar nicht feststellen.

><a href="download.php?my.pdf">my.pdf</a
>
> Mich ärgert es, wenn sich in der Linkbeschriftung der Dateiname befindet
> und so der Eindruck entsteht dass die Datei direkt verlinkt ist.

Ist sie doch. (Du hast vom Webbrowser aus niemals Zugriff auf "die
Datei", der Browser muss immer den Server bitten, den Inhalt der Datei
zu liefern. Und ob der Server-Code, der die Datei liest und an den
Browser schickt, in C oder PHP geschrieben ist, ist für den Client
bedeutungslos (er kann es auch gar nicht feststellen).

[W. Wolf]

Am 10.01.2012 15:48, schrieb Peter J. Holzer:

[...]

> Ist sie doch. (Du hast vom Webbrowser aus niemals Zugriff auf "die
> Datei", der Browser muss immer den Server bitten, den Inhalt der Datei
> zu liefern. Und ob der Server-Code, der die Datei liest und an den
> Browser schickt, in C oder PHP geschrieben ist, ist für den Client
> bedeutungslos (er kann es auch gar nicht feststellen).
>

Also ich sehe da schon einen Unterschied.
Wenn ich auf der Seite zwei Links habe:

<a href="download.php?my.pdf">my.pdf</a>

und
<a href="my.pdf">my.pdf</a>
ich nun rechts auf den ersten Link klicke und "Ziel speichern unter..."
im Kontextmenü wähle, passiert es schon, dass statt dem gewünschten PDF
sonst was auf der Platte landet. Ich glaube darauf bezieht sich auch
Hannes beim D&D. Ich denke aber, dass das nur mit der Link-Beschriftung
zu tun hat. Ein Link in der Form
<a href="download.php?my.pdf">Download</a> sollte weniger
missverständlich wirken - hoffe ich.

Schönen Gruß
W. Wolf

[Hannes Kuhnert]

W. Wolf schrieb:

> Am 10.01.2012 10:59, schrieb Hannes Kuhnert:
>> W. Wolf schrieb:
>>
> [...]
>>
>> Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine
>> Datei namens „download.php“ an. Das ist hässlich, besonders, wenn das
>> System lokale Dateien (nur) anhand der Endung identifiziert oder man
>> mehrere Dateien einer Reihe herunterladen möchte.
>
> Machst Du das wirklich so? Auch dann, wenn irgendwo ein Link mit der
> Beschriftung "Download" steht?

Ja, allermeistens.

„Speichern unter“-Dialoge sind mir lästig – viel zu viel rumgeklicke.

Wenn ich irgend etwas aus dem Web speichern will, habe ich häufig
einen sachlich dazugehörenden Arbeitsordner in einer Verzeichnisansicht
geöffnet oder öffne ihn oder lege mir einen an und lasse ihn dann für
weitere Aktionen offen. Gelegentlich benutze ich auch die Arbeitsfläche als
Kurzzeit-Zwischenlager.

Es kommt jedenfalls nur sehr selten vor, dass ich während einer Sitzung als
einzige Aktion in einem Verzeichnis eine einzige Datei dort hinein
herunterladen möchte. Und das wäre der einzige Fall, in dem die Benutzung
des „Speichern unter“-Dialogs die aufwandssparsamste Nutzungsvariante wäre.


Generell finde ich die Beschriftung „Download“ übrigens zu technisch gedacht
und unlogisch. Es ist doch an sich meine Sache als Nutzer, ob ich lokal
speichern oder direkt öffnen möchte.

> Wenn ich einen Link auf eine downloadbare Datei sehe, klicke ich rechts
> und wähle "Speichern unter" - was natürlich auch nicht funktioniert,
> wenn sich irgend ein Script hinter dem Link verbirgt.
>
> <a href="download.php?my.pdf">my.pdf</a

Wenn mit „Script“ ein Javascript-Link gemeint wäre, hättest du recht.

Für den Fall mit Skript auf dem Server, wie im Beispiel formuliert, siehe
Peters Antwort.

> Mich ärgert es, wenn sich in der Linkbeschriftung der Dateiname befindet
> und so der Eindruck entsteht dass die Datei direkt verlinkt ist.

Missverstehen wir uns? Für günstigstes Drag’n’Drop braucht man den
aussagekräftigen Dateinamen nicht etwa in der Linkbeschriftung, sondern im
URL – und zwar direkt, statt als Parameter hinter dem Fragezeichen …

… also nicht
<a href="download.php?my.pdf">Download</a>,
sondern besser
<a href="my.pdf">Download</a>.

Das wiederum schließt die von dir angedachte technische Lösung aus, was die
Kernaussage meines ersten Beitrags war.

> So wie ich das machen will, also
> <a href="download.php?my.pdf">Download</a>
> sollte die Versuchung nach D&D oder Rechtsklick eher gering sein, oder?

Bei mir nicht. ;-)
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

Peter J. Holzer schrieb:

> On 2012-01-10 09:59, Hannes Kuhnert <hannes....@gmx.de> wrote:
>> W. Wolf schrieb:
>>> Also m�sste ich mir so was wie ein zentrales download.php basteln
>>> und dieses dann per Link
>>> <a href="download.php?my.html">Download</a>
>>> aufrufen?
>>

>> Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine
>> Datei namens „download.php“ an. Das ist hässlich, besonders, wenn das
>> System lokale Dateien (nur) anhand der Endung identifiziert
>
> Ich dachte, Browser hätten mittlerweile gelernt, auf solchen Systemen
> eine lokal aussagekräftige Endung anzuhängen?

Mal abgesehen davon, dass die Speicherung, soweit ich sehen kann, nicht der
Browser durchführt – gibt es das tatsächlich irgendwo? Ich habe noch nirdend
gesehen, dass der in der HTTP-Übertragung gegebene Content-Type beim
Speichern irgendwie ausgewertet werden würde.

Wenn man aus dem Content-Type eine Dateinamensendung ableiten wollte, müsste
übrigens rückwärts gearbeitet werden – es müsste bei den einzelnen Dateityp-
Definitionen unter den oft mehreren Endungen eine geben, die als „die
richtige“ gilt.

Wenn es nach mir ginge, würde der Content-Type als spezielles Attribut im
Dateisystem gespeichert werden (können), siehe nebenan ab
<news:56c8t8-...@zuhause.froschmaschine.net>.

Die Sache mit der Endung bzw. dem Typ ist übrigens nur die Hälfte des
Problems. Ebenfalls unsinnig ist, dass der Name erstmal inhaltsunabhängig
„download[…]“ (oder sonst irgendwie) lautet.
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

W. Wolf schrieb:

> Also ich sehe da schon einen Unterschied.
> Wenn ich auf der Seite zwei Links habe:
> <a href="download.php?my.pdf">my.pdf</a>
> und
> <a href="my.pdf">my.pdf</a>
> ich nun rechts auf den ersten Link klicke und "Ziel speichern unter..."
> im Kontextmenü wähle, passiert es schon, dass statt dem gewünschten PDF
> sonst was auf der Platte landet. Ich glaube darauf bezieht sich auch
> Hannes beim D&D.

Nein, das war nicht gemeint.

Das Problem, das du beschreibst, kommt von einem falsch gemachten PHP-Skript
her – man kann es aber auch richtig machen, was allerdings noch nicht „mein“
Problem mit der Dateibenennung löst.

> Ich denke aber, dass das nur mit der Link-Beschriftung
> zu tun hat.

Dass die Link-Beschriftung irgendwo relevant wäre, ist mir nicht geläufig.
--
Hannes Kuhnert, Chemnitz

[W. Wolf]

Am 10.01.2012 18:06, schrieb Hannes Kuhnert:
> W. Wolf schrieb:
>
[...]
>
>

> Generell finde ich die Beschriftung „Download“ übrigens zu technisch gedacht
> und unlogisch. Es ist doch an sich meine Sache als Nutzer, ob ich lokal
> speichern oder direkt öffnen möchte.
>

Ich stimme dir grundsätzlich zu. Hier, siehe Anfangs-Thread, geht es
aber eindeutig um einen Download. Dem User wird die Möglichkeit gegeben
eine bestimmte Datei explizit und unmissverständlich herunterzuladen mit
dem Ziel diese Datei lokal zu speichern. Und da es sich dabei um eine
HTML-Datei handelt, ist das nicht so einfach. Momentan löse ich das
(unsauber) wie folgt:
<a href="my.html" target="_blank">Anzeigen</a><br />

<a href="my.html" type="multipart/alternative">Download</a>

was aber, eventuell irgendwann mit irgendeinen Browser Ärger machen
könnte. Die Variante Script scheint mir daher die bessere zu sein, sprich:
<a href="my.html" target="_blank">Anzeigen</a><br />

<a href="download.php?my.html">Download</a>

Wie könnte ich nun sinnvoller Weise Dir, also einem D&D User, eine
eindeutige und unmissverständliche Download-Lösung anbieten mit der auch
99% aller anderen User bestens zurecht kommen?

Schönen Gruß
W. Wolf

[W. Wolf]

Am 10.01.2012 18:10, schrieb Hannes Kuhnert:
> W. Wolf schrieb:
>
[...]
>

> Dass die Link-Beschriftung irgendwo relevant wäre, ist mir nicht geläufig.

Die Linkbeschriftung, also das was zwischen <a> und </a> steht ist nicht
relevant? Wenn an einer Stelle "Anzeigen" steht und an der anderen
Stelle "Download" steht, dann mag das technisch keine Bedeutung haben.
Der Anwender wird allerdings schon wissen, was der Entwickler mit diesen
zwei Links bezweckt.

Schönen Gruß
W. Wolf

[W. Wolf]

Am 10.01.2012 17:47, schrieb Hannes Kuhnert:

>
> Mal abgesehen davon, dass die Speicherung, soweit ich sehen kann, nicht der
> Browser durchführt – gibt es das tatsächlich irgendwo? Ich habe noch nirdend
> gesehen, dass der in der HTTP-Übertragung gegebene Content-Type beim
> Speichern irgendwie ausgewertet werden würde.
>

Das ist eben das Problem bei Content-Type. Der eine Beowser, z.B.
Firefox (hier 8.0) startet beim Klick auf

<a href="my.html" type="multipart/alternative">Download</a>

den Download. Der IE macht das nicht. Unter anderem auch deshalb
schreibe ich im Anfabgsthread dass das keine gute Lösung ist und ich
nach einer anderen Lösung suche.
Ich fürchte, ich drücke mich sehr, sehr unverständlich aus.

>
> Die Sache mit der Endung bzw. dem Typ ist übrigens nur die Hälfte des
> Problems. Ebenfalls unsinnig ist, dass der Name erstmal inhaltsunabhängig
> „download[…]“ (oder sonst irgendwie) lautet.

???
Willst mich wohl auf den Arm nehmen?

Schönen Gruß
W. Wolf

[Hannes Kuhnert]

W. Wolf schrieb:

> Am 10.01.2012 17:47, schrieb Hannes Kuhnert:
>
>> Mal abgesehen davon, dass die Speicherung, soweit ich sehen kann, nicht
>> der Browser durchführt – gibt es das tatsächlich irgendwo? Ich habe noch
>> nirdend gesehen, dass der in der HTTP-Übertragung gegebene Content-Type
>> beim Speichern irgendwie ausgewertet werden würde.
>
> Das ist eben das Problem bei Content-Type. Der eine Beowser, z.B.
> Firefox (hier 8.0) startet beim Klick auf
> <a href="my.html" type="multipart/alternative">Download</a>
> den Download. Der IE macht das nicht. Unter anderem auch deshalb
> schreibe ich im Anfabgsthread dass das keine gute Lösung ist und ich
> nach einer anderen Lösung suche.

Mir ging es um das Speichern bei angegebenem tatsächlichem Inhaltstyp, also
bspw. „image/jpeg“. Peter J. Holzer hatte vom Anhängen einer
Dateinamensendung bzw. Ändern derselben beim lokalen Speichern geschrieben,
was offensichtlich sinnvollerweise auf dem angegebenen Content-Type basieren
sollte, und ich stellte fest, dass ich noch nie gesehen hätte, dass der
Content-Type /beim Speichern ausgewertet/ werden würde.

Der Gedanke, dass ein bestimmter Content-Type evtl. /zum Speichern führen/
kann, bleibt davon unberührt. Dein Ansatz mit „multipart/alternative“ u. ä.
MIME-Types scheint mir übrigens eine … hm … ungewöhnlich kreative Verwendung
derselben darzustellen – <http://de.wikipedia.org/wiki/MIME#multipart>.

> Ich fürchte, ich drücke mich sehr, sehr unverständlich aus.

Dann hätten wir ja schon mal etwas gemeinsam. ;-) (auch wenn es keine gute
Basis für Kommunikation wäre).

>> Die Sache mit der Endung bzw. dem Typ ist übrigens nur die Hälfte des
>> Problems. Ebenfalls unsinnig ist, dass der Name erstmal inhaltsunabhängig
>> „download[…]“ (oder sonst irgendwie) lautet.
>
> ???
> Willst mich wohl auf den Arm nehmen?

Nein, es geht mir wie schon in meinem ersten Beitrag
<news:rpett8-...@zuhause.froschmaschine.net>
um den Namen der erhaltenen, dann lokalen Datei – der lautet dann
typischerweise nicht etwa „my(.html)“, sondern „download(.php)“, was
offensichtlich wenig Sinn hat.
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

W. Wolf schrieb:

Ich hänge sehr an meinem ganz oben zitierten Grundsatz.

Wenn es mehrere Links für ein und dasselbe gibt, dann fahre ich mit der Maus
über die Links und schaue dabei auf die Statusleiste und benutze dann den
direktesten Link, den es gibt. In deinem Beispiel würde ich persönlich also
zum Herunterladen den „Anzeigen“ Link in mein Arbeitsverzeichnis ziehen.

/Die/ Lösung für alle liegt aus meiner Sicht in einem einfachen, direkten
Angebot der Website – ein
<a href="my.html">Was auch immer</a>
reicht aus meiner Sicht völlig aus.

Zum Anschauen in einem neuen Fenster drücke ich die mittlere Maustaste, zum
lokalen Speichern ziehe ich den Link dorthin, wo ich die Datei haben möchte.

Wenn auf Layer 8 über diese oder verwandte Möglichkeiten keine Klarheit
herrscht, dann wird Layer 8 ohnehin keinen Grund haben, eine HTML-Datei
herunterzuladen.


Letzten Endes ist

<a href="my.html">Beispiel No. 4</a>

und Nutzung von Kontextmenü oder Drag’n’Drop unterm Strich nicht nur
flexibler und funktionssicherer, sogar es ist sogar für den Nutzer weniger
komplex und einleuchtender als ein alternativ nötiges

<p>Beispiel No. 4</p>

<a href="my.html" target="_blank">Anzeigen</a><br />

<a href="my.html" type="multipart/alternative">Download</a>,

finde ich.

Nur der einfache Direktlink nutzt die Chancen des eleganten, integriert
gedachten Hyperlink-Konzepts.
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

W. Wolf schrieb:

> Am 10.01.2012 18:10, schrieb Hannes Kuhnert:
>> W. Wolf schrieb:
>>
> [...]
>>
>> Dass die Link-Beschriftung irgendwo relevant wäre, ist mir nicht
>> geläufig.
>
> Die Linkbeschriftung, also das was zwischen <a> und </a> steht ist nicht
> relevant?

Doch, im Allgemeinen ist es natürlich relevant.

Beachte bitte den Kontext meiner Aussage – es ging mir um die Benennung der
lokalen Datei beim Herunterladen. Dafür ist der Text des Links
bedeutungslos.
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

Hannes Kuhnert schrieb:

> Der Gedanke, dass ein bestimmter Content-Type evtl. /zum Speichern führen/
> kann, bleibt davon unberührt. Dein Ansatz mit „multipart/alternative“
> u. ä. MIME-Types scheint mir übrigens eine … hm … ungewöhnlich kreative
> Verwendung derselben darzustellen –
> <http://de.wikipedia.org/wiki/MIME#multipart>.

Nicht falsch verstehen – von meiner Seite gibt’s da keinen Aufwärmbedarf.
Ich sah nur jetzt erst, dass die MIME-Type-Sache eigentlich schon geklärt
ist.
--
Hannes Kuhnert, Chemnitz

[Stefan Froehlich]

On Wed, 11 Jan 2012 14:03:25 Hannes Kuhnert wrote:
> Peter J. Holzer hatte vom Anhängen einer Dateinamensendung bzw. Ändern
> derselben beim lokalen Speichern geschrieben, was offensichtlich
> sinnvollerweise auf dem angegebenen Content-Type basieren sollte, und ich
> stellte fest, dass ich noch nie gesehen hätte, dass der Content-Type
> /beim Speichern ausgewertet/ werden würde.

Wirklich nicht?

Download-Links in meinen Applikationen werden ueblicherweise als
<a href="http://host.example/path/program?parameter">Description</a>
geschrieben, also ohne jede Dateinamensendung (was haette die an dieser
Stelle auch verloren?).

Dateiname und Mime-Type werden ueber (z.B.):

| Content-Disposition: attachment; filename="archive.zip"
| Content-Type: application/zip

festgelegt. Was der Browser dann damit anfaengt, ist seine Sache. Meiner
fraegt mich, ob er die Datei mit seiner Lieblingsapplikation oeffnen, oder
irgendwo abspeichern soll. Drag-and-drop funktioniert hier mangels
Filenamager nicht, aber ich wuesste nicht, weshalb das nicht ebenso
funktionieren sollte.

> Nein, es geht mir wie schon in meinem ersten Beitrag
> <news:rpett8-...@zuhause.froschmaschine.net> um den Namen der
> erhaltenen, dann lokalen Datei – der lautet dann typischerweise nicht
> etwa „my(.html)“, sondern „download(.php)“, was offensichtlich wenig Sinn
> hat.

In der Tat, das muss aber keineswegs so sein.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Nur sehnen ist griffiger als flennen! Stefan: Für den anspruchsvollen Herren!
(Sloganizer)

[W. Wolf]

Am 11.01.2012 14:31, schrieb Hannes Kuhnert:
> W. Wolf schrieb:

>

> /Die/ Lösung für alle liegt aus meiner Sicht in einem einfachen, direkten
> Angebot der Website – ein
> <a href="my.html">Was auch immer</a>
> reicht aus meiner Sicht völlig aus.
>
> Zum Anschauen in einem neuen Fenster drücke ich die mittlere Maustaste, zum
> lokalen Speichern ziehe ich den Link dorthin, wo ich die Datei haben möchte.

Damit landet auf deinem Desktop ein Link (eine Verknüpfung) und nicht
die HTML-Datei. Also so kommen wir nicht weiter.

Schönen Gruß
W. Wolf

[Hannes Kuhnert]

W. Wolf schrieb:

> Am 11.01.2012 14:31, schrieb Hannes Kuhnert:
>
>> /Die/ Lösung für alle liegt aus meiner Sicht in einem einfachen, direkten
>> Angebot der Website – ein
>> <a href="my.html">Was auch immer</a>
>> reicht aus meiner Sicht völlig aus.
>>
>> Zum Anschauen in einem neuen Fenster drücke ich die mittlere Maustaste,
>> zum lokalen Speichern ziehe ich den Link dorthin, wo ich die Datei haben
>> möchte.
>
> Damit landet auf deinem Desktop ein Link (eine Verknüpfung) und nicht
> die HTML-Datei.

Nein – beim Ablegen springt am Mauszeiger die dreifache Wahlmöglichkeit
verschieben, kopieren, verlinken auf. Wenn ich beim Ablegen [Strg] gedrückt
halte, wird ohne Nachfrage kopiert. Auf Windows-Systemen muss man vermutlich
die rechte Maustaste zum Ziehen nehmen, um gefragt zu werden.

Drag’n’Drop habe ich oben nur /beispielhaft/ nochmal erwähnt – der eine
Nutzer macht es so, der andere lieber anders, bspw. per „Speichern unter“ im
Kontextmenü. Der Punkt ist: Auf „richtigen Computern“ bietet jeder User-
Agent mindestens eine generell bei jedem echten Link gleichartig und logisch
zur Verfügung stehende Download-Möglichkeit, ohne, dass der Seitenersteller
etwas dafür tun müsste. Der Vorteil beim einfachen Link ohne
Spezialdeklaration ist, dass der Link dann ohne Umstände gleichzeitig sowohl
zum Herunterladen als auch zum Anschauen ohne lokale Speicherung taugt.
--
Hannes Kuhnert, Chemnitz

[Hannes Kuhnert]

Stefan Froehlich schrieb:

> On Wed, 11 Jan 2012 14:03:25 Hannes Kuhnert wrote:
>> Peter J. Holzer hatte vom Anhängen einer Dateinamensendung bzw. Ändern
>> derselben beim lokalen Speichern geschrieben, was offensichtlich
>> sinnvollerweise auf dem angegebenen Content-Type basieren sollte, und ich
>> stellte fest, dass ich noch nie gesehen hätte, dass der Content-Type
>> /beim Speichern ausgewertet/ werden würde.
>
> Wirklich nicht?
>
> Download-Links in meinen Applikationen werden ueblicherweise als
> <a href="http://host.example/path/program?parameter">Description</a>
> geschrieben, also ohne jede Dateinamensendung (was haette die an dieser
> Stelle auch verloren?).
>
> Dateiname und Mime-Type werden ueber (z.B.):
>
> | Content-Disposition: attachment; filename="archive.zip"
> | Content-Type: application/zip
>
> festgelegt. Was der Browser dann damit anfaengt, ist seine Sache. Meiner
> fraegt mich, ob er die Datei mit seiner Lieblingsapplikation oeffnen,

> oder irgendwo abspeichern soll.

… wobei die Angabe „Content-Type“ typischerweise verloren geht. Nur darauf
wollte ich oben hinaus.

>> Nein, es geht mir wie schon in meinem ersten Beitrag
>> <news:rpett8-...@zuhause.froschmaschine.net> um den Namen der
>> erhaltenen, dann lokalen Datei – der lautet dann typischerweise nicht
>> etwa „my(.html)“, sondern „download(.php)“, was offensichtlich wenig Sinn
>> hat.
>
> In der Tat, das muss aber keineswegs so sein.

OK, ich habe jetzt den Verdacht, das der entsprechende KIO-Slave oder welche
Komponente auch immer bei mir die Speicherung besorgt, die „filename“-Angabe
unter den Tisch fallen lässt.

Hast du mal einen Beispiellink, wo auf deinem System die Datei beim lokalen
Speichern unter dem im Header „Content-Disposition“ angegebenen Dateinamen
abgelegt wird? Dann könnte ich hier mal testen.
--
Hannes Kuhnert, Chemnitz

[W. Wolf]

"Hannes Kuhnert" <hannes....@gmx.de>
>
> Nein - beim Ablegen springt am Mauszeiger die dreifache Wahlmöglichkeit

> verschieben, kopieren, verlinken auf. Wenn ich beim Ablegen [Strg]
> gedrückt
> halte, wird ohne Nachfrage kopiert. Auf Windows-Systemen muss man
> vermutlich
> die rechte Maustaste zum Ziehen nehmen, um gefragt zu werden.
>

Eben nicht! Gerade hier noch mal getestet unter Win-XP

Firefox, linke Maustaste: Verknüpfung zur URL wird angelegt
Firefox, rechte Maustaste: keine Aktion

IE, linke Maustaste: Verknüpfung zur URL wird angelegt
IE, rechte Maustaste: Sicherheitsnachfrage, danach im Kontextmenü
dir Wahl zwischen Verknüpfung oder Active-Desktop-Element

Ich glaube es erübrigt sich andere Browser auch zu testen.

Ich sehe halt auch meine User, das sind i.d.R. keine Profis die mit
solchen Sachen umgehen können. Primäres Ziel dieser Dateien,
die ich hier zum Download anbieten will, ist eben der Download.
Die Dateien werden in ein bestimmtes Verzeichnis gespeichert
und dann von einer lokalen Anwendung gelesen. Die HTML-Datei
vor dem Download anzuzeigen, ist maximal eine Option und nicht
mehr. Ein Download-Link bei dem der Download startet wenn der
User auf den Link klickt ist das was er erwartet.

Schönen Gruß
W. Wolf

[Peter J. Holzer]

On 2012-01-10 15:44, W. Wolf <w.w...@dommel.de> wrote:
> Am 10.01.2012 15:48, schrieb Peter J. Holzer:
>
>> Ist sie doch. (Du hast vom Webbrowser aus niemals Zugriff auf "die
>> Datei", der Browser muss immer den Server bitten, den Inhalt der Datei
>> zu liefern. Und ob der Server-Code, der die Datei liest und an den
>> Browser schickt, in C oder PHP geschrieben ist, ist für den Client
>> bedeutungslos (er kann es auch gar nicht feststellen).
>>
>
> Also ich sehe da schon einen Unterschied.

Ich habe nicht behauptet, dass kein Unterschied zu sehen sei (der eine
URL ist länger als der andere ;-)), sondern dass es keinen Unterschied
macht, ob der Code in C oder PHP geschrieben ist. Das kann der Client
nämlich nicht feststellen, sondern höchstens aus dem URL erraten, und
das sollte er nicht tun. URLs sind bedeutungslos - der Browser sollte
aussschließlich auf den Content-Type schauen, wenn es darum geht, den
Typ eines Dokuments zu bestimmen.

> Wenn ich auf der Seite zwei Links habe:
><a href="download.php?my.pdf">my.pdf</a>
> und
><a href="my.pdf">my.pdf</a>
> ich nun rechts auf den ersten Link klicke und "Ziel speichern unter..."
> im Kontextmenü wähle, passiert es schon, dass statt dem gewünschten PDF
> sonst was auf der Platte landet.

Der Internet-Explorer schlägt in dem Fall als Name "download.pdf" vor,
so wie ich es erwartet hätte.

Der Firefox ist inkonsistent.

Wenn man eine HTML-Seite mit "Save as ..." abspeichert, deren URL nicht
in .html, .htm oder ähnlich endet, hängt er automatisch .html hinten an.
Das kannte ich.

Wenn er eine Helper-Applikation aufrufen muss, hängt er ebenfalls die
richtige Endung hinten an (zum Testen habe ich das Acrobat Plugin
deaktiviert).

Wenn man hingegen aus dem Öffnen-Dialog oder aus "Save link as ..."
heraus speichern will, hängt er die Endung *nicht* an. Inkonsequent und
blöd. Gibt's schon einen Bug dazu?

(Windows Vista, IE 8, FF 8)

> Ich glaube darauf bezieht sich auch
> Hannes beim D&D. Ich denke aber, dass das nur mit der Link-Beschriftung
> zu tun hat. Ein Link in der Form
><a href="download.php?my.pdf">Download</a> sollte weniger
> missverständlich wirken - hoffe ich.

Das macht aber für den Browser genau keinen Unterschied.

[Peter J. Holzer]

On 2012-01-10 16:47, Hannes Kuhnert <hannes....@gmx.de> wrote:
> Peter J. Holzer schrieb:
>> On 2012-01-10 09:59, Hannes Kuhnert <hannes....@gmx.de> wrote:
>>> W. Wolf schrieb:
>>>> Also m�sste ich mir so was wie ein zentrales download.php basteln
>>>> und dieses dann per Link
>>>> <a href="download.php?my.html">Download</a>
>>>> aufrufen?
>>>
>>> Bei der Technik, die du ins Auge gefasst hast, kommt das dann als eine
>>> Datei namens „download.php“ an. Das ist hässlich, besonders, wenn das
>>> System lokale Dateien (nur) anhand der Endung identifiziert
>>
>> Ich dachte, Browser hätten mittlerweile gelernt, auf solchen Systemen
>> eine lokal aussagekräftige Endung anzuhängen?
>
> Mal abgesehen davon, dass die Speicherung, soweit ich sehen kann, nicht der
> Browser durchführt

Der Filename kann nur vom Browser kommen. Ob der in diesem Fall direkt
speichert oder über irgendeinen Clipboard/RMI/Schlagmichtot-Mechanismus
dem Filemanager mitteilt, dass da etwas abzuspeichern ist, macht da
keinen Unterschied.

> – gibt es das tatsächlich irgendwo? Ich habe noch nirdend
> gesehen, dass der in der HTTP-Übertragung gegebene Content-Type beim
> Speichern irgendwie ausgewertet werden würde.

Siehe meine Antwort an W. Wolf.

> Wenn man aus dem Content-Type eine Dateinamensendung ableiten wollte, müsste
> übrigens rückwärts gearbeitet werden – es müsste bei den einzelnen Dateityp-
> Definitionen unter den oft mehreren Endungen eine geben, die als „die
> richtige“ gilt.

Ja. Z.B. einfach die erste. Das ist technisch kein Problem. Das macht
der IE so und der FF in manchen (aber leider nicht allen) Situationen.

>
> Wenn es nach mir ginge, würde der Content-Type als spezielles Attribut im
> Dateisystem gespeichert werden (können),

Ja, würde ich auch so machen, aber Microsoft sieht das wohl anders (die
Linux-Desktops auch).

[W. Wolf]

"Peter J. Holzer" <hjp-u...@hjp.at> schrieb
[...]

>
>
>> Ich glaube darauf bezieht sich auch
>> Hannes beim D&D. Ich denke aber, dass das nur mit der Link-Beschriftung
>> zu tun hat. Ein Link in der Form
>><a href="download.php?my.pdf">Download</a> sollte weniger
>> missverständlich wirken - hoffe ich.
>
> Das macht aber für den Browser genau keinen Unterschied.
>

Ich meine auch den Anwender und nicht den Browser. Wenn
dem Anwender klar ist, was der Programmierer mit einen
Link bezweckt, dann wird er ggf. auch sein Verhalten danach
richten. Das meinte ich mit der Beschriftung. Wenn diese
den Dateinamen enthält, dann neigt man eher dazu D&D oder
das Kontextmenü zum Speichern aufzurufen, als wenn hier nur
"Download" oder was ähnliches steht. Freilich, dem Browser
ist das egal, der Browser wird aber von jemandem bedient und
diesem Jemanden möchte ich unmißverständlich eine HTML-Datei
zum Herunterladen anbieten. Gar nicht so trivial, wie es scheint...

Schönen Gruß
W. Wolf