Dateidownload ohne "Spechern" im Dialog?

[Christof]

Hallo,

ich habe ein kleines Problem.
Ich biete jeweils ein Bild per Link als direkten Download aus einer DB an.
Dazu habe ich einfach den MIME-Type auf "application/octet-stream" geändert. So öffnet sich der Dateidownload-Dialog. So weit so gut.
Der bietet, an die Datei zu Speicher, oder zu Öffnen. Ansich total normal.
Wenn der Anwender jetzt auf "Öffnen" geht, wird das Bild im verknüpften Bildbetrachter angezeigt. Und hier kommt das Problem. Je nach Bildbetrachter kann er eventuell durch alle Bilder des temporären Ordners navigieren (wo das Bild ja zwischengespeichert wird). Und einige Benutzer verwirrt das, weil sie nicht verstehen, was das eine Bild mit den Anderen zu tun hat.

Weiß jemand eine Möglichkeit entweder den Dialog zu beeinflußen (abgesehen davon, der Bilddatei die Endung wegzunehmen, und damit die Verknüpfung zum Bildbetrachter) oder z.B. im Kontextmenue den Menüpunkt "Bild speicher unter.." zu triggern. Oder ganz was anderes?

Vielen Dank
Christof

[Dieter Raber]

Hallo Christof,

was du vorhast, ist nicht moeglich.

Gruß,

Dieter

[bleicher]

Hi!
um nicht unnötig ein neues thema zu starten - wie bestimmt/begrentzt man dateiarten die per upload-feld um formular ausgewählt werden? accept="image/jpeg" brachte nichts.
DiV
MFG
bleicher

[Dieter Raber]

Hallo bleicher,

Wie Du ja vermutlich in http://de.selfhtml.org/html/formulare/datei_upload.htm schon gelesen hast, kann man sich nicht darauf verlassen, dass der Browser sich tatsächlich für den MIME-Type interessiert. Du kannst Dir aber mit Javascript behelfen. Du kannst das Datei-Uploadfeld validieren mit einer Funktion, die etwa folgendermassen aussehen muss:

• finde anhand des Pfades in dem Feld die Dateiendung heraus
    (substring von lastIndexOf('.') bis Ende Pfad)
• bilde ein Array aus erlaubten Endungen, sowas wie ['gif','jpeg','jpg']
• gehe in einer Schleife durch das Array und vergleiche die Werte mit der gefundenen Endung

Wenn du keinen Treffer hast, ist was falschgelaufen, schick die Form nicht ab und gib einen Fehler aus.

Das ist natuerlich auch nichts 100%iges und entbindet dich nicht davon, auf dem Server eine Validierung vorzunehmen, aber die Mehrzahl der Uploads falscher Formate wirst du wohl verhindern koennen.

Gruß,

Dieter

[Skeeve]

Moin!

• bilde ein Array aus erlaubten Endungen, sowas wie ['gif','jpeg','jpg']
• gehe in einer Schleife durch das Array und vergleiche die Werte mit der gefundenen Endung

Oder

• Bilde ein assoziatives Array erlaubter Endungen: legal['gif']=1 ...
• teste ob legal[extension] == 1
  Spart die Schleife.

Oder

• Teste den Dateinamen gegen /.(?:gif|jpg|jpeg)$/i

-- Skeeve

[bleicher]

Danke,
aber DAS ist nicht das Problem. Dateiformat wird über PHP auf dem Server überprüft.
Es geht blos darum , dass Einschränkung der Formate die Suche nach nötigen Dateien beschleunigt (ich bringe es nciht übers Herz meine Festplatte aufzurüumen:) zudem dachte ich, dass Opera9 in diesem Bereich doch konform sein sollte.
MFG
bleicher

[Struppi]

• bilde ein Array aus erlaubten Endungen, sowas wie ['gif','jpeg','jpg']

Was mich da mal interssiert, benutzen MacOs Rechner diese Endungen?
Ich dachte immer dort gibt es keine Dateiendungen.

Struppi.

[Dieter Raber]

Hallo Struppi,

die Sachen, die ich von unseren Grafikern bekomme, sind meist in .eps, .jpg oder .psd, die haben immer korrekte Endungen. Ich nehme an, bei den gaengigen, OS-uebergreifenden Formaten wird das meist so sein.

