utf-8

[gary]

Morgen zusammen,

Ich wollte mal eure Meinung speziell zu der UTF-Codierung hören. Also was meint Ihr: Ist UTF-( eigentlich gut, oder eher böse?

Gruss gary

[gooxsy]

Hi gary,

Ich wollte mal eure Meinung speziell zu der UTF-Codierung hören. Also was meint Ihr: Ist UTF-( eigentlich gut, oder eher böse?

man kann _objektiv_ sagen, daß die Verwendung von utf-8 vorzuziehen ist, also definitiv "gut" ist. Dazu gibt es auch tausende Seiten im Netz. Erst vor kurzem gab es dazu eine interessante Diskussion hier im Forum.

mfG

gooxsy

[gary]

Hi gooxy,

man kann _objektiv_ sagen, daß die Verwendung von utf-8 vorzuziehen ist, also definitiv "gut" ist. Dazu gibt es auch tausende Seiten im Netz. Erst vor kurzem gab es dazu eine interessante Diskussion hier im Forum.

Erst mal Danke für den Link (ja, eine Forumssuche vor dem Posten wäre nicht verkehrt *g*)

Ich Frage, weil ich diesmal eine UTF-8 Codierung erstmals für ein Testprojekt verwendet habe http://www.vam-shop.com/online-journal-ceta.shtml.
Mich "wurmt" nur ein wenig, dass der Validator eine Warnung wegen einer BOM(Byte Order Mark) ausgibt. Er erkennt aber UTF-8. Weisst du zufällig, wie man eine BOM entfernt? Dann müsste die Seite ja fehlerfrei werden.

Grüsse gary

[Christian Seiler]

Hallo gary,

Ich Frage, weil ich diesmal eine UTF-8 Codierung erstmals für ein Testprojekt verwendet habe http://www.vam-shop.com/online-journal-ceta.shtml.
Mich "wurmt" nur ein wenig, dass der Validator eine Warnung wegen einer BOM(Byte Order Mark) ausgibt. Er erkennt aber UTF-8. Weisst du zufällig, wie man eine BOM entfernt? Dann müsste die Seite ja fehlerfrei werden.

Auch mit BOM ist die Seite im Prinzip fehlerfrei, allerdings macht ein BOM in UTF-8 einigen Programmen Probleme, deswegen verzichtet man wirklich besser darauf.

Windows Notepad speichert UTF-8 leider immer nur mit BOM, Du kannst da nichts gegen machen. Bei anderer Software kann man in den Einstellungen festlegen, dass keine BOM verwendet werden soll. Suche mal danach.

Wenn Du's manuell entfernen willst, kannst Du die Datei auch in einem Hex-Editor öffnen und die ersten 3 Bytes entfernen.

Viele Grüße,
Christian

[gary]

Hallo Christian,

Ich habe mal ein wenig auf Google gesucht. Eigentlich ist die BOM gar nicht verkehrt. Es gib Für und Wider, wobei von der Technik her gesehen, in Richtung zukünftige Standards, eher zu einer BOM geraten werden sollte. Lediglich einige ältere Programme machen Probleme.

Soweit ich dass verstanden habe, ist die BOM ein Informationshinweis für das Dateiöffnende Programm: "Achtung, jetzt kommt utf-8!"-vorrausgesetzt das Öffnende Programm kann damit umgehen.

Also im Prinzip was Gutes. Ähnlich nem Doctype, Charset usw...

Ist doch freundlich von der BOM, zu sagen woher es kommt und was es vor hat *g*

Merci und Gruss gary

[Daniel unreg]

Hallo,

Also im Prinzip was Gutes. Ähnlich nem Doctype [...]

Dokumenttypangaben sind nutzlos für das Dokument selbst. Die Tatsache, dass irgendwelche verrückten Browserhersteller meinen, anhand dieser Angabe verschiedene Verarbeitungsmodi für Webseiten zu verwenden ist die lösung zu einem Problem aus einer anderen Zeit.

Die Dokumenttypweiche sollte von den Browserherstellen nochmals überdacht werden.

Gruß

[Auge]

Hallo

Dokumenttypangaben sind nutzlos für das Dokument selbst. Die Tatsache, dass irgendwelche verrückten Browserhersteller meinen, anhand dieser Angabe verschiedene Verarbeitungsmodi für Webseiten zu verwenden ist die lösung zu einem Problem aus einer anderen Zeit.

Aha, du findest es nutzlos, dem darstellenden Programm mitzuteilen, nach welchem der vielen Standards das folgende Dokument aufgebaut ist?

Eine eigenartige Einstellung.

Tschö, Auge

[Daniel unreg]

Hallo

Aha, du findest es nutzlos, dem darstellenden Programm mitzuteilen, nach welchem der vielen Standards das folgende Dokument aufgebaut ist?

Dies ist ja gar nicht der Fall. Du kannst vielleicht HTML-3.2-, HTML-4.01-Transitional und -Strict-Dokumente schreiben, die dem Standard entsprechen. Aber tatsächlich kennt ein Browser nur HTML-Dokumente. Für das darstellende Programm hat die Version und damit die Dokumenttypangabe keinerlei Bedeutung.
Dies gilt auch für XML-Derivate wie SVG und XHTML.

Durch die Dokumenttypangabe bestimmt das darzustellende Programm lediglich, wie nah es sich bei der Darstellung an die vorgegebenen Standards (die in jedem Modus die selben sind) hält.

Ich finde daran nur eigenartig, das die nicht-konformen Modi immernoch so beliebt sind.

Gruß, Daniel

[josh]

Hallo,

Ich finde daran nur eigenartig, das die nicht-konformen Modi immernoch so beliebt sind.

Und das wird besser, wenn man die Doctypes weglässt?

Gruß

[Auge]

Hallo

Ich finde daran nur eigenartig, das die nicht-konformen Modi immernoch so beliebt sind.

Und das wird besser, wenn man die Doctypes weglässt?

Nicht besser, aber es wird. Das Weglassen des Doctype ist geradezu Bedingung für Nichtkonformität und seine häufigen Weglassung wohl auch Grund für letzterer "Beliebtheit".

Tschö, Auge

[Daniel unreg]

Hallo

Und das wird besser, wenn man die Doctypes weglässt?

Nicht besser, aber es wird. Das Weglassen des Doctype ist geradezu Bedingung für Nichtkonformität und seine häufigen Weglassung wohl auch Grund für letzterer "Beliebtheit".

Aus der Autorensicht. Lassen die Browserhersteller die Dokumenttypangabe unbeachtet (und führen keinen Ersatz ein), gibt es nur noch konforme Darstellung (bis auf unbeabsichtigte Fehler).

Gruß

[Auge]

Hallo

Aha, du findest es nutzlos, dem darstellenden Programm mitzuteilen, nach welchem der vielen Standards das folgende Dokument aufgebaut ist?

Dies ist ja gar nicht der Fall. Du kannst vielleicht HTML-3.2-, HTML-4.01-Transitional und -Strict-Dokumente schreiben, die dem Standard entsprechen. Aber tatsächlich kennt ein Browser nur HTML-Dokumente. Für das darstellende Programm hat die Version und damit die Dokumenttypangabe keinerlei Bedeutung.
Dies gilt auch für XML-Derivate wie SVG und XHTML.

Durch die Dokumenttypangabe bestimmt das darzustellende Programm lediglich, wie nah es sich bei der Darstellung an die vorgegebenen Standards (die in jedem Modus die selben sind) hält.

Du stellst die praktische Anwendung über den eigentlichen Zweck? Wer sagt dir, dass alle Programme, die HTML ausgeben, die Doctype-Angabe ignorieren bzw. nur zur Unterscheidung zwischen quirks mode und standard compliants mode heranziehen, wie du es darstellst? Wer sagt dir, dass es, so deine Aussage überhaupt zutrifft, immer dabei bleibt und nicht eine zukünftige Clients-Generation den Doctype dazu benutzt, festzulegen, wie das Dokument ausgegeben wird?

Dazu ist der Doctype, abseits seiner momentan häufigsten Anwendung, da.

Ich finde daran nur eigenartig, das die nicht-konformen Modi immernoch so beliebt sind.

Das ist eine ganz andere Frage. Und ja, ich finde es auch eigenartig, aber das ist wohl eher die Sicht von Leuten, die sich regelmäßig mit HTML und den verschiedenartigen Interpretationen desselben in verschiedenen Clients auseinanderseitzen müssen.

Tschö, Auge

[Daniel unreg]

Hallo,

Du stellst die praktische Anwendung über den eigentlichen Zweck? Wer sagt dir, dass alle Programme, die HTML ausgeben, die Doctype-Angabe ignorieren bzw. nur zur Unterscheidung zwischen quirks mode und standard compliants mode heranziehen, wie du es darstellst?

Welche Bedeutung hatte der Dokumenttyp je für das Dokument selbst? Sieh dir die Browsergeschichte an. Nie gab es SGML-Parser, nie wurden DTDs zur Überprüfung herangezogen.
Außer der Dokumenttypweiche hat die Angabe kaum Bedeutung. Das einzige, was mir einfällt ist das erkennen der Version in einem Überprüfungsapparat (Validator, etc.). Diese sagen aber auch nur aus, ob ein Dokument einem bestimmten Standard entspricht oder nicht. Das eigentliche Darstellungsprogramm hat daran kein Interesse.

Wer sagt dir, dass es, so deine Aussage überhaupt zutrifft, immer dabei bleibt und nicht eine zukünftige Clients-Generation den Doctype dazu benutzt, festzulegen, wie das Dokument ausgegeben wird?

Bis auf Microsoft haben sich bisher alle Browserhersteller dagegen ausgesprochen, einen derartigen Mechanismus einzuführen.

Dazu ist der Doctype, abseits seiner momentan häufigsten Anwendung, da.

Ich weis, es ist für viele keine beliebte Quelle, doch unabwendbar ist, dass HTML 5 definiert: „Eine Dokumenttypangabe ist eine großteils nutzlose, aber notwendige Kopfzeile.“ (HTML 5 §8.1.1 The DOCTYPE). Das Dokument „HTML 5 differences from HTML 4 §2.2 The DOCTYPE“ besagt zudem, dass die Dokumenttypangabe nur notwendig sei, um den standardkonformen Modus zu aktivieren, weshalb er in XHTML optional sei (XML wird immer standardkonform verarbeitet).

Die kommende Spezifikation hat die Angabe also eher als notwendiges Übel übernommen.

Das ist eine ganz andere Frage. Und ja, ich finde es auch eigenartig, aber das ist wohl eher die Sicht von Leuten, die sich regelmäßig mit HTML und den verschiedenartigen Interpretationen desselben in verschiedenen Clients auseinanderseitzen müssen.

Das ist wohl wahr.

Gruß, Daniel

[Cybaer]

Hi,

Du stellst die praktische Anwendung über den eigentlichen Zweck? Wer sagt dir, dass alle Programme, die HTML ausgeben, die Doctype-Angabe ignorieren bzw. nur zur Unterscheidung zwischen quirks mode und standard compliants mode heranziehen, wie du es darstellst? Wer sagt dir, dass es, so deine Aussage überhaupt zutrifft, immer dabei bleibt und nicht eine zukünftige Clients-Generation den Doctype dazu benutzt, festzulegen, wie das Dokument ausgegeben wird?

Weil das Unfug wäre (und mit HTML 5 auch wieder vom Tisch ist). Seit dem Beginn von HTML gilt ganz schlicht: Unbekannte Tags und Attribute sind zu ignorieren.

Wenn der Client ein Tag oder Attribut kennt, dann sollte es es halt interpretieren ...

Gruß, Cybaer

[Cybaer]

Hi,

Eine eigenartige Einstellung.

Nein, HTML 5.

Gruß, Cybaer

[Auge]

Hallo

Eine eigenartige Einstellung.

Nein, HTML 5.

Hatten wir schon. Dann will ich aber auch noch einen drauf- oder absetzen.

<überspitzung style="strength:even-stronger;">Die (HTML5-Leite) brauchen eine Doctypeangabe sowieso nicht, da sie den Clients eh erlauben wollen, alles so zu machen, wie es ihnen beliebt.</überspitzung> ;-)

Über die praktische Relevanz des Doctype brauchen wir uns nicht zu streiten. Er wird momentan zu nichts anderem benutzt, als zwischen quirks mode und standard compliants mode umzuschalten.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge:

Über die praktische Relevanz des Doctype brauchen wir uns nicht zu streiten. Er wird momentan zu nichts anderem benutzt, als zwischen quirks mode und standard compliants mode umzuschalten.

Wenn du dich auf HTML 4 beschränkst, solltest du das auch erwähnen.

In XML (also auch in als solchem verarbeitetem XHTML) kann die DOCTYPE-Deklaration auch dazu benutzt werden, eigene Entities zu definieren. [http://forum.de.selfhtml.org/archiv/2008/1/t165458/#m1078919]

Live long and prosper,
Gunnar

[Daniel unreg]

Hallo,

<überspitzung style="strength:even-stronger;">Die (HTML5-Leite) brauchen eine Doctypeangabe sowieso nicht, da sie den Clients eh erlauben wollen, alles so zu machen, wie es ihnen beliebt.</überspitzung> ;-)

Naja.. Aber da du so ein schönes Element verwendet hast lasse ich davon ab, Konter zu geben ;)

Gruß

[Gunnar Bittersmann]

@@Daniel unreg:

Dokumenttypangaben sind nutzlos für das Dokument selbst.

Nein, sind sie nicht. Woher sollte ein UA denn wissen, dass es sich um ein HTML-Dokument (SVG, RSS, Atom, ...) handelt, wenn nicht aus der DOCTYPE-Angabe?

Aus dem Start-Tag des Wurzelelements? Äußerst zweifelfaft, schließlich ist dieses in HTML optional.

Die Tatsache, dass irgendwelche verrückten Browserhersteller meinen, anhand dieser Angabe verschiedene Verarbeitungsmodi für Webseiten zu verwenden

ist in der Tat ziemlich blöd. Ein Verrückter hat’s vorgemacht; andere fanden es verrückt genug, es nachzuäffen.

Live long and prosper,
Gunnar

[Tim Tepaße]

Hallo Gunnar,

Nein, sind sie nicht. Woher sollte ein UA denn wissen, dass es sich um ein HTML-Dokument (SVG, RSS, Atom, ...) handelt, wenn nicht aus der DOCTYPE-Angabe?

Im HTTP-Umfeld gibt's MIME MEdia Typen, unter Desktop-OS eigene Mechanismen, z.b. die beliebten Dateiendungen. Prinzipiell ist ein Doctype-Angabe natürlich besser.

