| Author |
Message |
utf-8
knows MySQLDumper

Joined: 20 Oct 2010
Posts: 6

|
Posted:
2010-10-20, 18:14 Hilfe bei der Vorgehensweise Umstellung latin1 auf utf 8 |
  |
Hallo Forum,
Ich nutze mysql5.
Meine DB steht komplett auf latin1_german1_ci eingestellt.
Mein Webfrontend übergibt derzeit keine Zeichenkodierung. Bisher klappt auch alles problemlos, aber ich möchte dennoch auf UTF-8 umstellen.
In welcher Reihenfolge gehe ich nun vor, wenn ich absolut alles auf UTF-8 umstellen möchte?
1) header?
2) meta tag?
3) Dateien neu kodiert speichern?
4) Datenbank auf utf-8 umstellen?
5) Was ist mit den Wegen von Server zu mysql und zurück? Wie beeinflusse ich da die Kodierung? Ich kann die mysql-Konfiguration selber nicht beeinflussen, da sie beim Provider liegt.
6) was sonst noch?
7) ...
Und zu Punkt 3: Alle meine php-Dateien müssen ja auch auf UTF-8-Zeichenkodierung gespeichert werden.
Gibt es da ein Programm, was mir dabei hilft? Denn ich habe da etliche Dateien, die ich öffnen, speichern und wieder schließen müsste.
Gruß, Basti
|
|
  |
 |
Anzeigen
|
Posted:
Anzeigen |
 |
|
| |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg

|
Posted:
2010-10-20, 20:30 (No subject) |
  |
Quote: Meine DB steht komplett auf latin1_german1_ci eingestellt.
Das ist die Sortierungsvereinbarung (Kollation) und nicht der Zeichensatz! Der Zeichensatz einer Tabelle kann durchaus utf8 sein, während die Kollation latin1_german1_ci sein kann. Diese Angabe lässt nur indirekt Schlüsse auf den tatsächlichen Zeichensatz zu.
Siehe meinen Artikel zur Umlautproblematik hier im Forum unter FAQ.
1) Als Header sollte natürlich ein utf-8-Header gesendet werden
2) Sollte ebenfalls auf content-type ..;charset utf-8 gesetzt sein
3) Nur wenn die Skripte selbst utf-8-kodierte Zeichenketten enthalten, was normalerweise nicht der Fall ist (Lediglich PHP-Sprachdateien müssen in der Regel nach utf-8 ohne BOM konvertiert werden). Wenn alle Ausgabetexte aus der Datenbank kommen, ist das nicht notwendig.
4) Ja, klar.
5) Nach jedem Verbindungsaufbau zu MySQL aber vor dem Abholen von Datensätzen ein SET NAMES "utf8" senden.
6) Nichts mehr.
Quote: Gibt es da ein Programm, was mir dabei hilft?
Z.B. iconv
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
utf-8
knows MySQLDumper

Joined: 20 Oct 2010
Posts: 6

|
Posted:
2010-10-20, 22:00 (No subject) |
  |
« DSB » wrote:
Das ist die Sortierungsvereinbarung (Kollation) und nicht der Zeichensatz! Der Zeichensatz einer Tabelle kann durchaus utf8 sein, während die Kollation latin1_german1_ci sein kann. Diese Angabe lässt nur indirekt Schlüsse auf den tatsächlichen Zeichensatz zu.
Siehe meinen Artikel zur Umlautproblematik hier im Forum unter FAQ.
Hi DSB,
Deinen Artikel habe ich zuletzt gestern gelesen, davor aber auch schon 1 oder 2 mal.
Wie stelle ich denn fest, welcher Zeichensatz in der db tatsächlich verwendet wird?
Wäre es, wenn bei mir alles auf latin1 steht,nicht einfacher, als Zeichensatz in HTML Iso... anzugeben?
« DSB » wrote:
4) Ja, klar.
Wie gehe ich da genau vor?
Gruß, Basti
.
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg

|
Posted:
2010-10-20, 22:29 (No subject) |
  |
« utf-8 » wrote: Wie stelle ich denn fest, welcher Zeichensatz in der db tatsächlich verwendet wird?
Indem Du ein "SHOW CREATE TABLE `tabellenname`" ausführst und in der Ausgabe am Ende das "DEFAULT CHARSET="XXX"" betrachtest.
Quote: Wäre es, wenn bei mir alles auf latin1 steht,nicht einfacher, als Zeichensatz in HTML Iso... anzugeben?
Ach, Du hast gar keinen Grund auf utf-8 umzustellen?
Quote: « DSB » wrote:
4) Ja, klar.
Wie gehe ich da genau vor?
Wenn Du die Tabellenstruktur editierst kannst Du dort für die Tabelle Zeichensatz und Kollation wählen.
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
utf-8
knows MySQLDumper

