Beiträge von thomas_46

ICH DANKE ALLEN FÜR IHRE HILFE UND BEREITSCHAFT ZUM HELFEN.

PS: Ich sehe gerade, daß hier keine Zeichen für meinen Leerzeichenersatz sichtbar wurden. Ich wählte &-#-32-; Das normale ungeschützte Leerzeichen wurde jetzt von mir einmal vollkommen unrichtig geschrieben. Durch die Bindestriche wird es jetzt aber hoffentlich sichtbar, was ich vorher korrekt schrieb, aber nicht sehen kann...

Hallo Jörg, ich danke Dir für Deine konstruktive Hilfe. Es ist die Lösung. Ich habe die Leerzeichen jetzt nicht einfach nur mit der Tastatur getippt, weil das am Anfang im Netscape merkwürdige zeichen beim Offline-Öffnen verursachte und mich daher zum - wie wir jetzt wissen - falschen geschützten Leerezichen trieb. Jetzt habe ich das ungeschützte - normale - Pendant für %20 gewählt und den ASCII DEC-Eintrag &-#-32-; an die Stelle der vorherigen html-Variante des geschützten   gesetzt, was lt. Quellcodekontrolle wieder passt: %20 wird generiert.

Desweiteren gebe ich Dir in Bezug auf meine zögerliche Haltung zur URL Recht, daß ich die Titel-Funktion als künftig vorgeschlagenen Namen für das lokale Speichern übersah, weil beim lokalen Speichern der Browser den Generierungsprozess entsprechend des nun gespeicherten Dateinamens aus dem titel startet bzw. umsetzt. Für den titel muß man den Quellcode sehen können. Allerdings bist Du es, der die Lösung fand, nicht die beiden, die so stark auf den Quellcode bestanden, ihn auch abriefen, aber wie ich keine Lösung fanden. Du hattest bereits am Beginn der Suche ohne URL einen guten Gedanken, den ich als überlegenswerten Ansatz empfand. Ich dachte über diesen Ansatz viel nach, konnte jedoch keine weitere Brücke zum Generierungsprozeß finden. Deshalb stimmt die Quellcode-titel-Idee umso mehr, zumal der titel sich nicht im html- oder body-Bereich für html-Zeichen befindet. Das hätte mich eigentlich stutzig machen sollen. Aber auch im Fall einer ASCII-DEC-Variante von   als &-#-160-; wäre ich ja nicht weiter gekommen. Denn Deine Lösung heißt klar: kein geschütztes, sondern ein normales Leerzeichen. Ich wäre wohl nie drauf gekommen. Nochmals: Danke.

Gleichzeitig beweist daran der Firefox wieder einmal, daß er absolut korrekt umsetzt. Mal muß der FF doch auch zu seinem Recht kommen und gelobt werden. Für mich schon seit Jahren DER Browser. Nach wie vor. Ohne Alternative. Opera ist mir manchmal zu sehr Spezialfall.

Bei neuen Problemen nehme ich die Umsetzung des Firefox noch wörtlicher, anstelle mir seinen Wirkungsmechanismus zu erklären, und suche die Ursache doch eher im Quellcode.

(Siehe noch Nachtrag im nächsten Beitrag.)

Hallo Jörg, ich werde Deine Erkenntnis, für die ich Dir danke, in die Tat umsetzen und dann das Ergebnis hier auch für die anderen Leser mitteilen. Bis dahin Beste Grüße.

Die URL: (gelöscht)

Wie gesagt: Die Seite ist noch im Entstehen, nicht veröffentlicht bzw. frei gegeben und wird noch in vielen Dingen wie z. B. Doctype geändert. Meiner Ansicht nach hilft die URL nicht, sich den Generierungsprozeß im Firefox zu erklären, und insbesondere nicht, den möglichen Fehler im Firefox zu lokalisieren. Das ist in den bisherigen Zeilen mehr oder weniger schon erwähnt worden. In diesem Zusammenhang möchte ich noch anmerken, daß ich natürlich den Cache und auch meine anderen privaten Daten wie z. B. die Chronik aus meinem Firefox gelöscht habe, jedoch brachte das keinen Erfolg.

Hallo Ulli,

Dank für Deine Gedanken. Allerdings vermag ich Deinen letzten Ausführung nicht ganz zu folgen - so richtig verstanden habe ich es nicht. Mir geht es bei der Lösung um folgenden Hintergrund: Die html-Seite wird voraussichtlich von einfachen Nutzern ohne vertiefte Kenntnisse aufgerufen und möglicherweise auch wie eingangs beschrieben lokal gespeichert. Es ist durchaus denkbar, daß der Fehler bei fremden Rechnern nicht auftritt, weil der vielleicht bei denen vorhandene Firefox auch nicht mal versehentlich umgestellt worden ist. Es ist nur zu doof, daß gerade bei mir auf dem Schlepptopp die Chose solche Rätsel auslöst. Man verübele es mir bitte nicht, daß ich selbst wenigstens die Sache wieder in Ordnung haben möchte und vor allem auch die Ursache kennen und abstellen möchte. Wieso bei einer Webseite, und dies auch nur mit dem Firefox? Ich bin fest überzeugt, daß ich mit einem zweiten Rechner per Firefox das Problem nicht antreffen würde, besitze jedoch keinen zweiten, um die Vermutung bestätigt zu bekommen. Und die Richtigkeit der Vermutung ist mir auch gleichgültig. Es ist aktuell das eine klar beschriebene Problem, das beseitigt werden soll. Für ein Grübeln ohne Ausblick auf Lösung meinerseits reicht das eigentlich zu. Der Teufel im Detail? Ich bin sicher, daß es zum Schluß eine Kleinigkeit ist - aber welche?

Der saubere Dateinamen ist hier nicht mein Fragegegenstand, mir natürlich nicht unbekannt. Bewusst habe ich den Generierungsautomatismus des Webbrowsers angeführt. Für das Speichern von html-Dateien auf dem eigenen Rechner ohne weitere Versendungsabsichten genügt es, geht schneller und nutzt die %20-Generierung bewusst. Wie bei allen Webseiten. Wie kommt jedoch das Problem zustande bzw. wie könnte es gelöst werden? Unabhängig von den bekannten Wegen des Umgehens, sozusagen Vermeidungsstrategien des Problemauftretens mal ausgeschlossen. Es muss ja Ursachen haben und gelöst - nicht vermieden - werden können.

Hallo Jörg,

Danke für Deinen Hinweis. Das ist schon einmal gut zu wissen. Im Grunde stellt sich die Frage, wie Firefox das die Leerstelle ersetzende Zeichen beim lokal Speichern generiert und wie eine Einstellungsmöglichkeit gegeben ist. Merkwürdig ist, daß es nur diese URL betrifft, alle anderen Seiten im www nicht. Wüssten wir, wie dieseGenerierung exakt abläuft, könnte man auch gezielt auf Suche im Quellcode der Webseite gehen, die jedoch mit Netscape 7 vollkommen ordentlich mit funktionierender Bildreferenz gespeichert wird, die richtige Charset-Eintragung besitzt.. usw. usf. Zuerst müssen wir wissen, wie diese Generierung im Firefox läuft. Wer weiß da mehr?

Beste Grüße

Thomas

Ich stecke momentan in einem unerklärlichen Zeichenkodierungs-Phänomen, was ich bislang nicht lösen konnte. Es raubt mir ein wenig zu viel Zeit, weil ich so lang eigentlich nicht am Fundament verweilen wollte. Vielleicht würde jemand einen Ansatz wissen? Der Ansatz kann meiner Ansicht nach kaum aus Test oder Vermutung, sondern eher aus Wissen, Erfahrung und Logik kommen. Hier im Forum fand ich keinen ähnlichen Beitrag hierüber.

