[CIX88]

benutztes Templatesystem:
[PHP] Ein eigenes Templatesystem schreiben

Jetzt hab ich damit einige Probleme bezüglich UTF-8.
Wenn ich in den Sprachdateien Umlaute benutze, kommt nur noch mist raus.
Als mal versucht, die Sprachdateien als UTF-8 Datei abzuspeichern - erfolglos.
Alles andere geht wunderbar, aber Texte aus diesen Sprachdateien nicht.

Hatte jemand mal ähnliche Probleme?

[MrNiceGuy]

In meiner Template-Engine nutze ich auch Sprachdateien und schreibe die Umlaute direkt dort hinein. Beim Parsen des Templates wird dann mittels html_entities alles entsprechend in HTML-Code umgewandelt - Funktioniert wunderbar. Ich weiß jetzt allerdings nicht genau, wie die obig beschriebene Template-Engine diesbezüglich arbeitet, aber ich glaube nicht, dass UTF-8 die Lösung ist oder willst du die Umlaute im Klartext an den Browser übermitteln?

[robo47]

Also:
template-Dateien sind als UTF-8 gespeichert mit Umlauten drin ?

Du sendest einen passendes Content-Type-Header mit Charset ?

Und hast auch mal noch

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

im HTML drin ?

fehlt vielleicht einer dieser Punkte ?

[MrNiceGuy]

Sind HTML-Dateien nicht trotzdem invalid, wenn der Charset auf UTF-8 gestellt wird und die Umlaute im Klartext drinstehen? Oder ist der HTML-Standard so gut, dass er das unterscheidet? Würde mich mal interessieren!? Denn UTF-8 braucht man ja nicht, wenn man die Umlaute in HTML-Codes umwandelt!?

[robo47]

Zitat von MrNiceGuy

Sind HTML-Dateien nicht trotzdem invalid, wenn der Charset auf UTF-8 gestellt wird und die Umlaute im Klartext drinstehen? Oder ist der HTML-Standard so gut, dass er das unterscheidet? Würde mich mal interessieren!? Denn UTF-8 braucht man ja nicht, wenn man die Umlaute in HTML-Codes umwandelt!?

Gerade das ist doch der Vorteil bei UTF-8, dass man eben nicht jeden Umlaut oder sonstwas in irgendwelche HTML-Codes umwandeln muss (bis auf neuere Zeichen wie beispielsweise das €-Zeichen).

Nur btw. in ISO 8859-1 musst du die deutschen Umlaute (äöü und das ß ) auch nicht umwandeln!

[MrNiceGuy]

Dass es der Vorteil der Codierung ansich ist, ist mir irgendwie schon klar, was ich mich halt frage ist, ob der Validator des W3C dies berücksichtigt bzw. der Standard HTML ansich und somit auch alle Browser oder ob das auch nur "auf gut Glück" funktioniert!? Habe mich damit noch nicht so wahnsinnig auseinandergesetzt bisher

[Hobbyuser]

Zitat von robo47

Und hast auch mal noch

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

im HTML drin ?

Dieser Punkt ist völlig egal, weil...

... das nicht HTML ist sondern XHTML, zu erkennen an dem Slash (Endtag).
... bei XHTML der META-Tag für die Zeichenkodierung eigentlich unwichtig ist.

Ich vermute, das PHP eine Umwandlung beim speichern vornimmt.

@MrNiceGuy
Bei XHTML ist UTF-8 sogar der Standardzeichensatz und es könnte ganz auf die Angabe der Codierung verzichtet werden.


Gruß
Hobbyuser

[robo47]

Zitat von Hobbyuser

Dieser Punkt ist völlig egal, weil...

... das nicht HTML ist sondern XHTML, zu erkennen an dem Slash (Endtag).

Ist aber gleichzeitig auch valides HTML.

... bei XHTML der META-Tag für die Zeichenkodierung eigentlich unwichtig ist.

Wenn der Webserver falsch konfiguriert ist / das Script kein Charset beim Content-Type-Header mitschickt, gibt es in manchen Browsern ein Fallback, das zuerst auf den via meta übergebenen Content-Type/Charset-Wert überprüft, falls vorhanden den nutzt und dann das Browser-interne [eingestellte] Standard-Charset nutzt. Ausserdem selbst wenn man XHTML nutzt, in den wenigstens fällen schickt man es wirklich als xhtml an den client und der nutzt dann eh den normalen HTML-Parser anstatt nem XML-Parser, weil der wird ja nur benutzt wenn ein application/xhtml+xml oder anderer XML-Header kommt.

Zitat von Hobbyuser

Ich vermute, das PHP eine Umwandlung beim speichern vornimmt.

PHP 4 und 5 unterscheiden keine Kodierungen, es sieht nur Bytes, was auch bei den ganzen Standardfunktionen so zu sehen ist, z.b. strlen liefert z.b. bei Zeichenketten mit UTF-8-Zeichen die mehr als Byte lang sind dementsprechend auch eine höhere Länge zurück. (Wer mit UTF-8 oder anderen Kodierungen die Zeichen mit mehr als einem Byte für einzelne Zeichen nutzen sollten daher die mb_*-Funktionen nutzen.)

Daher ist es eher unwahrscheinlich, dass eine der Standard-PHP-Funktionen eine Umwandlung vornimmt.

[CIX88]

Also ich habe jetzt in den Sprachdateien (als Notlösung) immer utf8_encode() vor die Zeilen gesetzt. Das war bisher die einzigste Lösung. Alles andere geht auch wunderbar, nur eben die Sprachdateien wollten keine UTF-8-Ausgabe machen.

[robo47]

