/ Server - UTF-8 Vs. ANSI vs. ISO-8859-1 / Latin-1

[SorgenkindMech]

Hallo liebes Forum,

nach langem stehe ich mal wieder vor einem Problem:

Ich bin zur Zeit in einem Projekt, wo ich eine bestehende Seite modifizieren muss, ich habe normalerweise immer mit Servern basierend auf IIS gearbeitet, nun ist es in Linux-Server und ich habe ein wenig knartsch mit den Zeichenkodierungen ;)

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.

Die Seite selbst hat als kodierung ISO-8859-1 / Latin-1, die mysql-DB ist auch auf Latin-1 eingestellt. Dadurch erhoffe ich mir zumindest die einfachste Handhabung.

Nun das Problem: Wenn ich alle Dateien in UTF-8 speichere, so werden umlaute und sonderzeichen nicht korrekt dargestellt, was ja auch logisch ist, da die seite Latin-1 vorgibt. Stelle ich manuell im Browser auf UTF-8, so werden einige korrekt dargestellt, manche nicht...

wenn ich in den direkt aufgerufenen Dateien das BOM einschließe und in den includeten Dateien das BOM NICHT einschließe, so wird alles perfekt dargestellt, absolut keine probleme.

wenn ich in alle dateien BOM einschließe hab ich bei includeten dateien dieses tolle BOM als ausgabe im Browser (), was ich natürlich nicht haben will ...

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 ...

gibt es hierfür kein patentrezept? ;)

vielen Dank schonmal im Voraus!

LG das SorgenkindMech

[Sven Rautenberg]

Moin!

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.

Die Seite selbst hat als kodierung ISO-8859-1 / Latin-1, die mysql-DB ist auch auf Latin-1 eingestellt. Dadurch erhoffe ich mir zumindest die einfachste Handhabung.

Das ist schlecht. Stelle um auf UTF-8, oder du landest in der Codierungshölle...

Nun das Problem: Wenn ich alle Dateien in UTF-8 speichere, so werden umlaute und sonderzeichen nicht korrekt dargestellt, was ja auch logisch ist, da die seite Latin-1 vorgibt. Stelle ich manuell im Browser auf UTF-8, so werden einige korrekt dargestellt, manche nicht...

Ok, du bist in der Codierungshölle angelangt. Sehr schön. :)

wenn ich in den direkt aufgerufenen Dateien das BOM einschließe und in den includeten Dateien das BOM NICHT einschließe, so wird alles perfekt dargestellt, absolut keine probleme.

BOM ist nirgendwo notwendig bei UTF-8.

wenn ich in alle dateien BOM einschließe hab ich bei includeten dateien dieses tolle BOM als ausgabe im Browser (), was ich natürlich nicht haben will ...

Also weg damit.

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

[niklaskamenisch]

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

[SorgenkindMech]

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

[Gunnar Bittersmann]

@@SorgenkindMech:

nuqneH

zumindest fallen mir gerade keine zeichen ein, die ich [in latin1] vermissen würde.

Mir fallen da sofort einige ein: €, Anführungszeichen, Gedankenstriche, …

Qapla'

[Der Martin]

Hallo,

zumindest fallen mir gerade keine zeichen ein, die ich [in latin1] vermissen würde.
Mir fallen da sofort einige ein:

das war nicht anders zu erwarten. ;-)

€

Bevorzugt als "EUR" geschrieben.

Anführungszeichen

0x22 und 0x27 finde ich mehr als ausreichend.

Gedankenstriche

Auch 0x2D existiert und wird mit einem Blank davor und dahinter vom Bindestrich zum Gedankenstrich umgewidmet.

Ergo: Zumindest die deutsche und ein paar andere europäische Sprachen kann man mit dem Zeichenvorrat aus Latin-1 verlustfrei abbilden. Die diversen typographischen Perversionen vielleicht nicht. Muss man aber auch nicht.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

€
Bevorzugt als "EUR" geschrieben.

Von Bankern. Wieviel (besser: wie wenig) Ansehen die heutzutage genießen, sollte bekannt sein.

Normale Leute verwenden bevorzugt das €-Zeichen.

Anführungszeichen
0x22 und 0x27 finde ich mehr als ausreichend.

Sie tun in Programmiersprachen gute Dienste. In der Schriftform menschlicher Sprachen tun sie Bärendienste.

Gedankenstriche
Auch 0x2D existiert und wird mit einem Blank davor und dahinter vom Bindestrich zum Gedankenstrich umgewidmet.

Nein. Ein Bindestrich zwischen zwei Lehrzeichen sieht aus wie Scheiße, nicht wie ein Gedankenstrich. Ein Bindestrich ist und bleibt ein Bindestrich. Er wird weder zu einem Gedankenstrich noch zu einem Minuszeichen (Programmierspachen ausgenommen).

Ergo: Zumindest die deutsche und ein paar andere europäische Sprachen kann man mit dem Zeichenvorrat aus Latin-1 verlustfrei abbilden.

Nein. Das große ẞ fehlt.

Die diversen typographischen Perversionen vielleicht nicht.

Bedenke: lustig sein ≠ sich lächerlich machen.

Pervers ist es, die Mehrfachverwendung einiger Zeichen aus der Schreibmaschinenschrift (wo die Anzahl der Typen begrenzt war) in den Computersatz mit Proportionalschriften zu übernehmen.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Pervers ist es, die Mehrfachverwendung einiger Zeichen aus der Schreibmaschinenschrift (wo die Anzahl der Typen begrenzt war) in den Computersatz mit Proportionalschriften zu übernehmen.

