Moin!

in HTML stellt man ja die deutschen Umlaute wie im Titel beschrieben dar. Wenn ich jetzt aber das \"ä\" ganz normal rein nehme, dann wird es auch sauber angezeigt. Von was ist das denn jetzt abhängig, ob man die Umlaute auflösen muss? Vom Client oder vom Server?
Ich habe jetzt nämlich tschechische und andere Sonderzeichen und wenn ich mir ersparen kann, die aufzulösen, dann würde ich das lassen. Bei mir jedenfalls werden sie sauber angezeigt. Ist das dann überall so?

Greetz
Mike

> Moin!
>
> in HTML stellt man ja die deutschen Umlaute wie im Titel beschrieben dar.
> Wenn ich jetzt aber das \"ä\" ganz normal rein nehme, dann wird es auch
> sauber angezeigt. Von was ist das denn jetzt abhängig, ob man die Umlaute
> auflösen muss? Vom Client oder vom Server?
> Ich habe jetzt nämlich tschechische und andere Sonderzeichen und wenn ich
> mir ersparen kann, die aufzulösen, dann würde ich das lassen. Bei mir
> jedenfalls werden sie sauber angezeigt. Ist das dann überall so?
>
> Greetz
> Mike

Ich würde grundsätzlich immer mit den ¨-Dingern arbeiten. Das mit dem Umlaut-einfach-hinschreiben funktioniert AFAIK nur so lange, wie der PC des Betrachters mit dem verwendeten Zeichensatz was anfangen kann. Es ist auf jeden Fall die \"sauberere\" Methode.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Das mit dem
> Umlaut-einfach-hinschreiben funktioniert AFAIK nur so lange, wie der PC des
> Betrachters mit dem verwendeten Zeichensatz was anfangen kann.

Wenn die Seiten als UTF-8 gespeichert sind und der Server das auch so ausgibt, sollte es keine Probleme geben. Selbst mit ISO 8859-1 fängt man schon eine ganze Masse Zeichen ab.

Ich verwende die HTML-Entities schon seit Jahren nicht mehr. Und ist beim Forum schon mal aufgefallen, dass die Umlaute nicht korrekt angezeigt werden?

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> Ich verwende die HTML-Entities schon seit Jahren nicht mehr. Und ist beim
> Forum schon mal aufgefallen, dass die Umlaute nicht korrekt angezeigt
> werden?

Naja, schreibt hier im Forum irgendwer auf tschechisch? 

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Naja, schreibt hier im Forum irgendwer auf tschechisch? 

Interessanter sind da einige slowenische Sonderzeichen. Die tschechischen sind harmlos, und in jedem Unicode Zeichensatz eigentlich enthalten.

--
mein privates Hobby. www.ffzell.at

> > Naja, schreibt hier im Forum irgendwer auf tschechisch? 
>
> Interessanter sind da einige slowenische Sonderzeichen. Die tschechischen
> sind harmlos, und in jedem Unicode Zeichensatz eigentlich enthalten.

Ok, da kenn ich mich nicht so aus. Aber das meinte ich eben, so lange man sich im selben Sprachraum befindet, kein Problem. Wenn ich das jetzt auf ner Website mache, die sich Leute aus der ganzen Welt anschauen, dann kanns brenzlig werden.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Ok, da kenn ich mich nicht so aus. Aber das meinte ich eben, so lange man
> sich im selben Sprachraum befindet, kein Problem. Wenn ich das jetzt auf
> ner Website mache, die sich Leute aus der ganzen Welt anschauen, dann kanns
> brenzlig werden.

Deswegen ja UTF-8, womit sich diese Probleme erledigt haben sollten. Wenn jetzt ein User seinen Browser manuell konfiguriert, kann man natürlich nichts machen.

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> Naja, schreibt hier im Forum irgendwer auf tschechisch? 

Ja. Wenn ich zum Beispiel tschechische Ortsnamen nenne, verwende ich auch die tschechische Schreibweise.

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> > Ok, da kenn ich mich nicht so aus. Aber das meinte ich eben, so lange
> man
> > sich im selben Sprachraum befindet, kein Problem. Wenn ich das jetzt
> auf
> > ner Website mache, die sich Leute aus der ganzen Welt anschauen, dann
> kanns
> > brenzlig werden.
>
> Deswegen ja UTF-8, womit sich diese Probleme erledigt haben sollten. Wenn
> jetzt ein User seinen Browser manuell konfiguriert, kann man natürlich
> nichts machen.

Nun ja. Im Prinzip spielen da aber mehrer Faktoren mit.
Wenn eien Seite mittels PHP entsteht, kannst Du im MEtatag 17x den Cahrset als UTF8 auszeichnen, wenn der Server das Dokument so nicht ausliefert.