Gruß,

Dieter

[Tim Tepaße]

Hallo Struppi,

Was mich da mal interssiert, benutzen MacOs Rechner diese Endungen? Ich dachte immer dort gibt es keine Dateiendungen.

Jain. Früher war „keine Dateiendungen“ Standard, inzwischen haben sie sich leider durchgesetzt, aber sie sind immer noch eine doofe Variante, Dateitypen zu identifizieren, deswegen hat Apple eine weitere, neuere Variante der Dateityp-Identifikation in der Hinterhand.

Ich fang mal mit früher an, das ist hier Mac OS ≤ 9. Wie eventuell bekannt haben die dort verwendeten Dateisysteme (HFS, HFS+) die Möglichkeit neben den reinen Inhaltsdaten der Dateien auch Metadaten zu speichern, die über Dateiname und den Zeitpunkten des Erstellens und der letzten Änderung hinaus gehen. Ein Beispiel ist der Resource Fork, wo zusätzliche Informationen zu den Daten gespeichert werden, bei Programmen z.B. Icons. Der Resource Fork (im Gegensatz zum Data Fork) ist eh eine Mini-Wissenschaft für sich, am besten man stellt es sich als eine zusätzliche Datenstruktur vor. Andere Metadaten, die von Dateisystem zu einer Datei gespeichert sind sind Type und Creator Code, und da wird es in Sachen Dateityp spannend.

Type Code und Creator Code sind zwei Datenfelder, die jeweils vier Bytes halten. Apple hatte oder hat noch eine allgemeine Registrierung für diese Vier-Byte-Codes, wo man sich Drittfirmen registrieren kann. Sprich: Ein Vier-Byte-Code identifizierte immer etwas und nur das. Der Type Code ist für den Dateityp gedacht, z.B. TEXT für Textdateien, APPL für Programme, etc. Der Creator Code dagegen zeigt an, welches Programm diese Datei öffnen soll, wird darauf geklickt. Sprich: Es kann Textdateien geben, die mit Programm 1 als Default geöffnet werden und gleichzeitig Textdateien, die mit Programm 2 als Default geöffnet werden. Type Codes erzählen, welcher Typ die Datei ist, ob sich ein Programm dafür interessieren soll, Creator Codes erzählen, welches genaue Programm die Datei öffnen soll; Dateityp und Default-Programm sind also entkoppelt.

Das war damals durchaus ein nettes Konzept. Und ganz in den Anfängen des Mac-Zeitalters hat das auch niemanden weh getan. Aber in Zeiten in der Interoperabilität ist das doof. Weil all die anderen gebräuchlichen Dateisysteme da draussen (CD-ROM, etc) und im Internet (HTTP, FTP, E-Mail) es nicht das Konzept der Datei bestehend aus Daten und vielen Metadaten gibt, wie im Mac OS Dateisystem. Da besteht eine Datei nur aus Dateiname und Inhalt, zugegeben noch bei HTTP und E-Mail aus der zusätzlichen Datei-Typ-Identifizierungs-Variante MIME-Typ. Zip- und sonstige gepackten Archive. Es gibt zwar Ansätze für Metadaten bewahrende Archivformate auch für bestehende Formate wie Zip, aber das läuft immer auf doofe Hacks hinaus. Undsoweiter. Also schlichen sich Dateiendungen doch noch in Mac OS rein.

Mit Mac OS X wurden die dann wichtiger, Type und Creator Code wurden kaum noch beachtet, die Dateiendung ist leider nun mal der entscheidene Part geworden, den Dateityp zu identifizieren. Sprich: Ja, unter Mac OS X gibt es Dateiendungen und sie werden auch benutzt. Wobei das übliche bei benutzerfreundlichen Betriebssystemen gilt, im Default werden die Endungen ausgeblendet, es wird gewarnt, wenn man einfach so die Endung ändert, etc.

Unter Mac OS X machen sich viele Programme auch nicht mehr die Mühe, Type und Creator Code zu setzen:

