Websiteumstellung auf UTF-8, wie geht's?

[Matze]

Hallo,

es ist wirklich grauenhaft, was alles zu tun ist, um eine Website auf UTF-8 umzustellen. Was man da alles verändern muss.
Ich bekomme es jedenfalls nicht korrekt hin, denn entweder wirde es nicht alles in die Datenbank eingetragen oder es wird im Browser falsch codiert dargestellt.

Die MySQL-Datenbank ist so eingestellt (diese 2 Beispiele verdeutlichen das ganz gut):

SQL-Code:

# Datenbank
CREATE DATABASE `main`
    CHARACTER SET 'utf8'
    COLLATE 'utf8_unicode_ci';

# Eine der Tabellen
CREATE TABLE `page_acronyms` (
  `acronym_name` varchar(255) collate utf8_unicode_ci NOT NULL default '',
  `acronym_desc` varchar(255) collate utf8_unicode_ci NOT NULL default '',
  `lang` varchar(4) collate utf8_unicode_ci NOT NULL default '',
  PRIMARY KEY  (`acronym_name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Wenn ich nun ganz gewöhnlich über die PHP-Funktionen etwas in die Datenbank einfügen (INSERT INTO ...) und auch normal wieder auslesen möchte (SELECT ... FROM ...), dann sehe ich im Browser nur diese seltsamen Zeichen, trotz UTF-8-Header, den ich mittels header() sende und in den Meta-Tags zusätzlich angegeben habe (der Internet Explorer braucht das zwingend dort).

Mir wurde dann der Tipp gegeben, zu Beginn das hier aufzurufen, was jedoch auch nicht weiterhilft, denn das schneidet mir die String ab einem Sonderzeichen einfach ab:

SQL-Code:

SET NAMES 'utf8'

Es kann ja nicht sein, dass ich beim Eintragen und Auslesen immer utf8_encode() bzw. utf8_decode() verwenden muss.

Wo liegt der Fehler?

Grüße

[xaromz]

Hallo,

Zitat:

Zitat von Matze

Es kann ja nicht sein, dass ich beim Eintragen und Auslesen immer utf8_encode() bzw. utf8_decode() verwenden muss.

eine andere Lösung habe ich zumindest bisher nicht gefunden.

Zitat:

Zitat von Matze

Wo liegt der Fehler?

Das würde mich auch interessieren.

Gruß
xaromz

[Xong]

Zitat:

Zitat von Matze

Wo liegt der Fehler?

Das schönste UTF-8 bringt dir nichts, wenn du die Daten nicht auch in dieser Kodierung verschickst!

Mit welchem Zeichensatz sind deine Dateien kodiert?

LG,
Xong

[Matze]

Hallo Xong,

ich war der Meinung, wenn der Browser UTF-8 vorgegeben bekommt, übergibt er die Daten auch in dem Format weiter (beispielsweise bei Formularen).

Grüße

[Xong]

Formulareingaben musst du sowieso immer überprüfen.
Du weißt nie, in welchem Encoding die Daten ankommen. Dort ist ein utf8_encode also unerlässlich.

Trotzdem würde ich gerne noch wissen, mit welchem Editor / welcher IDE du deine PHP-Dateien speicherst und welche Zeichenkodierung diese haben. =)

LG,
Xong

[Matze]

Hallo Xong,

ach das hast du gemeint! Ich nutze PHPEclipse und das speichert die Dateien meines Wissens im ANSI-Format ab.
Ich muss das alles also doch immer manuell kodieren, ohje. :(

Grüße

Edit: Da ich die ganzen Strings in den Abfragen über eine eigene Funktion behandle, wäre der Aufruf von utf8_encode doch mit minimalem Aufwand verbunden, sehe ich gerade. :) Daran hatte ich gar nicht gedacht.
Nur utf8_decode wäre mit größerem Aufwand verbunden.

Dennoch würde mich interessieren, ob das wirklich zwingend erforderlich ist.

[Xong]

Zitat:

Zitat von Matze

Ich nutze PHPEclipse [...]

Man kann dort auch als UTF-8 speichern. Das würde ich dir dringend empfehlen!
Ich habe das Programm hier nicht installiert, aber wenn ich zu Hause bin, kann ich dir weiterhelfen, wenn du es bis dahin nicht schon selbst gefunden hast!

Zitat:

Zitat von Matze

Dennoch würde mich interessieren, ob das wirklich zwingend erforderlich ist.

Du kannst nie wissen, welche Daten an deinen Server gesendet werden. Und so kannst du auch nicht verhindern, dass eine "falsche" Kodierung benutzt wird.

[Matze]

Ich kann die Dateien natürlich als UTF-8 speichern, sehe jedoch keinen Grund dafür, da ich nicht über den ANSI-Zeichensatz hinausgehe.

[CalganX]

Hi Matze,
wenn du UTF-8 verwenden willst, musst du auch konsequent dieses Dateifomat verwenden. Die Angabe im Header alleine bedeutet ja noch nicht, dass die Datei wirklich dieses Format hat. Du versendest also im Moment einen Mix aus ANSI und UTF-8. Das muss zwangsläufig zu Fehlern führen.

Beispiel: Wenn du alles auf Unicode eingestellt hast, und in deiner (ANSI-)PHP-Datei dann schreibst

Code:

mysql_query("SELECT * FROM table WHERE intID = 2");

Dann sendest du ja automatisch einen ANSI-String an MySQL. Schließlich steht er in einer ANSI-Datei, ist also als ANSI gespeichert. Das gilt natürlich auch für String-Übergaben an eigene Methoden etc.

Also: Konsequent ein Dateiformat benutzen.

Christopher

[Xong]

Zitat:

Zitat von Matze

Ich kann die Dateien natürlich als UTF-8 speichern, sehe jedoch keinen Grund dafür, da ich nicht über den ANSI-Zeichensatz hinausgehe.

Hab ich dich. =)
Der ANSI-Zeichensatz ist in UTF-8 enthalten!
Du speicherst also schon in UTF-8... :thumb:

[Matze]

@Mike: Ah ok, dann muss ich das wirklich machen.

Zitat:

Zitat von Xong

Der ANSI-Zeichensatz ist in UTF-8 enthalten!
Du speicherst also schon in UTF-8... :thumb:

Das heißt doch nicht, dass ich es als UTF-8 speichere. ;)

Irgendwan konvertiere ich die ganzen Dateien, doch Iconv ist unter Windows eine Krankheit und manuell habe ich jetzt keinen Kopf dafür. Ich melde mich dann, wenn es mal soweit ist.

[Xong]

Zitat:

Zitat von Matze

Das heißt doch nicht, dass ich es als UTF-8 speichere. ;)

Nunja. Doch!
Ein Editor kann nämlich nicht unterscheiden, ob eine Textdatei im ANSI- oder um UTF-8-Zeichensatz gespeichert wurde.
Weil ANSI eben eine Untermenge von UTF-8 ist.
Es gibt nun Editoren, die automatisch die kleinst mögliche Untermenge auswählen. (Notepad2 z.B.)

Bsp.: { 1, 65, 23423, 32, 2 }
Sind die Elemente dieser Menge Natürliche oder Ganze Zahlen?
Beides natürlich... =)
Notepad2 würde nun festlegen, dass es Natürliche Zahlen seien.
Ich würde die Ganzen Zahlen bevorzugen. Aber das ist jedem selbst überlassen.

Ich hoffe, ich konnte etwas helfen.

LG,
Xong

[Matze]

Hm ok, danke. Ich habe die relevanten Dateien nun konvertiert (in Eclipse: "Set Encoding").

Also Umlaute wie ä, ö, ü werden korrekt eingetragen und dargestellt, wenn ich das richtig sehe. Doch sobald ich chinesische zeichen wie 文字 einfüge, steht in der Datenbank nur 文字, was so auch auf der Website angezeigt wird. :?

Edit: Die DP stellt das sogar richtig dar. Daher vermute ich, muss generell ein utf8_decode kommen, auch wenn ich nicht ganz verstehe wieso. Oben fügte ich übrigens als zweites: 文字 ein.

[Xong]

Zitat:

Zitat von Matze

Edit: Die DP stellt das sogar richtig dar. Daher vermute ich, muss generell ein utf8_decode kommen, auch wenn ich nicht ganz verstehe wieso. Oben fügte ich übrigens als zweites: 文字 ein.

文 und 字 sind Entitäten. Die Zahlen, die zwischen & und ; stehen kodieren sozusagen ein Zeichen. Deshalb werden 文 und 字 auch unabhängig von der Kodierung der darstellenden Seite angezeigt (vorausgesetzt, es gibt eine Schriftart, die diese Zeichen enthält).
Bei einer echten UTF-8 Kodierung würde das Zeichen 文 Hexadezimal als E6 96 87 gespeichert werden.

Und wenn du weiterhin Probleme mit UTF-8 bzw. Datenübertragung zwischen Datenbank und Webseite haben solltest, dann wendest du dich am besten ans Selfhtml-Forum. Da sind sehr kompetente Leute.

LG,
Xong

[marabu]

Herzlich willkommen in der Delphi-PRAXiS, Xong.

Zitat:

Zitat von Xong

... Der ANSI-Zeichensatz ist in UTF-8 enthalten!
Du speicherst also schon in UTF-8...

Du meintest sicher ASCII statt ANSI, denn ASCII und nicht ANSI (CP1252) wird identisch abgebildet.

Freundliche Grüße

[Xong]

Zitat:

Zitat von marabu

Herzlich willkommen in der Delphi-PRAXiS, Xong.

Danke! =)

Zitat:

Zitat von marabu

Zitat:

Zitat von Xong

... Der ANSI-Zeichensatz ist in UTF-8 enthalten!
Du speicherst also schon in UTF-8...

Du meintest sicher ASCII statt ANSI, denn ASCII und nicht ANSI (CP1252) wird identisch abgebildet.

Nene! Ich meinte schon ANSI bzw. EASCII.

ASCII: Die ersten 128 Unicode-Zeichen.
ANSI: Die ersten 256 Unicode-Zeichen.

[marabu]

Hallo,

Zitat:

Zitat von Xong

...
ASCII: Die ersten 128 Unicode-Zeichen.
ANSI: Die ersten 256 Unicode-Zeichen.

bitte überprüfe das nochmal: Die Unicode Blöcke 0 und 1 (0x00-0xFF) entsprechen ISO Latin 1, die control character mit gesetztem high bit inklusive DEL (0x7F-0x9F) sind in Latin1 nicht belegt, aber ANSI (CP1252) nutzt diesen Bereich durchaus. Als Prüfstein mag das Euro-Zeichen (0x80) gelten.

EASCII ist für mich ein informelles Akronym und ich verbinde es mit dem von IBM 1981 auf dem Ur-PC benutzten Extended ASCII (8 bit statt 7 bit). EASCII ist heute CP437. Kennst du eine andere Definition, vorzugsweise mit URL dazu?

Freundliche Grüße

[Xong]

Ich schreibe hier über ein Thema, womit ich mich eher oberflächlich beschäftigt habe.
Ich nutze UTF-8 und komme damit gut zurecht. Mit anderen Zeichensätzen musste ich mich also auch nicht großartig auseinandersetzen

Jedenfalls habe ich mich mit ANSI auf ISO 8859-1, nicht CP1252 bezogen. =)
(Die DP scheint sich auch darauf zu beziehen. Siehe DP-Akronyme)


Die Bezeichnung ANSI bzw. EASCII scheint kein expliziter Standard zu sein, sondern umfasst mehrere Zeichensätze.

Aber du hast wahrscheinlich recht und Matze nutzt im Moment ISO-8859-1 oder CP1252 und damit keine Untermenge von UTF-8.

[marabu]

Dafür, dass Zeichensätze nicht zu deiner Spezialität gehören, hast du aber bemerkenswert klarsichtig beraten.

Ich freue mich auf weitere Beiträge von dir.

Schönes Wochenende

[cruiser]

Zum Thema... um MySQL UTF-8 beizubringen (so wie ich es wollt) hab ich der Connection erst mal sagen müssen, dass sie überhaupt im UTF-8 Modus arbeiten soll.

Erst dannach ging alles wie gewünscht:

Code:

// mysqli Object
$DB->set_charset("UTF-8");

// proceduraler ansatz
mysql_set_charset("UTF-8", $dbconn);

Wenn alle Stricke reissen notfalls eine Query:

Code:

mysql_query('SET CHARACTER SET "UTF-8"', $dbconn);

[Matze]

Hallo Ronny,

danke, doch das funktioniert bei mir leider auch nicht. Dass das aber auch so kompliziert sein muss. :?

Edit: Ich habe mal ein Testskript geschrieben, mit dem es auch nicht funktioniert. Vielleicht ist es dort einfacher, den Fehler zu finden.

[cruiser]

Viel rumgebastelt und den Fehler entdeckt, im Hex-Editor :drunken:

Am Anfang deines Files stehen die 3 UTF-8 Identify-Bytes, die werden noch vor der Header-Anweisung an den Browser geschickt, das feuert zumindest bei mir einen Fehler.

Bei UTF-8 und PHP in Zusammenhang mit header(); dürfen die ID-Bytes in keinem fall verwendet werden.

Hoffe das hilft jetz ;)

EDIT:
- die utf8_encode(); können übrigens auch wech...
- das mit dem application knallt beim IE (zumindest bei mir)
- das header(); von zeile 11 nach unten unter den Submit-Block

Dann passt es...

Viel Spass! :mrgreen:

[Matze]

Hallo Ronny,

hm vielen Dank. Heißt das, ich muss nun bei allen meinen PHP-Dateien die ersten Bytes entfernen? :gruebel:

Grüße

[cruiser]

Hab oben noch mal editiert...

Im Editor einfach einstellen, das UTF-8 ohne BOM bzw. Identify Bytes gespeichert werden soll... ja oder die ersten 3 Bytes vor dem ersten <? php löschen

[Matze]

Dann teste ich das mal, dankeschön.
Nur schade, dass man bei Eclipse, im Gegensatz zu einigen anderen Editoren/IDEs, nur "UTF-8" auswählen kann und nicht "UTF-8 (ohne BOM)", wie es bei Notepad++ zu finden ist.
Naja, irgendwie krieg ich das schon hin, wenn's wirklich nur daran liegt.

Edit: Ich habe mir ein Tool heruntergeladen, das BOMs entfernt und richtig ist, dass beim Testprojekt diese Bytefolge enthalten war, bei meinem richtigen Projekt jedoch nicht. Dann liegt es doch nicht daran... :?

[cruiser]

Hab bei Eclipse eigentlich keine Probs mit dem BOM müsst evtl. mal schaun wo die Einstellung ist..

wenn du bereits UTF-8 als Codepage für die Abhandlung mit MySQL festlegst und dann noch utf8_encodest, encodest du quasi den UTF-8 string noch einmal... daher die Fehlzeichen

[Matze]

Ah, ich habe den Fehler gefunden. Es waren nicht komplett alle PHP-Dateien konvertiert. :wall:
Die des Admin-Panels waren teils noch nicht im UTF-8-Format und somit wurden neue Blogeinträge, die ich darüber hinzufüge, falsch dargestellt, Kommentare, die über den öffentlichen Bereich eingegeben werden, jedoch richtig.

Danke nochmals für eure Hilfe.

Übrigens benötige ich das Query

SQL-Code:

SET NAMES 'utf8'

nicht. Eclipse speichert die BOM-Bytes nicht mit, das kann diese IDE gar nicht und dass utf8_encode() und utf8_decode() nicht benötigt werden, gefällt mir auch sehr gut.

Auf jedenfall waren eure Beiträge sehr interessant und ich habe einiges dazugelernt. :thumb:

Matze

Nachtrag:
Nun hat FF aber noch seltsame Probleme (im IE geht alles wie es soll):
Rufe ich im FF eine Seite auf, sehe ich dies als Inhalt:

Zitat:

Da ich relativ gerne fotografiere und ein Online-Fotoalbum eine nette Sache ist, habe ich mich hingesetzt und eines programmiert. Im Vordergrund stand für mich, dass die Fotos ohne große Probleme in einem Rutsch ins Album gestellt werden können. Daher werden die Bilder und die zugehörige Verzeichnisstruktur einfach ausgelesen und angezeigt.

Lade ich die Seite erneut (Strg+R oder F5), dann wird alles richtig dargestellt. Lade ich die Seite weiterhin erneut, dann wechselt die Darstellung scheinbar zufällt wieder in die falsche und wieder zurück in die korrekte.
Den Cache habe ich bereits gelöscht, dennoch tritt dieses Problem auf. Was kann dies sein?

[cruiser]

DAs hab ich auch manchmal beim FF ... würde mich ebenfalls interessieren, wie man dem das so beibringt, dass die Automatik nich versagt ;)

[Matze]

Seltsam ist, dass ich das Phänomen nicht mehr reproduzieren kann, aber es kommt noch merkwürdiger:
Wenn ich diese russische Zeichenfolge eintrage:

Zitat:

а, е, ё, и, о, у, ы, э, ю und я

sehe ich im Browser das hier:

Zitat:

а, е, ё, и, о, у, ы, �?, ю und �?

Der Zeichensatz wird nur teilweise korrekt dargestellt. Das ist somit werder UTF-8, noch ISO-8859-15.

Ich euch nicht zu langweilen wird es nun noch spannender. :mrgreen: Ich kann im FF die Zeichenkodierung für meine Website nicht mehr umstellen, diese bleibt generell auf UTF-8 eingestellt, bei anderen Seiten geht es jedoch problemlos. :gruebel:

Btw: Schön, dass die DP einigermaßen UTF-8 unterstützt, sonst wäre es schwer, das alles in Worte zu fassen. *g*

Was kann die Ursache für diese Probleme sein?

[Matze]

Keiner 'ne Idee? :cheer:

[Xong]

Kann an den Headern und am Quellcode liegen! Eine Beispielseite wäre hilfreich. Dann kann ich dir auch sagen was du sonst noch so alles falsch machst. :lol:

[Matze]

Nun scheint alles zu funktionieren. Manche UTF8-zeichen benötigen "set names", andere nicht Fragt mich nicht wieso, ich habe es leider nicht nachvollzihen können. Auf jedenfall benötigt man "set names", wenn man die vollte UTF8-Unterstützung haben möchte.

Danke an alle und auch an Xong, der mir per PN noch ein paar Tipps gegeben hat.

Nun muss ich das ganze mal online konvertieren und aktialisieren. Mal sehen, ob alles klappt, ich bin gespannt ...