“Ambi­dext­rous quotes were intro­du­ced on type­writers as a space‐sa­ving mea­sure. That they have somehow sur­vived un­chang­ed into the era of digi­tal com­puters is actually rather shocking,” findet auch Aral Balkan.

“We’ve raised several gen­erat­ions of people who have no app­re­cia­tion for proper typographical punc­tua­tion.”

Ja, traurig.

Qapla'

[Der Martin]

Hallo,

We’ve raised several gen­erat­ions of people who have no app­re­cia­tion for proper typographical punctua­tion.
Ja, traurig.

eine Frage des Standpunkts. Ich betrachte gerade diese Reduktion als Fortschritt.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

We’ve raised several gen­erat­ions of people who have no app­re­cia­tion for proper typographical punctua­tion.
eine Frage des Standpunkts. Ich betrachte gerade diese Reduktion als Fortschritt.

NA DANN DOCH GLEICH NÆGEL MIT KŒPFEN MACHEN VND AVCH DIE BVCHSTABEN REDVZIEREN MINUSKELN BRAVCHT KEIN MENSCH INTERPVNKTION AVCH NICHT

Qapla'

[SorgenkindMech]

Huhu,

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

ich habe mal einen teil der seite und ein teil der datenbank "umgestellt" bin aber noch nicht wirklich zufrieden:

die php-dateien sind nun in unicode gespeichert
der html-charset ist nun UTF-8
die datenbanktabelle habe ich mittels ALTER TABLE tabellenname CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; geändert.

im speziellen habe ich eine art nachrichtensystem aktualisiert, wo es ein betreff und eine nachricht gibt. neue nachrichten werden perfekt dargestellt, alle umlaute und sonderzeichen sind top

bei den alten nachrichten gibt es jedoch nun probleme, im browser werden vierecke dargestellt. 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

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

ich habe mir nun mal den spar gemacht und einen neuen eintrag und einen alten eitrag ausgelesen

die beiden einträge sind:
(neu) test ä ü ö . ß ? = % $ " bla
(alt) Großraumstörung in Beckum

nun habe ich mir den spaß gemacht und die beiden "ß" verglichen
$test1=substr($test1,16,2);
$test2=substr($test2,3,1);
echo "'".dechex(ord($test1))." (".ord($test1).")'-'".dechex(ord($test2))." (".ord($test2).")'";

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

laut http://www.utf8-zeichentabelle.de/unicode-utf8-table.pl?view=2:
U+00DF - ß - c3 9f
ich mein das DF passt ja, resultiert aber in einem viereck
und das C3(Hex) passt ja auch, und wird auch korrekt als ß dargestellt

meinem verständnis nach stehen in der db die Unicode-Zeichenpositionen bei den alten einträgen, und bei den neuen einträgen die Hexadezimale UTF-8-Deklarierung

wenn das richtig ist, wie bekomme ich das korrekt konvertiert?

danke schonmal für eure antworten!

[SorgenkindMech]

ok man sollte vielleicht auch beachten die servervariablen zu ändern:

mysql_query("SET character_set_client=utf8");
mysql_query("SET character_set_connection=utf8");
mysql_query("SET character_set_database=utf8");
mysql_query("SET character_set_results=utf8");
mysql_query("SET character_set_server=utf8");
mysql_query("SET character_set_system=utf8");

zumindest werden jetzt einige werte mehr korrekt dargestellt, dafür andere umso schlimmer, aber ich vermute, das liegt an der noch nicht oder vielleicht doppelten konvertierung einer tabelle, mal schauen ;)

[dedlfix]

Tach!

ok man sollte vielleicht auch beachten die servervariablen zu ändern:

mysql_query("SET character_set_client=utf8");
mysql_query("SET character_set_connection=utf8");
mysql_query("SET character_set_database=utf8");
mysql_query("SET character_set_results=utf8");
mysql_query("SET character_set_server=utf8");
mysql_query("SET character_set_system=utf8");

Das ist viel zu umständlich und teilweise nicht zielführend. character_set_system müsste sogar einen Fehler zurückliefern, weil der sich nicht in der Client-Sitzung sondern nur in der Konfiguration umstellen lässt. Ein SET NAMES utf8 jedenfalls oder der Aufruf von mysql(i)_set_charset() reicht für deine Client-Verbindung völlig.

dedlfix.

[SorgenkindMech]

Tach!

ok man sollte vielleicht auch beachten die servervariablen zu ändern:

mysql_query("SET character_set_client=utf8");
mysql_query("SET character_set_connection=utf8");
mysql_query("SET character_set_database=utf8");
mysql_query("SET character_set_results=utf8");
mysql_query("SET character_set_server=utf8");
mysql_query("SET character_set_system=utf8");

Das ist viel zu umständlich und teilweise nicht zielführend. character_set_system müsste sogar einen Fehler zurückliefern, weil der sich nicht in der Client-Sitzung sondern nur in der Konfiguration umstellen lässt. Ein SET NAMES utf8 jedenfalls oder der Aufruf von mysql(i)_set_charset() reicht für deine Client-Verbindung völlig.

dedlfix.

hi,

super danke nochmal für die erläuterungen

ich hab deien vorherigen post auch gelesen, trotz meiner fehlerhaften schlussfolgerungen bin ich zufällig dennoch ans ziel gekommen, glück gehabt ;)

aber danke, im endeffekt wirds nun klarer ;)

LG SorgenkindMech

[dedlfix]

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.