[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HTML, firefox, utf8, und Umlaute



On 23.02.06 23:35:57, Norbert Preining wrote:
> On Don, 23 Feb 2006, Andreas Pakulat wrote:
> > Ach und kannst du das mal den LaTeX Leuten beibringen? Da muss man
> > naemlich auch "a nutzen, statt ä.
> 
> Also ich kann mich nicht mehr erinnern, wann ich das letzte Mal "a

Was mir im anderen Teilthread nicht einfiel: ca. 20%-30% meiner
Studienarbeit hab ich mit amerik. Tastatur geschrieben, da hab ich dann
lieber gleich "a ueberall genutzt. Ausserdem hatte ich anfangs Probleme
mit "normalen" Umlauten und dem Copy&Paste aus'm PDF. Das ergebnis
war dann immer:

"
a

fuer ein ae.

> Ja, wie die anderen schon geschrieben haben, fast gut, besser heute für
> uns:
> 
> \usepackage[latin9]{inputenc}

Ich wuerde lieber utf8 nehmen, aber das mag leider das listings-Paket
nicht :-(

> \usepackage{T1}{fontenc}

Sowieso

> \usepackage{textcomp}

<neugierig>Guck ich mir fuers Diplom mal an, Studienarbeit wird morgen
gedruckt.</neugierig>

> Und Es scheint zu stimmen, dass apachen irgendwelches Zeug noch
> nmitschickt, aber nur unter gewissen Umständen, weil wenn ich mit telnet
> localhost 80 mir das file sauge, dann sehe ich außer dem was im html
> file drinnen steht nichts. Keine zusätzlciehn header, nix was auf utf-8
> hindeutet.

<Vermutung>telnet gibt die HTTP-Header nicht aus</Vermutung>, denn da
kommen mit Sicherheit noch ein paar mehr als nur der Content-Type.
Einfach mal den "Netzwerk"-Traffic mitschneiden, oder wers einfach mag
mal wget --save-headers <url> ausfuehren.

Ein kurzer Test hier zeigt uebrigens folgendes:

Kein AddDefaultCharset definiert, liefert Content-Type: text/html dass
bedeutet der Browser muss "anders" rauskriegen welches Encoding benutzt
wird. Bei mir mit und ohne <meta http-equiv="Content-Type".. stellt FF
die Testseite ordentlich dar (also inkl. Umlaut) wenn die Kodierung
iso-8859-1 in der Datei eingehalten wird. Wenn ich dagegen die Datei in
UTF-8 kodiere, den meta-Header auf iso-8859-1 stelle, kriege ich 2 Bytes
raus, wie erwartet. Wenn ich den meta-Header weglasse und eine UTF-8
kodierte Datei habe, raet FF das es  Koreanisch ist!

Diesselben Tests mit AddDefaultCharset ISO-8859-1 in der apache-Config,
liefert Content-Type: text/html; charset=ISO-8859-1

1. Kein Meta, latin1-kodierte Datei -> Korrekte Anzeige
2. Meta mit latin1 oder utf8, latin1-kodierte Datei -> korrekte Anzeige
3. Kein Meta, UTF-8 kodierte Datei -> kaputte Anzeige, 2 Bytes
4. Meta-Angabe mit utf8 oder latin1, UTF-8 kodierte Datei -> kaputte
Anzeige, 2 Bytes

Also hat der Header Vorrang, es scheint aber auch so als ob
auch ohne AddDefaultCharset alles gehen sollte... Nichtmal wenn ich
Apache gewaltsam in eine UTF-8 Umgebung "verfrachte" kriege ich ein
Problem im FF.

> Und ich wiederhole, FF *glaubt* das es UTF 8 ist, sonst würde nicht
> unter View->Character Encoding UTF8 angehacklt sein, oder?

Also urspruenglich war bei dir kein Charset angegeben richtig? Was sagen
die Header? Welche Version von FF?

> > Ach und: Was zur Hoelle hat das mit Debian zu tun ;-)
> 
> Nix, oder schon, weil apache so installiert wurde.

BTW: Apache1 oder Apache2? Hier ists Apache2.

Andreas

-- 
You will be Told about it Tomorrow.  Go Home and Prepare Thyself.



Reply to: