Wer konvertiert mein UTF8?
0 
dedlfix
0 0 0 0 dedlfix
0 
Gunnar Bittersmann
0 dedlfix
0 0 dedlfix
0 0 Dazu ne andere Frage
0 Gunnar Bittersmann
Wer konvertiert mein UTF8?
Hi,
kurzes testfile:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html lang="en-US"><head><body>
<pre>
<?
var_dump($_POST);
?>
</pre>
<form action="test.php" method="post" name="eventform" id="eventform">
<input type="text" name="test">
</form>
</body>
</html>
Rufe ich dieses auf und fuelle Umlaute ein ist alles OK. Fuelle ich aber einen echten Unicodestring rein, wie z.B 東京, dann erhalte ich:
array(1) {
["test"]=>
string(16) "東京"
}
Irgendeine sch** Komponente konvertiert hier also, was dazu fuehrt, dass der String auch als solcher in der Datenbank landet und nicht als echter Unicode String.
Kann mir wer sagen, welche Komponente das ist, wie man es aendert und welche Implikationen das hat?
Ich frage deswegen so genau weils leider nicht um meine eigene Applikation geht sondern um horde kronolith. Erstelle ich dort UTF9 Termine (s.o. z.B. auf Japanisch), dann ist der Titel 東京 - was bei der Ausgabe wunderbar escaped wird.
lg
Peter
-
Hi!
Rufe ich dieses auf und fuelle Umlaute ein ist alles OK. Fuelle ich aber einen echten Unicodestring rein, wie z.B 東京, dann erhalte ich:
string(16) "東京"
Irgendeine sch** Komponente konvertiert hier also, was dazu fuehrt, dass der String auch als solcher in der Datenbank landet und nicht als echter Unicode String.
Kann mir wer sagen, welche Komponente das ist, wie man es aendert und welche Implikationen das hat?Diese Komponente nennt sich Browser. Da die Seite mit ziemlicher Sicherheit in einer Kodierung vorliegt, in der die Zeichen nicht darstellbar sind, ist das Verhalten der Browser undefiniert. Einige senden dann NCRs, so wie in deinem Fall.
In deinem Test-Script war zum einen keine Meta-Angabe zum Content-Type inklusive charset-Angae und vermutlich hat auch dein Server keine charset-Angabe im HTTP-Header Content-Type mitgesendet (diese muss ein Browser bevorzugt vor der Meta-Angabe verwenden) oder eine, die nicht UTF-8 ist.
Lo!
-
Hi!
Rufe ich dieses auf und fuelle Umlaute ein ist alles OK. Fuelle ich aber einen echten Unicodestring rein, wie z.B 東京, dann erhalte ich:
string(16) "東京"
Irgendeine sch** Komponente konvertiert hier also, was dazu fuehrt, dass der String auch als solcher in der Datenbank landet und nicht als echter Unicode String.
Kann mir wer sagen, welche Komponente das ist, wie man es aendert und welche Implikationen das hat?Diese Komponente nennt sich Browser. Da die Seite mit ziemlicher Sicherheit in einer Kodierung vorliegt, in der die Zeichen nicht darstellbar sind, ist das Verhalten der Browser undefiniert. Einige senden dann NCRs, so wie in deinem Fall.
In deinem Test-Script war zum einen keine Meta-Angabe zum Content-Type inklusive charset-Angae und vermutlich hat auch dein Server keine charset-Angabe im HTTP-Header Content-Type mitgesendet (diese muss ein Browser bevorzugt vor der Meta-Angabe verwenden) oder eine, die nicht UTF-8 ist.
Hallo und Danke!
Ach, in der Tat, das ist korrekt!
Wenn ich meinen Testscript nun folgendes hinzufuege:
header("Content-Type: text/html; charset=UTF-8");
Dann springt es im Firefox automatisch auf "Unicode (UTF-8)" (in View, Character Encoding).
Die Frage ist jetzt nur ob ich das mit dem Apache auch regeln kann, d.h. ohne
* header() von PHP
* und <meta>-DirektiveWie gesagt geht es bei mir um die horde Anwendung wo ich so wenig wie moeglich umschreiben moechte. Eigentlich gar nichts!
Leider scheint horde das ueberhaupt nicht zu setzen...weder in den meta-Tags noch durch zusaetzliche Header etc...
Gibt es da eine empfohlene Best Practice?
LG
Peter-
Mahlzeit Peter Mairhofer,
Die Frage ist jetzt nur ob ich das mit dem Apache auch regeln kann,
Ja - die allwissende Müllhalde weiß auch, wie.
Gibt es da eine empfohlene Best Practice?
Ja - immer die Ursache des Problems beheben ... :-)
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Hi,
Ja - immer die Ursache des Problems beheben ... :-)
Und die waere?
Zumindest theoretisch?
Horde ist eine riesige, populaere Applikation. Es wundert mich seeeeehr stark, dass hier der charset nicht explizit gesetzt wird. Gibt es irgendwelche Gruende, das nicht explizit zu setzen?
lg
Peter-
Hi!
Horde ist eine riesige, populaere Applikation. Es wundert mich seeeeehr stark, dass hier der charset nicht explizit gesetzt wird. Gibt es irgendwelche Gruende, das nicht explizit zu setzen?
Historische Nicht-Notwendigkeit (zumindest hat man früher, auch zum Zeitpunkt als Horde anfing, sich allgemein wenig um Zeichenkodierung geschert) und die immer noch nicht vorhandene Unterstützung von Mehrbyte-Kodierungen in PHP (Versionen kleiner als 6), wenn man mal von der optionalen Multibyte-String-Extension absieht. Schau in die Dokumentation von Horde, ob und was die zum Thema Zeichenkodierung sagt.
Lo!
-
-
-
@@Peter Mairhofer:
nuqneH
Die Frage ist jetzt nur ob ich das mit dem Apache auch regeln kann,
Ja. [QA-HTACCESS-CHARSET]
Qapla'
--
Alle Menschen sind klug. Die einen vorher, die anderen nachher. (John Steinbeck) -
Hi!
Die Frage ist jetzt nur ob ich das mit dem Apache auch regeln kann, d.h. ohne
* header() von PHP
* und <meta>-DirektiveAddDefaultCharset eigent sich dafür.
Leider scheint horde das ueberhaupt nicht zu setzen...weder in den meta-Tags noch durch zusaetzliche Header etc...
Gibt es da eine empfohlene Best Practice?Wenn ein Browser als Empfänger von textuellen Daten nicht mitgeteilt bekommt, in welcher Kodieruns sie vorliegen, dann rät er oder nimmt eine Default-Einstellung. Es ist technisch nicht zweifelsfrei möglich, die verwendete Kodierung zu erraten. Schon dewegen ist es immer empfehlenswert, die charset-Angabe im Content-Type zu setzen (aber nur bei Typen, bei denen das sinnvoll ist, also text/...) und ein gleichlautendes Meta-Element hinzuzufügen. Dies kommt dann zur Anwendung, wenn der Server keinen Header senden kann, wie bei lokal abgespeicherten Dateien.
Beachte auch, dass eine Anwendung, die sich nicht um die korrekte Auszeichnung von Daten kümmert, sich vermutlich auch keinen Kopf macht, in welcher Kodierung die Eingabedaten vorliegen, um dann daraufhin passende Verarbeitungsfunktionen aufzurufen. Wenn die Anwendung Daten nur durchreicht, ist das kein Problem, aber bei Stringverarbeitung ist die Beachtung der Kodierung wichtig, besonders bei Mehrbyte-Kodierungen wie UTF-8.
Lo!
-
-
-
Mahlzeit Peter Mairhofer,
kurzes testfile:
Zu kurz.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html lang="en-US"><head><body>Oder möchtest Du Deinen <head> nicht schließen? Da Du keine <meta>-Angaben zur verwendeten Zeichencodierung machst, gehe ich davon aus, dass der Webserver die korrekte sendet? Wie sieht diese aus?
<form action="test.php" method="post" name="eventform" id="eventform">
Du kannst die zu verwendende <http://de.selfhtml.org/html/formulare/definieren.htm#zeichenkodierung@title=Zeichencodierung der Formulardaten> selbst angeben - und solltest das vielleicht auch, wenn schon die HTTP-Header bzw. der HTML-Head keine brauchbaren Informationen darüber enthalten.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Hi!
Du kannst die zu verwendende <http://de.selfhtml.org/html/formulare/definieren.htm#zeichenkodierung@title=Zeichencodierung der Formulardaten> selbst angeben - und solltest das vielleicht auch, wenn schon die HTTP-Header bzw. der HTML-Head keine brauchbaren Informationen darüber enthalten.
Schön wäre es, wenn accept-charset browserübergreifend funktionieren tät, tut es aber nicht. Der IE spielt selbst bei ISO-8859-1 und UTF-8 nicht mit. Das einzige was hilft, ist, die Kodierung der das Formular enthaltenden Seite so zu setzen (und zu verwenden), wie man die Daten haben möchte (also charset-Angabe beim HTTP-Header Content-Type oder ersatzweise im Meta-Element).
Lo!
-
-
Versuchs mal indem du dem form ein "accept-charset" gibst.
Ist aber nur ne schnelle Idee... -
Zu diesem Thema eine allgemeinere Frage.
Ich frag mich grad wie das funktioniert, mit den ganzen Zeichensätzen.
Was wird dabei wo alles umgesetzt, vom Tastaturcode "Taste ü" bis zur Zeichencodierung in Unicode/Latin/sonstwas im Programm, dann daraus wieder das raussuchen des passenden Zeichens aus dem Font usw...-
@@Encoder:
nuqneH
Ich frag mich grad wie das funktioniert, mit den ganzen Zeichensätzen.
Was wird dabei wo alles umgesetzt, vom Tastaturcode "Taste ü" bis zur Zeichencodierung in Unicode/Latin/sonstwas im Programm, dann daraus wieder das raussuchen des passenden Zeichens aus dem Font usw...Zeichencodierung für Dummies hast du gelesen?
Und die Seite Zeichenkodierung in Michael Jendryschiks Einführung in XHTML, CSS und Webdesign?
Und den Abschnitt http://de.selfhtml.org/inter/index.htm@title=Internationalisierung in SELFHTML?
Qapla'
--
Alle Menschen sind klug. Die einen vorher, die anderen nachher. (John Steinbeck) -
Hi!
Zu diesem Thema eine allgemeinere Frage.
Ich frag mich grad wie das funktioniert, mit den ganzen Zeichensätzen.
Was wird dabei wo alles umgesetzt, vom Tastaturcode "Taste ü" bis zur Zeichencodierung in Unicode/Latin/sonstwas im Programm, dann daraus wieder das raussuchen des passenden Zeichens aus dem Font usw...Versuch bitte erst einmal die allgemeine von Gunnar Bittersmann immer wieder verlinkte (und von ihm ins Deutsche übersetzte) Information und andere Informationsquellen zu diesem Thema zu lesen. Wenn du dann noch konkrete Fragen hast, dann stell sie. Das Thema ist zu umfangreich, um es in einer Forumsantwort zu behandeln, ohne von der Forumssoftware als geschwätzig angezählt zu werden.
Lo!
-
-
@@Peter Mairhofer:
nuqneH
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<html lang="en-US">Zum einen solltest du in XHTML auch @xml:lang angeben. [I18N-HTML-TECH-LANG, LANGUAGE-DECL, http://de.selfhtml.org/html/xhtml/unterschiede.htm#lang@title=SELFHTML]
Zum anderen solltest du als Sprache "en" angeben (wenn dein Dokument denn in Englisch ist). [CHOOSING-LANGUAGE-TAGS]
Qapla'
--
Alle Menschen sind klug. Die einen vorher, die anderen nachher. (John Steinbeck)