Sonderzeichen richtig anzeigen lassen
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
anlegen
ansatz
arbeiten
code
datei
datenbank
datum
gefallen
header
http
problem
projekt
sauberes arbeiten
set
speichern
stehen
text
url
zeichen
zeug
-
Hallo zusammen.
Ich habe in einer MySQL Datenbank Daten stehen, die Sonderzeichen wie z.B. ein â enthalten können. Dieses Zeichen wird bei mir so angezeigt: â
Als Zeichensatz im meta Tag habe ich ISO-8859-1 angegeben. Wenn ich UTF-8 angebe dann wird es richtig angezeigt, allerdings werden dann andere Zeichen auf meiner Seite falsch angezeigt. Deswegen möchte ich ISO-8859-1 lassen und nur diesen Wert aus der Datenbank als UTF-8 angeben. Dazu habe ich folgenden Code gefunden:
mb_convert_encoding($daten, "UTF-8")
Wenn ich das allerdings anwende, wird da oben genannte Zeichen so dargestellt: â
Obwohl es ja vorher mit UTF-8 als Zeichencode für die gesamt Seite geklappt hat. Also wie kann ich diese Sonderzeichen jetzt richtig Darstellen? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
UTF-8 ist auf jeden Fall die bessere Wahl.
Woher kommen denn die Zeichen, die bei Wahl von UTF-8 trotzdem falsch dargestellt werden? Auch aus der Datenbank? Das wäre natürlich problematisch, denn dann würde es ja bedeuten, dass in deiner Datenbank Daten stehen, die mit unterschiedlicher Codierung eingefügt wurden.
Wenn die falsch dargestellten Zeichen aber aus dem statischen Teil deiner Website kommen (z.B. aus einem Template), dann ist es am besten, diesen Teil zu konvertieren.
Ein einfaches Werkzeug zu Konvertieren ist der Editor Notepad++. Dort Text einfügen oder Datei aufrufen und (bei deutscher Menüsprache) auf
Konvertierung >>Konvertiere zu UTF-8 ohne BOM
klicken und speichern
-
Wenn du etwas encodierst, musst du die umwandlung natürlich zurück machen, um anständig was zu sehen...
Nichts für ungut, aber ich gebe mein-wunschname Recht.
Wenn du was neu aufbaust, dann mach es gleich richtig, und gleich richtig heißt, sich für das Gesamtprojekt für eine Zeichensatzcodierung zu entscheiden und nicht hü und hott, mal so mal so...
ISO-8859-1 ist mehr als veraltet mittlerweile, nimm UTF-8, bleib bei UT8 und fang nciht an innerhalb eines Projektes hin und her zu switchen, du tust dir selbst keinen gefallen damit und falls wer mit deiner Seite arbeiten will, tust du dem auch keinen gefallen damit.
Wenn es dann losgeht, dass du formulareingaben entgegen nimmst, nimsmt du die auch in diesem auf und wilslt die in eine UTF-8 db reinklemmen, das geht schief... und dann stehst du wieder da und dann kommt der letzte Rotz an hickhack zusammen, wo dein Projekt die halbe Anfragedauer damit vertrödelt, Zeichensatzkonvertierungen durchzuführen...
als zwischenlösung für die Umstellung kannst du ja mit htmlspecialchars arbeiten, die dir das zeug in ä etc umwandelt, bei UTF-8 kannst du die dann mit ersetzung wieder zurückstellen... oder auch nciht, je nachdem... damit kommt UTF-8 auch klar...
@czibere: schöner Ansatz, aber der TE sollte sich wirklich sauberes arbeiten angewöhnen und dazu gehört, sich auf eine Collation zu beschränken, zumal das Projekt in der Phase der Erstellung zu stecken scheint... -
sebulon schrieb:
habe - glaube ich - an 2 stellen an die collation hingewiesen. (oder, aus unerklärtem grund komme ich jetzt nicht ganz mit.)
... @czibere: schöner Ansatz, aber der TE sollte sich wirklich sauberes arbeiten angewöhnen und dazu gehört, sich auf eine Collation zu beschränken, zumal das Projekt in der Phase der Erstellung zu stecken scheint... -
sebulon schrieb:
...
ISO-8859-1 ist mehr als veraltet mittlerweile, nimm UTF-8, bleib bei UT8 und fang nciht an innerhalb eines Projektes hin und her zu switchen, du tust dir selbst keinen gefallen damit und falls wer mit deiner Seite arbeiten will, tust du dem auch keinen gefallen damit.
Wenn es dann losgeht, dass du formulareingaben entgegen nimmst, nimsmt du die auch in diesem auf und wilslt die in eine UTF-8 db reinklemmen, das geht schief... und dann stehst du wieder da und dann kommt der letzte Rotz an hickhack zusammen, wo dein Projekt die halbe Anfragedauer damit vertrödelt, Zeichensatzkonvertierungen durchzuführen...
Da ISO-Latin-1 (8859-1) ein Unicode-Subset ist, ist eine Konvertierung von ISO-8859-1 nach UTF-8 kein Problem. Allerdings stimme ich dir insoweit zu, dass es bei Verarbeitung von HTML-Formularen besser ist, komplett auf UTF-8 zu setzen. Das vermeidet Probleme mit der Zeichensatzerkennung und -umwandlung.
als zwischenlösung für die Umstellung kannst du ja mit htmlspecialchars arbeiten, die dir das zeug in ä etc umwandelt, ...
Htmlspecialchars() wandelt "Rohtext" in HTML-Character-Data-Text. Es baut nur Character-Entities für die 5 HTML5-Standard-Escape-Zeichen ('&', '<', '>', '"', "'"). Von allen andern (inkl. deutschen Umlauten) lässt es die Finger. Und das ist auch besser so, denn die sind noch veralteter als ISO-8859-1 es deiner Meinung nach wäre.
@czibere: schöner Ansatz, aber der TE sollte sich wirklich sauberes arbeiten angewöhnen und dazu gehört, sich auf eine Collation zu beschränken, ...
Collations haben mit der Zeichenkodierung nichts zu tun. Sie sind für die Sortierung und Suche von Texten gedacht. Beide in einen Topf zu werfen, hilft dem TE sicher nicht dabei, sich sauberes Arbeiten anzugewöhnen.
Beitrag zuletzt geändert: 2.5.2014 0:26:13 von alopex -
Hatte selber mal damit sehr zu kämpfen :-)
Bei mir war das größte Problem das Eclipse (mein genutztes IDE) in den Standardeinstellungen jede Datei im ISO Format erstellt hat und ich am Ende jede Datei einzelnd ändern musste.
Denk dran wirklich alles auf UTF-8 umzustellen, sprich deine Datenbank falls vorhanden, die Dateien die erstellt werden können direkt im UTF-8 Format erstellt werden und in deinem Code kannst du entweder direkt in HTML den Meta Tag angeben oder per PHP diesen einbauen. -
Eigentlich müsste es gehen wenn du folgendes sicherstellst:
1. Die Daten in der DB in UTF-8 speichern
2. Deine PHP-Dateien als UTF-8 speichern. (lässt sich in jedem Editor einstellen)
3. Im PHP dem Client mitteilen, dass er utf-8 codierten Text bekommt. Das solltest du machen bevor du irgendetwas ausgibst.
header('Content-Type: text/html; charset=utf-8');
Wenn du das gemacht hast, sollte es wirklich kein Problem mehr sein. -
oder in der .htaccess
php_value date.timezone "Europe/Berlin" AddDefaultCharset UTF-8 AddCharset UTF-8 .php .html .htm .css .js php_value default_charset "UTF-8" php_value iconv.input_encoding "UTF-8" php_value iconv.internal_encoding "UTF-8" php_value iconv.output_encoding "UTF-8" php_value mbstring.internal_encoding UTF-8 php_value mbstring.http_output UTF-8 php_value mbstring.encoding_translation On php_value mbstring.func_overload 6
wichtig (evtl. ausreichend) sind dabei vorallem folgende 2 Zelen
AddDefaultCharset UTF-8 php_value mbstring.internal_encoding UTF-8
anstatt in der .htaccess geht das auch in einer PHP-Datei
<?php header('Content-Type: text/html; charset=utf-8'); mb_internal_encoding("UTF-8"); // ---- hier dein Script ---- ?>
nur header() ohne mb_internal_encoding() ist in vielen Fällen leider nicht ausreichend.
:=)
und ... EDIT ... für MySQL Datenbank ...
1.) die Tabelle mit UTF-8 anlegen
CREATE TABLE table_name ( ... ) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
und evtl. auch String-Datentypen innerhalb der Tabelle mit Charset = UTF-8 anlegen
meintext varchar(100) character set utf8
2.) bei Verbindung mit UTF-8 arbeiten
mysql_query("SET NAMES 'utf8'");
oder als ausführlichers MySQL-Query
mysql_query("SET character_set_results = 'utf8', character_set_client = 'utf8', character_set_connection = 'utf8', character_set_database = 'utf8', character_set_server = 'utf8'"
:=)
Beitrag zuletzt geändert: 4.5.2014 20:20:24 von hpsponsor -
hpsponsor schrieb:
oder in der .htaccess
Nichts gegen deine Tipps zu Statements in der .htaccess. Viele Dinge, die damit korrigiert werden, wären aber nicht existent, wenn der Programmierer bereits im Vorfeld die Empfehlungen eachtet hätte, die in diesem Thread schon gegeben wurden.
.htaccess ist NUR das letzte Mittel, welches man anwenden sollte Z.B. wenn Korrekturen in den Skripten und HTML-Seiten nicht möglich, oder zu aufwendig sind.
-
fatfreddy schrieb:
.htaccess ist NUR das letzte Mittel, welches man anwenden sollte Z.B. wenn Korrekturen in den Skripten und HTML-Seiten nicht möglich, oder zu aufwendig sind.Dem kann ich nur zustimmen.
Das kann auch ich bestätigen.
^^ Klingt beides doof? Ist aber so. :)
In einem Fall bearbeitete ich einen bestehenden Webauftritt - nur *.html -Seiten waren möglich, da der Anbieter derzeit nichts anderes erlaubte. Viele neue Seiten kamen hinzu. Später wurde der Anbieter gewechselt, und endlich waren auch PHP und .htaccess möglich.
Aber dann gab es eine entscheidene Änderung als Direktive über Amtswege:
Qualifizierung durfte nicht mehr Qualifizierung heißen, sondern sollte von nun an Beschäftigung heißen.
Alle Links wurden hinfällig. Da blieb nichts anderes übrig, als das über .htaccess zu realisieren. Der Verein hatte einfach nicht genug finanzielle Mittel, um das komplette Webseitengerüst völlig neu aufbauen zu lassen.
Just my 2 Cent.
Beitrag zuletzt geändert: 5.5.2014 4:26:48 von menschle -
100% ACK! Wer was neues aufbaut insbesondere mit MYSQL-DB immer UTF-8 (general-ci) einsetzen. Ganz wichtig, das Script muss auf/mit UTF-8 arbeiten als auch die MYSQL-DB selbst. Sonst ist Trödel vorprogrammiert...
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
