• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Utf8

P

P51D

Mitglied
Hallo miteinander

Ich bin etwas genervt:
Ich habe mich beim Überarbeiten meiner Homepage auch gleich an das Umstellen auf UFT8 gemacht. Doch bislang produziert das Ganze mehr Probleme als es löst.
MySQL Datenbanken sind auf UTF8 eingestellt, Header ebenfalls, Formulare auch.
Wenn ich jetzt einen Satz mit Sonderzeichen aus der DB lese, dann wird das nur mit Rechteck, Fragezeichen und sonstigem Müll ausgegeben.

Jeden String in PHP muss zusätzlich noch mit utf8_encode() verwendet werden..., wobei ich zwischendurch wieder decodieren muss, weil sonst bei doppeltem Aufruf von utf8_encode noch mehr Müll produziert wird.

Irgendwie sehe ich den Sinn nicht, die ganze Arbeit zu machen, wenn es sowieso nicht wirklich etwas bringt...

Oder gehe ich das Ganze falsch an?
MFG
P51D
 
Werbung:
Bist du sicher, dass in der Datenbank alles auch UTF-8 reingeschrieben wurde oder sind die Tabellen nur UTF-8 umgestellt, der Inhalt aber ANSI (oder sowas).
 
Werbung:
die tabellen werden vom PHP alle in dieser Weise erstellt:
Code: 
$error = mysql_query("
    CREATE TABLE IF NOT EXISTS `$db_table` (
      `id` int(5) NOT NULL auto_increment,
      `title` varchar(120) NOT NULL default '',
      `date_time` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
      `author` varchar(255) NOT NULL default 'Administrator',
      `description` varchar(255) NOT NULL,
      `type` varchar(100) NOT NULL default '',
      `url` varchar(255) NOT NULL default '',
      `content` longtext NOT NULL default '',
      UNIQUE KEY `id` (`id`)
    ) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
");                                                                    // Tabelle erstellen, falls sie nicht existiert

@T!P-TOP
Header wurde auch so angegeben.
Aber die Verbindung habe ich jetzt noch nicht speziel so definiert. Muss das beim DB-Select passieren?

Werde es aber noch ausprobieren. Muss dann jeweils utf8_encode auch noch ausgefürht werden?

EDIT:
Die Kollation der Tabellen ist "utf8_general_ci"....ev ist dies auch noch falsch.
Achja, cooler Link
Systemmitteilung Ihre Suchanfrage erzielte keine Treffer. Bitte versuchen Sie es mit anderen Suchbegriffen.
Zum Vergrößern anklicken....

MFG
 
Zuletzt bearbeitet:
Neues Problem:

Bei einem Menu von CSSPlay wird nur noch die Hälfte ausgeführt (das Hauptmenü funktioniert, aber die Untermenüs werden nicht mehr eingeblendet).
Und das alles nur, weil ich die PHP Dateien mit den Klassen für das CMS von ASCII auf UTF8 geändert habe (mit Programmers Notepad 2 erstellt).
Das ist absolut unlogisch. Habt ihr da auch schon ähnlihce Erfahrungen gemacht?
Oder Wie könnte man das Problem umgehen?

MFG
P51D
 
Also, es sollten folgende Dinge auf „UTF-8“ stehen:

  1. Charset/collation der Datenbank-Tabellen. utf8_general_ci ist in der Regel passend, grundsätzlich ist aber alles mit utf8_* möglich.[1]
  2. Charset der Datenbank-Verbindung. PDO::MYSQL_ATTR_INIT_COMMAND oder mysqli::set_charset oder mysql_set_charset oder SET NAMES utf8.
  3. HTTP-Header Content-Type charset: header('Content-Type: text/html; charset=UTF-8'); und/oder AddDefaultCharset UTF-8 in .htaccess, … I18n Checker zum Überprüfen.[2]
  4. Charset der Source-Code-Dateien beziehungsweise der HTML-Templates. UTF-8 (ohne BOM). Das sollte in den Editor-Optionen einstellbar sein.

Achtung: Ein <meta charset="utf-8" /> im HTML-Code ist häufig bedeutungslos, da es von einer Servereinstellung (Header) überschrieben wird! Die Angabe wird meist nur dann interessant, wenn eine Seite auf dem eigenen Rechner gespeichert und von dort als lokale Datei im Client geöffnet wird, da in diesem Fall kein Server existiert, der Header mitschickt.

[1] MySQL :: MySQL 5.6 Reference Manual :: 9.1 Character Set Support
[2] W3C I18n Checker

- Mehr Infos: UTF-8 - PHP Forum: phpforum.de

- Lesenswert (!): The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) - Joel on Software

