Unknown system variable 'NAMES'

[Martin Hein]

Hallo Forum,

ich hatte vor kurzem ein Problem mit verschiedenen Zeichensätzen
mit PHP und MySQL. ->

http://forum.de.selfhtml.org/archiv/2007/5/t152673/#m993885

Das Problem konnte ich damals dank der Mithilfe von illcp und
Sven Rautenberg lösen, indem ich dem eigentlichen Suchquery

mysql_query('SET NAMES 'utf8'');

voranschickte. Das funktionierte wunderbar auf meiner Entwicklungs-
umgebung. Auf dem Liveserver läuft allerdings eine ältere MySQL,
was das Problem zu sein scheint. Ich bekomme eine Fehlermeldung:

"Unknown system variable 'NAMES'"

Ich kann die DB-Version auf dem Liveserver nicht beeinflussen.

Weiss jemand Rat, was ich da machen kann ?

Danke und

viele gruesse,
martin hein

[dedlfix]

echo $begrüßung;

mysql_query('SET NAMES 'utf8'');
Das funktionierte wunderbar auf meiner Entwicklungsumgebung. Auf dem Liveserver läuft allerdings eine ältere MySQL, was das Problem zu sein scheint. Ich bekomme eine Fehlermeldung:
"Unknown system variable 'NAMES'"

Das wird ein System kleiner als Version 4.1 sein. Diese Versionen können nicht mit UTF-8 umgehen. Man kann problemlos UTF-8-kodierte Daten hinsenden und wieder zurückbekommen, aber eine serverseitige String-Verarbeitung (inklusive Vergleich) wird nicht richtig funktionieren. Das SET NAMES-Statement gehört zum stark verbesserten Zeichensatz-Konzept, das ab Version 4.1 vorhanden ist.

Es ist immer eine gute Idee, die Entwicklungsumgebung an das Produktivsystem anzupassen, um hinterher nicht feststellen zu müssen, dass bestimmte Funktionalitäten auf dem letzterem nicht vorhanden sind oder anders funktionieren.

Eine Möglichkeit mit solch gravierend unterschiedlichen Versionsständen zu arbeiten, ist, die Datenbankschicht mit versionsabhängigen "Treibern" zu versehen.

echo "$verabschiedung $name";

[Martin Hein]

hi,

dass mit den unterscheidlichen Versionen ist natürlich saublöd,
liess sich in dem Fall schwer vermeiden, weil und passiert mir
sicher auch nicht wieder.

