nicht angemeldet
Unicode Zeichen in <option>
Hallo!
Wie kann ich es bewerkstelligen, dass ich ein Unicode Zeichen in einem <option> habe?
Also:
<option value="bla">♂ Bla bla</option>
♂--> Zeichen für männlich
Wenn ich ♂ sonst irgendwo verwende, dann wird das Zeichen korrekt angezeigt. Nur beim <option> kommt nur Kästchen.
Leider ist es auch nicht möglich, ein Image in einem <option> zu haben.
ICh bräuchte aber ein Zeichen für das Geschlecht in meiner option, sonst ist langweilig.
Hat jemand eine Idee?
MFG Irki
-
Hallo Irki,
Wenn ich ♂ sonst irgendwo verwende, dann wird das Zeichen korrekt angezeigt. Nur beim <option> kommt nur Kästchen.
Ich vermute mal, das liegt daran, dass der Browser bei der Darstellung der Formular-Controls Betriebssystem-Ressourcen verwendet, unter anderem auch die dort benutzten Schriftarten.
Leider ist es auch nicht möglich, ein Image in einem <option> zu haben.
Teilweise schon:
http://aktuell.de.selfhtml.org/tippstricks/css/optionbilder/viele Gruesse
Stefan Muenz -
Hallo,
Wie kann ich es bewerkstelligen, dass ich ein Unicode Zeichen in einem <option> habe?
Indem Du dem Browser mitteilst, dass jetzt UTF-8-codierter Inhalt kommt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Geschlechter-Select</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<form action="#" method="POST">
<p>Geschlecht:
<select name="s1" size="1">
<option value="bla">♀ weiblich</option>
<option value="bla">♂ männlich</option>
</select>
</p>
</form>
</body>
</html>viele Grüße
Axel
-
Moin,
Indem Du dem Browser mitteilst, dass jetzt UTF-8-codierter Inhalt kommt.
Bitte führe aus was deiner Meinung nach UTF-8-Kodierung und numerische Zeichenentities miteinander zu tun haben.
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hallo,
Indem Du dem Browser mitteilst, dass jetzt UTF-8-codierter Inhalt kommt.
Bitte führe aus was deiner Meinung nach UTF-8-Kodierung und numerische Zeichenentities miteinander zu tun haben.
Das kommt darauf an, was die Browser mit diesen Entities tun, wenn sie nicht direkt geparst und in der Seite angezeigt werden.
Offensichtlich ist es so, dass MSIE (getestet mit IE6) das daraus resultierende Zeichen nur dann als UTF-8-Zeichen an das Control übergibt, welches die Select-Liste darstellt, wenn dieses Charset für die Seite entweder per Meta oder per Header angegeben wurde. Geckos und der neue Opera haben eigene Controls für Select-Listen. Diese stellen das Zeichen auch mit Charset ISO-8859-1 dar.
viele Grüße
Axel
-
Hallo,
Bitte führe aus was deiner Meinung nach UTF-8-Kodierung und numerische Zeichenentities miteinander zu tun haben.
Wenn schon genau, dann richtig ;-))
Bitte definiere, nach Lektüre von http://www.w3.org/TR/html4/charset.html#h-5.3 den Begriff "numerische Zeichenentities". Meiner Meinung nach gibt es soetwas nicht.
Kläre weiterhin die Bedeutung von #PCDATA in:
<!ELEMENT OPTION - O (#PCDATA) -- selectable choice -->
um zu ergründen, ob numeric character references in OPTION-Elementen überhaupt ausgewertet werden dürfen, oder ob nicht alle Browser etwas falsch machen, weil
<option value="bla">♀ weiblich</option>
einfach den Eintrag [♀ weiblich] ergeben müsste.
viele Grüße
Axel
-
Moin,
Bitte definiere, nach Lektüre von http://www.w3.org/TR/html4/charset.html#h-5.3 den Begriff "numerische Zeichenentities". Meiner Meinung nach gibt es soetwas nicht.
Gut, ich hätte es doch englisch schreiben sollen (wobei man dann wieder von anderen komisch angesehen wird) und wollte eigentlich nur den Unterschied zu Dingern wie & ausdrücken.
Kläre weiterhin die Bedeutung von #PCDATA in:
<!ELEMENT OPTION - O (#PCDATA) -- selectable choice -->
| PCDATA parsed character data; text occurring in a context in
| which markup and entity references may occur.
-- http://www.december.com/html/4/data/index.htmlDas war ja einfach. :-)
Im Übrigen schließe ich mich Sven an: Wenn der IE sowas braucht, dann sollte er repariert werden. Die Bedeutung von numeric character references ist vollkommen unabhängig von der verwendeten Zeichencodierung. (BTW: Der Zeichensatz ist sowieso immer fest und der gleiche.)
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~-
Hallo,
Bitte definiere, nach Lektüre von http://www.w3.org/TR/html4/charset.html#h-5.3 den Begriff "numerische Zeichenentities". Meiner Meinung nach gibt es soetwas nicht.
Gut, ich hätte es doch englisch schreiben sollenIst "Zeichenentities" Deutsch? Wie wäre es mit numerische Zeichenreferenzen?
(wobei man dann wieder von anderen komisch angesehen wird) und wollte eigentlich nur den Unterschied zu Dingern wie & ausdrücken.
Wie ich es verstanden habe, ist "amp" der Name der Entity. Das & ist auch eine Referenz, nur eben auf eine Entity.
Das war ja einfach. :-)
Ja, nich? ;-))
Was mich wundert ist allerdings, dass man das PCDATA nirgendwo auf w3.org definiert findet. Da finde ich nur CDATA.Im Übrigen schließe ich mich Sven an: Wenn der IE sowas braucht, dann sollte er repariert werden.
Ja, das mache ich, wenn ich mal Zeit habe.
viele Grüße
Axel
-
Hi,
Was mich wundert ist allerdings, dass man das PCDATA nirgendwo auf w3.org definiert findet. Da finde ich nur CDATA.
Das könnte daher kommen, daß die Definition bereits in SGML erfolgt - welches als ISO-Standard nur gegen Bezahlung verfügbar ist.
Aber immerhin gibt es ja auch Hinweise darauf in HTML 4.01: http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.3.3.1:
Document text (indicated by the SGML construct "#PCDATA"). Text may contain character references. Recall that these begin with & and end with a semicolon (e.g., "Hergé's adventures of Tintin" contains the character entity reference for the "e acute" character).
cu,
Andreas--
MudGuard? Siehe http://www.Mud-Guard.de/
Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
-
-
-
-
Danke, jetzt gehts!
MFG Irki
-
Moin!
Danke, jetzt gehts!
Mußt du nur beachten, dass deine Sonderzeichen (alles, was nicht in den unteren 7 Bit des ASCII-Codes enthalten ist) auch in UTF-8 codierst. Dazu zählen beispielsweise die Umlaute, das Euro-Zeichen, und vieles mehr.
Die Lösung an sich ist vom Grundsatz her unnötig. HTML nutzt als zugrundeliegenden Zeichensatz sowieso Unicode, und die Zahlen-Entities &#xHEXZAHL; bzw. &#DEZZAHL; sind absolut erlaubt, um auch bei anderen Zeichencodierungen (ISO-8859-1 beispielsweise) beliebige andere Unicode-Zeichen zu referenzieren.
Wenn der IE so blöd ist, seine Formular-Controls an dem angegebenen Zeichensatz auszurichten und Unicode-Sonderzeichen nicht darzustellen, dann sollte man eigentlich diesen Browser korrigieren.
Wie gesagt: Man erkauft sich die Tatsache, dass die Meta-Angabe UTF-8 das Problem im IE löst, mit der Notwendigkeit, alle Sonderzeichen, die man nicht als Entity schreibt, UTF-8 zu codieren. Mit dem richtigen Editor sicher kein Problem.
Das Problem kommt aber dann, wenn es um den Versand von Formulardaten geht. Denn die werden (hoffentlich - die Browser sind sich da oft nicht so einig) auch als UTF-8 verschickt. Das ist grundsätzlich kein Problem, und UFT-8 ist sowieso die beste Lösung, wenn es um die Übermittlung von Formulardaten geht - nur wissen muß man das, weil ansonsten durchaus seltsames Verhalten an den Tag gelegt wird, wenn man serverseitig gewisse Dinge nicht berücksichtigt.
So harmlose Dinge wie "ein Ä wird zu zwei Zeichen - und zählt dann auch als zwei Zeichen" könnten sich zu nervigen "Warum zählt der denn die Textlänge falsch" ausweiten - um nur ein Beispiel zu nennen.
Wer hingegen im String nach einem Einzelzeichen "Ä" sucht, dank UTF-8 aber keines findet, weil das Ä ja zwei Zeichen sind, seine Programmiersprache aber keine zwei Zeichen hintereinander finden kann (oder das anders getan werden muß), wird vermutlich schon eher verzweifeln.
- Sven Rautenberg
-
Hallo,
Das Problem kommt aber dann, wenn es um den Versand von Formulardaten geht. Denn die werden (hoffentlich - die Browser sind sich da oft nicht so einig) auch als UTF-8 verschickt.
Das sollte man aber mit dem Attribut accept-charset im FORM-Element beeinflussen können. http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charset
viele Grüße
Axel
-
Hallo Axel,
Das Problem kommt aber dann, wenn es um den Versand von
Formulardaten geht. Denn die werden (hoffentlich - die Browser
sind sich da oft nicht so einig) auch als UTF-8 verschickt.
Das sollte man aber mit dem Attribut accept-charset im FORM-Element
beeinflussen können.
http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charsetaccept-charset wird von allen Browsern ausser Opera ignoriert.
Probiere es hier aus:http://forum.de.selfhtml.org/cgi-bin/test.pl
Es ist ISO-8859-1, UTF im accept-charset angegeben. Das Dokument
wird mit latin1 ausgeschickt. Jetzt schicke mal z. B. das €-Zeichen,
und du wirst sehen: es kommt 0x80 an, nicht 0xE2 0xAC.Grüße,
CK-
Moin!
accept-charset wird von allen Browsern ausser Opera ignoriert.
Probiere es hier aus:http://forum.de.selfhtml.org/cgi-bin/test.pl
Es ist ISO-8859-1, UTF im accept-charset angegeben. Das Dokument
wird mit latin1 ausgeschickt. Jetzt schicke mal z. B. das -Zeichen,
und du wirst sehen: es kommt 0x80 an, nicht 0xE2 0xAC.Hierbei gibt es zwei gravierende Probleme:
Erstens - wie du sagst: Die Browser wählen sich nicht, wie man vermuten könnte, denjenigen Zeichensatz aus, mit dem sie die Formulareingabe korrekt übermitteln könnten.
Zweitens: Selbst wenn sie das tun würden, außer Opera übermittelt kein Browser, welche Wahl er denn tatsächlich getroffen hat. Und das ist durchaus entscheidend, denn UTF-8 verwendet unter Umständen genau die Bytes, welche auch in ISO-8859-1 erlaubte Zeichen darstellen. Man kann also meistens anhand der übermittelten Bytes gar nicht feststellen, welche Codierung verwendet wurde.
Und drittens: Solange die Browser anstelle der angegebenen Codierungen irgenwas anderes (wie Windows-1252 oder so) nutzen, ist sowieso alles verloren.
- Sven Rautenberg
-
Moin,
Zweitens: Selbst wenn sie das tun würden, außer Opera übermittelt kein Browser, welche Wahl er denn tatsächlich getroffen hat.
Ja, das hat alles äusserst schleimige Konsistenz und einen leicht fauligen Geruch. Da hätte man vor ca. 10 Jahren anfangen und _allem_ was mit Zeichendaten zu tun hat ein Zwangsfeld für die verwendete Kodierung spendieren müssen (ich rede nicht nur von HTTP sondern auch von Sachen wie Dateisystemen). Und jeden der sich vorsätzlich nicht dran hält einstweilig erschiessen.
Seufz, hat mal jemand eine Zeitmaschine?
--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
-
-
Hallo,
accept-charset wird von allen Browsern ausser Opera ignoriert.
Probiere es hier aus:http://forum.de.selfhtml.org/cgi-bin/test.pl
Es ist ISO-8859-1, UTF im accept-charset angegeben. Das Dokument
wird mit latin1 ausgeschickt. Jetzt schicke mal z. B. das -Zeichen,
und du wirst sehen: es kommt 0x80 an, nicht 0xE2 0xAC.Hm? MSIE 6 schickt die Formulardaten UTF-8-kodiert, sobald ein Zeichen außerhalb von ISO-8859-1 auftaucht. Ansonsten ISO-8859-1-kodiert. Das gilt auch für die zusätzlichen Zeichen in Windows-1252, falls diese auftauchen, wird UTF-8-kodiert.
Opera spielt verrückt und kapiert nicht, was zu ISO-8859-1 gehört und was nicht. Wenn man »â« eingibt, schickt er schon UTF-8, obwohl ISO-8859-1 völlig ausreichen würde.Ich kann leider auf die früheren Untersuchungen nicht zugreifen, aber wo lag das Problem im MSIE? Er beachtet entgegen deiner Aussage durchaus die accept-charset-Angabe und in meinen Tests sogar stimmiger als Opera 7.5.
Lediglich Mozilla kodiert in meinen Tests gewisse Zeichen als Windows-1252, das kennen wir ja.
Mathias
-
Hallo molily,
[...]
Hm? MSIE 6 schickt die Formulardaten UTF-8-kodiert, sobald ein
Zeichen außerhalb von ISO-8859-1 auftaucht.Ausserhalb von Windows-1252.
Ansonsten ISO-8859-1-kodiert. Das gilt auch für die zusätzlichen
Zeichen in Windows-1252, falls diese auftauchen, wird UTF-8-kodiert.Mit dem MSIE kommt 0x80 an, sobald ich das -Zeichen verwende.
Zumindest war das beim IE 5.5 so, den IE 6 habe ich nicht.Opera spielt verrückt und kapiert nicht, was zu ISO-8859-1 gehört
und was nicht. Wenn man »â« eingibt, schickt er schon UTF-8, obwohl
ISO-8859-1 völlig ausreichen würde.Das ist ja egal. Ich habe ja angegeben, dass ich gern Latin1 oder
UTF-8 haette.Ich kann leider auf die früheren Untersuchungen nicht zugreifen,
aber wo lag das Problem im MSIE? Er beachtet entgegen deiner
Aussage durchaus die accept-charset-Angabe und in meinen Tests
sogar stimmiger als Opera 7.5.Nein, gar nicht. Er schickt UTF-8 auch dann, wenn ich von UTF-8
nichts gesagt habe. Dass es in diesem Test funktioniert, liegt daran,
dass mir UTF-8 durchaus gelegen kommt :-)Der IE 5.5 scheint, was ich bisher herausgefunden habe, entweder
Windows-1252 oder UTF-8 zu schicken, egal, was die Seite angibt.Lediglich Mozilla kodiert in meinen Tests gewisse Zeichen als
Windows-1252, das kennen wir ja.Wie gesagt, IE 5.5 genau so. 6 habe ich nicht.
Grüße,
CK
-
-
-
Moin!
Das Problem kommt aber dann, wenn es um den Versand von Formulardaten geht. Denn die werden (hoffentlich - die Browser sind sich da oft nicht so einig) auch als UTF-8 verschickt.
Das sollte man aber mit dem Attribut accept-charset im FORM-Element beeinflussen können. http://www.w3.org/TR/html4/interact/forms.html#adef-accept-charset"Sollte" trifft es gut, die Browser verhalten sich da sehr uneinheitlich.
Außerdem ist das gar nicht wünschenswert! Denn wenn du Formulareingaben entgegennimmst, welche wieder auf der Seite ausgegeben werden sollen, wäre es Blödsinn, das Formular als ISO-8859-1 zuzuschicken zu lassen, weil man es dann wieder in UTF-8 konvertieren müßte. Denn die beiden Codierungen sind zueinander inkompatibel.
- Sven Rautenberg
-
-
-
-