Firefox 3: Chaos mit charsets
0 
MudGuard
0 0 1 
Gunnar Bittersmann
0 1 1 0 Gunnar Bittersmann
0 UTF-8
0 Gunnar Bittersmann
0 
Beat
2
0
0
0
Firefox 3: Chaos mit charsets
AugeHallo erstmal,
ich maskiere die Sonderzeichen in html nicht und arbeite hier sowohl mit iso-charsets, als auch mit utf-8 (beides im meta-tag angegeben). Firefox 3 geruht nun, die Sonderzeichen zu vermurksen: Unter (Debian)Linux werden die Umlaute (z.B.) bei iso-codierten Dateien erst dann korrekt angezeigt, wenn per Menü trotzdem explizit utf-8 als Zeichensatz angewählt wird. Unter Windows (xp) ist es genau umgekehrt: Umlaute in utf-files werden nur richtig angezeigt, wenn vorher beim Firefox iso-x angegeben wird.
Was wäre da zu tun?
Grüße
ben
-
Hi,
ich maskiere die Sonderzeichen in html nicht und arbeite hier sowohl mit iso-charsets, als auch mit utf-8 (beides im meta-tag angegeben). Firefox 3 geruht nun, die Sonderzeichen zu vermurksen: Unter (Debian)Linux werden die Umlaute (z.B.) bei iso-codierten Dateien erst dann korrekt angezeigt, wenn per Menü trotzdem explizit utf-8 als Zeichensatz angewählt wird. Unter Windows (xp) ist es genau umgekehrt: Umlaute in utf-files werden nur richtig angezeigt, wenn vorher beim Firefox iso-x angegeben wird.
Was wäre da zu tun?Den Content-Type header untersuchen, ob der das jeweils korrekte Encoding angibt, und falls nicht, dies korrigieren.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
Kann es sein, dass Du die ISO-Zeichen in UTF-8-Format gespeichert hast und umgekehrt? Grundsätzlich ist es immer empfehlenswert, alle Sonderzeichen in entsprechende HTML-Entities umzusetzen - eine entsprechende Such- und Ersetzfunktion ist schnell geschrieben.
Gruß, LX
--
RFC 1925, Satz 6: Es ist einfacher, ein Problem zu verschieben (...), als es zu lösen.-
Moin!
Kann es sein, dass Du die ISO-Zeichen in UTF-8-Format gespeichert hast und umgekehrt?
Es ist jedenfalls festzustellen, dass da irgendwas vermurkst ist - außerdem ist das Meta-Tag ja nur in zweiter Instanz entscheidend für die Auswahl der Zeichencodierung, primär dafür zuständig ist der entsprechende HTTP-Header. Wenn der nicht stimmt bzw. andere Werte angibt, ist Chaos programmiert.
Der W3C-Validator wird sowas aber, sofern man ihm die Online-URL der Seite gibt, anmeckern.
Grundsätzlich ist es immer empfehlenswert, alle Sonderzeichen in entsprechende HTML-Entities umzusetzen - eine entsprechende Such- und Ersetzfunktion ist schnell geschrieben.
Nein, da würde ich widersprechen wollen. Es ist grundsätzlich empfehlenswert, sich auf genau ein Encoding festzulegen und das dann ohne Entities auf allen Seite durchzuziehen. Nur in Sonderfällen besteht eine der möglichen Lösungen darin, dem Umkodieren zu entgehen, indem Entities verwendet werden. Das funktioniert aber eigentlich nur dann 100% sauber, wenn die einzige Datenrichtung vom Server zum Browser ist - also ohne irgendwelche Formulare, die Daten auch wieder zurücksenden sollen.
- Sven Rautenberg
-
Hallo!
»» Grundsätzlich ist es immer empfehlenswert, alle Sonderzeichen in entsprechende HTML-Entities umzusetzen - eine entsprechende Such- und Ersetzfunktion ist schnell geschrieben.
Nein, da würde ich widersprechen wollen. Es ist grundsätzlich empfehlenswert, sich auf genau ein Encoding festzulegen und das dann ohne Entities auf allen Seite durchzuziehen. Nur in Sonderfällen besteht eine der möglichen Lösungen darin, dem Umkodieren zu entgehen, indem Entities verwendet werden. Das funktioniert aber eigentlich nur dann 100% sauber, wenn die einzige Datenrichtung vom Server zum Browser ist - also ohne irgendwelche Formulare, die Daten auch wieder zurücksenden sollen.
Das trifft nur dann zu, wenn man die volle Kontrolle darüber hat, was der Server an Zeichensätzen ausliefert - und aus eigener, leidvoller Erfahrung kann ich bestätigen, dass man sich das nicht immer aussuchen kann. Außerdem ist es in jedem Fall ratsam, Formulareingaben in mehrerer Hinsicht serverseitig zu validieren bzw. zu filtern, insbesondere auch in Bezug auf den Zeichensatz, da sonst Verarbeitungsfehler auftauchen können.
Gruß, LX
--
RFC 1925, Satz 1: Es muss funktionieren.-
@@LX:
Das trifft nur dann zu, wenn man die volle Kontrolle darüber hat, was der Server an Zeichensätzen ausliefert
Die hat man. Der Zeichensatz eines jeden HTML-Dokuments ist das Universal Character Set (UCS)/Unicode.[QA-DOC-CHARSET]
Möchtest du in „Zeichencodierung für Dummies“ [QA-WHAT-IS-ENCODING] den Unterschied zwischen Zeichensatz und Zeichencodierung nachlesen? ;-)
und aus eigener, leidvoller Erfahrung kann ich bestätigen, dass man sich das nicht immer aussuchen kann.
Dann sollte man das Problem nicht verschieben (und sich damit haufenweise neue Probleme einhandeln), sondern lösen – und zwar an der Wurzel. Ggfs. ist ein Austausch mit oder des Hosters erforderlich.
Oder willst du dich auf [RFC1925] (6) berufen? Dessen Erscheinungsdatum hast du im Auge? ;-)
Live long and prosper,
Gunnar--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau) -
Moin!
»» Nein, da würde ich widersprechen wollen. Es ist grundsätzlich empfehlenswert, sich auf genau ein Encoding festzulegen und das dann ohne Entities auf allen Seite durchzuziehen. Nur in Sonderfällen besteht eine der möglichen Lösungen darin, dem Umkodieren zu entgehen, indem Entities verwendet werden. Das funktioniert aber eigentlich nur dann 100% sauber, wenn die einzige Datenrichtung vom Server zum Browser ist - also ohne irgendwelche Formulare, die Daten auch wieder zurücksenden sollen.
Das trifft nur dann zu, wenn man die volle Kontrolle darüber hat, was der Server an Zeichensätzen ausliefert - und aus eigener, leidvoller Erfahrung kann ich bestätigen, dass man sich das nicht immer aussuchen kann.
Wenn der Server unabänderliche Vorgaben macht, dann hat man sich dem entweder anzupassen (wie ich schon schrieb: Auf ein Encoding festlegen und das durchziehen), oder man sucht sich einen Server, der weniger restriktiv ist. Egal was man tut: EIN Encoding wählen, und dabei bleiben.
Außerdem ist es in jedem Fall ratsam, Formulareingaben in mehrerer Hinsicht serverseitig zu validieren bzw. zu filtern, insbesondere auch in Bezug auf den Zeichensatz, da sonst Verarbeitungsfehler auftauchen können.
Diese Validierung ist hinsichtlich des Encodings nur leider sehr schwierig. Natürlich kann man versteckte Testfelder ins Formular packen, und deren real vom Browser gesendeten Wert mit dem ordnungsgemäßen Erwartungswert vergleichen - das einzige, was man dabei aber rausfindet ist, ob was kaputt gegangen ist, aber nicht, was. Und wenn man sich die falschen Textwerte auswählt, findet man gar nichts heraus.
Und von einer grundsätzlicheren Warte aus gesehen: Welchen Sinn sollte es haben, in einem Formular einer ISO-8859-1-Seite einen Versuch zu unternehmen, UTF-8 eingeben und versenden lassen zu wollen. Wenn der Server zu UTF-8 beim Seitengenerieren schon nicht in der Lage ist, wird er beim Verarbeiten noch größere Schwierigkeiten bekommen. Insofern klingt es unsinnig, hier durch Entitie-Einbindung Zeichen auszusenden, die niemals wieder den Weg zurück zum Server finden können.
- Sven Rautenberg
-
-
Moinmoin,
Es ist jedenfalls festzustellen, dass da irgendwas vermurkst ist -
Habe mittlerweile via google gelernt, dass es bei der Umstellung von iso auf utf auf mehreren Ebenen Probleme geben kann. Schätze, es wird hier wohl daran liegen, dass ich unter Linux einen anderen Editor benutze als unter xp.
Bei solchen Komplexitäten werde ich hier wohl die Finger von der Umstellung lassen, denn bei einem Projekt ohne alle internationale Ambitionen ist sehr viel wichtiger, dass auch ältere Files und vor allem auch Perl-Scripts weiterhin problemlos funktionieren.Nein, da würde ich widersprechen wollen.
Ich auch- habe nämlich wenig Lust, mir die Datenbank mit html zuzumüllen (oder aber die Scripts mit umständlicher Escaperei aufzublähen)
THX @all
hat zur Klärung beigetragen :-)
ben
-
-
@@LX:
Grundsätzlich ist es immer empfehlenswert, alle Sonderzeichen in entsprechende HTML-Entities umzusetzen
Das ist grundsätzlich Unsinn.
„Es ist fast immer besser, eine Zeichencodierung zu benutzen, die es erlaubt, die Zeichen in ihrer normalen Form zu verwenden, anstatt Zeichen-Entity-Referenzen oder numerische Zeichenreferenzen zu verwenden.“ [QA-ESCAPES]
Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden. Und den Server dies angeben zu lassen. [QA-CHANGING-ENCODING]
Live long and prosper,
Gunnar--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau)-
Siehe meine Antwort an Sven.
Gruß, LX
--
RFC 1925, Satz 6: Es ist einfacher, ein Problem zu verschieben (...), als es zu lösen. -
Hi Gunnar,
Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
leider nein. Ich gehe sogar soweit zu sagen, wennn die Seite nicht wirklich internationalisiert sein soll oder mit exotischen Zeichen zu rechnen ist, sollte man beim guten alten ISO verbleiben, sofern man PHP nutzt.
Warum? Wegen der Ineffizienz der mb_*** Funktionen
Dermassen langsam....
http://forum.de.selfhtml.org/archiv/2009/3/t184875/#m1226300
Pete
-
Hi,
Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
leider nein. Ich gehe sogar soweit zu sagen, wennn die Seite nicht wirklich internationalisiert sein soll oder mit exotischen Zeichen zu rechnen ist, sollte man beim guten alten ISO verbleiben, sofern man PHP nutzt.
Wieso versuchst du einen allgemeinen Ratschlag zu verneinen, in dem du eine sehr spezielle Bedingung einführst?
Warum? Wegen der Ineffizienz der mb_*** Funktionen
Dermassen langsam....
Da dürften mit PHP 6 auch Fortschritte zu erwarten sein.
Darüber hinaus macht sich das wohl erst bemerkbar, wenn man mit wirkliche grossen Textmengen jongliert. Bei der privaten Durchschnittsseite mit 'nem Formulärchen für Gästebuch oder Kommentare wohl eher nicht der Fall; und wenn wirklich grosse Textmengen durchsucht/manipuliert werden sollen, dann frage ich mich, in wie fern das überhaupt eine in der Praxis sinnvoll brauchbare Anwendung darstellen kann, wenn man sich dann hinsichtlich der verwendbaren Zeichen derart einschränkt - für mich erst mal auch nur in Sonderfällen denkbar (und damit wieder unbrauchbar zur Widerlegung eines "grundsätzlichen" Ratschlags).
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Hi,
Wieso versuchst du einen allgemeinen Ratschlag zu verneinen, in dem du eine sehr spezielle Bedingung einführst?
»»
Mit spezieller Bedingung meinst du PHP? Denke das kann man heutzutage wohl schon als Standard deklarieren oder meinst du nicht?
»» Warum? Wegen der Ineffizienz der mb_*** Funktionen
»»
Da dürften mit PHP 6 auch Fortschritte zu erwarten sein.Kann sein, hilft im Moment aber nichts.
Darüber hinaus macht sich das wohl erst bemerkbar, wenn man mit wirkliche grossen Textmengen jongliert.....
Von wegen, teste es mal bei einer Durchschittsseite. Ein paar Stringoperationen die in fast jeder PHP Seite vorkommen mit mb_*** gemacht und du siehst was ich meine.
Pete
-
Hallo,
Mit spezieller Bedingung meinst du PHP? Denke das kann man heutzutage wohl schon als Standard deklarieren oder meinst du nicht?
Dies kann ich verneinen.
Zweifels ohne hat sich PHP sehr sehr weit von seinen Anfangstagen etnwickelt und für sehr viele Anwendungen geeignet. Ich möchte also PHP keineswegs seine Möglichkeiten absprechen, die sind mir bewusst. Aber PHP ist noch nicht in dem Status Industrie-Standard zu sein (auch dann nicht, wenn einige CMS-Hersteller dies so gerne behaupten).Grüße
Thomas-
Hi,
»» Mit spezieller Bedingung meinst du PHP? Denke das kann man heutzutage wohl schon als Standard deklarieren oder meinst du nicht?
»»Dies kann ich verneinen.
Zweifels ohne hat sich PHP sehr sehr weit von seinen Anfangstagen etnwickelt und für sehr viele Anwendungen geeignet. Ich möchte also PHP keineswegs seine Möglichkeiten absprechen, die sind mir bewusst. Aber PHP ist noch nicht in dem Status Industrie-Standard zu sein (auch dann nicht, wenn einige CMS-Hersteller dies so gerne behaupten).ob das jetzt etwas mit CMS zu tun hat...
Mir fehlt leider eine Statistik, aber ich schätze mal 90% aller dynamischen Webseiten werden mit PHP betrieben, mal von Megaprojekten wie Google oder dergleichen abgesehen. Asp bildet eher die Aussnahme und noch weniger ist das früher so beliebte CGI.
Wenn man das dann nicht als Standard bezeichnen kann, ja was dann. Wäre so als wenn man sagen würde Windows wäre kein Standard für OS. Und wenn sich die Linuxgemeinde noch so auf den Kopf stellt, es ist so ;-)
Pete
-
Hallo
»» »» Mit spezieller Bedingung meinst du PHP? Denke das kann man heutzutage wohl schon als Standard deklarieren oder meinst du nicht?
»» »»ChrisB meinte wohl eher den Spezialfall der Anwendung der mb_*-Funktionen. Den als Generalargument gegen UTF-8 und für ISO-irgendwas anzuwenden, ist zumindest grenzwertig.
Mir fehlt leider eine Statistik, aber ich schätze mal 90% aller dynamischen Webseiten werden mit PHP betrieben, mal von Megaprojekten wie Google oder dergleichen abgesehen. Asp bildet eher die Aussnahme und noch weniger ist das früher so beliebte CGI.
Ob das nun 90% sind sei dahingestellt, aber was CGI ist, ist dir offensichtlich nicht klar. Schließlich kann auch PHP 'als CGI daherkommen' (um es mal volkstümlich auszudrücken).
Wenn man das dann nicht als Standard bezeichnen kann, ja was dann. Wäre so als wenn man sagen würde Windows wäre kein Standard für OS. Und wenn sich die Linuxgemeinde noch so auf den Kopf stellt, es ist so ;-)
Der Bereich Desktop, für den auch ich das als gegeben ansehe, ist nicht allein. In anderen Bereichen würde ich diesen Schluss aus dem Windows vs. Linux (eigentlich vs. irgendeinOS) -Vergleich definitiv verneinen.
Tschö, Auge
-
Hi,
»» »» »» Mit spezieller Bedingung meinst du PHP? Denke das kann man heutzutage wohl schon als Standard deklarieren oder meinst du nicht?
»» »» »»ChrisB meinte wohl eher den Spezialfall der Anwendung der mb_*-Funktionen. Den als Generalargument gegen UTF-8 und für ISO-irgendwas anzuwenden, ist zumindest grenzwertig.
Thomas sieht das aber eher so wie ich dachte(und eigentlich immer noch denke), dass Chris das so meint.
»» ....aber ich schätze mal 90% aller dynamischen Webseiten werden mit PHP betrieben...»»
Ob das nun 90% sind sei dahingestellt, aber was CGI ist, ist dir offensichtlich nicht klar. Schließlich kann auch PHP 'als CGI daherkommen' (um es mal volkstümlich auszudrücken).
»»
Ich sagte ja bereits eine Statistik dazu kann ich nicht finden. Und was CGI ist, ist mir vollkommen klar, war ja leider vor PHP auch dazu gezwungen das zu verwenden, und ich habe es gehasst. Das PHP auf CGI aufgesetzt werden kann und auch oft so ist anstatt Modul, ist auch klar.
Was ich aber vielmehr damit meint ist, wenn man früher ein Forum, Gästebuch, Formmailer, usw.... haben wollte ging es nur mit CGI, heute ist das meisstens PHP. Und wenn dann im Hintergrund das Ganze auf CGI aufgesetzt ist, so ist das nebensächlich, da sich der Seitenersteller nicht drum kümmern muss.
Der Bereich Desktop, für den auch ich das als gegeben ansehe, ist nicht allein. In anderen Bereichen würde ich diesen Schluss aus dem Windows vs. Linux (eigentlich vs. irgendeinOS) -Vergleich definitiv verneinen.
Natürlich ist der Serverbereich etwas anderes, aber nicht umsonst zahlt MS seine Millionenstrafen wegen Monopolverletzungen, weil es eben ein Monopol ist. Somit Standard für den Endverbraucher sozusagen.
Gruss
Pete-
Hallo
»» »» »» »» Mit spezieller Bedingung meinst du PHP? ...
»»
»» ChrisB meinte wohl eher den Spezialfall der Anwendung der mb_*-Funktionen. ...Thomas sieht das aber eher so wie ich dachte(und eigentlich immer noch denke), dass Chris das so meint.
Das wird nur er selbst klären können, wenn er denn will.
Was ich aber vielmehr damit meint ist, wenn man früher ein Forum, Gästebuch, Formmailer, usw.... haben wollte ging es nur mit CGI, heute ist das meisstens PHP. Und wenn dann im Hintergrund das Ganze auf CGI aufgesetzt ist, so ist das nebensächlich, da sich der Seitenersteller nicht drum kümmern muss.
Um CGI musste sich der Seitenersteller auch früher nicht kümmern, außer als Teil des Verzeichnisnamens, unter dem seine Skripte typischerweise zu laufen hatten (bzw. im Falle des Falles auch heute noch haben).
Tschö, Auge
-
Hi,
Um CGI musste sich der Seitenersteller auch früher nicht kümmern,...»»
Na gut wenn du jedes Wort auf die Goldwaage legen willst, eben CGI-Scripte;-)
Pete
-
Hallo
»» Um CGI musste sich der Seitenersteller auch früher nicht kümmern,...»»
Na gut wenn du jedes Wort auf die Goldwaage legen willst, eben CGI-Scripte;-)
Um des Ausscheidens getrockneter Weintrauben willen ;-):
Skripte in welcher Programmiersprache auch immer, die die *CGI-Schnittstelle* benutzen. Das kann das wahrscheinlich von dir gemeinte Perl sein, aber auch PHP oder eben irgendeine andere Sprache.
Tschö, Auge
-
-
Hi,
»» ChrisB meinte wohl eher den Spezialfall der Anwendung der mb_*-Funktionen. ...
Thomas sieht das aber eher so wie ich dachte(und eigentlich immer noch denke), dass Chris das so meint.
Das wird nur er selbst klären können, wenn er denn will.
Wenn ihr drauf besteht :-)
Ja, mit der Bemerkung an dieser Stelle zielte ich tatsächlich auf die Verwendung von PHP ab.
Wie von anderen auch schon erwähnt, hat die Verwendung von UTF-8 grosse Vorteile vor allem dann, wenn es um den Datenaustausch zwischen verschiedenen Systemen geht, bzw. man handelt sich schnell ziemlich arge Probleme ein, wenn jeder der daran Beteiligten sein eigenes Süppchen kocht, was die Zeichenkodierung angeht.
Und deshalb ist der allgemeine Ratschlag, so wie er von Gunnar kam - heutzutage immer UTF-8 zu verwenden, wenn möglich - m.E. natürlich nicht unter Verweis auf eine bestimmte serverseitige Scriptsprache (für die es noch dazu zahlreiche Alternativen gibt) abzulehnen, die damit in manchen Szenarien Probleme bereiten kann oder "langsam" ist. Wenn diese Sprache Probleme verursacht, dann ist *sie* auszuwechseln (bzw. an ihr nachzubessern) - aber nicht UTF-8 als bewährtes Mittel zum Austausch von Daten unter verschiedensten Systemen (die andernfalls alle ihren eigenen "Dolmetscher" einschalten müssten, der zum Teil sogar noch zu zusätzlichem Verlust an Daten führen kann).MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.-
Hi,
....eine bestimmte serverseitige Scriptsprache (für die es noch dazu zahlreiche Alternativen gibt)....
Welche Alternativen wären das?
Es gibt für die Masse an Webseitenerstellern keine geeignete Alternative. Wer sich mit komplizierten CGI/Perl-Scripten herumschlagen kann und will, bitteschön, aber bestimmt ist das ein nicht zu beachtender Minderheitsanteil.
Vielleicht wäre Ruby noch möglich, aber der Umstieg wäre schwierig und für die meissten unmotiviert, wobei jede Scriptsprache ihre Macken hat, also Teufel mit Belzebub austreiben, wäre dann auch keine Alternative.
die damit in manchen Szenarien Probleme bereiten kann oder "langsam" ist. Wenn diese Sprache Probleme verursacht, dann ist *sie* auszuwechseln (bzw. an ihr nachzubessern)......
Keine Frage , nur um bei dem Beispiel mit Gunnar zu bleiben, solange ein Programm oder Browser oder sonstwas ein Problem hat muss man sich diesem Problem beugen bzw. versuchen es zu umgehen, denn die Abhilfe dauert meisstens.
Und bei UTF-8 gibt es eben noch sehr häufig Probleme nicht nur die mb_*** Funktionen von PHP. Also sage ich mir doch lieber ich bleibe bei altbewährtem, bis endlich vernünftig mit UTF-8 gearbeitet werden kann, zumindest solange ich die Wahl habe.
Gruss
Pete-
Hallo
Es gibt für die Masse an Webseitenerstellern keine geeignete Alternative. Wer sich mit komplizierten CGI/Perl-Scripten herumschlagen kann und will, bitteschön, aber bestimmt ist das ein nicht zu beachtender Minderheitsanteil.
ich benutze Perl selbst zwar auch nicht, aber ich könnte, sprich: mein Hoster bietet Interpreter für PHP *und* Perl (und auch Python) an.
»» die damit in manchen Szenarien Probleme bereiten kann oder "langsam" ist. Wenn diese Sprache Probleme verursacht, dann ist *sie* auszuwechseln (bzw. an ihr nachzubessern)......
Keine Frage , nur um bei dem Beispiel mit Gunnar zu bleiben, solange ein Programm oder Browser oder sonstwas ein Problem hat muss man sich diesem Problem beugen bzw. versuchen es zu umgehen, denn die Abhilfe dauert meisstens.
Um bei der Praxis zu bleiben: Bei mir sind die Skripte mit UTF-8 gespeichert, bei der Verbindung mit dem Datenbankserver gebe ich UTF-8 als zu benutzende Kodierung vor (alle Daten werden also als UTF-8 gespeichert und gelesen) und der Webserver liefert UTF-8 aus. Das vorzugeben, dauerte zwar einige Stunden (bestehende Skripte umstellen, die Anweisungen für den DB-Server einfügen, im Bedarfsfall bereits gespeicherte Daten umkodieren, der Webserver konnte das geforderte schon), aber im Nachhinein hat sich die Arbeit bei allen Projekten, die ich so angepasst habe, gelohnt. Es gibt keine Unterbrechung in der Kette und somit keine Probleme.
Tschö, Auge
-
Hi,
...Es gibt keine Unterbrechung in der Kette und somit keine Probleme....
Wenns denn immer so einfach wäre. Lassen wir die PHP-Problematik mal beiseite. Die grossen Suchmaschinen haben oft das Dilemma, dass durch den Fremdcontent ein Mix aus ASCII UTF-8 und was weiss ich entstehen, so sehe ich allzu oft bei einigen Einträgen Hieroglyphen auf dem Schirm. Genau so geht es mir bei den APIs der Suchmaschinen, aber damit muss ich wohl leben wegen International.
Es gibt auch noch zig anderer beispiele, allein das Forum hier ist voll davon. Aber es ist auch nur eine Frage der Zeit bis UTF-8 alleingültig ist, und somit gebe ich euch natürlich recht umzusteigen wenn man mit den momentanen Übergangsproblemen leben kann.
Pete
-
Es gibt auch noch zig anderer beispiele, allein das Forum hier ist voll davon. Aber es ist auch nur eine Frage der Zeit bis UTF-8 alleingültig ist, und somit gebe ich euch natürlich recht umzusteigen wenn man mit den momentanen Übergangsproblemen leben kann.
UTF-8 wird sicher einige Fragen beantworten und viele neue Fragezeichen aufwerfen. Das macht aber nichts. Schliesslich wird man sich daran gewöhnen dass viele Bytes zum Frag uh.. Wege nach Rom führen.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi,
UTF-8 wird sicher einige Fragen beantworten und viele neue Fragezeichen aufwerfen. Das macht aber nichts. Schliesslich wird man sich daran gewöhnen dass viele Bytes zum Frag uh.. Wege nach Rom führen.
"UTF-8: Ein bis vier Byte führen zum Zeichen."
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak. -
UTF-8 wird sicher einige Fragen beantworten und viele neue Fragezeichen aufwerfen. Das macht aber nichts. Schliesslich wird man sich daran gewöhnen dass viele Bytes zum Frag uh.. Wege nach Rom führen.
*gg* Das hast du schön gesagt.
Mathias
-
-
Hi,
Die grossen Suchmaschinen haben oft das Dilemma, dass durch den Fremdcontent ein Mix aus ASCII UTF-8 und was weiss ich entstehen, so sehe ich allzu oft bei einigen Einträgen Hieroglyphen auf dem Schirm.
Wohl nur dann, wenn die *Quelle* versäumt mitzuteilen, welche Kodierung sie verwendet (bzw. dabei "lügt").
Aber andersherum wird ein Schuh draus - wie viel mehr Hieroglyphen würden wir zu sehen bekommen, wenn eine Suchmaschine, die Seiten aus der ganzen Welt indiziert, ihre Ergebnisse in einer Kodierung ausliefern würde, die auf einen speziellen Sprachraum zugeschnitten ist, wie es bspw. mit denen der ISO-8859-Familie der Fall ist ...?
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak. -
Hallo
»» ...Es gibt keine Unterbrechung in der Kette und somit keine Probleme....
Die grossen Suchmaschinen haben oft das Dilemma, dass durch den Fremdcontent ein Mix aus ASCII UTF-8 und was weiss ich entstehen, so sehe ich allzu oft bei einigen Einträgen Hieroglyphen auf dem Schirm. Genau so geht es mir bei den APIs der Suchmaschinen, aber damit muss ich wohl leben wegen International.
Das liegt aber entweder daran, dass die Autoren verschiedene Kodierungen vermischen, obwohl *ein* Dokument nur *eine* Kodierung haben kann (Unterbrechung der Kette), oder die bei dir verwendeten Schriftarten für bestimmte Codes keine Zeichen anbieten.
Folge in beiden Fällen: Fragezeichen oder leere Kästchen mitten im Text.Tschö, Auge
-
Hallo
Erst lesen, dann abschicken:
Folge in beiden Fällen: Fragezeichen oder leere Kästchen mitten im Text.
... oder halt falsche Zeichen.
Tschö, Auge
-
-
-
-
-
-
-
-
-
Hallo,
Mir fehlt leider eine Statistik, aber ich schätze mal 90% aller dynamischen Webseiten werden mit PHP betrieben,
das muss ich ein wenig lachen, wobei du in gewisser hinsicht recht hast. Viele kleine bis einige mittlere Webseiten mutzen PHP.
Wirklich große dagegen recht selten.Wenn man das dann nicht als Standard bezeichnen kann, ja was dann.
Java.
Daraus/davon: JSP, Grails & Groovy (und/mit Frameworks wie Hibernate, Spring, Struts)Man erkennt es mittlerweile nicht mehr immer an Dateiendungen von Webpages, um welche Technologie sich dahinter verbirgt.
Grüße
Thomas
-
-
-
-
-
@@Pete:
»» Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
leider nein.Na und ob.
Ich gehe sogar soweit zu sagen, wennn die Seite nicht wirklich internationalisiert sein soll oder mit exotischen Zeichen zu rechnen ist, sollte man beim guten alten ISO verbleiben, […]
Sogar fürs Deutsche sind ISO 8859-1 und -15 unbrauchbar: damit lassen sich weder Anführungszeichen noch Gedankenstriche codieren. Unnötig zu erwähnen, dass weder Anführungszeichen noch Gedankenstriche „exotische Zeichen“ sind.
[…] sofern man PHP nutzt.
Warum? Wegen der Ineffizienz der mb_*** FunktionenSollten man in HTML PHP-Probleme lösen? Ich denke nein. Wenn PHP unfähig ist, mit Unicode umzugehen, muss das dort behoben werden.
Live long and prosper,
Gunnar--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau)-
Hi Gunnar,
»» »» Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
»» leider nein.
Na und ob.
Nö ;-)
Sogar fürs Deutsche sind ISO 8859-1 und -15 unbrauchbar: damit lassen sich weder Anführungszeichen noch Gedankenstriche codieren. Unnötig zu erwähnen, dass weder Anführungszeichen noch Gedankenstriche „exotische Zeichen“ sind.
Das ist die andere Seite der Münze. Aber damit kam man ja in den ganzen Jahren gut zurecht.
Sollten man in HTML PHP-Probleme lösen? Ich denke nein. Wenn PHP unfähig ist, mit Unicode umzugehen, muss das dort behoben werden.
Genau so gut könntest du sagen, ich schreibe mein html wie es sein soll, wenn die Browser das anders darstellen muss es von denen behoben werden.
Pete
-
@@Pete:
»» »» »» Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
»» »» leider nein.
»» Na und ob.
Nö ;-)
Doch. ;-)
»» Sogar fürs Deutsche sind ISO 8859-1 und -15 unbrauchbar: damit lassen sich weder Anführungszeichen noch Gedankenstriche codieren. Unnötig zu erwähnen, dass weder Anführungszeichen noch Gedankenstriche „exotische Zeichen“ sind.
»»Das ist die andere Seite der Münze. Aber damit kam man ja in den ganzen Jahren gut zurecht.
„Gut“ ist was anderes. Die Verwendung von '"' als Anführungszeichen verlangt zwingend nach Courier-Schrift.
Genau so gut könntest du sagen, ich schreibe mein html wie es sein soll, wenn die Browser das anders darstellen muss es von denen behoben werden.
Das hat sich sogar schon bis nach Redmond, WA herumgesprochen.
Live long and prosper,
Gunnar--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau)-
„Gut“ ist was anderes. Die Verwendung von '"' als Anführungszeichen verlangt zwingend nach Courier-Schrift.
Tolle RFC.
Kommentar im Anhangmfg Beat
--
/|
<°)))o>< __ / | /|
/__\ _|___/ | ><o(((°>
OvVVvO __ | ><o(((°>
<°)))o>< /v v\/ |
<°)))o>< ^ ^/_/_ ><o(((°>
^^^^/___/
---- ><o(((°>
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
Hallo,
»» »» »» Grundsätzlich ist es immer empfehlenswert, immer UTF-8 zu verwenden.
»» »» leider nein.
»» Na und ob.
Nö ;-)
Ich möchte dir nicht zu nahe treten, aber genau so eine "Hobbybastler-Einstelung" macht das leben eines Programmieres in einer Industrie-Umgebung zur Hölle.
Spitz gesagt: wenn man seine eigene niedliche Webseitchen für Freunde, Family und verirrte Googler pflegt, ist so eine sicht vollkommen OK.
Wenn man aber in einer Umgebung arbeitet, wo Daten aus verschiedenen Quellen (sei es Software, oder Länder, Firmen etc.) ausgetauscht werden, dann ist so eine Einstellung ein tatsächlich mit (viel) Geld beziffernbarer Kostenfaktor.Es ist besser, wenn man sich gleich angewöhnt, so fern ISO-xx nicht zwingend erforderlich ist, mit UTF-8 zu arbeiten.
Grüße
ThomasPS: was PHP betrifft, er ist mittlerweile gut genug solche Sachen zu können, wenn das doch nicht geht, ist nur der Programmierer schlecht.
-
-
Sogar fürs Deutsche sind ISO 8859-1 und -15 unbrauchbar: damit lassen sich weder Anführungszeichen noch Gedankenstriche codieren. Unnötig zu erwähnen, dass weder Anführungszeichen noch Gedankenstriche „exotische Zeichen“ sind.
Tja, lieber Gunnar, jetzt haste mich aber auch endgültig angesteckt mit dem utf-8-Virus. Die letzten Tage hab ich schon überlegt, dass utf-8 spätestens bei meinem Gästebuch fällig ist, könnte ja sein, dass eine meiner ehemaligen (hübschen) Kolleginnen aus Japan da mal aufschlaegt mit ner japanischen Tastatur... naja, den Rest der Site werde ich auch noch umschießen.
Hotte
--
Content-type: text/void
-
-
Moin!
leider nein. Ich gehe sogar soweit zu sagen, wennn die Seite nicht wirklich internationalisiert sein soll oder mit exotischen Zeichen zu rechnen ist, sollte man beim guten alten ISO verbleiben, sofern man PHP nutzt.
Warum? Wegen der Ineffizienz der mb_*** Funktionen
Dermassen langsam....
Man ist ja nicht in jedem Fall gezwungen, die Multibyte-Extension zu benutzen. PHP eignet sich auch ganz prima dazu, einfach nur die Bytes zu externen Verarbeitern durchzureichen, ohne die unicodehaftigkeit begreifen zu müssen.
- Sven Rautenberg
-
-
-
-
hi,
ich maskiere die Sonderzeichen in html nicht und arbeite hier sowohl mit iso-charsets, als auch mit utf-8 (beides im meta-tag angegeben). Firefox 3 geruht nun, die Sonderzeichen zu vermurksen: Unter (Debian)Linux werden die Umlaute (z.B.) bei iso-codierten Dateien erst dann korrekt angezeigt, wenn per Menü trotzdem explizit utf-8 als Zeichensatz angewählt wird. Unter Windows (xp) ist es genau umgekehrt: Umlaute in utf-files werden nur richtig angezeigt, wenn vorher beim Firefox iso-x angegeben wird.
Was wäre da zu tun?Klare Verhältnisse schaffen. Lege per Webserver-Konfig. _einen_ charset fest und dann schauen wir mal weiter. Du kannst das in der .htaccess machen:
AddDefaultCharset UTF-8
oder ISO...
Sofern Du CGI-Scripts am laufen hast, kann die Angabe im header gemacht werden:
Content-type: text/html; charset=UTF-8
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.