Joined: 20 Oct 2010
Posts: 6

|
Posted:
2010-10-21, 00:39 (No subject) |
  |
Hi DSB,
"Ach, Du hast gar keinen Grund auf utf-8 umzustellen? "
Um ehrlich zu sein ist der einzige Grund, dass ich dann mit Umlauten im HTML-Code arbeiten kan ;-)
"Wenn Du die Tabellenstruktur editierst kannst Du dort für die Tabelle Zeichensatz und Kollation wählen."
Ääh, ich habe davon ein paar Datenbanken mit jeweils ca. 50 Tabellen und je durchschnittlich 10 Spalten :-)
Geht das nicht etwas einfacher?
Gruß, Basti
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg

|
Posted:
2010-10-21, 07:58 (No subject) |
  |
« utf-8 » wrote: Um ehrlich zu sein ist der einzige Grund, dass ich dann mit Umlauten im HTML-Code arbeiten kan ;-)
Das kannst Du - zumindest mit Deutschen Umlauten - auch mit einer latin1-Tabelle. Liegt Dein eigentliches Problem ganz woanders?
utf-8 nutzt man dann, wenn man Mehrsprachigkeit unterstützen muss. Wenn man das gar nicht benötigt, handelt man sich durch eine Umstellung lediglich einen höheren Speicherplatzverbrauch ein. Wenn Du also keinen Grund für eine Umstellung auf utf-8 hast, dann lass es.
Quote: Ääh, ich habe davon ein paar Datenbanken mit jeweils ca. 50 Tabellen und je durchschnittlich 10 Spalten :-)
Was hat das mit den Spalten zu tun? Ich glaube, Du hast immer noch nicht den Unterschied zwischen dem zugrunde liegenden Zeichensatz einer Tabelle und der Sortiervereinbarung verstanden. Lies Dir den Abschnitt dazu noch einmal im erwähnten Artikel durch.
Quote: Geht das nicht etwas einfacher?
Nein, als Admin musst Du wissen was Du tust. Bei einem Automatismus kann einiges schief gehen, da er nicht alle Fälle automatisch erkennen kann. Die Anforderungen, wie und was umgestellt werden muss, hängen zu stark vom benutzten System ab.
Deshalb bieten viele Foren- und/oder Blog-Systeme für diesen Zweck fertige Konvertierungsroutinen an, die man lediglich einmal aufrufen muss. Das liegt aber außerhalb des Verantwortungsbereichs von MySQLDumper und hat eben mit der jeweiligen, speziellen Anwendung zu tun.
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
utf-8
knows MySQLDumper

Joined: 20 Oct 2010
Posts: 6

|
Posted:
2010-10-21, 16:37 (No subject) |
  |
« DSB » wrote: « utf-8 » wrote: Um ehrlich zu sein ist der einzige Grund, dass ich dann mit Umlauten im HTML-Code arbeiten kan ;-)
Das kannst Du - zumindest mit Deutschen Umlauten - auch mit einer latin1-Tabelle. Liegt Dein eigentliches Problem ganz woanders?
utf-8 nutzt man dann, wenn man Mehrsprachigkeit unterstützen muss. Wenn man das gar nicht benötigt, handelt man sich durch eine Umstellung lediglich einen höheren Speicherplatzverbrauch ein. Wenn Du also keinen Grund für eine Umstellung auf utf-8 hast, dann lass es.
Hm.
Aber es hat doch zu mysql 3-Zeiten auch schon mehrspachig unterstützte Programme gegeben? Und da wurde immer in latin1 kodiert?
Aber Du hast Recht und einen guten Riecher, denn möglicherweise liegt mein Problem wirklich woanders.
Ich muß herausfinden, warum ein (vertrauenswürdiger) User zuletzt in meinen Blog folgenden Eintrag verfasste und vor allem, wie ich sowas künftig vermeide:
Quote:
Bla, Bla, Bla
Gr�sse, User
Derzeit übermittle ich keine Zeichenkodierung in meinen php-generierten HTML-Dokumenten und ich verwende weder mysql_set_charset() noch SET NAMES.
Meine DB läuft unter mysql 5.irgendwas und zum Backupo verwende ich (natürlich) MySQL-Dumper in der Version 1.22.
Gruß, Basti
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg

|
Posted:
2010-10-21, 19:03 (No subject) |
  |