Tim

[Daniel unreg]

Hallo,

Nein, sind sie nicht. Woher sollte ein UA denn wissen, dass es sich um ein HTML-Dokument (SVG, RSS, Atom, ...) handelt, wenn nicht aus der DOCTYPE-Angabe?

Im HTTP-Umfeld gibt's MIME MEdia Typen, unter Desktop-OS eigene Mechanismen, z.b. die beliebten Dateiendungen. Prinzipiell ist ein Doctype-Angabe natürlich besser.

Ich denke auch, dass zu zuerst genannten Mechanismen ausreichen. Wie sonst erkennen heutige Browser HTML-Dateien?

Ich mag mich irren, doch in XML-Dokumenten sind sowohl Deklaration als auch Dokumenttypangabe optional. Wie erkennt ein Parser, dass es sich um SVG oder XHTML handelt? Vermutlich am Namensraum. Oder am Wurzelelement, welches hier nicht optional ist. Oder beidem.

HTML ist da schon ein Sonderfall, aber das wird sich auch nicht mehr ändern.

Gruß

[Cybaer]

Hi,

Die Dokumenttypweiche sollte von den Browserherstellen nochmals überdacht werden.

Das wurde gemacht.

In HTML 5 ist nur noch ein verkürzter Doctye (ohne Versionsangabe) "notwendig", der im Prinzip nur dafür da ist, die Kompatibilität zu dem von dir erwähnten Schwachsinn zu gewährleisten ...