--
mein privates Hobby. www.ffzell.at

> > > Ok, da kenn ich mich nicht so aus. Aber das meinte ich eben, so lange
> > man
> > > sich im selben Sprachraum befindet, kein Problem. Wenn ich das jetzt
> > auf
> > > ner Website mache, die sich Leute aus der ganzen Welt anschauen, dann
> > kanns
> > > brenzlig werden.
> >
> > Deswegen ja UTF-8, womit sich diese Probleme erledigt haben sollten.
> Wenn
> > jetzt ein User seinen Browser manuell konfiguriert, kann man natürlich
> > nichts machen.
>
> Nun ja. Im Prinzip spielen da aber mehrer Faktoren mit.
> Wenn eien Seite mittels PHP entsteht, kannst Du im MEtatag 17x den Cahrset
> als UTF8 auszeichnen, wenn der Server das Dokument so nicht ausliefert.

Das stimmt. Es muss schon alles zusammenpassen. Dann aber geht es wunderbar, auch ohne HTML-Entities.

--
„Tu es oder tu es nicht! Es gibt kein Versuchen.“
(Jedi-Meister Yoda)

> Deswegen ja UTF-8, womit sich diese Probleme erledigt haben sollten. Wenn
> jetzt ein User seinen Browser manuell konfiguriert, kann man natürlich
> nichts machen.

Ich weiß jetzt nicht, ob das was miteinander zu tun hat, aber wenn ich Thunderbird so einstelle, daß er mir empfangene Mails auf UTF8 anzeigt, dann kommt oft ziemliecher Müll dabei raus.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Ich verwende die HTML-Entities schon seit Jahren nicht mehr. Und ist beim
> Forum schon mal aufgefallen, dass die Umlaute nicht korrekt angezeigt
> werden?

Werden die Umlaute bei MLF nicht gecastet?  

--
Gruß,

ff

Möge TUX mit dir sein!

> Nun ja. Im Prinzip spielen da aber mehrer Faktoren mit.
> Wenn eien Seite mittels PHP entsteht, kannst Du im MEtatag 17x den Cahrset
> als UTF8 auszeichnen, wenn der Server das Dokument so nicht ausliefert.

Das stimmt natürlich. Deswegen gebe ich im Zweifelsfall auch den Header mit:

