Zunächst musst Du die verwendete Codierung herausfinden. Das geht auf
Unices etwa mit dem Programm file(1). Und dann hängt es von Deinem
Webserver (welcher?) ab, wie Du ihm den korrekten Content-Type"-Header
beibringst.
http://de.selfhtml.org/servercgi/server/
http://de.wikipedia.org/wiki/HTTP
http://de.wikipedia.org/wiki/Content-Type
Zusatzfrage: Kennt jemand eine Möglichkeit, dass Apache 1.3+ die verwendete
Codierung der auszuliefernden Ressource automagisch herausfindet und den
"Content-Type"-Header entsprechend setzt? Insbesondere wäre das bei
PHP-Scripts praktisch. TIA.
X-Post & F'up2 de.comm.infosystems.www.authoring.misc
PointedEars
--
"Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no
one will want to steal it.)" -- Tipp gegen Quellcode-Klau,
<http://www.vortex-webdesign.com/help/hidesource.htm>
Wie sollte file denn zwischen (bspw.) latin1, latin2 und latin9
unterscheiden können? Kann man überhaupt zuverlässig zwischen utf8 und
latin1 unterscheiden (will sagen: Sind nicht alle UTF-8-Bytes auch
gültige Latin1-Bytes - anders als umgekehrt ?)
Hab's gerade mal probiert: bei einem UTF-16 kodierten Text wirft file
gar nichts aus. Bei einem Latin1-Text sagt es
artikel.txt: ISO-8859 HTML document text
8859 hilft gar nicht (weil es eben 1 - 9 oder 15 sein könnte). HTML ist
sogar definitiv flasch (obwohl da Dinge drin rumlungern, die wie Tags
aussehen - sind aber keine!).
Kurz: file ist keine Lösung. Du musst schon *wissen*, wie das Dokument
kodiert ist.
> Zusatzfrage: Kennt jemand eine Möglichkeit, dass Apache 1.3+ die verwendete
> Codierung der auszuliefernden Ressource automagisch herausfindet und den
> "Content-Type"-Header entsprechend setzt? Insbesondere wäre das bei
> PHP-Scripts praktisch. TIA.
Ginge es so, wie Du oben schreibst (also mit file(1)), könnte man das
vielleicht auch dem Apache beibiegen (ggfs. mit einem Modul). Da es
nicht geht, solltest Du einfach Deinem PHP-Script beibringen, den
Content-type korrekt zu setzen. In Perl (CGI.pm) ist das problemlos
möglich, sollte wohl also in PHP auch gehen.
Thomas 'PointedEars' Lahn schrieb:
> Zunächst musst Du die verwendete Codierung herausfinden. Das geht auf
> Unices etwa mit dem Programm file(1). Und dann hängt es von Deinem
> Webserver (welcher?) ab, wie Du ihm den korrekten Content-Type"-Header
> beibringst.
Es ist ein Apache Webserver. Mehr weiß ich von dem Provider nicht, da
ich nur über FTP User Rechte verfüge.
Alle anderen Umlaute werden ja korrekt angezeigt, es geht nur um das
JS-Problem, dass man in der new Option keine Umlaute hinzufügen kann.
nochmals für die neue mitlesende NG:
obj.options[obj.options.length] = new Option('Bitte Auswählen', '0');
egal, was ich mit dem Umlaut mache, es wird nie korrekt dargestellt. Im
restlichen Dokument werden aber Umlaute richtig interpretiert (mit der
entsprechenden Maskierung).
danke und lg,
Ludwig
funktioniert 'Bitte Ausw\ählen'? Geht's, wenn Du DOM-Funktionen benutzt,
also sowas Ähnliches, wie das hier:
var option = document.createElement('option');
option.appendChild(document.createTextNode('Bitte Ausw\ählen'));
obj.appendChild(option);
ist das gleiche Ergebnis.
> var option = document.createElement('option');
> option.appendChild(document.createTextNode('Bitte Ausw\ählen'));
> obj.appendChild(option);
Wäre ebenso das gleiche Ergebnis.
Ich habs nun aber durch einen Umweg geschafft - warum auch immer, es
wird nun korrekt angezeigt (aber auch nur, weil ich PHP benutze, das
Grundproblem besteht weiterhin):
$text = utf8_encode("Bitte auswählen");
obj.options[obj.options.length] = new Option('<?=$text?>', '0');
Das wird in der Tat schwierig.
> Kann man überhaupt zuverlässig zwischen utf8 und latin1 unterscheiden
> (will sagen: Sind nicht alle UTF-8-Bytes auch gültige Latin1-Bytes -
> anders als umgekehrt ?)
Nein, natürlich sind sie das nicht. Ausserdem gibt es noch den BOM.
> Hab's gerade mal probiert: bei einem UTF-16 kodierten Text wirft file gar
> nichts aus. Bei einem Latin1-Text sagt es
>
> artikel.txt: ISO-8859 HTML document text
>
> 8859 hilft gar nicht (weil es eben 1 - 9 oder 15 sein könnte). HTML ist
> sogar definitiv flasch (obwohl da Dinge drin rumlungern, die wie Tags
> aussehen - sind aber keine!).
>
> Kurz: file ist keine Lösung. Du musst schon *wissen*, wie das Dokument
> kodiert ist.
-i gibt immerhin einen Hinweis, welche Codierung ausreichend ware. Dann
kann man ggf. mit iconv(1) konvertieren und einen entsprechenden Header setzen.
PointedEars
--
Kopf = {};
Kopf.onzahnweh = aua;
function aua(){alert('Aua!');}
(Georg Maaß in dcljs <b57n6s$26cacq$1...@ID-3551.news.dfncis.de>)
Wenn Dir ein J(ava)Script-Exp^W^W^W jemand, der sich mit J(ava)Script
wirklich sehr gut auskennt, weil er sich schon eine Dekade in der Freizeit
und beruflich damit beschäftigt, schreibt, dass das kein Script-Problem ist,
und daher beim Crosspost diesen irrelevanten Code weglässt, darfst Du ihm
schon glauben, dass er sich dabei wirklich *sehr* *sehr* sicher ist.
> funktioniert 'Bitte Ausw\ählen'? Geht's, wenn Du DOM-Funktionen benutzt,
> also sowas Ähnliches, wie das hier:
>
> var option = document.createElement('option');
> option.appendChild(document.createTextNode('Bitte Ausw\ählen'));
> obj.appendChild(option);
Da das kompletter Unfug ist ("\ä" ist eine ungültige Escape-Sequenz, wird
daher wie "Ä" behandelt; vgl. "<\/script>"), funktioniert es natürlich
nicht. "Wenn man keine Ahnung hat, einfach mal Klappe halten."
PointedEars
--
Was funktioniert in Tabellen bei NN4 wirklich verläßlich? Nicht mal die
Abstürze in Zusammenhang mit Tabellen sind verläßlich, auch wenn sie
häufig vorkommen. (Georg Maaß in dcljs <3D6CCAEC...@vnett.de>)
> Ich habs nun aber durch einen Umweg geschafft - warum auch immer, es
> wird nun korrekt angezeigt (aber auch nur, weil ich PHP benutze, das
> Grundproblem besteht weiterhin):
>
> $text = utf8_encode("Bitte auswählen");
> obj.options[obj.options.length] = new Option('<?=$text?>', '0');
Dann solltest du aber die Datei auch mit Content-Type: text/html;
charset=UTF-8 ausliefern, bzw. eine separate Script-Datei mit
Content-Type: application/x-javascript; charset=UTF-8.
--
Martin Honnen
http://JavaScript.FAQTs.com/
> nicht. "Wenn man keine Ahnung hat, einfach mal Klappe halten."
PointedEars, mit klemmender Shift-Taste ;-)
--
Wo im W3C-DOM für XML ist document.write spezifiziert? Nirgendwo. Das
geht also nicht, Du mußt das Dokument Knötchen für Knötchen aufbauen.
Soviel vom W3C zum Thema "Verstehen Sie Spaß???".
(Georg Maaß in dcljs <an91cq$c0ogv$1...@ID-3551.news.dfncis.de>)
Wenn ich jedem Fremden 100% Glaubwürdigkeit schenkte, wäre ich wohl
nicht mehr am Leben (und ich spreche nicht die steigende Kriminalität,
sondern vielmehr vom geschulten, studierten oder anderwertigen
qualifizierten Menschen).
Solch eine Egoismus hätte ich auch gerne!
lg,
Ludwig
Es hat nichts mit Egoismus (Du suchtest sicher den gleichfalls unpassenden
Ausdruck "Arroganz") zu tun, sich in seinem Fachgebiet auszukennen und dies
auch zu dokumentieren.
Score adjusted
F'up2 PointedEars
--
Lass es mich so ausdrücken: Eigentlich werde ich keine Zeit haben, aber die
fürs Usenet übliche nehme ich mir. Nähme ich mir noch zusätzlich was vor,
würde ich womöglich das tun, um nicht das, das ich tun sollte, tun zu müssen.
(Christoph Päper in <darw/> <avl5ul$30fp$1...@ariadne.rz.tu-clausthal.de>)
Aha. Ich lese mal ECMA-Script (von 1999, zugegeben) vor:
DoubleStringCharacter::
SourceCharacter but not double-quote " or backslash \ or LineTerminator
\EscapeSequence
SingleStringCharacter ::
SourceCharacter but not single-quote ' or backslash \ or LineTerminator
\ EscapeSequence
EscapeSequence ::
CharacterEscapeSequence
0 [lookahead ∉ DecimalDigit]
HexEscapeSequence
UnicodeEscapeSequence
CharacterEscapeSequence ::
SingleEscapeCharacter
NonEscapeCharacter
SingleEscapeCharacter :: one of
' " \ b f n r t v
NonEscapeCharacter ::
SourceCharacter but not EscapeCharacter or LineTerminator
Das liest sich (aber ich mag mich ja irren, weil ich "keine Ahnung"
habe) so, als ob eine "EscapeSequence" durchaus aus einem "\" gefolgt
von einem "SourceCharacter" bestehen könnte - und zwar ohne "ungültig"
zu sein.
Zumal es etwas später im selben Text heißt (CV= Character Value):
"The CV of CharacterEscapeSequence::NonEscapeCharacter is the CV of the
NonEscapeCharacter.
The CV of NonEscapeCharacter :: SourceCharacter but not EscapeCharacter
or LineTerminator is the SourceCharacter character itself. "
Bitte erklär mir doch, oh Weiser, wie ich aus diesen Zeilen schließen
kann, "\ä" sei eine "ungültige Escape-Sequenz"? Ich möchte ja ungern so
blöd sterben, wie ich offenbar bislang war.
Danke
*gähn*
Die aktuelle Revision ist ausserdem ECMA-262 Ed. 3 Final vom März 2000, in
der jedoch diesbezüglich dasselbe steht.
> [...]
> Bitte erklär mir doch, oh Weiser, wie ich aus diesen Zeilen schließen
> kann, "\ä" sei eine "ungültige Escape-Sequenz"? Ich möchte ja ungern so
> blöd sterben, wie ich offenbar bislang war.
Zugegeben, "ungültig" ist eine umgangssprachliche (aber im JS-Umfeld hierfür
übliche) Ungenauigkeit. Dennoch wirst Du sicher bemerkt haben, dass "ä"
nicht durch SingleEscapeCharacter produziert werden kann, worauf ich mich
natürlich bezog (wäre das ungültig im Sinne eines Syntaxfehlers, compilierte
der Code ja gar nicht erst).
Wie kommt es nur, dass ich den Verdacht habe, Du seist meinem
Scriptkiddie-Killfile entschlüpft?
F'up dcljs
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann