nicht angemeldet
HTML-Entities
MudGuard
StruppiHallo,
es geht um eine Intranet-Anwendung die auf FF und IE laufen soll (aktuelle Versionen). Das Problem ist wahrscheinlich ein HTML-Problem, weswegen ich es in dieser Kategorie gepostet habe.
Zum Umfeld: Es geht um eine PHP-Anwendung die auf eine Datenbank zugreift und UTF-8 ist zwingend notwendig, weil da Daten in vielen verschiedene Sprachen gespeichert und angezeigt werden. Und damit meine im Quelltext vorhandenen Umlaute auch korrekt dargestellt werden, sind die PHP- und JS-Quelldateien auch im UTF-8 Format gespeichert. Als das Ganze zuvor noch mit cp1252 lief trat das Problem nicht auf.
An einer bestimmten Stelle werden per URL Parameter übergeben in der Form
http://.../seite.php?param1=«wert1» «wert2»
Aber in den Browsern kommt der Query-String unterschiedlich an. Im IE wird « als « und im FF als « angezeigt. Ich dachte eigentlich, dass die Entities überall gleich konvertiert werden.
Weiß jemand eine einfache Antwort, warum das so ist und ob ich das vermeiden kann?
Ich hab das in PHP jetzt so gelöst, dass ich einfach beide Möglichkeiten ersetze, bin damit aber nicht besonders glücklich.
$itemVal = str_replace(array("«", "»", "«", "»"), array("«", "»", "«", "»"), $itemVal);
Alternativ könnte ich wahrscheinlich auch in der URL gleich « und » angeben, aber das wird von dutzenden Stellen aus aufgerufen, wäre viel Aufwand und würde die Lesbarkeit an den verschiedenen Quellcodestellen deutlich verringern.
Weiß jemand eine bessere Alternative?
Im Voraus vielen Dank,
keyboarder
-
Hi,
An einer bestimmten Stelle werden per URL Parameter übergeben in der Form
http://.../seite.php?param1=«wert1» «wert2»
Aber in den Browsern kommt der Query-String unterschiedlich an. Im IE wird « als « und im FF als « angezeigt. Ich dachte eigentlich, dass die Entities überall gleich konvertiert werden.
Entities haben an der Stelle höchstvermutlich sowieso nichts verloren.
Weiß jemand eine einfache Antwort, warum das so ist
Bei der wenig ergiebigen Problembeschreibung kann ich nur vermuten, dass du nicht mal ansatzweise daran gedacht hast, die Werte für den Kontext „URL“, in den du sie bringst, zu behandeln.
und ob ich das vermeiden kann?
Ja, hole dein Versäumnis nach.
urlencode/rawurlencode.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam] -
Hi,
http://.../seite.php?param1=«wert1» «wert2»
Die Quotes mußt Du url-gerecht codieren, damit das eine korrekte URL wird.
Aber in den Browsern kommt der Query-String unterschiedlich an.
SISO-Prinzip: Shit in, Shit out.
Du gibst etwas ungültiges vor, und das wird eben unterschiedlich interpretiert.
Mach eine korrekte URL draus, dann wird's auch gleich behandelt.Weiß jemand eine bessere Alternative?
?name1=value1&name2=value2
Dann hast Du die Parameter in PHP auch gleich getrennt greifbar in $_GET
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Weiß jemand eine bessere Alternative?
?name1=value1&name2=value2
gerne auch ?name1=value1;name2=value2
-
Hi!
Weiß jemand eine bessere Alternative?
?name1=value1&name2=value2
gerne auch ?name1=value1;name2=value2Das setzt voraus, dass man sein PHP richtig konfiguriert hat, respektive dazu überhaupt in der Lage ist.
Die php.ini-Direktive arg_separator.input muss dazu angepasst werden, was aber nur außerhalb von PHP-Scripten geschehen kann. Denn das Parsen des Querystrings erfolgt, bevor die Steuerung an das PHP-Script gegeben wird und dann eine Änderung nicht mehr berücksichtigt werden kann.
In der php.ini sähe das so aus:
arg_separator.input = ";&"
Damit kann PHP sowohl ; als auch & als Trennzeichen nehmen. Das & wird weiterhin benötigt, denn den Browsern ist schlecht abzugewöhnen, dass sie beim Querystring-Erstellen aus Formulardaten das & als Trennzeichen nehmen.
Lo!
-
-
-
Hi!
An einer bestimmten Stelle werden per URL Parameter übergeben in der Form
Wie geneu kommen die denn dahin? Besteht für den Empfänger Klarheit oder darf der die Kodierung erraten? So unspezifisch gefragt, kann ich dich erst einmal nur auf SELFHTML-Wiki Themen:Zeichencodierung verweisen, da speziell auf den Abschnitt Webserver.
Aber in den Browsern kommt der Query-String unterschiedlich an. Im IE wird « als « und im FF als « angezeigt. Ich dachte eigentlich, dass die Entities überall gleich konvertiert werden.
Weiß jemand eine einfache Antwort, warum das so ist und ob ich das vermeiden kann?Einfache Antworten auf komplexe Probleme sind nicht selten falsch oder unzureichend. Bei Webanwendungen spielen mehrere Systeme Hand in Hand und jeder muss seinem Nachfolger mitteilen, welche Kodierung verwendet wird und manchmal auch seinen Vorgänger darum bitten, eine bestimmte Kodierung zu verwenden. Klingt einfach, aber der Teufel steckt in den vielen Details.
Wenn du mit Entitys hantierst, hast du schon einen Fehler gemacht. Wenn du UTF-8 verwendest, benötigst du keine Entitys mehr, weil alle Zeichen direkt kodiert werden können. (Lediglich die HTML-eigenen Zeichen bilden aufgrund des HTML-Kontextes eine Ausnahme.) Weitere Fehler sind möglicherweise auch nich drin, aber um konkret zu sagen, was du vermeiden sollst, musst du konkret zeigen, was du machst. Auf das Wesentliche reduzierte aber nachvollziehbare Beispiele wären nciht schlecht.
Lo!
-
Hallo,
die Frage war, woran es liegen kann, dass FF und IE in meinem Fall unterschiedliche Ergebnisse bringen. Also noch einmal gaaaanz langsam:
Mein PHP-Programm auf das Problem reduziert. Klar, hier wird kein DOCTYPE oder xmlns definiert, das interessiert nicht, und die Seite ist so auch nicht valide, aber das ist jetzt mal vollkommen egal, das Problem taucht immer auf.
<?php if ($_GET["param"] == "") print "<script type='text/javascript'>window.open('?param=«eins» «zwei»', '_self');</script>"; print $_GET["param"]; ?>FF gibt aus: «eins» «zwei»
IE gibt aus: «eins» «zwei»Warum ist das so? Das ist jetzt so einfach beschrieben, dass wirklich jeder verstehen muss und einfach mit Copy and Paste nachvollziehen kann.
Gruß,
keyboarder
-
Hi!
Mein PHP-Programm auf das Problem reduziert. Klar, hier wird kein DOCTYPE oder xmlns definiert, das interessiert nicht, und die Seite ist so auch nicht valide, aber das ist jetzt mal vollkommen egal, das Problem taucht immer auf.
Und welche Zeichenkodierung liegt vor? Soll der Browser das erraten oder willst du ihm das nicht lieber doch mitteilen?
Warum ist das so?
Weil die Browser anscheinend unterschiedliche Ergebnisse beim Raten erhalten.
Lo!
-
Warum ist das so? Das ist jetzt so einfach beschrieben, dass wirklich jeder verstehen muss und einfach mit Copy and Paste nachvollziehen kann.
Auf wenn es keine einfache Antwort gibt, ich versuchs trotzdem:
[...] das interessiert nicht, und [...] das ist jetzt mal vollkommen egal [...]
Und weil dir auch die kontextgerechte Behandlung und die Zeichenkodierung egal ist, ist es den Browsern halt auch egal und sie nehmen deren Standard her oder raten einfach.
-
Die Vorgabe bei den Abarbeitung von URL-Parametern ist in beiden Browsern unterschiedlich. Wenn Du keine Codierung vorgibst, gibt es keine Garantie, wie es hinten rauskommt.
shi-ko-ko
-
Hi,
Die Vorgabe bei den Abarbeitung von URL-Parametern ist in beiden Browsern unterschiedlich.
Nein, das Verhalten bei in URLs nicht zulässigen Zeichen ist in den Browsern unterschiedlich.
Aber das schrieb ich ja schon, daß die URL nicht korrekt ist.cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Ok, danke, das ist die Antwort, die ich suchte.
Danke,
keyboarder
-
Ok, danke, das ist die Antwort, die ich suchte.
Meinst du mit "die Antwort" diese hier?
Aber das schrieb ich ja schon, daß die URL nicht korrekt ist.
Du bist komisch. SCNR
-
Nein, sondern dass die Browser defaultmäßig unterschiedlich auf URL-Parameter reagieren. Das genügt meinem Chef und für mich ist das Problem erledigt.
Gruß, keyboarder
-
Nein, sondern dass die Browser defaultmäßig unterschiedlich auf URL-Parameter reagieren. Das genügt meinem Chef und für mich ist das Problem erledigt.
Wobei sich das Problem auch einfach lösen liesse, wenn man das richtige macht, dazu müßte man aber auch das Falsche Wissen.
Struppi.
-
Hi,
Nein, sondern dass die Browser defaultmäßig unterschiedlich auf URL-Parameter reagieren.
Wie oft denn noch? Die Browser reagieren unterschiedlich auf inkorrekte URLs.
Die Quote-Zeichen (« und ») dürfen nicht in einer URL vorkommen.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-
-
-
Hi!
Die Vorgabe bei den Abarbeitung von URL-Parametern ist in beiden Browsern unterschiedlich.
Nein, das Verhalten bei in URLs nicht zulässigen Zeichen ist in den Browsern unterschiedlich.
Aber das schrieb ich ja schon, daß die URL nicht korrekt ist.Im konkreten Fall liegt es weniger an der URL selbst, sondern an der nicht vorhandenen Angabe zur Zeichenkodierung des HTML-Dokuments. Zumindest konnte ich das Problem sehr gut nachvollziehen, und es war in beiden Browsern weg, als ich eine charset-Angabe hinzufügte. Die Unterschiede wirkten sich nicht nur auf die URL-Zeile des Browsers aus. Als ich in seinem Beispiel das Javascript-Window-Open durch einen einfachen Link ersetzte, zeigten sich und verschwanden die Unterschiede ebenso.
Dem Wert eine URL-Kodierung zukommen zu lassen löst anscheinend auch das Problem, weil dieser Vorgang von PHP stets auf gleiche Weise vorgenommen wird und kein browserindividuelles Raten dabei ist. Das Ergebnis ist dann eine ASCII-kompatible Zeichenfolge, die die Browser unberührt lassen. Nicht gelöst bleibt dadurch jedoch die höchstwahrscheinlich generell fehlende Angabe zur Zeichenkodierung.
Zu einer optimalen Lösung gehören also mindestens diese drei Schritte:
- Entitys weglassen, weil sie wegen UTF-8 nicht benötigt werden (Ausnahmen: HTML-eigene Zeichen und besondere Whitespace-Zeichen (z.B. , ­))
- Zeichenkodierung der HTML-Dokumente in Richtung Browser mitteilen
- URL-Daten kontextgerecht behandeln
Lo!
-
Zu einer optimalen Lösung gehören also mindestens diese drei Schritte:
- Entitys weglassen, weil sie wegen UTF-8 nicht benötigt werden (Ausnahmen: HTML-eigene Zeichen und besondere Whitespace-Zeichen (z.B. , ­))
Und auch Zeichen die schwer unterscheiden kann - z.B. das Minus-Zeichen, den Gedankenstrich oder einen Bindestich.
-
-
-
-
Hi,
die Frage war, woran es liegen kann, dass FF und IE in meinem Fall unterschiedliche Ergebnisse bringen.
Weil *du* es versäumt hast, die Daten *korrekt* zu übergeben.
Also noch einmal gaaaanz langsam:
Ja, lies die Antworten noch mal gaaanz langsam.
Und so oft, wie du brauchst, um sie zu verstehen.Warum ist das so?
Das wurde dir bereits erklärt.
Das ist jetzt so einfach beschrieben, dass wirklich jeder verstehen muss und einfach mit Copy and Paste nachvollziehen kann.
Wir haben kein Problem, deinen Fehler nachzuvollziehen; wir haben dir deutlich gesagt, was du falsch machst.
Wenn du das nicht verstanden hast, dann frage bitte vernünftig nach.
Aber stelle es bitte nicht so hin, als ob das Verständnisproblem auf unserer Seite liegen würde.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
-