Gruß, Cybaer

[Daniel unreg]

Hallo,

Die Dokumenttypweiche sollte von den Browserherstellen nochmals überdacht werden.

Das wurde gemacht.

Die Angabe wurde überarbeitet (sinnvollerweise). Die Weiche selbst auch, gibt aber eher den den aktuellen Stand wieder, anstatt diesen stärker zu überdenken.

Aber vielleicht mache ich mir auch zu viele Sorgen. Opera immitiert z.B. kaum noch den IE. Aber schauen auch andere Hersteller, ob Quirks entfernt werden können?

Gruß

[Cybaer]

Hi,

Aber schauen auch andere Hersteller, ob Quirks entfernt werden können?

IMHO auf nähere Sicht unrealistisch. Nach der Google-Webseiten-Statistik ist AFAIR die überwiegende Mehrheit der Webseiten invalde, bzw. sogar quirkig (da ohne Doctype).

Und man sollte in Erinnerung haben, das wohl viele Sitebetreiber mit dem Update auf IE 7 Probleme bekamen (was MS ja erst zum "Kompatibilitäts-Modus" beim IE 8 veranlaßte).

Gruß, Cybaer

[Daniel unreg]

Hallo,

IMHO auf nähere Sicht unrealistisch. Nach der Google-Webseiten-Statistik ist AFAIR die überwiegende Mehrheit der Webseiten invalde, bzw. sogar quirkig (da ohne Doctype).

