nicht angemeldet
iFrame: Erkennen, ob Bild, Text oder SGML-Daten beinhaltet
Gunnar Bittersmannhi,
Seitenaufbau: auf meiner aktuellen Seite gibt es eine iFrame, in diesem Inhalte lade. Ich verwende kein Request-Objekt, da dies eine alternative für Nutzer des Internet Explorers mit deaktiviertem ActiveX darstellen soll. Der Eventhandler "onload" zeigt dem Script, wann die Seite geladen ist und dieses liest dann die Inhalt in ein XMLHttpRequest-ähnliches Objekt. Die Seite, die ich im iFrame aufrufe, beinhaltet je nach Query eine andere, von Usern hoch-geladene Datei.
Problem:
Mir bereiten vor allem die Eigenschaften .responseXML und .responseText Kopfschmerzen, da die Seite, welche sich im iFrame öffnet, sowohl Text, HTML, XML, als auch Bilder (im Format, in dem sie der User hoch-geladen hat) beinhalten, etc. Also so ziemlich alles (*.exe zum Beispiel nicht). Wie soll ich diese beiden Eigenschaften im XMLHttpRequest-ähnlichen Objekt zur Verfügung stellen?
Lösungsversuche:
- Auslesen von
'<html>'+document.body.parentNode.innerHTML+'</html>'als.responseTextunddocument.body.parentNodeals.responseXML. Schön wäre es, aber die Browser verwandeln automatische alle Inhalte, die im iFrame laden ohne Rücksicht auf Verluste in SGML-Daten. Und das wirkt sich natürlich auch auf ".innerHTML" etc. aus.
(Beispiel:)
Aus der Plaintextdatei mit Inhalt "So ein Taxi gibt's nur in Bayern." wäre dann <html><head></head><body><pre>So ein Taxi gibt's nur in Baern.</pre></body></html> geworden. Und <html><head></head><body><pre>... würde mein Script ganz anders behandeln als einen Textstring wie "So ein Taxi gibt's nur in Bayern.".
Also brauche ich eine Möglichkeit, festzustellen, ob es sich um eine SGML-Datei (einfach document.body.parentNode.innerHTML und document.body.parentNode auslesen), ein Text (Bei <html><head></head><body><pre>So ein Taxi gibt's nur in Baern.</pre></body></html> Inhalt des PRE-Elements auslesen) oder ein Bild handelt.
- Solche vom Browser generierte Dateien haben (je nach Browser) einen leeren Header bis keinen HEAD-Element. Allerdings gibt es auch so dumme Nutzer, die auf das TITLE-Element und die META-Elemente vergessen und somit auch einen leeren Header haben. Also ist das auch kein Kriterium, ob es sich um ein SGML-Dokument oder nicht handelt.
- Auslesen von der
location.hrefdes Frames, da ich scharf auf das Dateikürzel war. Doch leider Fehlanzeige: In allen Fällen handelt es sich dabei um eine *.cgi-Datei, welche den Dateityp nur als MIME-Type im Headerfeld Content-Type angibt. Also brauche ich einen Weg, den MIME-Type eines iFrames zu lesen, um somit auf die Art des Dokuments (SGML/Picture/TXT) schließen zu können. - Auslesen von
document.contentType, weil diese den MIME-Type beinhaltet. Perfekt, fast schon zu perfekt, um wahr zu sein. Doch leider wird diese Eigenschaft nur von Gecko unterstützt ("Non-Standard"). - Überprüfen vom boolischen Wert von
document.doctype, weil solche nur bei echten SGML-Dokumenten existieren und der boolische Wert danntrueist. Doch auch da: Manche Nutzer, sind zu blöd, einfach einen !DOCTYPE anzugeben. Und dann ist dieser auch hierfalse. - Und am Anfang der Datei einfach den MIME-Type mit-versenden. Nein, ich habe keine Möglichkeit, dass Script zu bearbeiten, da dieses jemand anderer "verwaltet" (:iron:) :-(
Zusammenfassung:
Ich brauche einfach eine Möglichkeit, festzustellen, ob es sich um eine SGML-Datei (einfach document.body.parentNode.innerHTML und document.body.parentNode auslesen), ein Text (Bei <html><head></head><body><pre>So ein Taxi gibt's nur in Baern.</pre></body></html> Inhalt des PRE-Elements auslesen) oder ein Bild handelt.
Es ist ein sehr komplexes Problem; ich hoffe, ich konnte es trotzdem verständlich schildern. Mir ist eine nicht-weiterhelfende Antwort zu viel lieber als eine weiterhelfende zu wenig. mfg Latzhose;
-
Das Problem schildert sich etwas komplexer, als es tatsächlich ist: Du möchtest im Client scriptseitig den Mimetype einer unbekannten Ressource ermitteln.
Die Dateiendung hilft Dir nicht weiter, das CGI übermittelt auch den Mimetype der übertragenen Daten möglicherweise nicht korrekt, ansonsten könntest Du mit xhr.getResponseHeader('Content-Type') zum gewünschten Ergebnis kommen.
Falls all dies nicht funktionieren soll, hilft nur noch die tatsächliche Erkennung anhand bestimmter "magischer Zeichen", wie es das Unix-Kommando "file" macht - in diesem Fall entspräche responseText bspw. dem binären Inhalt einer Bild-Datei. Dementsprechend kannst Du verschiedene RegExp durchexerzieren, die Dateien erkennen. Für JPEG/JFIF wäre es bspw.
/^.{6}J(PEG|FIF)/
mit /^.{6}J(PEG|FIF)/.test(data) kannst Du demnach prüfen, ob Du eine JPEG/JFIF-Datei hast. Für nahezu alle Dateitypen kann man mit ein wenig Einfallsreichtum derartige RegExp schreiben (etwa /<html>/i für html).
Gruß, LX
--
RFC 1925, Satz 2: Egal, wie fest man schiebt, ganz gleich, wie hoch die Priorität ist, man kann die Lichtgeschwindigkeit nicht erhöhen.-
@@LX:
nuqneH
Für nahezu alle Dateitypen kann man mit ein wenig Einfallsreichtum derartige RegExp schreiben (etwa /<html>/i für html).
Das '>' ist zu viel.
Qapla'
--
Volumen einer Pizza mit Radius z und Dicke a: pi z z a-
@@Gunnar Bittersmann:
nuqneH
Für nahezu alle Dateitypen kann man mit ein wenig Einfallsreichtum derartige RegExp schreiben (etwa /<html>/i für html).
Das '>' ist zu viel.
Und überhaupt sind Start- und End-Tag des 'html'-Elements in HTML optional.
Qapla'
--
Volumen einer Pizza mit Radius z und Dicke a: pi z z a-
Hallo, Gunnar!
Das war nur ein Beispiel, um den Einfallsreichtum herauszufordern. Dass Dein Einfallsreichtum dabei auch herausgefordert wurde, war ein unerwünschter Nebeneffekt :-)
Gruß, LX
--
RFC 1925, Satz 2: Egal, wie fest man schiebt, ganz gleich, wie hoch die Priorität ist, man kann die Lichtgeschwindigkeit nicht erhöhen.
-
-
-
-
Moin!
auf meiner aktuellen Seite gibt es eine iFrame, in diesem Inhalte lade. Ich verwende kein Request-Objekt, da dies eine alternative für Nutzer des Internet Explorers mit deaktiviertem ActiveX darstellen soll.
Das bedeutet also, dass du den IE6 noch unterstützen musst? Für den darin auch noch sehr seltenen Fall des deaktivierten ActiveX? Was für eine extrem merkwürdige Aufgabenstellung.
Denn alle neueren Browser realisieren das XMLHTTPRequest-Objekt nativ, auch der IE 7: http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx
Als Resultat handelst du dir Probleme ein, die du nur deshalb hast, weil du vielleicht 10% IE6-User berücksichtigst, von denen vielleicht 10% ActiveX ausgeschaltet haben - insgesamt also allerhöchstens 1% der Gesamtuserzahl. Oder?
- Sven Rautenberg