hi,

ich kann mich Sven da nur anschließen.
Sag den leuten in der Codierungshölle mal einen Gruß ;)

Scherz beiseite. Es ist zwar nervig aber geh alle Dateien durch und speichere sie in UTF-8. Dann noch einmal von oben nach unten drüber lesen und die komischen zeichen ersetzen. Wenn du lang-dateien hast, ist das natürlich schneller gemacht als bei weit verbreiteten Scripten.

Datenbanken hab ich aber teils auch noch auf latin und damit keine probleme. Neue stelle ich aber bereits auch auf UTF-8 um.

UTF-8 erlaubt auch das man direkt ä im code hat und nicht ä machen muss!

Gruß Niklas

Moin!

Hallo Sven, vielen Dank für deine Antwort!

Soweit ich mich belesen habe arbeitet Linux hauptsächlich mit UTF-8-Dateien und Windows mit ANSI. Gut dachte ich mir, speicherst die Dateien in UTF-8.

Stimmt nicht. Die Kodierung einer Datei bestimmt immer noch der Programmierer selbst.

Ah sehr gut zu wissen, danke ;)

ich habe aber nicht wirklich lust bei einem fremden projekt jetzt zu prüfen welche dateien alle direkt aufgerufen werden, und welche alle includet werden ...

Überflüssig. Aber die Codierung sollte überall gleich sein.

gibt es hierfür kein patentrezept? ;)

Schritt 1: Stelle die Codierung überall auf UTF-8 um.
Schritt 2: Prüfe die Ausgabe. Wenn Coddierungsprobleme auftreten, wurden bei Schritt 1 noch Elemente übersehen.

:)

• Sven Rautenberg

mir wäre es auch am liebsten, alles auf einen nenner zu bringen. Da die Datenbank, welche ich nicht unbedingt komplett konvertieren möchte, jedoch komplett latin1 ist, würde ich sagen stelle ich die dateien und das encoding des browsers auch komplett auf latin1 um, zumindest fallen mir gerade keine zeichen ein, die ich vermissen würde.

ich werde aber dennoch mal schauen, welchen umstand es macht die db komplett in UTF-8 zu konvertieren, vielen dank erstmal bis hierhin ;)

Gruß

SorgenkindMech

Tach!

ich bin gerade dabei alles nach und nach auf utf8_unicode umzustellen.

Wichtig sind die Felder. Die Tabellen- und Datenbank-Werte zur Kodierung und Kollation sind nur Defaultwerte für neu angelegte Felder und Tabellen. Ob in den Feldern alles richtig ist, zeigt dir der phpMyAdmin. Wenn der Fehler zeigt, hast du ein Problem mit den Daten selbst.

Punkt zwei neben den Feldern ist die Verbindungskodierung. Siehe SELFHTML-Wiki Zeichencodierung/MySQL.

bei den alten nachrichten gibt es jedoch nun probleme, im browser werden vierecke dargestellt.

Solche Vierecke � sind ein Zeichen, dass der Empfänger UTF-8 zu lesen versucht, aber keins bekommt.

wenn ich dem browser sage, dass er die seite nicht in utf8 sondern in latin1 darstellen soll, so wird aus einer neuen (in utf8 korrekt dargestellten) test ä ü ö . ß ? = % $ " bla => test ä ü ö . ß ? = % $ " bla

Diese Kombinationen sind UTF-8-Sequenzen als ISO-8859-1 interpretiert. Manchmal aber auch mehrfach UTF-8-kodierte Zeichen.

dafür werden nun aber die alten korrekt angezeigt, trotz konvertierung der datenbank

Die Konvertierung in der Datenbank wirkt sich nicht auf die Verbindung zum Client aus. Je nachdem, was da ausgehandelt oder defaulteingestellt ist, konvertiert MySQL hin und her.

echo "'".dechex(ord($test1))." (".ord($test1).")'-'".dechex(ord($test2))." (".ord($test2).")'";

urlencode() lässt sich gut zur Kontrolle missbrauchen. ord() ist unbrauchbar, weil das nur ein Byte berücksichtigt.

ausgabe: 'c3 (195)'-'df (223)'

laut http://www.utf8-zeichentabelle.de/unicode-utf8-table.pl?view=2:
U+00DF - ß - c3 9f

Verwechsel bitte nicht Unicode (und die CodePoints) mit den Bytes der Kodierung UTF-8 (Grundlagenwissen: Zeichenkodierung und geschriebene Sprache).
Das DF ist nicht (nur) der Unicode-CodePoint sondern in dem Fall das ISO-8859-1-Byte für ß. c3 9f musst du sehen, wenn es UTF-8 ist.

ich mein das DF passt ja, resultiert aber in einem viereck

Klar, ist ja kein gültiges UTF-8.

und das C3(Hex) passt ja auch, und wird auch korrekt als ß dargestellt

Du betrachtest nur Teile uns ziehst die falschen Schlussfolgerungen.

dedlfix.