Startseite aufrufen
« Zurück
Vor »

Kommentar schreiben | Drucken

UTF-8 und die Entity

-- 24.September 2005 (#42)

Der Anfang aller Zeichensätze war ASCII. ASCII erlaubt 128 Zeichen, 32 davon sind nicht-visuelle Steuerzeichen. So kann man mit ASCII also maximal 96 Zeichen darstellen – für die Anfänge der Informatik, die fast ausschließlich auf die Buchstaben des englischen Alphabets zurückgriff, war das noch ausreichend. Sonderzeichen aus anderen Sprachen, wie die deutschen Umlaute ä, ü, ö und ß, konnten durch HTML Entities dargestellt werden.
Eine HTML Entity beginnt stets mit einer Et-Ligatur (&) und endet mit einem Semikolon (;). Dazwischen befindet sich eine Codierung mit maximal 6 Buchstaben. Für die Umlaute ä, ü, ö und ß sind die Entities ä, ü, ö und ß.

Später begann man, Zeichensätze (Code Pages) einzuführen, um auch die Sonderzeichen der Westeuropäern ohne spezielle Codierung mit HTML Entities zu ermöglichen. Der Zeichensatz für die deutsche Sprache ist ISO8859-1 bzw. ISO8859-15 (mit Euro-Zeichen). Entities können zwar weiterhin benutzt werden, sind aber dadurch nicht mehr zwingend notwendig.
Leider kann man mit den Zeichensätzen nur sehr begrenzt Zeichen aus verschiedenen Sprachen darstellen. Die gleichzeitige Darstellung von deutschen und französischen Sonderzeichen funktioniert problemlos, aber Deutsch und Hebräisch würden ernsthafte Probleme bereiten.

Die nächste Stufe der „Sonderzeichen-Reform“ ist Unicode. Die gängigste Unicode-Kodierung lautet UTF-8. UTF-8 steht für 8-bit Unicode Transformation Format. Mit UTF-8 können bis zu 4 Byte, das heißt 1.114.112 Zeichen dargestellt werden. 1.114.112 Zeichen, um die Zeichen aller Sprachen aufzunehmen und jedem Zeichen eine eindeutige Nummer zu geben. Mit UTF sind HTML-Entitäten also (in der Theorie) überflüssig und verschiedenste Sprachen können in ein und demselben Dokument problemlos dargestellt werden.

Um bei HTML und XHTML auf UTF-8 zu setzen, sollte man

  • die Kodierung des HTML-Editors auf UTF eistellen (1)

  • die Kodierung von CSS-Dateien in UTF ändern (2)

  • den Webserver (idR) anweisen, HTML-Seiten, CSS-Dateien usw. mit der Kodierung UTF auszuliefern (3)

  • die UTF-Kodierung in die XML-Deklaration hinzufügen (4)

  • UTF-8-Kodierung für PHP-Dateien einstellen (5)

  • Formulare UTF-8 kodieren. (6)

  • die Kodierung zusammen mit dem MIME-Typ in die Meta-Tags der HTML-/XHTML-Seiten einfügen. (7)


1. UTF-8-Kodierung im HTML-Editor einstellen

In den besseren Editoren ist es möglich, die Kodierung einfach in den Einstellungen zu ändern. Als Beispiel ist hier rechts nebenstehend der Einstellungsdialog von Bluefish dargestellt.
Durch die Kodierung als UTF wird eine BOM in die Dateien geschrieben. An Hand der BOM, welche eine Sequenz von Bytes vor einer Datei ist, kann ein Client (Browser) erkennen werden, welches Encoding benutzt werden soll.

2. CSS-Dateien und Unicode

Das Thema CSS und UTF ist schnell abgehakt, wir stellen nämlich einfach folgende Zeile an den Anfang der Stylesheets:

@charset "utf-8";


3. Webserver (Apache) für UTF-8 vorbereiten

Um den Webserver explizit anzuweisen, dass wir unsere Seiten in UTF ausliefern wollen, fügen wir folgende Zeilen hinzu (.htaccess wäre eine Möglichkeit):

AddType text/css;charset=utf-8 .css
AddType text/html;charset=utf-8 .html

oder

AddCharset utf-8 .css .html .xhtml


4. UTF-Kodierung in der XML-Deklaration

Im Prinzip ist dieser Schritt unnötig, weil XHTML-Dateien per se UTF-8-kodiert sind, aber wer sicher gehen will, kann diese Zeile seinen XHTML-Seiten voranstellen:

<?xml version="1.0" encoding="utf-8"?>


5. UTF-8-Kodierung für PHP-Dateien

Entweder man ändert den PHP-Header:

header('content-type: text/html; charset=utf-8');

oder – in so fern man Zugriff auf diese Datei hat – in der php.ini:

default_mimetype = "text/html"
default_charset = "utf-8"


6. UTF-8 für Formular-Eingaben

Damit Besucher in Formularen ebenfalls sämtliche Zeichen, die UTF-8 kennt, eingeben können, bedarf es dem Hinzufügen des Attributs accept-charset:

<form accept-charset="utf-8" method=…


7. UTF und Meta-Tags

Für HTML:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

Für XHTML:

<meta http-equiv="content-type" content="application/xhtml+xml;charset=utf-8" />


Schlussbemerkung

Wenn alle Vorkehrungen für UTF-8 getroffen wurden, dann sollte es keine Schwierigkeiten geben. Manches mag doppelt gemoppelt wirken, aber so werden Probleme umgangen.
Es kann allerdings vorkommen, dass man die Einstellungen des Servers nicht ändern kann, weil der Server-Betreiber sehr restriktive Zugriffseinstellungen hat. Dann kann muss man womöglich doch wieder auf HTML-Entitäten zurückgreifen. Alternativ kann man auch (hexadezimale) Unicodes benutzen. HTML-Entities können nämlich auch bei UTF weiterhin benutzt und auch mit Unicodes problemlos kombiniert werden.

Für die Zeichen ", &, < und > sollten auch bei „funktionierendem“ UTF weiterhin als HTML Entities geschrieben werden. Die Entitäten lauten &quot;, &amp;, &lt; und &gt;.


Geschrieben von
GDur (anonym)
-- 29.August 2010 (#69)

viiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiilen dank!
habe das php header ding benutz und es hat sofort alle meine probleme gelöst!!!

so musses sein!


Geschrieben von
spine (anonym)
-- 19.August 2008 (#61)

@Manuel (anonym):

Doch muss man - speicherst du nämlich deine PHP Dateien MIT BOM, kommt es zu sehr unschönen Fehlern wie zb. Abständen im Layout hervorgerufen durch die BOM Zeichen.

OHNE BOM läuft es super - also Leute - NO BOM ^^


Geschrieben von
Bene (anonym)
-- 15.Dezember 2005 (#5)

danke für die Zusammenfassung! Hat mir geholfen!


Geschrieben von
Niko (anonym)
-- 26.Januar 2006 (#8)

ah. hab’s.

die pappnasen bei dem schweizer provider haben in die httpd-conf ein default-charset reingeknallt und mit "allowOverride none" verboten, dies per .htaccess zu ändern. über html-meta-angaben kann das dann auch nicht mehr gerissen werden. ein bisschen email-hin-her mit dem support hat das geklärt und jetzt klappts auch mit dem nachbarn.

grüße, niko.


Geschrieben von
Kevin (anonym)
-- 12.März 2009 (#65)

Das "<?xml version="1.0" encoding="utf-8"?>" bringt den Internet Explorer in den QuirksMode und kann so eventuell das Design zerfetzen. Sollte man weg lassen..


Geschrieben von
Niko (anonym)
-- 31.Dezember 2005 (#6)

klasse zusammenfassung. habe trotzdem noch probleme. hab eigentlich alles probiert:


<?php; include("includes/modules.php"); ?>
<?php; echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"; ?>
[…]
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />

in meiner index.php und


AddCharset utf-8 .css .html .xhtml .php

in meiner .htaccess. die seite tut auch auf meinen zwei eigenen servern, bei 1und1 und bei dreamhost. aber bei so nem seltsamen schweizer provider leider nicht:

hier gehts:
http://www.niko-dittmann.com/Kunden/www.lingenhel.ch/

hier nicht:
http://www.lingenhel.ch/demo2/

hat irgendjemand ne ahnung, wieso? bin für jede hilfe dankbar.

grüße, niko.


Geschrieben von
Mirco (anonym)
-- 14.April 2007 (#43)

Echt nette Seite.

Hier eine Ergänzung, damit man nicht bei jeder DB-Verbindung einen Query ausführen muss. Einfach in die my.cnf dieses übernehmen:

[mysqld]
init-connect=’SET NAMES utf8’

Mich würde interessieren, ob man diesen Query nicht ganz loswerden kann? Das wäre eine feine Sache, in der MySQl-Dokumentation konnte ich leider nichts finden, sehr schwammig.

Noch ein Problem: Mein htmlentites() funktioniert nur noch mit: htmlentites($string,ENT_QUOTES,’UTF-8’)

Vielleicht weiß einer wieso das so ist?

VG, Mirco


Geschrieben von
Hertz-lich gebloggt... (anonym)
-- 06.Februar 2006 (#9)

zu 5. UTF-8-Kodierung für PHP-Dateien
php.ini:

default_mimetype = "text/html"
default_charset = "iso-8859-1"

Bist Du Dir sicher damit? Müsste hier nicht

default_mimetype = "text/html"
default_charset = "utf-8"

stehen?


Geschrieben von
Konky (anonym)
-- 13.Juni 2006 (#12)

Zum Beispiel dass es in den Anfängen der Informatik gar kein html gab ? :)


Geschrieben von
Armin Oberländer (anonym)
-- 16.Oktober 2005 (#3)

Danke für die Auflistung. Konnte mein Problem damit beheben. Durch Einbau Deiner Scriptzeile in den index.php header läuft die Codierung der Umlaute problemlos!

Vielen Dank nochmal! :)

Armin


Geschrieben von
Tom (anonym)
-- 29.März 2007 (#36)

sorry … hatte ich vergessen, zu erwähne:

Ich setze auch den SET NAMES Befehl ab.


Geschrieben von
Chris (anonym)
-- 22.Januar 2006 (#7)

Kann es sein, dass css beim Umstellen von ISO auf UTF-8 Probleme bereitet? In ISO codierte Website erkennt alle css anweisungen, utf-8 werden die CSS Anweisungen teilweise ignoriert und manche divs in der HP erst gar nicht angezeigt.


Geschrieben von
Dirk
-- 03.November 2006 (#20)

Weil ich bislang kein UTF-8 benutze. ;-)


Geschrieben von
Peter (anonym)
-- 19.Oktober 2006 (#18)

Hallo Dirk,

Klasse Darstellung. Kurz knapp präzise.

Hab’ leider trotzdem ein Problem:

In einer Form innerhalb einer HTML-Seite habe ich mehrere Eingabefelder. Diese werden per POST an ein php-Script übergeben und dort mit HTTP_POST_VARS abgeholt. UTF-8 ist sowohl im HTML als auch im PHP Header eingestellt. Aus den Variablen wird eine Mail zusammengebaut.

In dieser Mail kommen die Umlaute aus dem Formular nicht richtig an, während Umlaute, die als fester Text im php-Script stehen, richtig ankommen. Also klappt wohl irgendwie die Übergabe nicht. Dass die Eingaben auf der HTML-Seite richtig in der Variable stehen, habe ich per alert überprüft.

Wer hat einen Tipp, woran es liegen kann? Danke vorab für alle Hinweise.
Muss dazusagen, dass ich ein Newbie bin. Also können auch Anfängerfehler enthalten sein!

Peter


Geschrieben von
Web- Mediendesigner by A2D (anonym)
-- 06.August 2006 (#13)

Hallo

Also ich glaube der stephan hat recht!
Es sollte so aussehen…

default_mimetype = "text/html"
default_charset = "utf-8"

Greetz
C.T.


Geschrieben von
Heiko (anonym)
-- 13.Februar 2010 (#68)

hi. ich finde deine erklärungen sehr gut erklärt und finde es gut dass du anderen bei der arbeit an den webseiten unter die arme greifst.

leider jedoch fand ich zu meinem problem keine lösung… ich hab mehrere reiseseiten geschrieben. das ganz war in xhtml. um zu verhindern dass ich die navi auf allen seiten immer ändern muss habe ich die navis und manch andere dinge per php included und die endung in .php geändert. es funktioniert einwandtfrei, die seiten laden schneller und die navi und andere dateien müssen nur einmal anstatt x-mal geändert werden. jedoch ist der code laut validator nicht mehr valide.

so sehen die includes aus:
<?php include ("inc/navi_top.php"); ?>
<?php include ("inc/navi_left.php"); ?>

Da die Seite dann nicht mehr funktionierte habe ich folgende Zeilen rausnehmen müssen:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="style.css" type="text/css"?>

Wie man aber dem Ergebnis vom Validator entnehmen kann ist die Seite nicht mehr valide und das Encoding ist anstatt UTF-8 auf einmal iso-8859-1.
http://validator.w3.org/check?uri=http://www.reisen-ferienhaus.de/

Ich habe schon das ändern des Encodings per htaccess und per php.ini probiert!
php.ini:
default_mimetype = "text/html"
default_charset = "utf-8"

htaccess:
AddCharset utf-8 .css .html .xhtml .php

hast du oer jemand anderes eine ahnung woran es liegen kann, dass der code nicht mehr valide ist und wie ich das iso-encoding weg bekomme?

danke schonmal im voraus.

ps: falls ich irgendwelche angaben vergessen haben sollte die bei der fehlersuche hilfreich sein könnten, dann bitte ich um entschuldigung. werde diese natürlich nachliefern…


Geschrieben von
mark (anonym)
-- 03.September 2007 (#48)

Eine kleine Frage..

nachdem ich nun auf UTF8 umgestellt hab (Seiten und DB), habe ich ein paar Daten in die DB eintragen lassen über ein Formular.

Und zwar lokal (XAMPP) und auch dem Server (all-inkl.com).
Beides mal - wenn ich in den PHPMYADMIN-bereich gehe, werden die Umlaute etc mit den Unicodesymbolen dargestellt, anstatt wie ich eigentlich dachte in unseren Sprache - da ja die DB auch auf UTF8 ist.. mein Dreamweaver stellt ja die Umlaute auch plain dar - und nur im Hintergrund verschüsselt - also unsichtbar.

es stört jetzt nich so arg - nur ist es dann etwas schade, wenn ich nicht mir direkt in der DB etwas manuell umschreiben kann - weil ich ja dann die UTF8 kodierung eventuell übersehe bei Umlauten..

danke
LG Mark


Geschrieben von
spine (anonym)
-- 19.August 2008 (#62)

Sorry Manuel - meinte Henrik -.-


Geschrieben von
Gurkenpapst (anonym)
-- 30.November 2006 (#23)

Anmerkung zu Punkt 4 - UTF-Kodierung in der XML-Deklaration

In der Regel wird man gerade bei UTF-8 die XML-Deklaration weglassen, um nicht unnötig im IE den Quirksmode auszulösen. Sonst darf man sich nicht wundern, dass der noch mehr Fehler macht als er es eh schon tut. Wenn man XHTML ohne UTF-8 verwendet, hat man dagegen immer irgendwo unnötige Probleme. Entweder mit XML-Deklaration den Quirksmode im IE, oder es wird ohne Deklaration nach dem Speichern der Seiten (als *.xhtml) im Browser die Kodierung nicht mehr korrekt erkannt. Bei Auslieferung als application/xhtml+xml tritt das Problem sogar schon direkt beim Aufruf auf.

Auch muss es unter Punkt 7 übrigens (unter Berücksichtigung der Regeln zur Kompatiblität mit HTML) selbst in XHTML immer(!)

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

lauten, da hat Thomas Scholz völlig recht. Siehe auch http://schneegans.de/web/xhtml/#codierung

Auch gilt Punkt 4 natürlich ausschließlich für XHTML, in HTML hat diese Angabe eh nichts verloren. Ich schlage daher vor, den Punkt 4 in der Praxis zu ignorieren. Man schafft sich dadurch lediglich Probleme, löst aber keine.


Geschrieben von
astera (anonym)
-- 24.August 2008 (#64)

Ische nochmal,

hab den Fehler gefunden. Wenn UTF-8, dann aber konsequent, also auch in den Kommentaren. Da hatte ich ä`s und ö`s.

LG
astera


Geschrieben von
DonTermi (anonym)
-- 08.September 2006 (#15)

Danke. Dein Beitrag hat mir sehr geholfen inwieweit Entitäten in (X)HTML noch notwenig sind. Die meisten sagten immer, daß trotzdem noch alles in Entitäten (auch Umlaute) auszudrücken ist. Gut das es doch nicht so ist :)

Werde ich demnächst mal die Seiten auf UTF-8 basteln.


Geschrieben von
Hendrik (anonym)
-- 29.April 2008 (#58)

Ganz kurz zu:

Zitat:"Noch ein Hinweis bezüglich PHP-Sessions:
Man darf alle .php-Dateien, die am Anfang eine Session initialisieren nicht in UTF-8 mittels BOM (Byte Order Mark) speichern, da diese Methode 3 Zeichen vor den eigentlichen Inhalt setzt, welche der Webserver direkt ausliefert und somit keine Header mehr modifiziert werden können. Solche Dateien am besten als "ANSI as UTF-8"/"UTF-8 ohne BOM" speichern und UTF-8 mit "header("Content-Type: text/html; charset=utf-8");" am Anfang ausliefern."

Also übertreiben muss man es ja wohl nicht !


Geschrieben von
Dirk
-- 06.August 2006 (#14)

Danke für die Anregung, aber das habe ich schon lange korrigiert.


Geschrieben von
zazi (anonym)
-- 19.März 2007 (#29)

also, wenn ihr alles beachtet habt und es eventuell immer nicht funktioniert bei ner verbindung mit einer mysql-datenbank - lasst euch einfach mal mit mysql_client_encoding(); das character-set der client-verbindung ausgeben, die läuft std-mäßig auf latin1. wenn das der fall ist, macht einfach wie oben wo schon mal erwähnt ein query mit ’SET NAMES "utf-8";’ an den mysql-server bevor ihr andere queries startet und schon sollte es funktionieren.

!- zazi


Geschrieben von
Tobias (anonym)
-- 04.Januar 2007 (#24)

und für alle, die noch Probleme mit phpMyAdmin bzw. PHP in Verbindung mit MySQL haben hier Punkt 8:
- Zeichensatz / Kollation der MySQL-Verbindung in phpMyAdmin umstellen
- Kollation aller Tabellen auf utf8-general-ci umstellen
- bei jeder MySQL-Verbindung in PHP die query ’SET NAMES "utf8"’ ausführen


Geschrieben von
Manuel (anonym)
-- 22.Januar 2008 (#52)

Hallo,

Noch ein Hinweis bezüglich PHP-Sessions:
Man darf alle .php-Dateien, die am Anfang eine Session initialisieren nicht in UTF-8 mittels BOM (Byte Order Mark) speichern, da diese Methode 3 Zeichen vor den eigentlichen Inhalt setzt, welche der Webserver direkt ausliefert und somit keine Header mehr modifiziert werden können. Solche Dateien am besten als "ANSI as UTF-8"/"UTF-8 ohne BOM" speichern und UTF-8 mit "header("Content-Type: text/html; charset=utf-8");" am Anfang ausliefern.


Geschrieben von
Michael (anonym)
-- 11.Januar 2007 (#25)

Eine Frage zu phpMyAdmin und UTF-8:
Habe jetzt endlich auf MySQL5 umgestellt … mit dem zweifelhaften Erfolg, dass phpMyAdmin meckert, dass die Extension ’mbstring’ nicht installiert ist und das zu Problemen führen kann.
Lokal kann ich das für PHP leicht umstellen. Mein Provider hat mbstring allerdings nicht im Programm, und daran kann ich natürlich erst einmal nichts machen.
Frage daher: Wird mbstring denn noch benötigt, wenn alles wie oben beschrieben eingestellt ist???

Danke für jeden Hinweis
Michael


Geschrieben von
Maximilian Baumgart (anonym)
-- 07.Oktober 2005 (#2)

Prima, mir hat deine Auflistung sehr geholfen, gänzlich auf Unicode umzustellen. Danke vielmals :)!
Max.


Geschrieben von
Basti (anonym)
-- 14.April 2009 (#66)

Danke für die Anleitung.
Auch wenns schon länger her ist, super erklärt :)

lg


Geschrieben von
Gast (anonym)
-- 04.Oktober 2006 (#17)

Der Artikel ist sehr gut gelungen, allerdings verstehe ich nicht, warum man ", &, < und > noch immer codieren soll.


Geschrieben von
Tom (anonym)
-- 29.März 2007 (#35)

Hallo.

Vielen Dank für diese Auflistung. Ich habe lange nach einer solchen Ausarbeitung gesucht.
Dennoch …. ich habe bei der Umsetzung einige Probleme:

System: LAMP (PHP 4.3.9, MySQL 4.1.12)

Folgende Schritte habe ich entsprechend den Hinweisen auf dieser Seite ausgeführt (bzw. es versucht):

1. Im Editor "Homesite" speichere ich die PHP-Datei als UTF8
Problem: Sobald ich die Datei als UTF-8 speichere, werden beim Ausführen einige Zeichen angezeigt, die vor dem header(’content-type: text/html; charset=utf-8’) Befehl interpretiert werden. Damit ist dieser wirkungslos ("Cannot modify header information - headers already sent by …") und das Dokument wird in der iso-8859-1 Codierung ausgeliefert.
Folge: Wirre Zeichen
Speichere ich in ANSI, habe ich kein Problem. Codierung UTF-8, Anzeige der gewünschten chinesischen Zeichen

2. CSS findet in meiner Testumgebung noch keine Anwendung

3. .htaccess anpassen
Funktioniert bei mir nicht. Sobald ich die .htaccess mit "AddCharset utf-8 .css .html .xhtml .php" einstelle, erhalte ich einen "Internal Server Error". Niko hatte zu diesem Thema geschrieben, dass hier vom Provider das DefaultCharset vorgegeben wird und nicht überschrieben werden kann.
Ist dieser Punkt zwingend notwenig oder reicht der php-Header?

4. -

5. UTF-8-Kodierung für PHP-Dateien
Ist getan

6. Bisher keine Formulare

7. Meta-Tag
Ist eingebaut


Weiteres Problem:
Entsprechend des Tipps von Zazi habe ich folgendes probiert:
mysql_client_encoding()
Als Ergebnis bekomme ich latin1, obwohl ich die DB auf utf8 umgestellt habe, die Collations sind alle auf utf8_unicode_ci eingestellt.


Fazit: Solange ich die Dateien in ANSI speichere, klappt die Anzeige der chinesischen Zeichen.
Das Ganze macht mich nur sehr stutzig, da ich nur wenige der in diesem Artikel beschriebenen Schritte befolgen konnte.

Ich weiss, dies ist eine lange Frage, aber ich hoffe Ihr könnt mir helfen.

Danke

Tom


Geschrieben von
Dirk
-- 24.September 2005 (#1)

Ich bin mir nicht sicher, ob das alles vollständig und korrekt ist. Ergänzungen und Berichtigungen also erwünscht.


Geschrieben von
Marc Humer (anonym)
-- 27.Februar 2006 (#11)

Ich danke Dir herzlich für die prägnante Zusammenfassung. Vieles war mir bekannt, einiges nicht aber alles in dieser kompakten Form ist auf jeden Fall ne gute Sache.

Da ich von "Nachwuchs-Programmierern oft nach solchen Sachen gefragt werde, habe ich Diese Seite gleich mal gebookmarkt und gebe sie gerne weiter.

Es muss nicht immer seitenweise abgehandelt werden, was in wenigen Sätzen erklärbar ist.

:) Liebe Grüße, Marc Humer


Geschrieben von
Thomas Scholz (anonym)
-- 17.November 2005 (#4)

Bei XHTML ist das Meta-Element überflüssig: XHTML ist ohne weitere Angaben *immer* UTF-8 oder UTF-16, es sei denn, es wird als HTML versandt (warum auch immer). In diesem Fall braucht man als Content-Type aber auch kein application/xhtml+xml anzugeben, das hilft nichts und stiftet höchstens Verwirrung.
Wichtig: Wenn man in Stylesheets ein BOM verwendet, dann kann man nicht zugleich die @charset-Regel benutzen, denn die muß immer die allererste Zeichenkette im Dokument sein. Es gibt auch Browser, die ein BOM für einen Teil des ersten Selektors halten; da hilft ein

bom { /* catch */ }


am Anfang.
Interessant, daß du gerade Hebräisch erwähnst. Diese Zeichen laufen von rechts nach links; damit hat man sowieso Probleme, wenn man es mit ltr-Text mischt. Eigentlich fangen die Probleme schon damit an, einen Editor zu finden, der das ordentlich hinkriegt(…)


Geschrieben von
Juergen (anonym)
-- 31.Mai 2008 (#59)

Hallo,
danke für die Hinweise bzgl. UTF-8
Bin gerade dabei, mein Projekt komplett von ISO auf UTF-8 zu stellen.
Pain in the ass. Von Apache2, über php.ini bis header, das ganze Programm
Die ganzen schönen workarounds, um die Unzulänglichkeiten von ISO aufzufangen, müssen jetzt wieder entfernt werden.
Der Dom-Bau ist gar nichts dagegen. aber daür bin ich für die Zukunft gerüstet.
Jürgen
PS. Dein Skript braucht ein Strippslashes :-)
PPS. Ausser laeuft es nicht mit Opera :-)


Geschrieben von
Ines (anonym)
-- 27.April 2007 (#45)

Hallo,

Das Attribut accept-charset im Formtag scheint Case-sensitive zu sein,
ist zumindest bei der Angabe

accept-charset="ISO-8859-1"

der Fall. Bei klein geschriebenem "iso" wird die Anweisung ignoriert.
(ich weiß, auf dieser Seite geht es um die Umsetzung von UTF 8. Aber ich bin hier gelandet, weil ich unerwünschte utf8-Codierungen vermeiden wollte. Könnte ja auch anderen so gehen). Gute Seite!

Viele Grüße


Geschrieben von
Torwart (anonym)
-- 10.Juni 2009 (#67)

@Peter: Du musst bei Mailversenden auch noch die Richtige Codierung angeben!
(http://ch.php.net/manual/de/function.mail.php#91058)

@gast (der, der frafte, wieso man <, >, &, " immernoch nicht direkt schreiben darf):
Da diese Zeichen direkte Bedeutung im (X)HTML-Quellcode haben!

Das Problem mit der DB _kann_ man anstatt mit dem genannten SQL-String auch mit der PHP-Funktion "mysql_set_charset()" lösen (http://ch.php.net/manual/de/function.mysql-set-charset.php).


Geschrieben von
nane (anonym)
-- 07.Mai 2007 (#46)

Kann man denn auch ein n Accent acute &#324; anzeigen? Leide rhabe ich niergends eine HTML-Zeichenreferenz für dieses n gefunden!
gruß nane


Geschrieben von
Tim (anonym)
-- 27.Oktober 2006 (#19)

Gute Erklärung, vielen Dank. Aber warum beginnt die Seite selbst mit der Zeile

<?xml version="1.0" encoding="iso-8859-1"?>

?


Geschrieben von
Dirk
-- 07.Februar 2006 (#10)

Ähm ja, danke. Das ergibt mit utf-8 natürlich mehr Sinn.


Geschrieben von
rob (anonym)
-- 12.September 2006 (#16)

Jawoll!
Das hab ich gesucht - die erste Seite die die Umstellung auf UTF-8 komplett erklärt! Vielen Dank!!!

Ohne deinen Beitrag würde ich wohl morgen noch an der Umstellung sitzen :)


Geschrieben von
astera (anonym)
-- 24.August 2008 (#63)

Hallo,

sehr schöner und informativer Beitrag. Habe meine HP auf UTF-8 ungestellt und spitze im FF und IE7. Bis ich mir die Seite im IE6 angeschaut habe. Da zerschiesst er mir doch tatsächlich das Layout und ich habe keinen blassen Schimmer wieso. Könntest du mir das vielleicht erklären?
Habe im Header mit einer If-Abfrage das charset ändern wollen aber funzt auch nicht.
Wenn ich mir die Seite im IE mit Ansicht --> Codierung: Windows ISO anschaue ist alles OK, mit UTF-8 (was ich im Header und über die css voreingestellt habe) nicht.
www.hundeschule-teamwork.de

Lieben Dank
astera


↑↑





Zeige Formatierungsmöglichkeiten an

Menü
Beitragsübersicht
Kontakt & Impressum
Über mich
Linkempfehlungen/Linkpartner

Letzte Kommentare
»UTF-8 und die Entity…
»Validierung, wozu? Waru…
»Backlinks gegen Content…
»Gute Weiterleitung, bös…
»Essay zu Quizsendungen/…

Meta
RSS 2.0
XHTML-Validierung
CSS-Validierung

Backlinks
»Spam vermeiden
»Internetagentur Ulm
»Bruststraffung
»Achterbahn & Freizeitpark
»Fernstudium
»TuS Graf Kobbo Tecklenburg