tim $ /Developer/Tools/GetFileInfo bla.png
  file: "/Users/tim/bla.png"
  type: ""
  creator: ""
  attributes: avbstClinmedz
  created: 10/27/2006 20:51:37
  modified: 10/27/2006 20:58:36

Allerdings winkt ein neues System der Dateityp-Identifizierung am Horizont bzw. ist schon wirksam, der Identifizierung durch UTIs (Universal Type Identifier). UTIs sind erstmal nur ein String, was unterscheidet sie also von Vier-Byte-Codes, Datei-Endungen und MIME-Typen? Zum einen die Länge, was durchaus praktisch ist angesichts der Drei-Buchstaben-Konvention bei DOS-Dateiendungen und dass Dateinamen nicht ewig kang werden. Dann die Nutzbarkeit durch jeden, „im Prinzip“ gibt es keine zentrale Registrierung dafür. Und die Vererbbarkeit, spezielle Typen können von allgemeineren Typen erben. Ein UTI sieht zum Beispiel so aus:

org.tepasse.bla.blubb

Man beachte: Beim privaten Erstellen von UTIs nutzt man Reverse DNS, sprich für die Bezeichnung von Namensräumen hat man ein System, das wirkt, Verwechselungen vermeidet und vermutlich noch lange Zeit bei uns bleiben wird. Finde ich geschickter als die x-Konvention bei MIME-Typen. Mein hypothetisches Programm „bla“, dass ein Dateityp „blubb“ definiert könnte dann auch zusätzlich noch ankündigen, dass dieser Dateityp von den allgemeinen Dateityp public.plain-text erbt, also aus einer speziellen Form von reiner Text erbt. So dass alle Programme, die Plain Text öffnen können, auch erkennen, dass sie Dateien vom Typ org.tepasse.bla.blubb öffnen können, auch wenn ihnen dann die Feinheiten des speziellen Formats entgehen. Ähnlich wie die image/* bei MIME Media Typen. Die Definition von public.* unterliegt der Domäne von Apple.

Die UTIs werden wiederrum als spezielles Attribut einer Datei im HFS+-Dateisystem gespeichert, sind also wiederum nicht portabel. Wie auch, wenn das Standardmodell einer Datei ausserhalb spezieller Dateissysteme nur aus Datenstrom und als einzigen Metadaten Dateinamen (plus Dateiendung besteht)? Aber intern kann man es gut für alle möglichen Zwecke nutzen. Für eindeutige Identifizierung des Dateiformates, Spotlight, der Mac OS X Suchservice speichert das auch noch mal zusätzlich in seinen Indizes:

tim $ mdls bla.png
  bla.png -------------
  kMDItemAttributeChangeDate     = 2006-10-27 20:58:38 +0200
  kMDItemBitsPerSample           = 40
  kMDItemColorSpace              = "RGB"
  kMDItemContentCreationDate     = 2006-10-27 20:51:37 +0200
  kMDItemContentModificationDate = 2006-10-27 20:58:36 +0200
  kMDItemContentType             = "public.png"
  kMDItemContentTypeTree         = ("public.png", "public.image", "public.data",
                                    "public.item", "public.content")
  kMDItemDisplayName             = "bla.png"
  ... abgeschnitten

Man beachte den Content-Type-Tree, der die Vererbung von UTIs schildert.

Was hat man nun davon? Man hat intern eine Möglichkeit, Datenformate eindeutig zu identifizieren und diese durch die UTI-Hierarchie abzuleiten. Im wesentlichen ist das dasselbe wie die Creator Codes früher, nur in etwas technisch ausgereifter. Das Zauberwort lautet „intern“, für die Zwecke der Interoperabilität mit weniger reichen Dateisystemen oder Dateiübertragungsformate verzichtet man immer noch darauf, dort muss man weiter noch mit Dateiendungen und/oder MIME-Typen hantieren. Konsequenterweise wird die UTI auch aus solchen Informationen gewonnnen, im Prinzip existieren unter Mac OS X zum Mittel der Identifikation Dateiendungen in ihren Varianten (*.jpg, *.jpeg), MIME-Typen und als Altlast die Type Codes. Allerdings: UTIs sind die letztendliche interne Authorität. Ich meine mich zu erinnern, dass diverse Linux Desktop Umgebungen ähnliches mit MIME-Typen machen.

Im Prinzip bräuchte man keine Dateiendungen. In der Praxis bleiben die aber trotzdem noch, wegen Interoperabilität und weil auch noch nicht alles wirklich so toll UTI-fiziert ist. Die LaunchServices (Verantwortlich für das Öffnen von Dateien) bevorzugen meiner Erfahrung nach wohl mehr die Dateiendung denn den UTI. Allerdings sind UTIs erst mit Mac OS X 10.3 eingeführt und mit Mac OS X 10.4 richtig popularisiert worden; ich rechne also noch mit Verbesserung in Mac OS X 10.5.

Und weil die Welt sich nie auf einen minimalen Konsens in Sachen Dateien einigen konnte, der über Daten und Name hinausgeht, bleibt es immer nur auf die schöne kleine Mac-Welt begrenzt. Wie immer schon. ;)

Tim

[Struppi]

Was mich da mal interssiert, benutzen MacOs Rechner diese Endungen? Ich dachte immer dort gibt es keine Dateiendungen.

Jain. Früher war „keine Dateiendungen“ Standard, inzwischen haben sie sich leider durchgesetzt, aber sie sind immer noch eine doofe Variante, Dateitypen zu identifizieren, deswegen hat Apple eine weitere, neuere Variante der Dateityp-Identifikation in der Hinterhand.

Ich fang mal mit früher an, ....

Vielen dank, für die umfangreiche Erläuterung.

Ich hatte mich mit solchen Test immer zurürck gehalten und stattdesen Bilder anhand des Dateiheader identifiziert (mit dem Perl Module Image::Size).

Was die - wie du es nennst [wieder was gelernt] - Interoperabilität angeht, halte ich das Verfahren für sinnvoll, ist aber natürlich nicht in jedem Fall Praktikabel (wenn man z.b. Verzeichnisse mit einigen tausend Dateien listet ist der Preis u.U. zu hoch).

Struppi.

[Skeeve]

Moin!

Ich habe das jetzt nicht so ganz verstanden. Wenn Du meinst es reicht, daß der Benutzer das Bild nur abspeichern kann, also keine "Öffnen" Möglichkeit bekommt, dann nimm einen eigenen mime type. Also statt application/octet-stream sowas wie "x-application/christofs-bilder-download". Im Normalfall kennt ein Browser das wohl kaum und der Benutzer müßte da erstmal was einrichten.

Wenn allerdings der Browser die Verknüpfung wirlich anhand der Extension zu erkennen glaubt, dann geht's natürlich nicht.

Probier es halt mal.

-- Skeeve

[Christof]

Leider schon vor meinem ersten Posting erfolglos probiert:-(

[Sven Rautenberg]

Moin!

Wenn Du meinst es reicht, daß der Benutzer das Bild nur abspeichern kann, also keine "Öffnen" Möglichkeit bekommt, dann nimm einen eigenen mime type. Also statt application/octet-stream sowas wie "x-application/christofs-bilder-download".

Zunächst mal: Nicht offiziell registrierte Mime-Typen und Sub-Typen erfordern ein vorangestelltes "x-" - in deinem Beispiel wäre "application/x-christofs-bilder-download" also korrekt, weil "application" ein existierender Mimetyp ist (das kann man nutzen).

Um den Download sicherzustellen auch im IE, würde ich "application/x-msdownload" empfehlen, denn "application/octet-stream" (und einige andere Mime-Typen) interpretiert der IE so, dass er im Dateiinhalt nachsehen darf, was da kommt, und wenn er den Datentyp erkennt, wird er sich so verhalten, als wäre der "richtige" Mimetyp angegeben worden.

Im Normalfall kennt ein Browser das wohl kaum und der Benutzer müßte da erstmal was einrichten.

Der Browser entscheidet anhand des Mime-Type, was er selbst oder eines seiner Plugins mit der Datei anfangen können. Aber bei "Datei öffnen" entscheidet das Betriebssystem anhand der Dateiendung des Namens, was mit der Datei passiert. Ein .jpg wird dabei mit hoher Wahrscheinlichkeit von einem Bildbetrachter geöffnet werden.

- Sven Rautenberg