also mal angenommen du hast Sprachdateien die wirklich schon utf8 sind und jagst da utf8_encode drüber, dann muss eigentlich logischer weise dein System irgendwo wieder utf8_decode [oder etwas gleichwertiges] aufrufen sonst würdest du auch wieder Mist ausgegeben bekommen, arbeitest du noch mit irgendeiner anderen extension oder so ? z.b. tidy um den html-code zu formatieren / validieren / etc ?

[CIX88]

die wirklich schon utf8 sind

Ja wenn das so wäre, müsste ich nicht diesen Umweg gehen.

Natürlich hatte ich auch versucht, diese Dateien als UTF-8 zu speichern. Aber dann hatte ich massenweise Header-Fehler, weil das System vor Header-Anweisungen (Session etc..) irgendwelche nichtsichtbaren Zeichen ausgegeben hat. Umlaute und andere Zeichen gingen aber dennoch nicht.

Vielleicht hängt es mit der Art und Weise zusammen, wie die Sprachdateien geparst werden - keine Ahnung, jedenfalls bin ich heute echt ins grübeln gekommen.

[robo47]

Zitat von CIX88

Ja wenn das so wäre, müsste ich nicht diesen Umweg gehen.

Natürlich hatte ich auch versucht, diese Dateien als UTF-8 zu speichern. Aber dann hatte ich massenweise Header-Fehler, weil das System vor Header-Anweisungen (Session etc..) irgendwelche nichtsichtbaren Zeichen ausgegeben hat. Umlaute und andere Zeichen gingen aber dennoch nicht.

Vielleicht hängt es mit der Art und Weise zusammen, wie die Sprachdateien geparst werden - keine Ahnung, jedenfalls bin ich heute echt ins grübeln gekommen.

Dann ist dein Problem ganz einfach
Dein Problem nennt sich BOM ! ( http://de.wikipedia.org/wiki/Byte_Order_Mark )

Dein Editor schreibt an den Anfang JEDER UTF-8-Datei ein spezielles Zeichen, das sie quasi als UTF-8 outet. Jetzt musst du nur noch in deinem Editor finden wo man das umstellen kann, dass das Eben nicht geschrieben wird oder einen anderen Editor zum konvertieren nutzen. Das Teil ist nämlich nicht wirklich nötig in deinem Fall.

siehe auch dieser Thread:
Was ist das denn?
oder hier:
http://www.phpfriend.de/forum/ftopic63630.html

[CIX88]

Jo das ist mir dann beim Online-Editieren der Templates aufgefallen, dass überall ein ? am Anfang steht. Naja jetzt hab ich Wochenende, und werde mir das Montag wieder angucken
Aber danke für den Hinweis!

EDIT:

Ähmm Moment mal, aber die Zeichen am Anfang haben vorher nicht gestört, erst im zusammenhang mit der Sprachdatei.
Die Templates hatte alle so ein Zeichen am Anfang, komisch dass ich da keine Probleme hatte. Achhhh neeee, ich mach jetzt Wochenende ...

[robo47]

Zitat von CIX88

Jo das ist mir dann beim Online-Editieren der Templates aufgefallen, dass überall ein ? am Anfang steht. Naja jetzt hab ich Wochenende, und werde mir das Montag wieder angucken
Aber danke für den Hinweis!

EDIT:

Ähmm Moment mal, aber die Zeichen am Anfang haben vorher nicht gestört, erst im zusammenhang mit der Sprachdatei.
Die Templates hatte alle so ein Zeichen am Anfang, komisch dass ich da keine Probleme hatte. Achhhh neeee, ich mach jetzt Wochenende ...

Die Sprachdateien includierst du ja -> wahrscheinlich ohne irgendwo mit ob_start zu arbeiten oder ähnliches
und die Templates wirst du wohl mit fopen / file_get_contents oder sowas laden

Deshalb tritt das Problem nur beim includieren auf, dass PHP dann Probleme macht, bei der Ausgabe fallen sie nicht unbedingt auf.

[Hobbyuser]

Zitat von robo47

Ist aber gleichzeitig auch valides HTML.

Sorry, aber da irrst du!

Zitat von SelfHTML

In HTML 4.0 gibt es diverse leere Elemente. Das sind Elemente ohne Inhalt. Das Abschluss-Tag ist deshalb verboten, weil die Elemente als inhaltsleer definiert sind.
Quelle

Jedenfalls kann ich da nichts von optional oder zulässig lesen.


Die Zeichenkodierung wird bei XHTML über die XML-Deklaration übermittelt (siehe SelfHTML). Das ist der korrekte Weg. Wobei wie gesagt UTF-8 die Standardkodierung ist und gar nicht angegeben werden müsste.
Nachzulesen im gleichen Abschnitt von SelfHTML unter "Beachten Sie:".

[CIX88]

Ähmmm, XHTML, valides HTML ... Content-Type, war eigentlich nicht Gegenstand meiner Frage.

@robo47
Jo hatte mittels include() und ob_start() probiert, ging aber auch nicht so wirklich.

[Basti]

OT:

Zitat von Hobbyuser

Sorry, aber da irrst du!

Jedenfalls kann ich da nichts von optional oder zulässig lesen.

Ich bin mir sicher, dass diese Notation (z.B. <br/>) in HTML erlaubt ist, kanns aber nicht belegen bzw. nicht wirklich nachvollziehen, was da wie in SGML definiert ist (mit und ohne Web SGML Adaptations Annex, mit oder ohne Technical Corrigendum 2). Das übersteigt mein Interesse. Aber SelfHTML ist da sicherlich keine Referenz.

Basti

[robo47]

Zitat von Basti

OT: