utf8
Mathias Fiedler
ich habe eine ausgangstabelle mit der collation latin swedish. Ich m�chte
diese tabelle einfach kopieren, die kopierten werte aber in utf8 erhalten.
Ich m�che in der Tabelle2 keine Umlaute mehr haben, sondern die utf8
Kodierungen daf�r.
Eine Kopie ist ja so m�glich:
INSERT INTO produkte2 SELECT * FROM produkte1
Wie kann ich aber nun die Werte aus produkte1 beim kopieren in produkte2
gleich in utf8 umwandeln? Geht das �berhaupt?
mfg
Mathias
Claus Reibenstein
> ich habe eine ausgangstabelle mit der collation latin swedish.
Die Sortierung (collation) ist f�r Dein Problem irrelevant. Der
Zeichensatz (character set) w�re da schon interessanter gewesen, aber
auch der ist irrelevant.
> Ich m�chte
> diese tabelle einfach kopieren, die kopierten werte aber in utf8 erhalten.
Genau das erreichst Du durch einfaches Kopieren.
> Ich m�che in der Tabelle2 keine Umlaute mehr haben, sondern die utf8
> Kodierungen daf�r.
Diesen Satz verstehe ich nicht. Was meinst Du damit?
> Eine Kopie ist ja so m�glich:
> INSERT INTO produkte2 SELECT * FROM produkte1
Besser w�re es, die jeweiligen Spalten sowohl beim Ziel als auch bei der
Quelle anzugeben. Ansonsten ist Stress vorprogrammiert.
> Wie kann ich aber nun die Werte aus produkte1 beim kopieren in produkte2
> gleich in utf8 umwandeln? Geht das �berhaupt?
Zieltabelle mit UTF8 anlegen, Daten kopieren, fertig.
Wann _endlich_ wirst Du Dich mal mit den _Grundlagen_ vertraut machen?
Gru�. Claus
Mathias Fiedler
>
> Wann _endlich_ wirst Du Dich mal mit den _Grundlagen_ vertraut machen?
>
Die tabelle1 ist codiert als latin swedish
Die Tabelle2 ist codiert als utf8
in tabelle1 steht "Stra�e"
in tabelle2 steht nach dem Kopieren auch noch "Stra�e"
da sollte aber stehen "Straïe"
davon rede ich. Was soll nun also schon wieder dieser �berhebliche Ton?
Im �brigen habe ich alle spalten einzeln aufgelistet, das ist hier nur der
einfachheit halber gek�rzt. H�tte aber auf das Endergebnis keinen Einfluss.
Ein
INSERT INTO produkte1 SELECT CONVERT(description USING utf8) .....
nutzt auch nichts.
Nun bin ich auf den n�chten geistreichen Erguss gespannt.
Claus Reibenstein
> Die tabelle1 ist codiert als latin swedish
Einen solchen Zeichensatz gibt es nicht. Du meinst vermutlich latin1.
> Die Tabelle2 ist codiert als utf8
>
> in tabelle1 steht "Stra�e"
Codiert als Latin1.
> in tabelle2 steht nach dem Kopieren auch noch "Stra�e"
Codiert als UTF8.
> da sollte aber stehen "Straïe"
So sieht UTF8 aus, wenn man es sich als Latin1 ausgeben l�sst.
Du untersch�tzt mal wieder die Intelligenz der Datenbank. Die wei�,
welchen Zeichensatz Dein Anzeigeger�t hat (falls Du ihr den richtig
mitgeteilt hast) und wandelt bei der Ausgabe alle Daten in genau diesen
Zeichensatz um, so dass Du _immer_ "Stra�e" zu sehen bekommt, egal in
welcher Codierung diese "Stra�e" vorliegt (cp850, cp1250, dec8, hp8,
latin1, macroman, utf8 etc.)
Schau Dir die beiden Werte doch mal hexadezimal an. Dann siehst Du den
Unterschied.
Gru�. Claus
Axel Schwenke
>Claus Reibenstein wrote:
>> Wann _endlich_ wirst Du Dich mal mit den _Grundlagen_ vertraut machen?
>
> Super Ausf�hrungen, nur leider eben auch irrelevant.
Nein. Absolut relevant.
WANN ENDLICH WIRST DU DICH MAL MIT DEN GRUNDLAGEN VERTRAUT MACHEN?
Sehr sch�n verst�ndlich (und sogar in Deutsch) hat Kris das mal
aufgeschrieben:
http://blog.koehntopp.de/archives/1424-MySQL-Zeichensatz-Grundlagen.html
ansonsten steht das nat�rlich alles auch etwas technischer im
MySQL-Manual.
> Was soll nun also schon wieder dieser �berhebliche Ton?
> Nun bin ich auf den n�chten geistreichen Erguss gespannt.
Der einzige, der hier �berheblich ist, bist du. Du bist so ahnungs-
und geistlos, da� schon das blo�e Lesen deiner Postings weh tut.
M�chtest du deine Merkbefreiung gleich jetzt haben?
XL
Mathias Fiedler
>
> Der einzige, der hier �berheblich ist, bist du. Du bist so ahnungs-
> und geistlos, da� schon das blo�e Lesen deiner Postings weh tut.
>
> M�chtest du deine Merkbefreiung gleich jetzt haben?
>
�berhaupt? Wenn mir was weht tut, mache ich eine gro�en Bogen darum herum.
Bist Du Masochist?
Mathias Fiedler
> Mathias Fiedler schrieb:
>
>> Die tabelle1 ist codiert als latin swedish
>
> Einen solchen Zeichensatz gibt es nicht. Du meinst vermutlich latin1.
>
>> Die Tabelle2 ist codiert als utf8
>>
>> in tabelle1 steht "Straße"
>
> Codiert als Latin1.
>
>> in tabelle2 steht nach dem Kopieren auch noch "Straße"
>
> Codiert als UTF8.
>
>> da sollte aber stehen "Straße"
>
> So sieht UTF8 aus, wenn man es sich als Latin1 ausgeben lässt.
>
> Du unterschätzt mal wieder die Intelligenz der Datenbank. Die weiß,
> welchen Zeichensatz Dein Anzeigegerät hat (falls Du ihr den richtig
> mitgeteilt hast) und wandelt bei der Ausgabe alle Daten in genau diesen
> Zeichensatz um, so dass Du _immer_ "Straße" zu sehen bekommt, egal in
> welcher Codierung diese "Straße" vorliegt (cp850, cp1250, dec8, hp8,
> latin1, macroman, utf8 etc.)
>
> Schau Dir die beiden Werte doch mal hexadezimal an. Dann siehst Du den
> Unterschied.
>
So sollte es sein. Da gebe ich dir Recht. Aber meine Seite gibt aus:
Stra�e.
Das charset meiner Seite ist utf8 und das charset der DB auch.
Steht also in der DB "Straße" bekomme ich die Ausgabe Stra�e. Steht darin
"Straße" bekomme ich die Ausgabe Straße. Jetzt habe ich die gesamte alte
Tabelle über php mit utf8_encode() codiert und in die neue Tabelle
geschrieben und es ist ok. Ich glaube Dir ja, was du da sagst. Es sollte ja
auch so ein. Aber wenn mein Browser eben was anderes ausgibt, muss ich mir
Gedanken machen warum. Deshalb habe ich gefragt und nicht um Euch zu
ärgern. Wer das aber denkt, soll sich doch bitte einfach seinen Teil denken
und das Posting einfach wieder zu machen. Da gibt es keinen Streit und
jeder ist zufrieden.
mfg
Mathias
Sebastian Suchanek
> [...]
> So sollte es sein. Da gebe ich dir Recht. Aber meine Seite gibt aus:
> Stra�e.
> Das charset meiner Seite ist utf8 und das charset der DB auch.
> Steht also in der DB "Straße" bekomme ich die Ausgabe Stra�e. Steht darin
> "Straße" bekomme ich die Ausgabe Straße. Jetzt habe ich die gesamte alte
> Tabelle über php mit utf8_encode() codiert und in die neue Tabelle
> geschrieben und es ist ok. Ich glaube Dir ja, was du da sagst. Es sollte ja
> auch so ein. Aber wenn mein Browser eben was anderes ausgibt, muss ich mir
> Gedanken machen warum.
> [...]
Aha. Du hast also offensichtlich rund um MySQL noch zig andere
Fehlerquellen wie PHP und Webbrowser eingebaut. Dann zu behaupten, daß
ausgerechnet MySQL schuld ist, halte ich für etwas verwegen.
Tschüs,
Sebastian
Thomas Rachel
>> Schau Dir die beiden Werte doch mal hexadezimal an. Dann siehst Du den
>> Unterschied.
>>
>
> So sollte es sein. Da gebe ich dir Recht.
Dann gehe ich davon aus, daß der Inhalt, in hex umgewandelt, dann
stimmt. Also paßt es innerhalb von MySQL.
> Aber meine Seite gibt aus: Stra�e.
> Das charset meiner Seite ist utf8 und das charset der DB auch.
Und das der Verbindung? Vermutlich nicht. -> das ist die Schraube, an
der zu drehen ist.
> Ich glaube Dir ja, was du da sagst. Es sollte ja auch so ein.
Eben.
> Aber wenn mein Browser eben was anderes ausgibt, muss ich mir
> Gedanken machen warum.
Lobenswert. Aber die DB so zu verdrehen, daß Müll drinsteht, nur damit
die Ausgabe paßt, ist der falsche Weg.
Thomas
Andreas Born
> So sollte es sein. Da gebe ich dir Recht. Aber meine Seite gibt aus:
> Stra�e.
Daß ist die utf8-Ausgabe eines (wegen utf8 ungültigen) iso-zeichens.
> Das charset meiner Seite ist utf8 und das charset der DB auch.
Und das Charset der Verbindung ist Latin1.
Stell das doch mal auf utf8 um:
"set names utf8"
> Steht also in der DB "Straße" bekomme ich die Ausgabe Stra�e. Steht
> darin
> "Straße" bekomme ich die Ausgabe Straße.
Ja, aber nur weil die Daten in der DB dann fälschlicherweise "doppelt
utf8-kodiert" wären.
> Jetzt habe ich die gesamte alte Tabelle über php mit utf8_encode()
> codiert und in die neue Tabelle geschrieben und es ist ok.
Nein, ist es nicht. Es ist kaput/doppelt kodiert, so funktioniert in
Zukunft keine Sortierung mehr.
> Ich glaube Dir ja, was du da sagst. Es sollte ja auch so ein. Aber
> wenn mein Browser eben was anderes ausgibt, muss ich mir Gedanken
> machen warum. Deshalb habe ich gefragt und nicht um Euch zu ärgern.
Der Grund für das Warum ist folgender:
Die Datenbank hat einen Zeichensatz für die Verbindung definiert, der
meistens mit Latin1 voreingestellt ist. Schickst Du ein INSERT an die
DB, wird der String als Latin1 interpretiert, rufst Du mittels SELECT
Werte ab, werden diese nach Latin1 konvertiert, egal wie diese in der DB
gespeichert werden. Willst Du utf8 an die DB senden und von dort
erhalten, musst Du den Verbindungszeichensatz auch auf utf8 festlegen.
Viele Grüße,
Andreas
Mathias Fiedler
Danke, das war wohl das Übel. Ich habe schon die Verbindung auf utf8
gesetzt, aber nur beim lesen. Die Inserts sind mir durchgegangen. Damit
hatte ich dann zwei verschiedene Codierungen in der DB. Und mit dem Umweg
über php dann eben utf8 nochmal utf8 codiert. OK, das war der fehler. Danke
noch mal.
Mathias Fiedler
Wer hat was von Schuld gesagt? Was seid Ihr denn immer gleich beleidigt?
Ich habe halt hier nachgefragt. Na und? Eine Lösung hat es ja gegeben. man
muss doch mal ein wenig über den Tellerrand sehen können. In der php group
heißt es dann: Da ist ja noch mysql dabei, da liegt es daran. Klar, imemr
erst mal zu dem anderen schieben ist die einfachste Möglichkeit. Aber da
kommt nie eine Lösung raus. Die php group schiebt es auf mysql, die mysql
group auf php, die webserver group auf beide. Toll. Nur geholfen ist damit
keinem.
Claus Reibenstein
> Am Wed, 09 Dec 2009 20:11:06 +0100 schrieb Sebastian Suchanek:
>
>> Aha. Du hast also offensichtlich rund um MySQL noch zig andere
>> Fehlerquellen wie PHP und Webbrowser eingebaut. Dann zu behaupten, daß
>> ausgerechnet MySQL schuld ist, halte ich für etwas verwegen.
>
> Wer hat was von Schuld gesagt? Was seid Ihr denn immer gleich beleidigt?
Niemand ist hier beleidigt, sondern bestenfalls genervt, was bei Deinen
Fragen auch nicht weiter verwunderlich ist. Insbesondere Deine
Informationspolitik ist stark verbesserungswürdig.
Hättest Du gleich Dein _tatsächliches_ Problem geschildert, wäre die
Hilfe garantiert schneller und zielgerichteter erfolgt. So muss man erst
mal nachhaken, um rauszubekommen, worum es _wirklich_ geht.
> In der php group
> heißt es dann: Da ist ja noch mysql dabei, da liegt es daran. Klar, imemr
> erst mal zu dem anderen schieben ist die einfachste Möglichkeit. Aber da
> kommt nie eine Lösung raus. Die php group schiebt es auf mysql, die mysql
> group auf php, die webserver group auf beide.
Niemand schiebt hier irgendetwas auf irgendjemanden.
Es sind nun mal mehrere Komponenten beteiligt, von denen jede als
Fehlerquelle in Frage kommt. Allerdings war letztendlich keine dieser
Fehlerquellen die Ursache, sondern - mal wieder - falscher Umgang mit
den Werkzeugen.
Im Übrigen gibt es die Gruppe de.comp.lang.php.datenbanken, die sich
speziell mit Datenbanken unter PHP auseinandersetzt.
> Toll. Nur geholfen ist damit
> keinem.
Dir zu helfen, ist angesichts Deiner immer wieder demonstrierten
Lernresistenz auch nicht gerade einfach.
Nochmal (und das meine ich ernst): Wann _endlich_ wirst Du Dich mal mit
den _Grundlagen_ vertraut machen?
Gruß. Claus
Axel Schwenke
> Am Thu, 10 Dec 2009 00:11:11 +0100 schrieb Andreas Born:
>> Willst Du utf8 an die DB senden und von dort
>> erhalten, musst Du den Verbindungszeichensatz auch auf utf8 festlegen.
>>
> Danke, das war wohl das �bel. Ich habe schon die Verbindung auf utf8
> gesetzt, aber nur beim lesen. Die Inserts sind mir durchgegangen. Damit
> hatte ich dann zwei verschiedene Codierungen in der DB. Und mit dem Umweg
> �ber php dann eben utf8 nochmal utf8 codiert. OK, das war der fehler.
Tja. Wenn du dich, wie vorgeschlagen, erst mit den Grundlagen
vertraut gemacht h�ttest, dann h�tte dieser ganze, unfreundliche
Thread gar nicht sein m�ssen.
XL
Mathias Fiedler
ich war nicht unfreundlich :)
Harald Fuchs
Mathias Fiedler <let...@psygonis.de> writes:
> Am Thu, 10 Dec 2009 11:56:24 +0100 schrieb Axel Schwenke:
>> Mathias Fiedler <let...@psygonis.de> wrote:
>>> Am Thu, 10 Dec 2009 00:11:11 +0100 schrieb Andreas Born:
>>
>>>> Willst Du utf8 an die DB senden und von dort
>>>> erhalten, musst Du den Verbindungszeichensatz auch auf utf8 festlegen.
>>>>
>>> Danke, das war wohl das ï¿œbel. Ich habe schon die Verbindung auf utf8
>>> gesetzt, aber nur beim lesen. Die Inserts sind mir durchgegangen. Damit
>>> hatte ich dann zwei verschiedene Codierungen in der DB. Und mit dem Umweg
>>> ï¿œber php dann eben utf8 nochmal utf8 codiert. OK, das war der fehler.
>>
>> Tja. Wenn du dich, wie vorgeschlagen, erst mit den Grundlagen
>> vertraut gemacht hï¿œttest, dann hï¿œtte dieser ganze, unfreundliche
>> Thread gar nicht sein mï¿œssen.
>>
>>
>> XL
> ich war nicht unfreundlich :)
Manche Leute finden es ziemlich unfreundlich, daￜ Du Dich weigerst,
Dich mit den Grundlagen von dem zu beschï¿œftigen, was Du zu tun hast.
Mathias Fiedler
>
> Manche Leute finden es ziemlich unfreundlich, da� Du Dich weigerst,
> Dich mit den Grundlagen von dem zu besch�ftigen, was Du zu tun hast.
Ds ist aber ein wenig sehr einfach.
Ich arbeite mit html, php, javascript und mysql, manchmal auch .NET. Ich
bin also nicht so wie Ihr "spezialisiert". Mein Wissen mag vielleicht f�r
Eure Messlatte nicht reichen, aber daran kann ich jetzt auch nichts �ndern.
Ich hatte eine einfache Frage (wie sich herausstellte) und es gab eine
einfache Antwort. Ich sehe da kein Problem. Der Hinweis auf Googel, B�cher,
Schulungen und Grundlagenstudium ist zwar an sich nicht falsch und auch
immer wieder lustig aber viel zu oft der Aufh�nger um anderen zu zeigen,
dass man selbst mehr weis. Wenn ich nicht davon �berzeugt w�re, dass es
hier Leute gibt, die besser sind als ich, h�tte ich nicht gefragt. Aber auf
die Knie fallen und dem mysql Gott Claus huldigen werde ich nicht. Damit
wird er wohl leben m�ssen.
Ich hab schon ein paar B�cher gelesen. Aber das mit dem charset der
Verbindung habe ich erst nach dem Hinweis von Andreas �ber Google gefunden.
Und das auch nicht gleich. Wenn ich gewusst h�tte, nach was ich suche,
h�tte ich auch nicht fragen m�ssen.
OK, vielleicht war ich wirklich ein wenig ungeduldig, aber ein bisschen
weniger Hochn�sigkeit w�rde Euch auch gut tun.
Mathias