Hast du einen Verweis zu dieser Statistik, ich scheine sie nicht zu kennen.

Kurzfristig sicher ein Ding der Unmöglichkeit, ich schlage ja auch keinen übergang von 0 auf 1 vor, sondern einen langfristigen Umstieg.

Und man sollte in Erinnerung haben, das wohl viele Sitebetreiber mit dem Update auf IE 7 Probleme bekamen (was MS ja erst zum "Kompatibilitäts-Modus" beim IE 8 veranlaßte).

Das wird sich mit IE8 nicht ändern. Dieser wird seinen Standardkonformen Modus als Standard-Modus für Webseiten verwenden (außer Seiten, die sich im Quirksmodus befinden). Das wird auch Probleme bereiten. Aber letztendlich ist es ein Weg der Besserung.

Da der IE8 voraussichtlich große CSS- und ein paar DOM-Fortschritte macht, ist es für andere Hersteller sinnvoll, die an IE angelehnten Fehler nochmals zu überdenken und ggf. zu entfernen.

Das sollte im realistischen Bereich liegen. Aber ich warte ab, was die Zukunft bringen mag.

Gruß

[Cybaer]

Hi,

Hast du einen Verweis zu dieser Statistik, ich scheine sie nicht zu kennen.

Google Web Authoring Statistics

Kurzfristig sicher ein Ding der Unmöglichkeit, ich schlage ja auch keinen übergang von 0 auf 1 vor, sondern einen langfristigen Umstieg.

Ja, seeehr langfristig. =:-)

Ich meine: Wie lange gibt es jetzt schon XHTML 1? Wie oft sieht man, daß bei Seiten ein Doctype angegeben wurde, der nicht stimmt (Seite nicht valide, gemischte HTML- & XHTML-Syntax, ...)? Wieso hatten (auch große Sites) massivste Probleme mit dem IE 7 (und werden sie wohl auch mit dem IE 8 wieder bekommen - sofern nicht zeitig wenigstens auf den Kompatibilitätsmodus geschaltet wird)? Warum kommt jetzt nicht der seit Jahren diskutierte Umstieg auf XHTML 1.1 (von XHTML 2 erst gar nicht zu reden), sondern HTML 5? Warum senden selbst so viele XHTML-1-Autoren die Seiten immer nur als HTML? Warum wissen das viele XHTML-1-Autoren gar nicht? Und wenn *die* schon solche Wissenslücken haben, wie sieht es mit der Mehrzahl der 08/15-HTML-Autoren erst aus?

Die Webautoren-Welt "da draußen" sieht IMHO ziemlich anders aus, als das kleine SELFHTML-Biotop mit den paar Postern & Lesern mitunter den Anschein erwecken mag ...

Das wird sich mit IE8 nicht ändern. Dieser wird seinen Standardkonformen Modus als Standard-Modus für Webseiten verwenden

Ja, aber erst nachdem ein massiver Aufschrei durch die Developergemeinde ging. Alleine daß MS sich vor diese Frage gestellt sah, sagt nicht nur über MS etwas aus, sondern auch über die Webdesigner jenseits von SELFHTML ...

Gruß, Cybaer

[Sven Rautenberg]

Moin!

Soweit ich dass verstanden habe, ist die BOM ein Informationshinweis für das Dateiöffnende Programm: "Achtung, jetzt kommt utf-8!"-vorrausgesetzt das Öffnende Programm kann damit umgehen.

