Nochmal utf8
am 12.06.2006 15:11:06 von letters
Hallo, da bin ich schon wieder.
Ich hatte mich leider zu früh gefreut. Mit Varchar klappt zwar alles, aber
ich habe zu wenig Zeichen zur Verfügung. Kein Problem, hab ich mir gedacht,
wird das Feld eben wieder Longtext. Es gibt ja die Änderung des character
sets nach utf8. Aber leider falsch gedacht.
Folgendermaßen erstellte Tabelle funktioniert prima. Nur das die Spalte utf
zu wenig Zeichen besitzt.
CREATE TABLE `test_utf8` (
`id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
`utf` Varchar(255) CHARACTER SET utf8 NOT NULL ,
PRIMARY KEY ( `id` )
)
Hier klappt dann auch das Ein- und Auslesen.
Folgende Eingabe funktioniert aber nicht. Hier meckert mysql schon beim
Erstellen der Tabelle. Warum?
CREATE TABLE `test_utf8` (
`id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
`utf` LONGTEXT CHARACTER SET utf8 NOT NULL ,
PRIMARY KEY ( `id` )
)
Was ist an zweiter Syntax falsch? Oder anders, wenn ich longtext nicht auf
utf-8 bekomme, was muß ich dann nehmen?
Ich spring gleich im Dreieck. Kaum denkt man mal, es funktioniert, kommt
der nächste Stein ins rollen.
Fehlermeldung:
#1064 - You have an error in your SQL syntax. Check the manual that
corresponds to your MySQL server version for the right syntax to use near
'character set utf8 NOT NULL ,
PRIMARY KEY ( `id` )
)' at lin
Re: Nochmal utf8
am 12.06.2006 15:23:20 von letters
Ich muß noch dazu sagen, auf meinem Server läuft mysql 4.0
Re: Nochmal utf8
am 12.06.2006 15:30:04 von Christian Kirsch
Mathias Fiedler schrieb:
> Hallo, da bin ich schon wieder.
Schön - aber warum machst Du einen neuen Thread auf? Wenn es um
dasselbe Problem geht, dann schreib doch bitte da weiter, wo Du
aufgehört hast. Sonst geht nämlich jeder Zusammenhang flöten.
> Folgende Eingabe funktioniert aber nicht. Hier meckert mysql schon beim
> Erstellen der Tabelle. Warum?
>
> CREATE TABLE `test_utf8` (
> `id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
> `utf` LONGTEXT CHARACTER SET utf8 NOT NULL ,
> PRIMARY KEY ( `id` )
> )
>
> Was ist an zweiter Syntax falsch? Oder anders, wenn ich longtext nicht auf
> utf-8 bekomme, was muß ich dann nehmen?
>
> #1064 - You have an error in your SQL syntax. Check the manual that
> corresponds to your MySQL server version for the right syntax to use
near
> 'character set utf8 NOT NULL ,
> PRIMARY KEY ( `id` )
> )' at lin
Schaun wir mal.
Hier (mysql-5.0.15):
mysql> create table utf (didel longtext character set utf8 not null);
Query OK, 0 rows affected (0,07 sec)
Dito mit Deiner Query.
Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
Re: Nochmal utf8
am 12.06.2006 15:41:24 von letters
Am Mon, 12 Jun 2006 15:30:04 +0200 schrieb Christian Kirsch:
> Mathias Fiedler schrieb:
>> Hallo, da bin ich schon wieder.
>
> Schön - aber warum machst Du einen neuen Thread auf? Wenn es um
> dasselbe Problem geht, dann schreib doch bitte da weiter, wo Du
> aufgehört hast. Sonst geht nämlich jeder Zusammenhang flöten.
>
Das hat eben mein Newsreader von selbst gemacht.
>> Folgende Eingabe funktioniert aber nicht. Hier meckert mysql schon beim
>> Erstellen der Tabelle. Warum?
>>
>> CREATE TABLE `test_utf8` (
>> `id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
>> `utf` LONGTEXT CHARACTER SET utf8 NOT NULL ,
>> PRIMARY KEY ( `id` )
>> )
>>
>> Was ist an zweiter Syntax falsch? Oder anders, wenn ich longtext nicht auf
>> utf-8 bekomme, was muß ich dann nehmen?
>>
>> #1064 - You have an error in your SQL syntax. Check the manual that
>> corresponds to your MySQL server version for the right syntax to use
> near
>> 'character set utf8 NOT NULL ,
>> PRIMARY KEY ( `id` )
>> )' at lin
>
>
> Schaun wir mal.
>
> Hier (mysql-5.0.15):
>
> mysql> create table utf (didel longtext character set utf8 not null);
> Query OK, 0 rows affected (0,07 sec)
>
> Dito mit Deiner Query.
>
> Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
> jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
Leider wird es wohl an dem wort aktuell scheitern. Die verfügbare Veriosn
von mysql ist 4.0.25. (Managed Server bei Puretec)
Gibts für die 4.0.25 nicht auch eine Möglichkeit? Oder kann ich das UTF-8
mit irgendeiner anderen Codierung wieder in ein Format brigen, welches ich
unter Longtext speichern kann?
mfg
Mathias
Re: Nochmal utf8
am 12.06.2006 16:01:00 von Christian Schmelzer
Mathias Fiedler wrote:
> Ich muß noch dazu sagen, auf meinem Server läuft mysql 4.0
Hallo,
hm, mir war so als ob UTF-8 erst ab MySQL 4.1 existiert.
Christian
Re: Nochmal utf8
am 12.06.2006 16:03:29 von Christian Schmelzer
Christian Schmelzer wrote:
> Mathias Fiedler wrote:
>> Ich muß noch dazu sagen, auf meinem Server läuft mysql 4.0
>
> Hallo,
> hm, mir war so als ob UTF-8 erst ab MySQL 4.1 existiert.
>
Hehe, das klang natürlich komisch, also für MySQL existiert es meiner
Meinung nach erst ab 4.1
Christian
Re: Nochmal utf8
am 12.06.2006 16:03:57 von Christian Kirsch
Mathias Fiedler schrieb:
> Am Mon, 12 Jun 2006 15:30:04 +0200 schrieb Christian Kirsch:
>> Hier (mysql-5.0.15):
>>
>> mysql> create table utf (didel longtext character set utf8 not null);
>> Query OK, 0 rows affected (0,07 sec)
>>
>> Dito mit Deiner Query.
>>
>> Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
>> jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
>
> Leider wird es wohl an dem wort aktuell scheitern. Die verfügbare Veriosn
> von mysql ist 4.0.25. (Managed Server bei Puretec)
> Gibts für die 4.0.25 nicht auch eine Möglichkeit? Oder kann ich das UTF-8
> mit irgendeiner anderen Codierung wieder in ein Format brigen, welches ich
> unter Longtext speichern kann?
>
Richtigen UTF-8-Support gibt's erst ab MySQL 5.irgendwas, IIRC. Also
wirst Du wohl ein bisschen um das Problem rumarbeiten müssen.
LONGTEXT ist jedenfalls ein Format, das Dir das Speichern beliebiger
Zeichen erlaubt - also auch UTF-8. Du kannst aber den Zeichensatz
nicht deklarieren, und Du kannst auch keine vernünftigen Vergleiche
(Sortierung, Suche etc.) durchführen. Was allerdings bei LONGTEXT
ohnehin nicht sinnvoll sein dürfte. Wenn Du also *weißt*, dass Du in
der Spalte UTF-8 speicherst, dann ist doch eigentlich alles ok - Du
musst dann eben nur dafür sorgen, dass alle Anwendungen die Daten aus
dem Feld auch korrekt behandeln.
Was also ist Dein Problem genau?
Disclaimer: PHPMyAdmin ist aus guten Gründen hier *nicht* on-topic.
Re: Nochmal utf8
am 12.06.2006 16:27:14 von Axel Schwenke
Mathias Fiedler wrote:
> Am Mon, 12 Jun 2006 15:30:04 +0200 schrieb Christian Kirsch:
>
>>> CREATE TABLE `test_utf8` (
>>> `id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
>>> `utf` LONGTEXT CHARACTER SET utf8 NOT NULL ,
>>> PRIMARY KEY ( `id` )
>>> )
>>>
>>> #1064 - You have an error in your SQL syntax.
>> near
>>> 'character set utf8 NOT NULL ,
>> Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
>> jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
> Leider wird es wohl an dem wort aktuell scheitern. Die verfügbare Veriosn
> von mysql ist 4.0.25. (Managed Server bei Puretec)
MySQL Versionen vor 4.1 scheren sich kaum um den Zeichensatz, mit dem
Daten gespeichert werden. Abgesehen von String-Vergleich und Sortierung.
Es spricht also nicht viel dagegen, in einer TEXT oder LONGTEXT Spalte
Daten in UTF8 Kodierung abzulegen. MySQL gibt exakt die gleichen Daten
zurück, die du abgespeichert hast. BTDTMT.
Das Problem kommt beim Upgrade auf 4.1 oder 5.0 weil dann die Deklara-
tion (Server default-charset) nicht mit der Realität übereinstimmt. Ich
würde empfehlen, auf ein aktuelles MySQL zu upgraden und die Zeichen-
satzgeschichte gleich *richtig* zu machen.
XL
Re: Nochmal utf8
am 12.06.2006 18:08:57 von letters
Am Mon, 12 Jun 2006 16:27:14 +0200 schrieb Axel Schwenke:
> Mathias Fiedler wrote:
>> Am Mon, 12 Jun 2006 15:30:04 +0200 schrieb Christian Kirsch:
>>
>>>> CREATE TABLE `test_utf8` (
>>>> `id` INT( 4 ) NOT NULL AUTO_INCREMENT ,
>>>> `utf` LONGTEXT CHARACTER SET utf8 NOT NULL ,
>>>> PRIMARY KEY ( `id` )
>>>> )
>>>>
>>>> #1064 - You have an error in your SQL syntax.
>>> near
>>>> 'character set utf8 NOT NULL ,
>
>>> Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
>>> jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
>
>> Leider wird es wohl an dem wort aktuell scheitern. Die verfügbare Veriosn
>> von mysql ist 4.0.25. (Managed Server bei Puretec)
>
> MySQL Versionen vor 4.1 scheren sich kaum um den Zeichensatz, mit dem
> Daten gespeichert werden. Abgesehen von String-Vergleich und Sortierung.
>
> Es spricht also nicht viel dagegen, in einer TEXT oder LONGTEXT Spalte
> Daten in UTF8 Kodierung abzulegen. MySQL gibt exakt die gleichen Daten
> zurück, die du abgespeichert hast. BTDTMT.
>
> Das Problem kommt beim Upgrade auf 4.1 oder 5.0 weil dann die Deklara-
> tion (Server default-charset) nicht mit der Realität übereinstimmt. Ich
> würde empfehlen, auf ein aktuelles MySQL zu upgraden und die Zeichen-
> satzgeschichte gleich *richtig* zu machen.
>
>
Da bin ich leider daran gebunden, was mein Provider vorgibt.
Trotzdem danke. Ich kann in Longtext speichern, was auch immer da abgelegt
wird, es ist wieder anzeigbar ohne das utf8 irgendwie durcheinandergebracht
wird.
mfg
Mathias
Re: Nochmal utf8
am 12.06.2006 18:11:29 von letters
Am Mon, 12 Jun 2006 16:03:57 +0200 schrieb Christian Kirsch:
> Mathias Fiedler schrieb:
>> Am Mon, 12 Jun 2006 15:30:04 +0200 schrieb Christian Kirsch:
>
>>> Hier (mysql-5.0.15):
>>>
>>> mysql> create table utf (didel longtext character set utf8 not null);
>>> Query OK, 0 rows affected (0,07 sec)
>>>
>>> Dito mit Deiner Query.
>>>
>>> Sieht also nicht so aus, als ob an der Syntax irgendwas flasch wäre -
>>> jedenfalls nicht in einer leidlich aktuellen MySQL-Version.
>>
>> Leider wird es wohl an dem wort aktuell scheitern. Die verfügbare Veriosn
>> von mysql ist 4.0.25. (Managed Server bei Puretec)
>> Gibts für die 4.0.25 nicht auch eine Möglichkeit? Oder kann ich das UTF-8
>> mit irgendeiner anderen Codierung wieder in ein Format brigen, welches ich
>> unter Longtext speichern kann?
>>
>
> Richtigen UTF-8-Support gibt's erst ab MySQL 5.irgendwas, IIRC. Also
> wirst Du wohl ein bisschen um das Problem rumarbeiten müssen.
>
> LONGTEXT ist jedenfalls ein Format, das Dir das Speichern beliebiger
> Zeichen erlaubt - also auch UTF-8. Du kannst aber den Zeichensatz
> nicht deklarieren, und Du kannst auch keine vernünftigen Vergleiche
> (Sortierung, Suche etc.) durchführen. Was allerdings bei LONGTEXT
> ohnehin nicht sinnvoll sein dürfte. Wenn Du also *weißt*, dass Du in
> der Spalte UTF-8 speicherst, dann ist doch eigentlich alles ok - Du
> musst dann eben nur dafür sorgen, dass alle Anwendungen die Daten aus
> dem Feld auch korrekt behandeln.
>
> Was also ist Dein Problem genau?
Es war genau das. Ich war der Meinung, speichern ohne dem Longtext utf8
vorzugeben geht nicht. DAS es doch klappt ist erst mal gut. Wenn das Update
auf php5 kommt, muß ich mich halt wieder damit beschäftigen.
>
> Disclaimer: PHPMyAdmin ist aus guten Gründen hier *nicht* on-topic.
Es ging mir auch nur in untergeordneter Form darum. Das Problem als solches
war schon mysql. Danke für die Ausführungen.
mfg
Mathias