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

DOCTYPE bei include header

B

bigfailor

Neues Mitglied
Hallo,

in meiner Homepage benutze ich folgende Doctype anweisung:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

HTML reagiert dabei ja besonders empfindlich auf direkt geschriebene Umlaute und will diese durch Zeichencode ersetzt haben.

nun habe ich der Einfachheit halber den gesamten header in eine extra Datei gepackt und per PHP included. Nun ist mir aufgefallen, dass das oben beschriebene Umlautproblem einfach verschwunden ist. Was ist da passiert? Es funktioniert alles, aber wird die Anweisung jetzt nicht mehr interpretiert? Welche folgen hat das ganze?

Muss ich in der Index.php wo der header included wird ebenfalls einen eigenen header mit der Doctype Anweisung einbauen?
 
bigfailor schrieb:
HTML reagiert dabei ja besonders empfindlich auf direkt geschriebene Umlaute und will diese durch Zeichencode ersetzt haben.
Zum Vergrößern anklicken....
HTML reagiert eher empfindlich auf den Charcode. Das Problem sollte bei UTF-8 kein Thema sein.

bigfailor schrieb:
Nun ist mir aufgefallen, dass das oben beschriebene Umlautproblem einfach verschwunden ist. Was ist da passiert?
Zum Vergrößern anklicken....
Wenn die Datei in UTF-8 angelegt wurde, wurde vll. zwischenzeitlich der Browser-Cache gelöscht.

bigfailor schrieb:
Es funktioniert alles, aber wird die Anweisung jetzt nicht mehr interpretiert?
Zum Vergrößern anklicken....
Sorry, versteh ich nicht, welche Anweisung ?

bigfailor schrieb:
Muss ich in der Index.php wo der header included wird ebenfalls einen eigenen header mit der Doctype Anweisung einbauen?
Zum Vergrößern anklicken....
Die PHP-Datei, in welche includiert wird, bekommt den Header, Dateien welche includiert werden, nicht.
 
Sorry, versteh ich nicht, welche Anweisung ?
Zum Vergrößern anklicken....
ich meine damit dass er sich strict verhalten soll. also im jetzigen zustand kann ich ruhig die normalen umlaute benutzen wie ä ö ü usw. und brauche keine &uml; etc.

so wie ich dich verstehe, hat die index.php nun also keinen html header. habe mir das ganze allerdings beim wordpress default theme angeschaut, da sieht das genau so aus, wie ich das gemacht habe. normal braucht man aber doch den header oder nicht?

was könnte passieren wenn jetzt kein header vorhanden ist? sämtliche sachen die in dem ausgelagerten header gefiniert wurden wie stylesheets etc werden ja übernommen. nur die doctype anweisung halt nicht mehr.


EDIT: Habe gerade einen Test gemacht und die excludierung des headers rückgängig gemacht. die umlautsache bleibt wie oben beschrieben. also scheint es da kein problem mehr zu geben. seltsam ist das ganze trotzdem. es muss ja online funktionieren. offline habe ich heute die neueste version des xampp installiert. könnte es was damit zu tun haben?

EDIT 2: Ok, ohne Apache werden die umlaute auch richtig erkannt. das war vorher nicht der fall. habe auch ansi und utf-8 ausprobiert. immer das gleiche spiel. jetzt bin ich überfragt wieso vorher immer diese kryptischen symbole kamen und jetzt auf einmal nicht mehr. btw: in welcher codierung sollte man standartmäßig fürs inet speichern? oder ist das egal?
 
Zuletzt bearbeitet:
bigfailor schrieb:
so wie ich dich verstehe, hat die index.php nun also keinen html header. habe mir das ganze allerdings beim wordpress default theme angeschaut, da sieht das genau so aus, wie ich das gemacht habe. normal braucht man aber doch den header oder nicht?
Zum Vergrößern anklicken....
Die index.php wird vermutlich die Datei sein, in welche includiert wird. Diese Datei hat einen Header, alle anderen nicht.

bigfailor schrieb:
ohne Apache werden die umlaute auch richtig erkannt. das war vorher nicht der fall. habe auch ansi und utf-8 ausprobiert. immer das gleiche spiel. jetzt bin ich überfragt wieso vorher immer diese kryptischen symbole kamen und jetzt auf einmal nicht mehr. btw: in welcher codierung sollte man standartmäßig fürs inet speichern? oder ist das egal?
Zum Vergrößern anklicken....
Wenn es lokal funzt und online nicht, könnte es imho tatsächlich am Server liegen. Die Frage ist, wie der Server die Seite weitergibt (Konfirguration). Hier im Forum wurde vor kurzem eine Seite zum Testen des Charsets präsentiert, nur leider weiss nicht nicht mehr, wie das Ding heisst.
 
- W3C I18n Checker

Habe den Link auch beim passenden Wiki-Eintrag hinzugefügt, falls ihn mal jemand sucht.

- Internationalisierung

Die dort angeführten Kriterien unter „Information → Character encoding“ sind von oben nach unten gewichtet. Sobald das erste Kriterium gesetzt ist, legt es das Encoding fest.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben