Habe (neuerdings?) ein merkwürdiges Verhalten von Safari festgestellt:

Eine Seite mit einem Frame in der Mitte stellt im äußeren Frame Umlaute korrekt dar.. Im eingebetteten Frame sind die Umlaute allerdings "zerschossen" (s. Bild).

Öffne ich den inneren Frame als neuen Tab (oder Fenster), ist dort wieder alles korrekt.

Zeichenkodierung ist "Standard". Umstellung auf "Mitteleuropäisch (ISO Latin 4" bewirkt, dass IM Frame die Umlaute wieder stimmen, im äußeren Rahmen allerdings nicht mehr, kann daran nicht liegen.

Camino hat das Problem nicht.

Weiß jemand Rat?

bernddasbrot
Was verstehst du denn unter "Standard"? Entweder sind die Zeichen nicht richtig kodiert, oder es ist eine falsche Zeichenkodierung definiert worden.

Mit "Standard" meinte ich hier die Safari-(Standard-)Einstellung für die Textkodierung (s. Bild). Das eigenartige ist ja, dass der Frame, wenn man ihn in einem eigenen Tab/Fenster öffnet, korrekt dargestellt wird... Die Kodierung halte ich nicht an sich für das Problem.

u.U. liegt das auch an den HTTP-Headern der einzelnen Frame-Contents.
Wie ist denn die URL des Framesets? (der Seite mit den Frames?)

dergl
Ist eine Intranet-Seite, kann daher keine URL angeben.

Wenn ich den Quelltext anzeigen lasse, bekomme ich (im inneren Frame) auch ein Sonderzeichen bei Umlauten, öffne ich die gleiche Seite ohne den äußeren Frame, wird im Quelltext der Umlaut angezeigt ...

bernddasbrot
Genau da ist das Problem. Am besten konvertiert man Sonderzeichen in ihre HTML-Entsprechungen.
z.B. ü ü

lass Dir mal den Quelltext der Frame-Seite anzeigen.
Da siehst Du ja die einzelnen Frame-Content-URLs.

Nimm jeweils eine vom Rand (in der die Umlaute stimmen) und die der mittigen (mit den falschen Umlauten) in die Zwischenablage, mach das Terminal auf und gib folgendes ein

curl -i
curl -i

sieht dann etwa folgendermaßen aus:

ate: Fri, 23 Jun 2006 10:45:43 GMT
Server: Apache
X-Powered-By: PHP/4.3.10-16
Set-Cookie: fe_typo_user=b8f23beed7; path=/
Transfer-Encoding: chunked
Content-Type: text/html;charset=iso-8859-1

... ab hier beginnt dann html..



alles was in der Ausgabe dann vor der ersten Leerzeile kommt sind die HTTP-Header. Der der uns interessiert ist Content-Type.
Ich tippe mal drauf, dass der Content-Type des mittigen Frames sich von dem der Randframes unterscheidet.

Uups. Für die Links natürlich deine beiden URLs (die der Frames) einsetzen.

dergl
Danke für die Tipps!!

Habe allerdings das Problem, dass die Seite über ein eigenes Login verfügt, welches ich über das Terminal nicht eingeben kann (bekomme nur die Meldung, dass ich nicht berechtigt sei etc.

Die Suche im Quelltext nacht content-type ergibt nichts - könnte das auch im css stecken?

nein, das steht im HTTP-Header, der wird nirgends angezeigt.
gib in der Konsole mal

man curl

ein. Da stehen noch weitere Optionen, mit denen Du dich auch authentifizieren kannst.
Alternativ: Für Firefox gibt es auch Plugins, die dir die Header zu jedem Abruf einer Seite anzeigen.

Ok, vielen Dank für die vielen Tipps! Mit dem Authentifizieren muss ich aber im Terminal noch ein bisschen herumprobieren, habe ich nicht so schnell hinbekommen. Bleibe aber dran ...

Ok, habe mal folgendes aus der Fehlermeldung (Authentifizierung) herausgenommen, hilft aber noch nicht richtig weiter:

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=windows-1252">

Zwei Fragen machen mich trotzdem stutzig:

1 Warum erscheint dieser Darstellungsfehler nur im inneren Frame?
2 Warum haben weder Camino, iCab noch der IE das Problem? Shiira und Opera aber schon?

Scheint mir ein doch Problem mit dem aktuellen WebKit zu sein - habe gerade einmal ein "Nightly Build" ausprobiert (Version 2.0.3 (417.9.3)) - da ist es korrekt ...