Die Wahrscheinlichkeit, dass hinter den drei Bytes einer UTF-8-codierten BOM tatsächlich UTF-8 folgt, ist natürlich nicht unbedingt niedrig, aber man kann allein an den verwendeten Bytes eines Datenstromes nicht erkennen, welche Codierung benutzt wurde.

Die Sache sieht anders aus, wenn man sich anschaut, ob der Datenstrom in irgendeiner Weise ein Codierungslabel besitzt. Wenn ein Datenstrom als UTF-8 ausgezeichnet ist, z.B. durch die Charset-Angabe im Mimetyp, dann muß man nicht raten. In so einem Fall ist bei UTF-8 die BOM allerdings überflüssig, da ihre Funktion der "Byte Order" in UTF-8 nicht benötigt wird.

- Sven Rautenberg

[gooxsy]

Hi gary,

Erst mal Danke für den Link

aber gerne doch

(ja, eine Forumssuche vor dem Posten wäre nicht verkehrt *g*)

das hast _Du_ gesagt ;-)

Mich "wurmt" nur ein wenig, dass der Validator eine Warnung wegen einer BOM(Byte Order Mark) ausgibt.

das würd mich auch ärgern

Er erkennt aber UTF-8. Weisst du zufällig, wie man eine BOM entfernt?

Ja, man nimmt einen Editor, bei dem man einstellen kann, daß er die Datei als utf-8 codiert _ohne_ BOM speichert. Dazu bietet sich _zum Beispiel_ mein seit jeher geliebtes Notepad++ an. Dort kannst Du einstellen, ob die Datei als "utf-8" oder "utf-8 ohne BOM" gespeichert werden soll. Du kannst natürlich auch einen anderen Editor verwenden, wichtig ist nur, daß Du darauf schaust, daß der von Dir verwendete Editor utf-8 ohne BOM speichern kann, was nicht bei _jedem_ Editor der Fall ist.

mfG

gooxsy

[Sven Rautenberg]

Moin!

