UTF8 im PHP-Script

[onemorenerd]

Hey das hat aber nichts mehr mit dem Problem des TO zu tun, ist euch das bewußt? Der TO bekommt Daten in UTF8 und will sie zu Latin1 umkodieren.
Dabei ist völlig egal, wie der PHP-Code kodiert ist. Denn die Daten stehen da nicht in drin. Das Script bekommt sie von irgendwo, z.B. von einem Webservice, aus einer DB oder durch Benutzereingabe.

[combie]

Die Anforderung des TE ist nicht zu lösen!
Es sei denn er konvertiert zu einem Zeichensatz mit €, da er aber auf utf8-decode() beharrt, keine Chance. Das Ergebnis ist, wie er schon richtig erkannt hat iso-8895-1 und das kann kein €. Nie und nimmer. Irgendwelche Zwischenschritte über 7Bit __EUR__ oder so, sind da irrelevant.

[h3ll]

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.

Es geht um was ganz anderes. "\xc3\xb6" ist _immer_ ein "ö" im UTF-8 Zeichensatz. Egal, ob die PHP-Datei selber als latin1, utf8, oder sonst irgendwas abgespeichert wurde. Sagen wir, es ist einfach deppensicher. Man kann die PHP-Datei nicht im falschen Zeichensatz abspeichern, weil jeder Zeichensatz in den ersten 7-Bit identisch ist.

Würde jemand "ö" schreiben, aber die PHP-Datei nicht im vorhergesehenen Format abspeichern, hat man einen falschen Wert in der Datei stehen. Das sollte nicht passieren, aber es gibt vielleicht Fälle, wo sowas passiert.

Ich persönlich (bzw. meine Kollegen) speichern PHP-Dateien immer als UTF-8 ab. Es ist so definiert, wir wissen das, es hält sich jeder dran, somit gibt es keine Probleme. Aber ich kann trotzdem nachvollziehen, warum jmc einer anderen Meinung ist.

[jmc]

Ich bin nicht einmal anderer Meinung als du und ich bevorzuge auch UTF-8, aber wie du selbst sagt, wenn man im Script nur ASCII Zeichen verwendet ist es richtiggehend deppensicher. Und es gibt gibt bei uns immer wieder Leute die beim Schreiben Zeichensätze wie Latin1 verwenden.

[combie]

Ich denke nicht, dass jedes Mittel recht ist um mangelnde Disziplin zu kompensieren. Und, dein "\xc3\xb6" ist eins der hässlichsten und unleserlichsten ö welche mir je untergekommen sind.

Dass man sich bei Funktions(und sonstigen) Bezeichnern und Kommentaren auf English beschränken sollte, ist hoffendlich jedem klar. Da gibts das Problem also gar nicht. Somit kann das ö nur ein Teil der Ausgabe sein. Und bei der Ausgabe muß man sich doch sowieso auf eine Zeichencodierung festlegen.

Und ja, ich halte es auch für eine gute Idee die gesammte TextDatenhaltung in utf-8 abzuhandeln. Und dann nur unmittelbar vor der Ausgabe in das benötigte "Format" umwandeln.

// beispiel schlechter Code:
ausgabe('Überlauf!');


// besser
ausgabe(_('overflow')); 

Wobei dann die konkret benötige Konvertierung (wenn überhaupt) entweder von ausgabe() oder sogar von einem ob_handler gemacht werden kann.

Ich hoffe, jetzt wird klarer, was ich meine.

Und es gibt gibt bei uns immer wieder Leute die beim Schreiben Zeichensätze wie Latin1 verwenden.

Ist doch auch nicht schlimm!
Muß man nur konsequent sein!

function trööt() {}
function trÖÖt() {} 

Das geht unter utf-8 beanstandungslos durch. Als iso-8859-1 wirft es richtigerweise einen fatal error. Gib dem PHP eine Chance dir solchen Blödsinn zu melden.

[h3ll]

Ganz primitives Beispiel:

// String "Müller" aus der Datenbank im UTF-8 Zeichensatz
$name = "M\xc3\xbcller";

// ersetze "ü" durch "ue"
$name = str_replace("ü", "ue", $name); 

Wenn die PHP-Datei nicht als UTF-8 abgespeichert wurde, wird hier das UTF-8 "ü" nicht ersetzt.

[jmc]

Ist doch auch nicht schlimm!
Muß man nur konsequent sein!

Wenn man Daten aus ganz verschiedenen Quellen erhält (andere Firmen, andere Personen, etc), denen man nicht sagen kann sie sollen konsequent Latin1 verwenden, dann wird man automatisch Probleme mit dem Zeichensatz haben. Mit ASCII hat niemand Probleme.

Wer einen Funktionsnamen wie trööt verwendet, der hat wohl eh noch einiges, das er ändern sollte.

Das mit den HTML-Entities war nur ein Beispiel. Egal welcher Zeichensatz da im Content-Type definiert ist (ob vom User, vom Server oder vom Script) die Zeichen werden richtig angezeigt werden, wenn die Zeichen bekannt sind.

[combie]

Wozu brauchst du ein ue?

[h3ll]

Wozu brauchst du ein ue?

Ich brauchs nicht. Aber die Anforderung könnte ja vom Kunden kommen, oder? Eventuell brauchen sie einen Datenexport für ein uraltes System, das nur ASCII-Zeichen kennt.

[combie]

Aber dann ist es ja sowieso ein Problem der Ausgabe!
Und die sollte schon über ihre Zeichensätze Bescheid wissen. Sonst ist doch Hopfen und Malz verloren.

[h3ll]

Aber dann ist es ja sowieso ein Problem der Ausgabe!
Und die sollte schon über ihre Zeichensätze Bescheid wissen. Sonst ist doch Hopfen und Malz verloren.

Ja eben. Wenn ich eine Ausgabe programmiere, die aus einem ü ein ue machen soll, muss ich ja irgendwo ein "ü" im Programmcode reinschreiben. Oder kennst du eine Funktion, die das automatisch macht? Ich mein aus einem ü ein u machen ist keine Kunst. Das geht mit iconv() problemlos. Aber eine Funktion, die ein ue daraus macht, ist mir nicht bekannt.