UTF8 im PHP-Script

Um Kompatibilitätsprobleme zu vermeiden solltest du, wenn möglich (was eigentlich immer der Fall ist), auch keine Zeichen in deinem Script benutzen, die mehr als 7 bit benötigen. Dafür gibts ja z.B. HTML-Entities.

Einspruch!

Weil Automotoren dauernd kaputtgehen, habe ich meinen sofort ausgebaut und lass mich jetzt schieben. Geht nicht schneller, aber dafür habe ich nie wieder Sorgen mit dem Motor.

EDIT:

---

edited by asp2php. Grund: von http://www.php-resource.de/forum/php...t-zeichen.html wegen OT getrennt

---

Warum findest du das so aufwändig?
Du kannst dir ja automatisch alle HTML-Entities immer setzen lassen und auf allen websiten immer UTF-8 verwenden. Dann wirst du niemals mehr Probleme mit irgendeinem Zeichen haben (egal ob polnisch, chinesisch, japanisch oder irgendwas und egal aus welcher Quelle das Zeichen kommt - vom Benutzer oder vom Script) und du sparst so eine menge Zeit.

Ich erzeuge aber nicht nur Webseiten, sondern auch Images, PDF und Emails... (um nur mal ein Paar zu nennen)
Was will ich da mit den htmlentities?
Nee, das nervt doch nur.

Das hast du recht, du kannst natürlich nicht überall HTML Entities nehmen, aber es gibt bei all diesen Beispielen (auch für PHP Strings) einen Ersatz, sodass du ohne grossen Aufwand mit ASCII in deinem Script klarkommst und dir damit eine Menge Zeit wegen Problemen, z.B. beim Wechseln des Servers, der Datenbank oder auch nur deiner Platform sparen kannst.

nicht überall HTML Entities nehmen,

Richtig!
Und zwar nur und ausschließlich wenn ich beabsichige HTML auszugeben.
In allen anderen Fällen macht es Null Komma gar keinen Sinn.

Das habe ich glaube ich nie behauptet, sondern nur, dass man besser nur ASCII in einem Script verwendet also

z.B. HTML Entities

.

dass man besser nur ASCII in einem Script verwendet

Wenn du meinst, in Funktions und sonstigen Bezeichnern, dann muß ich dir recht geben. Bis PHP6 wird da nur iso-8895-1 unterstützt.

Aber bei den Inhalten, gibts heutzutage kaum noch einen Grund auf utf-8 zu verzichten. ASCII ist da wenig brauchbar. Das hat weder ö noch Ü und €. Von koreanisch ganz zu schweigen.

Dies ist ja, was ich zu sagen versuchte... Es gibt in all deinen Beispielen einen Ersatz der ganz einfach zu benutzen ist und für den du nur ASCII also 7 bits benötigst.

Es gibt in all deinen Beispielen einen Ersatz der ganz einfach zu benutzen ist und für den du nur ASCII also 7 bits benötigst.

Zeige mir bitte ein 7 Bit ö ..

Zitat von combie

Zeige mir bitte ein 7 Bit ö ..

PHP-Code:

$char = "\xc3\xb6"; 


Nee... das ist ganz großer Unsinn!
Da ist jeweils das 8te Bit(höchstwertige) gesetzt und zusammen sinds dann auch noch 16 Bit.
16 !== 7

Zitat von combie

Nee... das ist ganz großer Unsinn!
Da ist jeweils das 8te Bit(höchstwertige) gesetzt und zusammen sinds dann auch noch 16 Bit.
16 !== 7

Ich denke er hat vom Zeichensatz der PHP-Dateien gesprochen und nicht vom Zeichensatz der Daten, mit denen man arbeitet.

Und \xc3\xb6 sind 8 Stück 7-Bit ASCII Zeichen im PHP-Code.

Es gibt keine 7-bit Darstellung für äöü u.ä.

7bit-ASCII enthalten nur: s. Bild; es sind 128 Bitmuster, sie enthalten 33 nichtdruckbaren und 95 druckbaren Zeichen. Mehr ist nicht drin, also hör doch auf solche Unsinn zu verbreiten.

Danke h3ll endlich jemand, der versteht was ich meine. Es geht nicht darum, dass es in der Ausgabe ASCII ist, da ist es natürlich UTF-8, aber in deinem Script verwendest du mit "\xc3\xb6" nur ASCII Zeichen, also ein Byte mit einem Wert von jeweils 0-127 und dieser Standard hat heute eigentlich kaum mehr Ausnahmen (früher war das vieleicht anders, kA) und du wirst kaum jemals wieder Kompatibilitätsprobleme haben und ausserdem für alle Zeichen den gleichen Zeichensatz verwenden können.

Und \xc3\xb6 sind 8 Stück 7-Bit ASCII Zeichen im PHP-Code.

8 X 7 = 56 sind also ein 7 Bit ö
Ah, ja, das merke ich mir.

Der "natürliche" PHP Zeichensatz ist iso-latin-1 und der ist halt ein 8 Bit Zeichensatz. Da beißt keine Maus einen Faden ab. Zumindest nicht bis PHP6.

Und was das Ganze jetzt mit htmlentities zu tun hat erschließt sich mir auch noch nicht.

Nee.., mir stellt sich die Sache so dar: Da hat mal wieder jemand einen Hammer begriffen, und jetzt sieht erstmal die ganze Welt wie ein Nagel aus.

Aber in einem gebe ich dir recht:
Man muß konsequent zwischen Script und Content unterscheiden.