Umlaute in MySql

[Sanjoy]

Hallo liebe Helfer,

ja, zu diesem Thema findet man diverse Treffer sowohl hier im Forum als auch mit Suche mit Google. Allerdings komme ich nicht so recht weiter...
Folgende Umgebung: HTML - PHP - Apache - MySql.
Aufgrund der Hinweise hier im Forum habe ich mich für eine UTF-8 Kodierung der HTML-Seiten entschieden.
MySQL:
MySQL-Zeichensatz:  UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8-unicode_ci

Damit Umlaute auf der HTML-Seite richtig angezeigt werden, verwende ich benannte Zeichen - aber das brauche ich hier natürlich nicht zu erwähnen ;-)
Die benannten Zeichen werden in der Datenbank als ä, ü, usw. gespeichert, nicht als benannte Zeichen.
Wo wird das bestimmt? Ist das eine Einstellung vom Apache? Helft mir, ich habe keine Ahnung - wo kann ich das einstellen?

Was ich allerdings überhaupt nicht verstehe:
Wenn ich beim Aufbau der Seite Daten aus der Datenbank lade, stehen sie als ä, ü, usw. im Quellcode, also nicht als benannte Zeichen, werden aber trotzdem richtig angezeigt?!? Wenn ich in meinen HTML-Code Umlaute schreibe, werden diese nicht richtig angezeigt...Verstehe gar nichts mehr!

Was hab ich falsch verstanden?
Vielen Dank und liebe Grüße
Sanjoy

[Sanjoy]

Damit Umlaute auf der HTML-Seite richtig angezeigt werden, verwende ich benannte Zeichen - aber das brauche ich hier natürlich nicht zu erwähnen ;-)

Schwachsin!!! Von mir selbst...ich könnte die Umlaute auch einfach so eintippen...
Somit vergessen wir auch die 2. Frage.
Die erste bleibt, wieso werden die benannten Zeichen beim Speichern in die Datenbank umgewandelt?

[Sven Rautenberg]

Moin!

Die erste bleibt, wieso werden die benannten Zeichen beim Speichern in die Datenbank umgewandelt?

Wie kommen die denn dahin?

- Sven Rautenberg

[Antipitch]

Hi Sanjoy,

verwende ich benannte Zeichen

Wo / bei was verwendest du die denn? Beim direkten schreiben in die Datenbank? Beim speichern von Daten mit php Funtionen in deinen Seiten. Beim coden deiner HTML / PHP dateien? Wenn's letzteres ist musst du deinen Editor auch auf utf-8 stellen und das maskieren weglassen. Dass  man das nicht mehr braucht, ist ja einer der Vorteile von utf-8. Nur sollte man dann halt alles andere auch auf utf-8 stellen...

Gruß
Antipitch

[dedlfix]

echo $begrüßung;

MySQL-Zeichensatz:  UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8-unicode_ci

Das sind Dinge, die der phpMyAdmin erzählt, und die sind für ihn von Belang, haben aber keinen Bezug auf dein Script.

Was hab ich falsch verstanden?

Da ich das grad eben schonmal (und auch schon wieder) beantwortet habe, verweise ich einfach mal darauf: https://forum.selfhtml.org/?t=159623&m=1039144 Es geht zwar dort um ein konkretes Problem, kann aber auch zu deinem allgemeinen Verständnis beitragen.

echo "$verabschiedung $name";

[Tom]

Hello,

MySQL-Zeichensatz:  UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: utf8-unicode_ci

Damit Umlaute auf der HTML-Seite richtig angezeigt werden, verwende ich benannte Zeichen

Das ist nicht mehr notwendig, wenn Du die Daten auch nach dem Erfassen als UTF-8 abspeichern lässt.
Das ist dann aber eine Sache Deines Editors, mit dem Du die Scripte schreibst.

Der Editor lässt Dir über das OS die Daten am Bildschirm so anzeigen, wie sie in der eingestellten Landessprache aussehen sollen, egal ob sie im UTF-8-Code ein, zwei, drei oder noch mehr Bytes benötigen. Wenn Du ein 'Ü' eintippst, werden vom Editor im Hintergrund (bei richtiger Einstellung) also 2 Bytes in die Datei geschrieben (hoffe, dass das jetzt stimmt).

http://de.selfhtml.org/inter/unicode.htm

Um nun die Bytes im Editor (auch im Browser) nicht aus Versehen einzeln anzeigen zu lassen in einem falschen Zuordnungssystem (also zum Beispiel in ISO 8859-X, X je nach Spracheinstellung), sondern eben immer die Sequenzen in der UTF-8-Decodierung erkennen zu lassen, muss der Browser (Editor) wissen, dass es sich um eine in UTF-8 codierte Datei handelt.

Die benannten Zeichen werden in der Datenbank als ä, ü, usw. gespeichert, nicht als benannte Zeichen.

Das kannst Du eigentlich nur beantworten, wenn Du weißt, wie der Editor, mit dem Du Dir die Bytes aus der Datenbank anzeigen lässt, das handhabt. Wenn Du sehen willst, welches Bytmuster drinsteht, musst Du z.B. einen Hex-Editor verwenden, die Darstellung also in einer numerischen, auf 16 dargestellte Zeichen reduzierten Weise durchführen lassen.

Wo wird das bestimmt? Ist das eine Einstellung vom Apache? Helft mir, ich habe keine Ahnung - wo kann ich das einstellen?

Der Apache hat eine Standardeinstellung für dfas Default-Character-Set. Passend zu diesem sendet er den HTTP-Header an den Client, der dann annimmt, dass die Ressourcen auch in dieser Codierung geliefert werden.

Wie Du die Daten in der Datenbank abspeicherst, ist für die Schiene "Erfassung - Speicherung - Wiedergabe" erst einmal egal.

Wenn Du aber innerhalb der Datenbank mit den abgespeicherten Texten (Zahlentypen und Datumstypen sind ja für Westeuropa gar nicht betroffen) sinnvoll innerhalb der Datenbank arbeiten willst, sie also z.B. richtig sortieren willst, Substrings ausschneiden willst, usw, dann muss die Datenbank die Codierung auch berücksichtigen.

In der Datenbank steht das 'ü' in dem utf-8-codierten String 'Große Änderungsübersicht' nicht mehr an Byteposition Nr 16, sondern weiter hinten, da sowohl das 'ß', als auch das 'Ä' vorher schon mehr als ein Byte in Anspruch genommen haben.

Ich hoffe, dass ich die Verwirrung nicht vergrößert habe, sondern etwas Licht ins Dunkel gebracht habe.

http://www.unicode.org/

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

noch ein Link: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

sorry, es kleckert noch was hinterher.

Mir fiel gerade ein, dass man vielleicht noch auf die "BOM" hinweisen sollte,
und auf die Multi-Byte-Funktionen der Programmiersprachen...

Wenn Du nun Deine Scripte (z.B. PHP) in utf-8-Codierung abspeichern lässt durch Deinen Editor, dann ist das im Prinzip unschädlich für alle Funktionen, die nicht die Stringerkennung betreiben.

Substr() kann nicht mehr benutzt werden, da es byteweise arbeitet. Ein Zeichen ist also immer ein Byte lang. Stattdessen musst Du dann die mb_-Funktionen verwenden.
http://www.php.net/manual/en/function.mb-substr.php

Ein paar Nebengedanken:
Ob man nicht besser eine Konfigurations-Variable oder -Konstante eingeführt hätte, die am Scriptanfang gesetzt würde, und PHP nun anzeigt, dass das Script in UTF-8 geschrieben ist...
Dann hätten alte Scripte nicht umgeschrieben werden müssen, sondern nur am Anfang die Parseranweiseung eingesetzt werden müssen...

Problematisch ist aber noch die sogenannte BOM an Anfang der Datei. PHP kann die noch nicht selbstständig erkennen und ignorieren. Manche Editoren setzen sie aber einfach automatisch ein.
http://de.wikipedia.org/wiki/Byte_Order_Mark

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Ob man nicht besser eine Konfigurations-Variable oder -Konstante eingeführt hätte, die am Scriptanfang gesetzt würde, und PHP nun anzeigt, dass das Script in UTF-8 geschrieben ist...

Diese Überlegung ist in einer Vergangenheitszeitform nicht weiter relevant. PHP kann insgesamt noch nicht mit Mehr-Byte-Kodierungen umgehen. Die Stellen, die mit UTF-8 oder anderen Kodierungen umgehen können, kochen mehr oder weniger ihr eigenes Süppchen. Der Parser gehört jedenfalls nicht dazu.

Dann hätten alte Scripte nicht umgeschrieben werden müssen, sondern nur am Anfang die Parseranweiseung eingesetzt werden müssen...

Auch hier müsstest du erst einmal schauen, was die Version 6 bringt und wie die Implementierungsdetails aussehen. In einer schon recht alten Entscheidung[1] soll Unicode per php.ini (de)aktiviert werden können, also nicht per Request oder gar per (include-)Datei.

[1] aus dem Jahr 2005 http://www.php.net/~derick/meeting-notes.html

echo "$verabschiedung $name";