Topic sagt eigentlich schon alles, ich würde gerne UTF8 im SMF nutzen, soweit wie ich weiss ist das aber nicht ganz so einfach.
Ist es mit SMF möglich überhaupt UTF8 zu benutzen?
Wenn ja, was ist dazu nötig? Was muss man alles anpassen und wie Aufwendig ist der Spass?
Ich hatte vorhin einfach mal die SMF MySQL Tabellen von latin1 german in utf8 unicode geändert, das Resultat war das ich keine Umlaute mehr schreiben kann und ich kein Schimmer hab an was das liegen könnte.
Als erstes mußt Du das Template Deines Themes von ISO-8859-1 / ISO-8859-15 auf UTF-8 ändern. Damit werden Deine Umlaute wieder richtig angezeigt und Du kannst Sie auch schreiben. Natürlich sollte Dein Apache als Default-Charset auch UTF-8 anliefern (z.B in der httpd.conf einzustellen mit "AddDefaultCharset UTF-8" anstelle von ISO-8859-?).
Beispiel für einen XHTML Kopf:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de"><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="keywords" xml:lang="de" lang="de" content="<Deine Keywords>" />
Apache Konfiguration:
AddDefaultCharset UTF-8
Die Letzte Falle die mir aufgefallen ist, befindet sich bei der Rechtschreibprüfung falls Du diese benutzt. Was da zu tun ist findest Du hier:
[gelöst] Spellcheck und UTF-8 (http://www.simplemachines.org/community/index.php?topic=83664.0)
Du wirst bei Deinem Theme/Templates auch noch alle Umlaute maskieren müssen. Also statt "ä ö ü Ä Ö Ü ß" "&aauml; ö ü &Aauml; Ö Ü ß" etc.
Leider kommen wir nun zu dem Problem der Textdateien mit Strings für Javascript (die Fensterchen mit Meldungen wie "Rechtschreibprüfung beendet"). Da mußt Du die TEXTDATEI mit dem Unicode Bytecode füttern. Unter Windows bietet sich dafür ein Editor wie UltraEdit an, der eine Datei in UTF-8 umkodieren kann. Unter Linux nimmst Du Deinen Lieblingseditor (z.B nano) der hoffentlich für UTF-8 kompiliert und konfiguriert wurde (sprich: UTF-8 ist auch Dein Charset unter Linux).
Leider muß SM hier noch etwas nachbessern, fairerweise sollte man aber nicht verschweigen das PHP selber bis zur Version 5 sich nicht gerade mit Ruhm bekleckert was UTF-8/Unicode Support angeht. Mit PHP6 soll das angeblich besser werden, man wird sehen (vorallem den Umstellungsärger :> )
PS & Edit: Natürlich muß auch die Verbindung zum MySQL Collation Unicode sein!
[mysql]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8
...
[mysqld]
character-set-server = utf8
default-character-set = utf8
default-collation = utf8_unicode_ci
Den Unterschied der Abschnitte mysql und mysqld beachten!
Achja, WIE hast Du eigentlich die Collation geändert?
Also auf welchem Wege hast Du von "latin1 german" nach "utf8 unicode" geändert?
Ich vermute mal mit phpmyadmin, ich würde nur gerne wissen wie exakt Du vorgegangen bist.
(Ich vermute da stimmt auch noch etwas nicht)
Danke für die Antworten, da sind doch noch ein paar Dinge dabei die ich nicht berücksichtigt hatte. ;)
Rechtschreibprüfung benutze ich nicht, da mein Webserver die zwar unterstützt, aber sie nur ein leeres Popup-Fenster liefert. Das war auch hier im Board so, doch jetzt gerade geht sie das erste mal. Mir scheint die nicht ganz zuverlässig zu sein, daher lass ich da erstmal die Finger von (kann ich ja später noch einschalten).
Nun, ich wollte es ursprünglich per phpMyAdmin machen, da ich aber absolt kein Bock hatte über 40 Tabellen von Hand abzuarbeiten (ich hab jedenfalls keine Funktion gefunden mit dem ich alle auf einen Rutsch ändern kann...), hab ich mir die DB exportiert und hab dort alle Einträge per suchen/ersetzen von latin1_german2_ci in utf8_unicode_ci und latin1 in utf8 geändert und dann wieder importiert (mit Drop Tabelle), seltsamerweise stand danach dann bei den tabellen utf8_general_ci statt utf8_unicode_ci. Vor dem Importieren hatte ich natürlich die DB auf utf8_unicode_ci Collation gestellt. Dachte eigentlich auf die Art müsste es korrekt sein (das Ergebnis, nicht unbedingt der Weg dahin ;) ).
Ich muß leider nochmal schnell weg, aber ich wollte noch schnell anmerken das Du damit nichts auf UTF-8 umgesetzt hast. Du hast zwar MySQL veranlasst den INHALT einer Zelle anders zu interpretieren, aber der Inhalt an sich ist immernoch in der alten Kodierung. Es geht bei phpMyAdmin auch leider nicht in einem Rutsch afaik. Da Dein Forum ja noch ganz am Anfang ist, würde ich Dir empfehlen alle Inhalte (sind ja wenige) in eine Textdatei zu kopieren, die Datenbank zu DROP'en und komplett neu zu erstellen als utf8_unicode_ci .. anschließend zur Kontrolle nochmal in die einzelnen Tabellen gehen und unter "Struktur" schauen ob die eigentlichen Felder der Tabelle auch wirklich als UTF-8 erstellt wurden. Danach solltest Du bereits UTF-8 haben und, insofern die Templates sich als UTF-8 ausgeben, auch Texte mit Umlaut erstellen können und so wieder richtig angezeigt bekommen (Teste auch ruhig mal ein wenig Griechisch oder Russisch). Auf meinem Forum gibt es ein Gast Board in dem Du es Dir mal ansehen kannst (Gäste haben Schreibrecht).
Der Inhalt wurde ja auch neu eingelesen mit den geänderten Tabellen, hab ja nicht nur die Struktur geändert und alle Felder standen auch auf utf8_unicode_ci.
<meta http-equiv="Content-Type" content="text/html; charset=', $context['character_set'], '" />
Bin ich blind oder wieso finde ich keine Einstellung im Admin Center? Wo ist diese Einstellung versteckt?
Hm, seltsam... wie kann es sein das hier jap. Zeichen gehn (http://thenga.de/prerelease/index.php/topic,8.0.html), wenn ich da überhaupt nichts auf utf8 umgestellt hab und die tabellen selbst alle auf latin1_german2_ci eingestellt sind? Das dürfte dann doch eigentlich gar nicht gehn? Also wenn das auch ohne utf8 geht, dann kann ich mir die ganze Arbeit auch sparen.
Die Variable "character_set" ist festgelegt in Deinen Theme Templates:
Themes/<theme>/languages/index.<sprache>.php
Der Inhalt wurde aber nicht geändert. Wenn in Deiner Datenbank z.B ein Eintrag "A" stand, und der HexCode "für" A entspricht in Deinem neuen Charset einem "B", dann erscheint nach dem laden des Beitrages ein "B" statt dem "A". Es hat ja keine Konvertierung zwischen den Charsets stattgefunden. Du hast simpel die Aussage "Dies ist nun Charset X und nicht mehr Charset Y" geändert, jedoch nicht die Daten selbst von Charset X nach Charset Y übertragen. Diese Inkonsistenz wird sich bemerkbar machen, je nachdem wie Du nun weiter verfährst dürfte in Zukunft alles in UTF-8 geschrieben werden, die alten Daten liegen aber in Wirklichkeit in ISO-8859-1/15 vor ... somit wird je nachdem ob Du den Browser veranlaßt UTF-8 oder ISO-8859-1 zu dekodieren das eine oder das andere falsch angezeigt.
Der Grund warum das japanische richtig angezeigt wird, ist das es maskiert in die Datenbank eingetragen wurde per HTML Maskierung. Das heißt in Deiner Datenbank stehen nicht wirklich die japanischen Zeichen, sondern ein HTML Code der Dir unabhängig der gewählten Codepage das richtige Zeichen anzeigt insofern ein passender Zeichensatz dazu vorhanden ist. In Deinem Beispiel ist es:
& #12398;& #23550;& #25126; (ohne Leerzeichen zwischen & und # eigentlich)
Das ist eine Ersatzschreibweise wie auch "ä" ein deutsches "ä" maskiert. Wenn Dir das so reicht, dann kannst Du Dir UTF-8 sparen, hat aber wenig mit "echtem" UTF-8 zu tun. Vielleicht hilft Dir ein Blick in diesen Artikel für Dich selbst zu entscheiden ob Du UTF-8 haben willst/brauchst:
Wiki Artikel zu UTF-8 (http://de.wikipedia.org/wiki/UTF-8)
und ergänzend:
Wiki Artikel zu Unicode (http://de.wikipedia.org/wiki/Unicode)
Ein Blick in Dein Forum:
Immerhin funktioniert das Transcoding ausreichend, vielleicht nochmal mit dem IE testen ob er die Daten identisch anliefert (sollte er, but who knows?)
Zumindest ersetzt er bei Dir alles sauber durch maskierte Zeichen, das macht längst nicht jede PHP Forensoftware.
<EDIT: Vielleicht sollte ich kurz einfach mal anschneiden wo das Pro für natives UTF-8 liegt:
- Deine Datenbank wird etwas schlanker ausfallen, da keine längeren Ersatzstrings gespeichert werden.
- Die Inhalte der Datenbank könnten ohne (möglicherweise Fehlerhaftes) Transcoding direkt in eine UTF-8 kompatiblen Anwendung (z.B Editor) weiterverarbeitet werden.
- Es ist kein Transcoding und damit keine weiteren Schichten nötig. Transkodierung hat immer die Gefahr das es durch bestimmte Einschränkungen/Umständen zu Fehlinterpretationen kommt.
- UTF-8 ist ziemlich sicher der Schritt in die Zukunft.
- Umsetzungsschichten könnten mal in einer späteren PHP Version wegfallen oder einfach anders arbeiten.
>
Sollte eigentlich nicht beim Import über phpMyAdmin bei der Charset Einstellung die Daten im richtigen Charset geladen werden und so eben doch korrekt in der DB landen?
Eben ich bin sowas von anderer Forensoftware auch nicht gewohnt und bin daher nicht mal auf die Idee gekommen das einfach mal auszuprobieren. Eigentlich würde mir die Ausgabe so reichen, werde mir das mit dem Unicode und UTF-8 noch mal durchlesen, allerdings nicht in den nächsten Tagen, hab nur noch 2 Tage meine Seite fertig zu kriegen und da wirklich keine Zeit für mich damit rumzuschlagen. Trotzdem danke, jetzt blick ich da schon etwas besser durch. :)
Hallo,
In my.cnf habe ich überall cp1251 für SET NAMES und collations.
Wo kann ich in der Skript alle db queries definieren, zB
@mysql_query("SET NAMES 'utf8'", $this->_resource);
Meine Seite (Joomla) hat dies in /includes/database.php, aber d. selsbst. Forum akzeptiert es nicht, nur wenn als Komponent berufen.
Danke
Uff, 20 J. hab ich kein Deutsch geschrieben. :D