Vorab: Web-Browser-Menü Datei, dann Speichern unter, dann Eintrag des Dateinamens mit zwei Wörtern, zwischen denen eine Leertaste steht, dann Auswahl des Dateityps der vollständigen html-Datei inkl. zugehörendem Ordner für Bilder usw. Die nicht als optimal angesehen Leertaste wird in Normalfall vom Browser stets automatisch und zuverlässig durch ein ASCII-HEX-Zeichen %20 ersetzt. Der Browser vervollständigt ohnehin automatisch beim Speichern. Alle relativen Links der gespeicherten Webseite zu anderen Unterseiten werden automatisch auf absolute Links vervollständigt, wie die Überprüfung offline in der Statuszeile zeigt, nachdem die gespeicherte Seite neu geöffnet wurde. Und alle Bildreferenzen usw. werden automatisch mit der neuen Referenz zum Bildordner der html-Datei gesepichert, eben, je nachdem, wie die html-Datei fürs Speichern benannt wurde. Ein Blick in den Seitenquelltext vor und nach der Speicherung bestätigt das hier vorab Erwähnte.

Mein Problem: Ob mit Firefox 2, Opera 9, Netscape 7 oder IE 7, das Vorgenannte klappt immer bei allen unterschiedlichen Webseiten. Ich speichere mit allen Browsern eine neu entstehende Seite. die im Kopf auch den Eintrag hat: meta http-equiv="content-type" content="text/html; charset=ISO-8859-1". Bei einer im Entstehen befindlichen html-Seite von mir, die noch nicht frei gegeben ist, habe ich vielleicht auch einmal die Einstellung der Zeichenkodierung unter Ansicht nur im Firefox auf UTF-8 geändert, um zu sehen, was passiert, danach jedoch wieder auf ISO 8859-1 bzw. auf automatisch bestimme/universell zurückgestellt. Davon ist wohl der Firefox nun nicht mehr zu beeindrucken, er bleibt laut Kontrolle im Quelltext bei UTF-8, obwohl er vorgibt, universell oder nach ISO 8859-1 anzuzeigen. Diese praktisch ausgeführte UTF-8-Zeichenkodierung zeigt sich an den UTF-8-Quelltextzeichen für die automatisch gesetzten Zeichen der Leertaste in Form von %C2%A0. Daraus folgt, daß eine lokal gespeicherte html-Datei, die wieder offline geöffnet wird, keine Bilder angezeigt werden, die jedoch im zugehörigen Ordner gespeicherter Maßen liegen. Denn beim lokalen Öffnen verwendet Windows kein UTF-8, d. h. die im Quelltext stehende Referenzierung kann nicht umgesetzt werden. Speichere ich diese Problem-Web-Seite mit meinen anderen Browsern, dann gibt es nach wie vor keine Probleme bezüglich der hilfreichen browsertypischen Automatisierung beim Zeichensetzen für Leertasten im Namen der zu speichernden html-Seite. Im Firefox-ähnlichen Netscape 7 erscheint stets das richtige ASCII-HEX-Zeichen %20. Wie kann ich diesen Wurm wieder im Firefox beheben? Der offenbar störrische Firefox macht diesen UTF-8-Unsinn auch nicht bei irgendwelchen anderen Webseiten, die ich für Gegenkontrollen speichere. Nur bei dieser einen aufgerufenen Webadresse. Und nur der Firefox. Und das nach meiner Meinung auch nur durch den beschriebenen und nur richtig gewünschten Automatismus, der beim Speichern in Gang kommt.

Was tun? Browser-Cache leeren, und alles ist behoben? Firefox ist nun mal der wichtigste Browser, auf den ich meine Seite auch zuerst teste.

Würde jemand eine stichhaltige Erklärung/Lösung sehen?

Ich würde mich über Antworten freuen.

Thomas