Ich wollte mal eure Meinung speziell zu der UTF-Codierung hören. Also was meint Ihr: Ist UTF-( eigentlich gut, oder eher böse?

UTF-8 ist nur gut. Böse sind nur die anderen Codierungen, wenn man von UTF-8 nach dorthin konvertieren muß, weil dann unweigerlich die uncodierbaren Zeichen verlorengehen müssen.

Deshalb ist es extrem schlau, die komplette Verarbeitungskette auf UTF-8 zu haben. Alternativ geht aber natürlich auch jede andere Unicode-Codierung.

- Sven Rautenberg

[Engelein]

Ich wollte mal eure Meinung speziell zu der UTF-Codierung hören. Also was meint Ihr: Ist UTF-( eigentlich gut, oder eher böse?

UTF-8 ist nur gut.

Nein, utf-8 ist problematisch, wenn man nur dusseliges Werkzeug zur Verfügung hat, das mit Mehrbytezeichen nicht vernünftig umgehen kann. Im Web zum Beispiel PHP und Python, wo für utf-8-kodierte Daten andere Funktionen bzw. ein eigener Zeichentyp benutzt werden muss - als wenn ein Buchstabe jemals etwas anderes sein sollte als ein Buchstabe.

MySQL hingegen ist die löbliche Ausnahme, dort wird die Zeichenkodierung einmalig angegeben und man muss sich im Folgenden um nichts weiter kümmern, sondern kann ein Zeichen auch als solches behandeln, egal welche Kodierung vorliegt.

Die Ursache liegt nun zweifelsohne nicht bei utf-8, und die Vorteil von utf-8 überwiegen sicherlich im Allgemeinen, trotzdem sollte dieser Umstand nicht blauäugig ausgeblendet werden. Es nützt alle bunte Theorie nichts, wenn die Praxis anders aussieht.

[Gunnar Bittersmann]

@@Engelein:

UTF-8 ist nur gut.

Nein, utf-8 ist problematisch, wenn man nur dusseliges Werkzeug zur Verfügung hat, das mit Mehrbytezeichen nicht vernünftig umgehen kann. Im Web zum Beispiel PHP und Python, wo für utf-8-kodierte Daten andere Funktionen bzw. ein eigener Zeichentyp benutzt werden muss - als wenn ein Buchstabe jemals etwas anderes sein sollte als ein Buchstabe.

PHP ist wirklich dusselig. Anstatt dass diese Sprache* vernünftig wächst, wuchert sie wie ein Krebsgeschwür. Anstatt die vorhandenen Stringfunktionen UTF-8/16/32-fähig zu machen, wurden neue Funktionen eingefüht – und die alten im Sprachumfang belassen. Mit Vernunft hat das nichts zu tun.

Wer allerdings heutzutage noch UTF-8-unfähige Werkzeuge einsetzt, der ist selber schuld. Das ist wie eine Herzoperation mit einem Faustkeil durchzuführen.

Die Ursache liegt nun zweifelsohne nicht bei utf-8, und die Vorteil von utf-8 überwiegen sicherlich im Allgemeinen,

Eben. UTF-8 ist immer gut. Es sei denn, UTF-16 ist besser. Lediglich einige Werkzeuge sind schlecht.

trotzdem sollte dieser Umstand nicht blauäugig ausgeblendet werden. Es nützt alle bunte Theorie nichts, wenn die Praxis anders aussieht.

Ja. Ich überlege mir auch zweimal, ob ich Mails UTF-8-codiert versende, da etliche Nutzer ja nicht vernünftige Mailclients, sondern UTF-8-unfähige Webmail-Interfaces benutzten, also schlechte Werkzeuge.

Live long and prosper,
Gunnar

* PHP darf getrost eher als Gestammel bezeichnet werden denn als Sprache.

[dedlfix]

echo $begrüßung;

PHP ist wirklich dusselig. Anstatt dass diese Sprache* vernünftig wächst, wuchert sie wie ein Krebsgeschwür. Anstatt die vorhandenen Stringfunktionen UTF-8/16/32-fähig zu machen, wurden neue Funktionen eingefüht – und die alten im Sprachumfang belassen. Mit Vernunft hat das nichts zu tun.

Bitte nichts vermischen. Die mb-Funktionen ist irgendwann als Erweiterung zum PHP-Core hinzugefügt worden, und sie ist noch nicht einmal per default aktiviert. Außerdem lässt sich diese Erweiterung per php.ini-Direktive so einstellen, dass sie einige der vorhandenen String-Funktionen überschreibt: http://de.php.net/manual/en/mbstring.overload.php

Es ist außerdem nicht einfach damit getan, mal eben ein paar Funktionen umzuschreiben. Die Sache ist wegen der Multibyte-Geschichte deutlich aufwendiger in das Gesamtkonzept (Ruhe!) zu integrieren. Nicht umsonst wird es erst zum Major-Versionsnummernwechsel auf 6 enthalten sein und nicht schon unter 5.x. Beispielsweise wird es einen neuen Unicode-String-Typ geben (wobei wohl string beibehalten wird und das bisherige string nach binary umbenannt wird). Damit müssen dann nicht nur "die paar" Stringfunktionen zurecht kommen sondern quasi alle Funktionen, die irgendwie mit Strings hantieren.

Wer allerdings heutzutage noch UTF-8-unfähige Werkzeuge einsetzt, der ist selber schuld. Das ist wie eine Herzoperation mit einem Faustkeil durchzuführen.

Die Welt ist im Wandel. Ich fühle es im Wasser. Ich fühle es in der Erde. Ich rieche es in der Luft. Doch selbst bei anderen Projekten (Python beispielsweise) ist der vollständige Umstieg noch nicht abgeschlossen.

echo "$verabschiedung $name";

[Mega]

Ich wollte mal eure Meinung speziell zu der UTF-Codierung hören. Also was meint Ihr: Ist UTF-( eigentlich gut, oder eher böse?

Ich arbeite seit lange nur noch mit UTF-8. Dummerweise gibt es aber immer wieder Probleme, wenn die Kunden unter Windows irgendwelche COnfig-Dateien ändern und die schrottigen Editoren das BOM dann einfügen, das es anschliessend im Browser erscheint.

Auf meinen Rechnern gibt es nix anderes und das wird so bleiben, da ich UTF-* für wenselicht flexibler halte also irgendwelche ISO-* die sich für jedes Land ändern.