Ich hatte mir nur die phpinfo() gecheckt ;(

Das System ist '2.7.0-pl2' und das Problem ist, dass ich das
Kuddelmuddel mit den Ziechensätzen immernoch nicht wiklich
verstanden habe.

Jetzt steht in meiner DB (jedenfalls laut PHPMyAdmin) ein
"Ä", dass ich da mit deinem SELECT hinaushole, mit einem
"htmlspecialchars" umwandle, um es auf einer Seite, die
mit "<meta ...; charset=UTF-8" />" darzustellen. Dargestellt
wird aber ein "?"

Ursprünglich hatte ich "htmlentities" verwendet, was aber nicht
funktionierte, wenn ich die DB nach einem "Ä" durchsucht habe.

Ich hab überhaupt keine Ahnung, was ich tun kann.

viele grüsse,
martin hein

[dedlfix]

echo $begrüßung;

dass mit den unterscheidlichen Versionen ist natürlich saublöd,
Ich hatte mir nur die phpinfo() gecheckt ;(

Die sagt zur MySQL-Server-Version nichts aus. Wie soll sie auch, ohne zu wissen, welcher Server gefragt werden soll. Die von phpinfo() angezeigt Versionsnummer ist die der Client-API. Die kann mit der Version des Servers übereinstimmen, wenn z.B. beides aus den gleichen Quellen kompiliert wurde.

Das System ist '2.7.0-pl2'

Das ist auch keine MySQL-Server-Version, sondern die vom phpMyAdmin.

und das Problem ist, dass ich das Kuddelmuddel mit den Ziechensätzen immernoch nicht wiklich verstanden habe.

Jetzt steht in meiner DB (jedenfalls laut PHPMyAdmin) ein "Ä", dass ich da mit deinem SELECT hinaushole, mit einem "htmlspecialchars" umwandle, um es auf einer Seite, die mit "<meta ...; charset=UTF-8" />" darzustellen. Dargestellt wird aber ein "?"

Wenn der PMA etwas richtig anzeigt, deutet das nur darauf hin, dass die Daten im Feld ordnungsgemäß eingetragen sind. Wenn beim Abfragen Mist entsteht, ist meist eine für die Verbindung falsche eingestellte Kodierung schuld.
htmlspecialchars() hat keinen Einfluss auf die Umlaute.
Da MySQL kleiner als 4.1 die Daten (hierzulande) Latin1-kodiert ausliefert, kann man diese nicht einfach so in ein UTF-8-Dokument einfügen. Das ist eine ungültige Byte-Folge, die mit einem Ersatzzeichen angezeigt wird. Der ursprüngliche Byte-Wert geht beim Weiterverarbeiten verloren.

Ich hab überhaupt keine Ahnung, was ich tun kann.

Möglichkeit 1: Lege UTF-8-kodierte Daten in der Datenbank ab. Sende UTF-8-kodierte Daten zur DB und du bekommst sie so wieder zurück. Das reicht aus, wenn man seitens des DBMS nicht weiter mit den Daten arbeiten will. Unter Umständen kann man sogar suchen. Jedenfalls muss man sich dabei imKlaren sein, dass MySQL von 1 Byte = 1 Zeichen ausgeht, was bei UTF-8 ja nicht der Fall ist. Es ist auch nicht mehr richtig möglich, mit dem PMA zu arbeiten, da dieser nun die Nicht-ASCII-Zeichen nicht richtig darstellen kann.

Möglichkeit 2: Wandle deine Daten vor dem Eintragen in die Datenbank nach Latin1[*] um, und nach dem Abfragen nach UTF-8. Dabei kann es zu Zeichenverlust kommen, wenn Nicht-Win-1252-Zeichen von der Anwendung kommen. Beachte, dass die Konvertierungsfunktion Win-1252 verwendet, sonst hast du schon beim €-Zeichen Probleme.

Möglichkeit 3: Erkunde, ob nicht doch irgendwie ein MySQL Version 4.1 oder größer zur Verfügung steht.

[*] MySQL versteht darunter Win-1252, nicht das eigentliche, weniger Zeichen enthaltende ISO-8859-1. Zu den Unterschieden siehe: http://de.wikipedia.org/wiki/ISO-8859-1.

echo "$verabschiedung $name";

[Martin Hein]

hi,

dass '2.7.0-pl2' nicht den db-server, sondern die phpmyadmin meint,
ist mir dann auch aufgefallen. wir sprechen von einem sytem, dass
sich 'MySQL 4.0.15-Max' nennt. spielt aber an dieser stelle wohl
auch keine rolle, sondern betaetigt nur die annahme, dass der db-server > 4.1 ist.

ich habe nun folgenden weg ausprobiert:
---------------------------------------
1. für die verarbeitung meines $_post-paramters im select-statement:
"SELECT ... LIKE ".mysql_real_escape_string(utf8_decode($-post[]))

2. für die darstellung der db-inhalte im browser htmlspecialchars((utf8_encode())

das führt auf den ersten blick zur lösung. was ich mir vorstellen kann, ist:

dass das zu deinem unter 2. skizzierten problem führen kann. wenn
ich dich richtig verstanden habe, scheint die beste möglichkeit
ein update des db-servers zu sein. allerdings wird doch in jedem
fall eine umwandlung stattfinden, oder ? "SET NAMES utf8" als
mysql-anweisung vor der weiterverarbeitung ist doch auch eine
umwandlung. was wäre denn der sicherste weg ?

merci und

viel gruesse,
martin hein

[dedlfix]

echo $begrüßung;

[derzeitige Lösung]

Das sieht den Umständen entsprechend in Ordnung aus.

scheint die beste möglichkeit ein update des db-servers zu sein. allerdings wird doch in jedem fall eine umwandlung stattfinden, oder ? "SET NAMES utf8" als mysql-anweisung vor der weiterverarbeitung ist doch auch eine umwandlung. was wäre denn der sicherste weg ?

Das "SET NAMES utf8" ist nur ein Hinweis an den Server, dass die zu erwartenden Daten UTF-8-kodiert sind und dass die Ergebnisdatenmenge ebenso kodiert sein soll. Es findet nur dann seitens MySQL eine Konvertierung statt, wenn die Kodierungseinstellung eines oder mehrerer Felder anders ist als die Verbindungskodierung.

echo "$verabschiedung $name";

[Martin Hein]

hi,

ich werde mich mal mit t-systems in verbindung setzen, ob da ein
update möglich ist, hab allerdings eher weniger hoffnung. aber mal
sehen ...

... ob ich meine lösung fahren muss.

Das "SET NAMES utf8" ist nur ein Hinweis an den Server, dass die zu erwartenden Daten UTF-8-kodiert sind und dass die Ergebnisdatenmenge ebenso kodiert sein soll. Es findet nur dann seitens MySQL eine Konvertierung statt, wenn die Kodierungseinstellung eines oder mehrerer Felder anders ist als die Verbindungskodierung.

wenn ich dich richtig verstehe, gibst du mir insofern recht, als
dass eine "umwandlung" (=="konvertierung") stattfindet. nur eben,
dass sie seitens mysql stattfindet, was aber sicherer, ergo
vorzuziehen ist ?

vieln gruesse,
martin hein

[dedlfix]

echo $begrüßung;

Das "SET NAMES utf8" ist nur ein Hinweis an den Server, dass die zu erwartenden Daten UTF-8-kodiert sind und dass die Ergebnisdatenmenge ebenso kodiert sein soll. Es findet nur dann seitens MySQL eine Konvertierung statt, wenn die Kodierungseinstellung eines oder mehrerer Felder anders ist als die Verbindungskodierung.

wenn ich dich richtig verstehe, gibst du mir insofern recht, als dass eine "umwandlung" (=="konvertierung") stattfindet. nur eben, dass sie seitens mysql stattfindet, was aber sicherer, ergo vorzuziehen ist ?

Wie gesagt, es kommt darauf an, ob du innerhalb des MySQL-Servers unterschiedliche Kodierungen verwendest. Wenn alle Felder UTF-8-kodiert sind und die Verbindung ebenfalls UTF-8 verwendet, findet keine Konvertierung statt. Die Felder solltest du natürlich auf UTF-8 stellen, sonst nützt es dir wenig, wenn du zwar UTF-8 reden kannst, dir aber nur Latin1 merkst.

echo "$verabschiedung $name";

[MudGuard]

Hi,

wir sprechen von einem sytem, dass sich  'MySQL 4.0.15-Max' nennt.
betaetigt nur die annahme, dass der db-server > 4.1 ist.

4.0 > 4.1?

Nach welcher Logik?

cu,
Andreas

[Martin Hein]

hi,

4.0 > 4.1?

Nach welcher Logik?

keine logik. verschreiber. sorry!

viele gruesse,
martin hein