« utf-8 » wrote: Aber es hat doch zu mysql 3-Zeiten auch schon mehrspachig unterstützte Programme gegeben?
Ja, aber das war immer viel Getrickse und ganz besonders in browserbasierten Anwendungen. IBM hat damit bis heute bei GreenScreen-Anwendungen erhebliche Probleme.
Deshalb hat man unicode ja entwickelt.
Quote: Ich muß herausfinden, warum ein (vertrauenswürdiger) User zuletzt in meinen Blog folgenden Eintrag verfasste und vor allem, wie ich sowas künftig vermeide:
Quote:
Bla, Bla, Bla
Gr�sse, User
Nichts leichter als das. Ich sage meinem Browser, dass er den Zeichensatz bei Deiner ISO-8859-x-Seite ignorieren soll, stelle also die automatische Zeichensatzerkennung ab und setze ihn manuell auf utf-8. Dann poste ich was mit Umlauten und schon bekommt Dein Skript utf-8 kodierte Daten und speichert sie treudoof als latin1 in der DB ab. Dann hast Du diesen Effekt.
Du kannst versuchen, dem entgegenzuwirken, indem Du Deinen Forms ein accept-charset mitgibst:
<form action="..." method="post" accept-charset="ISO-8859-1">
Inwiefern das aber wirklich und zuverlässig greift habe ich nicht getestet.
Quote: zum Backup verwende ich (natürlich) MySQL-Dumper in der Version 1.22.
Warum 1.22 obwohl V 1.24 seit einem Jahr draußen ist? Wir entwickeln nicht zum Spaß (ok, nicht nur ) weiter, sondern besonders weil sinnvolle Anpassungen drin sind.
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
utf-8
knows MySQLDumper

Joined: 20 Oct 2010
Posts: 6

|
Posted:
2010-10-21, 23:29 (No subject) |
  |
« DSB » wrote:
Quote: Ich muß herausfinden, warum ein (vertrauenswürdiger) User zuletzt in meinen Blog folgenden Eintrag verfasste und vor allem, wie ich sowas künftig vermeide:
Quote:
Bla, Bla, Bla
Gr�sse, User
Nichts leichter als das. Ich sage meinem Browser, dass er den Zeichensatz bei Deiner ISO-8859-x-Seite ignorieren soll, stelle also die automatische Zeichensatzerkennung ab und setze ihn manuell auf utf-8. Dann poste ich was mit Umlauten und schon bekommt Dein Skript utf-8 kodierte Daten und speichert sie treudoof als latin1 in der DB ab. Dann hast Du diesen Effekt.
Aber der Browser des Users stand auf Automatik.
Ich denke, es liegt daran, dass ich selber weder den Zeichensatz per Header oder meta Daten festlege, noch per Verbindung zu mysql, oder?
Also muß ich da jetzt nachbessern.
Aber was konkret?
Es geht nicht darum, dass mir irgendwer Codesalat ganz bewußt einschleust. Da gibt es interessantere Möglichkeiten. Der User hat das unbewußt, versehentlich gemacht. Und er selber hat mir den Fehler mit Bitte um Verzeihung gemeldet.
Zu den Versionen: Ich etwickel ja selber Software und weiß, wie schade das ist, wenn User mit alten Versionen arbeiten. Ich verstehe also Deinen Hinweis zu Vers. 1.22 vs. 1.24. Vergiss aber nicht, dass wir Entwickler wirklich einen Tunnelblick für unser Projekt entwickeln und nur schwerlich verstehen können, wenn die User da nicht genauso 100%ig mitziehen, wie wir entwickeln. Frustet mich auch immer wieder. Versprochen, ich schau mir die Änderungen seit 1.22 an und update, wenn sich viel geändert hat.
Peace ;-), UTF-8
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16070
Location: Reichenberg bei Würzburg

|
Posted:
2010-10-22, 07:53 (No subject) |
  |
« utf-8 » wrote: Ich denke, es liegt daran, dass ich selber weder den Zeichensatz per Header oder meta Daten festlege, noch per Verbindung zu mysql, oder?
Auf der Umlautproblematik-Seite sind 2 Artikel aus dem Internet magazin von mir verlinkt. Dort werden alle Stolperstellen recht ausführlich angesprochen. Mehr kann ich diesbezüglich aus der Ferne nicht für Dich tun.
Du musst die programmtechnische Kontrolle über die Zeichensätze in der gesamten Kette (Browser - PHP - MySQL) in beide Richtungen übernehmen. Wenn Du das programmtechnisch nicht tust, sind die Ergebnisse nicht vorhersehbar (sie hängen dann ausschließlich von Umgebungsparametern des/der Server ab) und es kann Dir ohne Kenntnis Deines Codes auch niemand helfen.
Hier noch einmal die Links:
http://www.internet-magazin.de/ratgeber/codierungsprobleme-in-mysql-beheben-175128.html
http://www.internet-magazin.de/ratgeber/mysql-codierungsproblem-beheben-nie-wieder-umlaut-chaos-185474.html
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
|
|
CrackerTracker © 2004 - 2012 CBACK.de
Powered by Orion based on phpBB
© 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours
phpBB SEO
|