header(\'Content-Type: text/html; charset=utf-8\');

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> Ich weiß jetzt nicht, ob das was miteinander zu tun hat, aber wenn ich
> Thunderbird so einstelle, daß er mir empfangene Mails auf UTF8 anzeigt,
> dann kommt oft ziemliecher Müll dabei raus.

Ja, wenn die nicht als UTF-8 gesendet wurden, ist das klar. Wird das im TB nicht automatisch erkannt?

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> Ja, wenn die nicht als UTF-8 gesendet wurden, ist das klar. Wird das im TB
> nicht automatisch erkannt?

Normal schon, aber manchmal eben nicht. Ist mir allerdings in letzter Zeit nicht mehr untergekommen, vielleicht haben die Mozilla-Leute da was geschraubt.

--
Grüße aus Strasshof an der Nordbahn (ja, da wo die Natascha im Keller lebte)
bender

sudo apt-get install brain_2.0

> Werden die Umlaute bei MLF nicht gecastet?  

Was die Originalsoftware macht, weiß ich leider nicht. Dazu könnte sich MudGuard äußern.

Hier wurde schon so viel verändert …

Ich habe jetzt auch nicht das gesamte Script im Kopf - es kann schon sein, dass htmlentities zumindest bei der DB eingesetzt wird. Wenn ich jedoch irgendwelche Klartexte eingebe (Beschreibungen, Hinweise, Legenden, usw.), tippe ich die ohne Umwandlung ein.

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> Normal schon, aber manchmal eben nicht. Ist mir allerdings in letzter Zeit
> nicht mehr untergekommen, vielleicht haben die Mozilla-Leute da was
> geschraubt.

Dass mal etwas schiefgehen kann, ist schon möglich. Grob gesagt spielen da vier Sachen eine Rolle, die die Kodierung beachten müssen:

- Eingabe
- alle Verarbeitungen auf dem Server (Scripte, DB, usw.)
- Ausgabe durch den Server
- Übergabe an den Browser

Wenn in der Kette irgendwo irgendwas nicht stimmt, gibt es schon mal Probleme bei der Anzeige. Ärgerlich ist, wenn man eine umfangreiche Seite als UTF-8 speichert und später aus Versehen in irgendeinem ISO. Da kann ich ein Lied von singen …

--
Viele Grüße

Jörg


VBA-Beispiele | Meine Fotosammlung | www.joerglorenz.de | Mail: nt@joerglorenz.de

> in HTML stellt man ja die deutschen Umlaute wie im Titel beschrieben dar.

Das macht man eigentlich nur dann, wenn die verwendete Codierung die gewünschten Zeichen nicht direkt erlaubt.

Welche Codierung verwendest Du denn?

UTF-xx? ISO-8859-1, ISO-8859-15?
Die enthalten alle die deutschen Umlaute direkt, also gibt es keinen Grund, die Entities dafür zu verwenden.

> Ich habe jetzt nämlich tschechische und andere Sonderzeichen und wenn ich
> mir ersparen kann, die aufzulösen, dann würde ich das lassen.

Hängt davon ab, ob die verwendete Codierung die Zeichen enthält.
Wenn nicht, gibt es 2 Möglichkeiten:
1. zu bevorzugen: auf eine Codierung umstellen, die alle benötigten Zeichen enthält (ggf. UTF-xx)
2. die Zeichen durch Entities (soweit vorhanden) oder numerical character references zu ersetzen (was die Quelltexte schwer lesbar macht)

--

MudGuard
O-o-ostern

> Interessanter sind da einige slowenische Sonderzeichen. Die tschechischen
> sind harmlos, und in jedem Unicode Zeichensatz eigentlich enthalten.

Im Unicode-Zeichensatz (es gibt nur einen) sind alle Zeichen enthalten.

--

MudGuard
O-o-ostern

> > Ja, wenn die nicht als UTF-8 gesendet wurden, ist das klar. Wird das im
> TB
> > nicht automatisch erkannt?
>
> Normal schon, aber manchmal eben nicht. Ist mir allerdings in letzter Zeit
> nicht mehr untergekommen, vielleicht haben die Mozilla-Leute da was
> geschraubt.

Wahrscheinlicher ist, daß die Absender entsprechender Mails ihre Mail-Clients repariert haben und jetzt die richtige Encoding-Angabe verwenden.

--

MudGuard
O-o-ostern

> Wenn eien Seite mittels PHP entsteht,

wie die Seite entsteht, ist irrelevant

> kannst Du im MEtatag 17x den Cahrset
> als UTF8 auszeichnen, wenn der Server das Dokument so nicht ausliefert.

Das meta-Element kommt aber nur dann zum Zug, wenn der Webserver keinen content-type-Header angibt.

--

MudGuard
O-o-ostern

Hallo,

> Wenn ich jetzt aber das \"ä\" ganz normal rein nehme, dann wird es auch
> sauber angezeigt. Von was ist das denn jetzt abhängig, ob man die Umlaute
> auflösen muss? Vom Client oder vom Server?

grundsätzlich ist der vom Client zur Anzeige zu verwendende Zeichensatz im Kopfbereich des Seitenquelltextes anzugeben.
Vorzugsweise UTF8 (-general-ci wenn MySQL DB im Einsatz), in ISO-8859-1 ist nämlich z.B. gar kein Euro-Zeichen drin, auch wenn das viele (Windows-User) meinen.

> Ich habe jetzt nämlich tschechische und andere Sonderzeichen und wenn ich
> mir ersparen kann, die aufzulösen, dann würde ich das lassen. Bei mir
> jedenfalls werden sie sauber angezeigt. Ist das dann überall so?

Zusätzlich ist noch die Frage: Woher kommen die Inhalte? Aus einer Datenbank? Ist diese durchsuchbar, wenn ja wie?
Wenn Du in der DB nämlich Deine Inhalte mit entities (&...;) speicherst, wirst Du bei einer Suchroutine u.U. vor die Wand fahren, wenn sie Umlaute und Sonderzeichen enthält und Du dies nicht bei der Suchroutine berücksichtigst.

Gruß,
Johann

> grundsätzlich ist der vom Client zur Anzeige zu verwendende Zeichensatz im
> Kopfbereich des Seitenquelltextes anzugeben.

Nein.

Der Zeichensatz von HTML ist IMMER ISO10646 (= Unicode).
Die Zeichencodierung muß dagegen keine der Unicode-Variante (UTF-x) sein.

Zeichensatz (die Menge der Zeichen, die benutzt werden können) und Zeichencodierung (welche/wieviele Bits werden für das Zeichen verwendet) müssen getrennt voneinander betrachtet werden!

(dummerweise heißt das Teil im Content-Type-Header charset statt korrekt encoding - aber dieser Fehler ist genauso hartnäckig wie der referer mit einem r zu wenig)

--

MudGuard
O-o-ostern