- Auch auf Englisch, aber ganz ausgezeichnet (!): http://www.w3.org/International/tutorials/language-decl/

P51D schrieb:
Habt ihr da auch schon ähnlihce Erfahrungen gemacht?
Zum Vergrößern anklicken....

Oh ja, aber das ist zum Glück viele Jahre her. Irgendwann fällt der Groschen.

Eine Änderung von ASCII auf UTF-8 ändert übrigens gar nichts, weil ASCII (ASCII 7 Bit) eine Untermenge von UTF-8 ist.

- American Standard Code for Information Interchange

Du hast vermutlich von ISO-8859-1 (aka latin1) oder von Windows-1252 (aka cp1252) in UTF-8 konvertiert.

Das beeinflusst alle Zeichen, die nicht in ASCII liegen. Also alle Zeichen außer:

Code: 
 !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
`abcdefghijklmnopqrstuvwxyz{|}~

Um zu sagen, was genau bei dir das Problem ist, fehlen glaube ich Informationen, etwa eine Demoseite.



PS: utf8_encode konvertiert von ISO-8859-1 zu UTF-8. Die Funktion brauchst du nicht, wenn du dein Umfeld korrekt konfigurierst (siehe oben).
 
Werbung:
Besten Dank für die Ausführliche Antwort.

Ich habe den Fehler gefunden:
mermshaus schrieb:
Charset der Source-Code-Dateien beziehungsweise der HTML-Templates. UTF-8 (ohne BOM). Das sollte in den Editor-Optionen einstellbar sein.
Zum Vergrößern anklicken....
Die Dateien habe ich alle neu im UTF-8 Format MIT BOM erstellt. Als ich sie auf die Verion ohne BOM geändert habe, lief alles wieder.

Laut W3C:
  1. warning.png
    Byte-Order Mark found in UTF-8 File.
    The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported.
Zum Vergrößern anklicken....
Ältere Browser?? Ich nutze FF 6.0.2 und FF ist normalerweise ja nicht ein Browser, der alles sehr spät einführt. Aber ja, jetzt läufts.
Aber an so einer Kleinigkeit kann man ja dann sehr sehr lange basteln und schliesslich verzweifeln.

Achja, wieso soll die BOM noch nicht angegeben werden? Da ja alles immer weiter entwickelt wird, wird UTF-8 sicher einmal in UTF-16, UTF32 geändert werden, wodurch dann wieder die BOM angegeben werden muss. Wenn jetzt schon die Browser und Editoren kompatibel sind, dann muss später nicht wieder eine grosse Umstellung gemacht werden, oder?

MFG
P51D
 
Aber an so einer Kleinigkeit kann man ja dann sehr sehr lange basteln und schliesslich verzweifeln.
Zum Vergrößern anklicken....

Ja, allerdings. Ich habe beispielsweise ewige Zeit nicht gewusst, dass es Punkt 3 aus meinem letzten Post gibt, also dass die Angabe des Charsets in aller Regel eine serverseitige Header-Einstellung ist. Das führt zu dem Effekt, dass Code auf einem zufällig passend konfigurierten Server funktioniert, aber auf einem anderen – warum auch immer – nicht.

Die BOM ist ihrerseits so tückisch, da sie in einem Editor, der die Datei als UTF-8 anzeigt, nicht dargestellt wird, am Dateianfang jedoch trotzdem als drei Bytes vorhanden ist. Die stehen etwa vor einem einleitenden <?php und sind Ausgabe, was ständig zu „Headers already sent…“-Problemen führt (Stichwort Sessions) oder eben zu solchen Effekten, wie du sie beobachtet hast.

Das muss man wissen. Von alleine kommt man da wohl kaum drauf.

Da ja alles immer weiter entwickelt wird, wird UTF-8 sicher einmal in UTF-16, UTF32 geändert werden, wodurch dann wieder die BOM angegeben werden muss.
Zum Vergrößern anklicken....

Diese drei Zeichensätze sind unterschiedliche Kodierungsmöglichkeiten für dieselben konkreten Unicode-Zeichen („Characters“).

Die genauen Eigenschaften werden bei Wikipedia erklärt.

- Unicode Transformation Format

Die kurze Antwort ist: UTF-8 wins.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben