Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hallo,
beim Datenübertragen von einer 5.0-Tabelle
auf eine MySql 4.0.23 Tabelle werden die
Umlaute nit korrekt dargestellt. Z.B.:
Büsche

MySql 5.0
Zeichensatz / Kollation der MySQL-Verbindung:
utf8_unicode_ci
Kollation auf einigen Feldern:
latin1_general_ci

MySql 4.0
Zeichensatz / Kollation der MySQL-Verbindung:
utf8_unicode_ci

Kompat. auf MySql 4.0 hatte ich beim Export
schon eingestellt ...
(und das bei dem Wetter ...)

Weiß jemand worauf ich da achten muß,
was anzupassen ist??

Vielen Dank schonmal,
Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Claudia Calone schrieb:
> Hallo,
> beim Datenübertragen von einer 5.0-Tabelle
> auf eine MySql 4.0.23 Tabelle werden die
> Umlaute nit korrekt dargestellt.

Jedes Programm stellt selbst ein, in welchem Zeichensatz es die Daten
von mysql erwartet bzw. einliefert. mysql codiert um, wenn die Daten in
einem anderen Zeichensatz gespeichert sind, als sie übertragen werden
müssen (kostet natürlich Rechenzeit und ist auch nicht immer verlustfrei
möglich).
Wenn das eine Programm UTF-8 einstellt und das andere latin-1, dann
kommen genau solche Ergebnisse raus...

Es ist übrigens auch möglich, dass es sich um einen reinen Anzeigefehler
handelt. Der erste Schritt ist also: kontrollieren, welcher Zeichensatz
von dem Programm verwendet wird, das die Daten auf den Bildschirm
bringt. (Ggf. mit phpmyadmin: in Browsern funktioniert UTF-8 oft besser
als in einer SSH-Konsole oder in der Windows-Eingabeaufforderung. Aber
auch dann muss man kontrollieren, ob das phpmyadmin, das man da hat,
wirklich mit UTF-8 klarkommt - einige ältere Versionen machen es falsch.)

Die Collation (Sortierreihenfolge) ist für den Datentransfer erstmal
unwichtig. Die kommt erst dann wieder zum Tragen, wenn man
Anwendungsprogramme auf die Tabellen loslässt.

Grüße
Jo

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Danke,
grob verstanden - theoretisch, hilft aber nicht.
Wie kann ich die Umlaute aus MySql 5 denn
"einfach normal" bzw. "anders" ausgeliefert bekommen??

Wo beeinflußt man, dass in einer
Export-sql und -cvs nicht ü sondern ü steht??

Ich habe hier XAMPP für Windows Version 1.5.5. ...
Moz-Browser steht auf ISO-8859-1, ebenso die
html-head-Einstellung.

Auf entferntem Server liegen o.g. Vers. MySql 4 - mit
den aus MySql 5 "falsch" codierten Zeichen.

Ich kann innerhalb einer Datei doch nicht
2 Kodierungen anbieten.

Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hi Joachim
> ...
> Wenn das eine Programm UTF-8 einstellt und das andere latin-1, dann
> kommen genau solche Ergebnisse raus...
MySql 5 stellt UTF-8 ein,
MySql 4 latin-1 ? ... ?
Das ist doch *ein* Browser und beides nur MySql???
Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Claudia Calone schrieb:
> Wie kann ich die Umlaute aus MySql 5 denn
> "einfach normal" bzw. "anders" ausgeliefert bekommen??

"Einfach normal" gibt's nicht :-)

Unter Windows sind cp1250 (Windows), cp1250 (latin1) und utf8 üblich.
Ich weiß gar nicht mehr, was XAMPP als Default annimmt, ich hab's
ziemlich rasch auf utf8 umgestellt.

> Wo beeinflußt man, dass in einer
> Export-sql und -cvs nicht ü sondern ü steht??

Die Befehlszeilentools (mysql, mysqldump etc.) verwenden die my.cnf,
soweit man nicht explizit eine Option auf der Befehlszeile angibt.
phpmyadmin kann ebenfalls konfiguriert werden, in der config.inc.php
gibt es Einstellungen dafür.

> Ich habe hier XAMPP für Windows Version 1.5.5. ...
> Moz-Browser steht auf ISO-8859-1, ebenso die
> html-head-Einstellung.

Das klingt verdächtig nach einem Problem im phpmyadmin.
Welche Version von phpmyadmin ist denn da im Einsatz? Einige ältere
Versionen hatten Bugs in der Zeichensatzbehandlung.
Ich bin auf 2.6.4-pl3, da klappt alles (ich glaube aber, ich habe
phpmyadmin auf utf-8 umkonfiguriert).

>> Wenn das eine Programm UTF-8 einstellt und das andere latin-1, dann
>> kommen genau solche Ergebnisse raus...
> MySql 5 stellt UTF-8 ein,
> MySql 4 latin-1 ? ... ?
> Das ist doch *ein* Browser und beides nur MySql???

Wenn die beiden mysql-Installationen unterschiedliche Einstellungen für
die Zeichensätze verwenden, kann es da durchaus Unterschiede geben.


Grüße
Jo

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hallo Joachim,
Vielen Dank!
> ...
in meiner config.inc.php steht
$cfg['DefaultCharset'] = 'iso-8859-1';
....
$cfg['AvailableCharsets'] = array(
'iso-8859-1',
...
'utf-8',
.... ...
> ...
> Das klingt verdächtig nach einem Problem im phpmyadmin.
> Welche Version von phpmyadmin ist denn da im Einsatz?
mein hoster hat 2.6.4-pl3 (PHP 4.4.2)
und hier ist 2.9.1.1

hosters Apache hat
HTTP_ACCEPT_CHARSET ISO-8859-15,utf-8
Accept-Charset ISO-8859-15,utf-8

PHP Variables
_SERVER["HTTP_ACCEPT_CHARSET"] ISO-8859-15,utf-8
> ...
> Wenn die beiden mysql-Installationen unterschiedliche Einstellungen für
> die Zeichensätze verwenden, kann es da durchaus Unterschiede geben.
in meiner c:\win\my.ini steht u.a.:
character-set-server = latin1
collation-server = latin1_general_ci

ebenso in meiner my.cnf, die im bin-Verz. liegt

obwohl bei meinem phpMyAdmin-Eingangsscreen sowas steht:
MySQL-Zeichensatz: UTF-8 Unicode (utf8)

hosters my.* konnte ich nicht finden / einsehen.

vielleicht meine my.* character... mal auf
utf8 ändern? Was trägt man da ein?

Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

> ebenso in meiner my.cnf, die im bin-Verz. liegt
>
> obwohl bei meinem phpMyAdmin-Eingangsscreen sowas steht:
> MySQL-Zeichensatz: UTF-8 Unicode (utf8)
>
> hosters my.* konnte ich nicht finden / einsehen.
>
> vielleicht meine my.* character... mal auf
> utf8 ändern? Was trägt man da ein?
>
my.conf auf Home-rechner und hoster ist doch was völlig verschiedens?
Was sagt ein "SHOW VARIABLES LIKE 'character%'" auf beiden Seiten (?);
vermutlich was völlig verschiedenes?
Stelle einfach bei beiden utf8 ein und konterviere (wenn denn Tabellen
mit falschen Zeichensätzen da sind) in den entspr. Zeichen-
satz (->mysql-Doc hier ist das sehr ausfürhlich beschrieben;
z.B. http://dev.mysql.com/doc/refman/5.1/de/charset.html
http://dev.mysql.com/doc/refman/5.1/de/localization.html)


S.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hi sylvio,
Danke!
>> ...
> my.conf auf Home-rechner und hoster ist doch was völlig verschiedens?
> Was sagt ein "SHOW VARIABLES LIKE 'character%'" auf beiden Seiten (?);
> vermutlich was völlig verschiedenes?
> ...
*beim hoster*:
character_set latin1
character_sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620
ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew
win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257
latin5
convert_character_set

*und hier*:
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_filesystem binary
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir E:\xampp\mysql\share\charsets\

Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Claudia Calone schrieb:
> Hallo Joachim,
> Vielen Dank!
>> ...
> in meiner config.inc.php steht
> $cfg['DefaultCharset'] = 'iso-8859-1';

D.h. überall da, wo phpmyadmin nicht so genau weiß, welche Codierung
relevant ist, wird es iso-8859-1 alias latin1 nehmen.
Ich hab das bei mir auf utf-8 umgestellt, seither ist Ruhe.

> ...
> $cfg['AvailableCharsets'] = array(
> 'iso-8859-1',
> ...
> 'utf-8',

Das ist nur die Liste der Codierungen, die phpmyadmin erlauben soll.
Aber gut, dass utf-8 mit dabei ist, dann sollte die Umstellung bei
DefaultCharset keinen Ärger machen.

>> ...
>> Das klingt verdächtig nach einem Problem im phpmyadmin.
>> Welche Version von phpmyadmin ist denn da im Einsatz?
> mein hoster hat 2.6.4-pl3 (PHP 4.4.2)
> und hier ist 2.9.1.1

Das ist beides aktuell genug.

> hosters Apache hat
> HTTP_ACCEPT_CHARSET ISO-8859-15,utf-8
> Accept-Charset ISO-8859-15,utf-8

15? Na ja... manche exotischen Sonderzeichen könnten da in die Hose gehen.
Aber wenn sie beide UTF-8 können (was heutzutage zum Glück normal ist),
kann man den phpmyadmin ohne Gewissensbisse auf utf-8 umstellen und
davon ausgehen, dass wenigstens auf der Strecke vom Apache zum Browser
nix verkehrt umcodiert wird.
Im Fall von phpmyadmin geht es nur noch darum, dass er sich mit mysql in
utf-8 unterhält, dann sollte alles funktionieren.

> in meiner c:\win\my.ini steht u.a.:
> character-set-server = latin1
> collation-server = latin1_general_ci
>
> ebenso in meiner my.cnf, die im bin-Verz. liegt

Empfehlung: Umstellen auf utf8 bzw. utf8_general_ci.
Sonst wird dem mysql abverlangt, die Daten in latin1 zu konvertieren.

> obwohl bei meinem phpMyAdmin-Eingangsscreen sowas steht:
> MySQL-Zeichensatz: UTF-8 Unicode (utf8)
>
> hosters my.* konnte ich nicht finden / einsehen.

Hmm, ja, ist normal. Sylvios Hinweis auf SHOW VARIABLES ist die richtige
Spur.

> *beim hoster*:
> character_set latin1
> character_sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis
> tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251
> danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek
> win1250 croat cp1257 latin5

Das ist aber merkwürdig. Kein utf8?
Und character_set_connection wäre auch wichtig; ich wundere mich ein
bisschen, dass das nicht dabei ist. (Außer, mysql 4 hatte nur eine
einzige Einstellung.)

> *und hier*:
> character_set_client latin1
> character_set_connection latin1
> character_set_database latin1
> character_set_filesystem binary
> character_set_results latin1
> character_set_server latin1
> character_set_system utf8
> character_sets_dir E:\xampp\mysql\share\charsets\

Autsch.
Das wichtigste ist character_set_connection. Das ist die Codierung, in
der der Server mit phpmyadmin bzw. mysqldump redet. Das ist latin1, d.h.
wenn er mit dieser Einstellung eine Datei importiert, interpretiert er
das als latin1. Wenn in Wirklichkeit UTF-8 drinsteht, kommt nur Murks raus.
Außerdem sollten, wenn möglich, alle Einstellungen auf den gleichen
Zeichensatz gebracht werden, sonst ist mysql zu Konvertierungen
gezwungen, wenn es Daten aus einem Bereich in einen anderen zu bringen.

Eine Sache ist wirklich seltsam. Der Hoster hat latin1, Deine lokale
Installation ebenfalls. *Eigentlich* sollten die Daten damit sauber
importiert werden.
So, wie Du es beschreibst, vermute ich mal, dass Du die Daten mit
phpmyadmin vom Host exportiert hast, und der dortige phpmyadmin liefert
sie im UTF8-Format ab.

Diagnose: Die exportierte Datei mal im Binärformat aufmachen und
nachschauen, was denn da wirklich drinsteht.
Fängt die Datei mit den Bytes FFFE oder FEFF an, ist es definitiv UTF-8.
Ist jeder Umlaut in zwei Zeichen kodiert, ist es höchstwahrscheinlich
ebenfalls UTF-8.
Falls Du keinen Editor hast, der Dateien binär anzeigen kann: ich schaue
mir solche Sachen mit Textpad an. Das Programm ist zwar ein bisschen
veraltet, und Editieren im Binärmodus ist nicht grad das Gelbe vom Ei,
aber zum Anschauen reichts, und das Programm ist schnell installiert.

Zwei mögliche Gegenmittel:
1) Die lokale Installation möglichst komplett auf UTF-8 umstellen.
2) Dem phpmyadmin beim Import sagen, dass er die UTF8-Kodierung
verwenden soll. (Auf der Seite "SQL" kann man eine SQL-Datei angeben,
und unten drunter kann man "Zeichenkodierung der Datei" angeben.)

HTH
Jo

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Leute, die ganze Diskussion ist voll daneben. 4.0 hat noch keine
Unterstützung für transparentes Storage-Encoding, das wurde erst
mit 4.1 eingeführt. 4.0 speichert einfach alle Strings so, wie sie
ankommen und schert sich einen Sch**ss um das Encoding. Wenn du
utf8 in die Datenbank gestopft hast, kommt auch utf8 wieder raus.
Auch dann, wenn charset=latin1 in der my.cnf steht.


Joachim Durchholz wrote:
> Claudia Calone schrieb:
>> Hallo Joachim,
>> Vielen Dank!
>>> ...
>> in meiner config.inc.php steht
>> $cfg['DefaultCharset'] = 'iso-8859-1';
>
> D.h. überall da, wo phpmyadmin nicht so genau weiß, welche Codierung
> relevant ist, wird es iso-8859-1 alias latin1 nehmen.

AFAIK ist das das Encoding, in dem phpMyAdmin seine Ausgaben rendert.
Wenn es die Daten von der Datenbank in einem anderen Encoding bekommt,
muß es umwandeln. Aber in der Tat ist utf8 hier die einzig sinnvolle
Einstellung.

>> hosters Apache hat
>> HTTP_ACCEPT_CHARSET ISO-8859-15,utf-8
>> Accept-Charset ISO-8859-15,utf-8
>
> 15? Na ja... manche exotischen Sonderzeichen könnten da in die Hose gehen.
> Aber wenn sie beide UTF-8 können (was heutzutage zum Glück normal ist),
> kann man den phpmyadmin ohne Gewissensbisse auf utf-8 umstellen und
> davon ausgehen, dass wenigstens auf der Strecke vom Apache zum Browser
> nix verkehrt umcodiert wird.

Ganz andere Baustelle. Das ist das Encoding, in dem Apache Formular-
daten akzeptiert. Aber in der Tat sollte hier utf8 dabei sein, sonst
kann man u.U. keine Datensätze mit Umlauten per phpMyAdmin einfügen.

> Im Fall von phpmyadmin geht es nur noch darum, dass er sich mit mysql in
> utf-8 unterhält, dann sollte alles funktionieren.
>
>> in meiner c:\win\my.ini steht u.a.:
>> character-set-server = latin1
>> collation-server = latin1_general_ci
>>
>> ebenso in meiner my.cnf, die im bin-Verz. liegt
>
> Empfehlung: Umstellen auf utf8 bzw. utf8_general_ci.
> Sonst wird dem mysql abverlangt, die Daten in latin1 zu konvertieren.

Tja, nur daß MySQL 4.0.x das nicht kann. Keine Arme, keine Kekse!

Abgesehen davon halte ich es für eine Dumme Idee ganz allgemein
character-set-server=utf8 zu setzen. Dann ist nämlich für jede String-
Spalte utf8 der Default. Und wenn du bei CREATE TABLE kein Encoding
angibst (vergessen die meisten) reserviert MySQL für Daten und Indexe
gleich mal den dreifachen Platz, auch wenn da letzendlich nur latin1
Zeichen drin landen. Also den Default besser auf z.B. latin1 lassen
und dann nur die Spalten auf utf8 stellen, die das auch brauchen.

Für die Connection sieht das anders aus. Sobald die Chance besteht,
daß Daten in mehr als einem Encoding über die Leitung gehen, sollte
man hier auf utf8 stellen.

> > *beim hoster*:
> > character_set latin1
> > character_sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis
> > tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251
> > danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek
> > win1250 croat cp1257 latin5
>
> Das ist aber merkwürdig. Kein utf8?
> Und character_set_connection wäre auch wichtig; ich wundere mich ein
> bisschen, dass das nicht dabei ist. (Außer, mysql 4 hatte nur eine
> einzige Einstellung.)

*Klink*

> Eine Sache ist wirklich seltsam. Der Hoster hat latin1, Deine lokale
> Installation ebenfalls. *Eigentlich* sollten die Daten damit sauber
> importiert werden.
> So, wie Du es beschreibst, vermute ich mal, dass Du die Daten mit
> phpmyadmin vom Host exportiert hast, und der dortige phpmyadmin liefert
> sie im UTF8-Format ab.

Hinreichend neue Versionen von phpMyAdmin können Daten wahlweise als
utf8 exportieren (mysqldump ab 4.1 macht das per Default). Die Daten
werden auch mit einem

SET NAMES utf8;

weit am Anfang als utf8 gekennzeichnet. Und MySQL ab 4.1 kann das utf8
(Transport-)Encoding dann auch in das gewünschte Storage-Encoding
umwandeln. Nur MySQL 4.0 kann das nicht. Der Dump muß also als latin1
erfolgen *und* die Daten müssen auch wirklich latin1 sein.
Im einfachsten Fall jagt man den UTF8 Dump durch einen utf8 -> latin1
Konverter. Das SET NAMES steht ohnehin in einem magischen Kommentar und
wird von 4.0 überlesen.


XL

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hallo,
vielen Dank für die ausführlichen Antworten!

nochmal klargestellt:
ü ist also utf8
und
ü ist latin1

dann krieg ich *bei mir* MySql 5, myadmin 2.9.1.1 utf8 raus
und *hoster* MySQL 4.0.23-Max-log, myadmin 2.6.4-pl3 verarbeitet das nicht.

> ...
> Hinreichend neue Versionen von phpMyAdmin können Daten wahlweise als
> utf8 exportieren
oder latin1 exportieren bzw. müßte ich als solches exportieren?
mmh - wo das denn?
Abgesehen von einer Umstellung in der
phpmyadmin-cfg ($cfg['DefaultCharset']) latin1 / utf8, sehe
ich für die Vers. 2.9.1.1
nur Möglichkeiten unter Exportieren - SQL-Optionen
und da steht nichts, nur SQL-Kompatibilitätsmodi.

> (mysqldump ab 4.1 macht das per Default). Die Daten
> werden auch mit einem
>
> SET NAMES utf8;
>
Oder über die Console? (hab aber noch kaum Erfahrung damit ...)
z.B. mit mysqldump:
dann mit set-charset latin1 ...
Grüße, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hallo,
> Im einfachsten Fall jagt man den UTF8 Dump durch einen utf8 -> latin1
> Konverter.
welchen denn?
iconv?
Wie/wo würde ich das denn anwenden/aufrufen?
iconv -f iso-8859-1 -t utf-8 DATEINAME.sql
Ich find da im Netz (noch?) nichts zu.

Nach euren Beiträge wäre also allg. utf8 zu bevorzugen
bzw. zukunftssicherer?? Kann man das sagen?
Standardmäßig verwendet MySQL ja den Zeichensatz latin1.

Danke schon mal,
Gruß, C.

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Claudia Calone wrote:
> Hallo,
>> Im einfachsten Fall jagt man den UTF8 Dump durch einen utf8 -> latin1
>> Konverter.
> welchen denn?
> iconv?

z.B. Sonst kenne ich noch recode.

> Wie/wo würde ich das denn anwenden/aufrufen?
> iconv -f iso-8859-1 -t utf-8 DATEINAME.sql

Wohl eher anders herum (from utf8 to latin1)

Aber mir hat mysqldump --compatible=mysql40 ...
gerade alles hypsch als latin1 gedumpt. Auch die Umlaute aus der
utf8-Spalte wurden als latin1 gedumpt [1] und im CREATE TABLE fehlt
das 'charset utf8' (logisch, würde 4.0 ja auch nicht kennen)

> Nach euren Beiträge wäre also allg. utf8 zu bevorzugen
> bzw. zukunftssicherer?? Kann man das sagen?

So allgemein kann man das nicht sagen. UTF8 belegt mehr Platz und
macht die Verarbeitung auch allgemein langsamer (z.B. ist es viel
aufwendiger, die Länge eines Strings [also die Anzahl Zeichen] zu
bestimmen als bei latin1).

Andererseits bietet utf8 halt mehr als die 256 verschiedenen Zeichen
aus einem 8-bit Encoding. Also immer, wenn eine Spalte Strings
aufnehmen muß, die Zeichen aus verschiedenen Encodings enthalten
können, ist UTF8 eine gute Wahl. Manchmal auch ucs2.

> Standardmäßig verwendet MySQL ja den Zeichensatz latin1.

Ja. Sozusagen als default-default. Und weil MySQL aus dem schwe-
disch/finnischen Kulturkreis kommt, Collation latin1_swedish_ci.


XL


[1] Beispiel-Session mit Server version 5.0.42-log

mysql> create table t2 (c1 char(10) charset latin1, c2 char(10) charset utf8);
Query OK, 0 rows affected (0,01 sec)

mysql> insert into t2 values ("abcäöü", "abcäöü");
Query OK, 1 row affected (0,00 sec)


~ $mysqldump test
....
/*!40101 SET NAMES utf8 */;
....
DROP TABLE IF EXISTS `t2`;
CREATE TABLE `t2` (
`c1` char(10) default NULL,
`c2` char(10) character set utf8 default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

LOCK TABLES `t2` WRITE;
/*!40000 ALTER TABLE `t2` DISABLE KEYS */;
INSERT INTO `t2` VALUES ('abcäöü','abcäöü');
/*!40000 ALTER TABLE `t2` ENABLE KEYS */;
UNLOCK TABLES;
....


~ $mysqldump --compatible=mysql40 test
....
DROP TABLE IF EXISTS `t2`;
CREATE TABLE `t2` (
`c1` char(10) default NULL,
`c2` char(10) default NULL
) TYPE=MyISAM;

LOCK TABLES `t2` WRITE;
/*!40000 ALTER TABLE `t2` DISABLE KEYS */;
INSERT INTO `t2` VALUES ('abcäöü','abcäöü');
/*!40000 ALTER TABLE `t2` ENABLE KEYS */;
UNLOCK TABLES;

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Claudia Calone schrieb:
> Nach euren Beiträge wäre also allg. utf8 zu bevorzugen
> bzw. zukunftssicherer?? Kann man das sagen?

In der Tat.

Ein Beispiel:
Wir programmieren hier an Turniersoftware. Gelegentlich nehmen an diesen
Turnieren auch Teilnehmer aus westeuropäischen Ländern teil. Eigentlich
ist ja schon abzusehen, dass irgendwann auch Polen und Tschechen kommen,
und bevor wir uns dann *diese* Probleme antun, haben wir die Datenbanken
von vornherein auf UTF-8 ausgelegt.

Die von Axel Performance-Nachteile sind natürlich Realität. Andererseits
werden die Daten zwischen Datenbank und Applikation in der Regel ohnehin
mehrfach umkopiert und umkodiert, da kommt es auf einen
Verarbeitungsschritt mehr oder weniger in der Regel nicht an.

In der Regel, wohlgemerkt. Es kommt nur selten vor, aber manchmal muss
man auch das letzte Quäntchen Leistung herausholen.
Allerdings gibt es dann meistens auch jede Menge anderer
Optimierungsmöglichkeiten: schnellerer Prozessor, mehr RAM,
Lastverteilung auf mehrere Server, anderes Betriebssystem, anderes
Datenbanksystem, von Optimierungen in der Applikation mal ganz abgesehen :-)

Re: Zeichencodierungprobl. v. 5.0 -> 4.0 (Sprachbarriere ;-) )

Hallo & Danke!

so, fertig - aber etwas eigenwillig:

$querr = "SELECT * FROM ".$table."";
$result = @mysql_query($querr);
while ($row = mysql_fetch_row ($result)) {
echo "INSERT INTO `".$table."` VALUES ($row[0], ...);
";}

dann mit einem schönen, sauberen charset im Kopf :-)

in html und einfach per copy/past ins SQL-Fenster und ab.

bei iconv habe ich keinen Zeilenumbruch hinbekommen.
Mir wurd auch nicht klar, wie/wo anzuwenden.

Und die Beispiel-Session funktionieren, aber irgendwie
war das 3x Tabelle erstellen und füllen und löschen??

zu recode bin ich nit mehr gekommen.

Ich werd wohl bei latin bleiben.
Hab zwar mal bischen was mit griechisch zu tun,
aber nicht viel und dann könnt ich es wohl spaltenmäßig
codieren.

Vielen Dank nochmal,
beste Grüße, C.