nicht angemeldet
Perl chr() und NCR
Struppihi,
für meine ISO-Tabs nehme ich chr(), da werden die 'echte' Zeichen zum Browser gesendet:
http://rolfrost.de/cgi-bin/isotabs.cgi
Ein erster Versuch mit NCRs und dem entsprechenden Header funktionierte da nicht, iso-8859-5 zeigt mir nur dann meine geliebten kyrillischen Zeichen, wenn die echt, also keine Num. Cha. Referenzen sind like &#...;
Anders hingegen bei meinen UTF-8-Tabellen:
http://rolfrost.de/cgi-bin/charmap.cgi
hier muss ich NCRs einsetzen, weil sonst im IE der untere Bereich von 32..255 nicht richtig dargestellt wird. Warum das so ist, ist mir noch nicht ganz klar, kann mich mal jemand aufklären?
Hotti
-
Hi!
Ein erster Versuch mit NCRs und dem entsprechenden Header funktionierte da nicht, iso-8859-5 zeigt mir nur dann meine geliebten kyrillischen Zeichen, wenn die echt, also keine Num. Cha. Referenzen sind like &#...;
Hast du dabei etwa Zahlen von 160 bis 255 verwendet und bei charset=ISO-8859-5 erwartet, dass dann kyrillische Zeichen angezeigt werden? Wenn nicht, beschreibe bitte nicht im Glaskugelmodus sondern nachvollziehbar.
Anders hingegen bei meinen UTF-8-Tabellen:
http://rolfrost.de/cgi-bin/charmap.cgi
hier muss ich NCRs einsetzen, weil sonst im IE der untere Bereich von 32..255 nicht richtig dargestellt wird. Warum das so ist, ist mir noch nicht ganz klar, kann mich mal jemand aufklären?Es wäre seltsam, wenn er das machte. Ich gehe von einem Fehler deinerseits aus. Aber auf raten habe ich keine Lust.
Die Überschrift auf der Seite ist auch falsch. Du schreibst UTF-8, gibst aber keine UTF-8-Byte-Sequenzen an sondern Unicode-Codepoints.
Weiterhin ist die Anzeige im Bereich der Codepoints 128 bis 159 falsch. Diese Zeichen sind in Unicode ebenso wie in der ISO-8859-Familie nicht mit sichtbaren Zeichen belegt. FF und IE stellen allerdings Windows-1252-Zeichen dar, was an den NCRs liegt, die die Browser stillschwiegend falsch interpretieren, weil sie annehmen, der Seitenautor hätte diese Zeichen gemeint und nur nicht den richtigen Unicode-Codepoint verwendet. Bei echten UTF-8-Sequenzen zeigten die Browser Kästchen mit 0080 bis 009F drin oder wie der IE ohne Inhalt an.
Lo!
-
hi,
Weiterhin ist die Anzeige im Bereich der Codepoints 128 bis 159 falsch.
ok. raus damit. Was ist mit den Zeichen von 160 bis 255?
hotti
-
Hi!
Weiterhin ist die Anzeige im Bereich der Codepoints 128 bis 159 falsch.
ok. raus damit. Was ist mit den Zeichen von 160 bis 255?Was genau meinst du jetzt? Soll ich nachschauen, ob es in deiner Tabelle diese Zeichen richtig darstellt? (Momentan ist da gähnende Leere, weil du vermutlich daran arbeitest.) Nachschauen kannst du selbst, die http://de.selfhtml.org/inter/unicode.htm@title=Unicode-Tabellen sind in SELFHTML verlinkt.
Oder meintest du jetzt, wie diese Werte bei NCRs zu interpretieren sind? Immer als Unicode-Codepoint. Egal, in welcher Kodierung die Seite ansonsten vorliegt.
Lo!
-
Hi!
Oder meintest du jetzt, wie diese Werte bei NCRs zu interpretieren sind? Immer als Unicode-Codepoint. Egal, in welcher Kodierung die Seite ansonsten vorliegt.
Genau das ist meine Frage: Sollte ich für den Bereich 7F-FF NCRs nehmen? Weil: Wenn ich da mit chr(codepoint) Zeichen erzeuge, zerhauts mir beim IE die Tabelle. Mit NCRs hingegen dargestellt kommen da die Zeichen, die ich so von ISO-8859-1 her kenne.
Hotti
-
Hi!
Oder meintest du jetzt, wie diese Werte bei NCRs zu interpretieren sind? Immer als Unicode-Codepoint. Egal, in welcher Kodierung die Seite ansonsten vorliegt.
Genau das ist meine Frage: Sollte ich für den Bereich 7F-FF NCRs nehmen? Weil: Wenn ich da mit chr(codepoint) Zeichen erzeuge, zerhauts mir beim IE die Tabelle. Mit NCRs hingegen dargestellt kommen da die Zeichen, die ich so von ISO-8859-1 her kenne.Oder auch die von Windows-1252, die die Browser anzeigen, wenn ISO-8859-1 deklariert ist, jedoch trotzdem Zeichen aus 80..9F kommen.
Aber zu den NCRs: Offensichtlich machen die Browser mit NCRs aus dem Bereich 80 bis 9F Unfug (um unwissenden Seitenerstellern einen Gefallen zu tun). Wenn du NCRs verwenden willst, solltest du überlegen, den Bereich explizit auszusparen. Ansonsten ist es normalerweise in keinen Browser notwendig, NCRs zu verwenden, wenn die Seite korrekt in UTF-8 vorliegt (HTML-eigene Zeichen (<>"&) sind natürlich zu beachten). Und da stellt sich die Frage: Warum macht der IE da was verkehrt? Und bekommt er alles korrekt geliefert - sprich: macht vielleicht Perls chr() nicht alles richtig, oder zumindest anders als erwartet?
Warum aber machst du dir die Mühe, noch eine Seite mit Zeichentabellen zu erstellen. Was unterscheidet dich von anderen Anbietern, wo ist der Mehrwert? Zum Beispiel finde ich, besser als die Wikipedia kann man die ISO-8859-Familie eigentlich gar nicht mehr präsentieren.
Lo!
-
hi,
[..]Ansonsten ist es normalerweise in keinen Browser notwendig, NCRs zu verwenden, wenn die Seite korrekt in UTF-8 vorliegt
Ok, x80 bis x9F ist raus.
Bleibt die Frage, was von xA0 bis xFF zu sehen sein sollte.
macht vielleicht Perls chr() nicht alles richtig, oder zumindest anders als erwartet?
chr() hat mir bis heute immer die Zeichen geliefert, die ich erwartet habe ;-)
Warum aber machst du dir die Mühe, noch eine Seite mit Zeichentabellen zu erstellen.
Ich erstellte die Seiten doch gar nicht, das macht ein Script.
Hotti
-
Hi!
Bleibt die Frage, was von xA0 bis xFF zu sehen sein sollte.
Siehe bereits verlinkte Unicode-Zeichentabelle. Der Bereich 00..FF ist gleich zu ISO-8859-1, inklusive der Steuerzeichen-Lücken.
macht vielleicht Perls chr() nicht alles richtig, oder zumindest anders als erwartet?
chr() hat mir bis heute immer die Zeichen geliefert, die ich erwartet habe ;-)Die chr()-Beschreibungsseite sagte, da gäbe es eine Besonderheit im Bereich 128..255, nur schrieb sie nicht, welche Auswirkungen das hat. Weiterhin stand da zum Parameter "NUMBER in the character set". Ja, toll, but which one? Muss man dazu anderswo stehende Informationen haben, wie Perl allgemein mit dem Thema umgeht?
Lo!
-
Hi mein Guter,
Bleibt die Frage, was von xA0 bis xFF zu sehen sein sollte.
Siehe bereits verlinkte Unicode-Zeichentabelle. Der Bereich 00..FF ist gleich zu ISO-8859-1, inklusive der Steuerzeichen-Lücken.
Ich werde das einfach ausblenden, die ISO-Tabellen gehen bei mir extra. Oder isch schreibe "siehe ISO" rein ;-)
Die chr()-Beschreibungsseite sagte, da gäbe es eine Besonderheit im Bereich 128..255, nur schrieb sie nicht, welche Auswirkungen das hat.
Arggh. In meiner Doku steht das aber nicht, hehe. Jetzt kann ich mir so Einiges erklären ;-)
Muss man dazu anderswo stehende Informationen haben, wie Perl allgemein mit dem Thema umgeht?
Ja. Oder dumm gucken. Oder hier im Forum mal nachfragen ;-)
Danke Dir!
Horst Hasel(Schnee)huhn
-
-
-
hi,
Warum aber machst du dir die Mühe, noch eine Seite mit Zeichentabellen zu erstellen. Was unterscheidet dich von anderen Anbietern, wo ist der Mehrwert?
Hier ;-)
Ich frag mich eher, warum sich manche die Mühe machen und die Tabellen als PDF erstellen... wo mich mein Seiltänzer jedesmal fragt, ob er ein Update kriegen kann und ich jedesmal sagen muss: Bedaure, ich hab noch zu tun :-)
Viele Grüße,
Horst Haselhuhn-
Hi!
Hier ;-)
Dort (nicht hier!) sehe ich Fehler: "[...] wobei die Zeichen bis 32 Steuerzeichen und dem PC vorbehalten sind." - Achwas. Damit steuert man das Verhalten eines PCs. Zeilenumbrüche, Dateiende, Zeichen löschen, NUL (in C als Stringende verwendet) sind sehr wohl vom Anwender verwendbar.
"Reserviert ist der Bereich von 7F bis 9F." Erst nimmst du dezimale Werte und nun Hex, das ist inkonsistent.
"Die Zeichen von A0 bis FF fallen in den ISO-Bereich, siehe also dort." Fallen sie nicht, sie sind nur mit ihm identisch. Der gesamte Bereich 00..FF (0..255) ist das. Ebenso wie 00..7F (0..128) identisch zu ASCII ist.Ich frag mich eher, warum sich manche die Mühe machen und die Tabellen als PDF erstellen...
Man kann mit PDF Dokumente erstellen, und dabei Schriftarten verwenden, die der Anwender nicht installiert zu haben braucht, weil sie (zumindest für die verwendeten Zeichen) eingebettet werden können. Außerdem gibt es (oder muss das mittlerweile "gab es" heißen?) kein systemübergreifendes und nahezu überall lesbares Ein-Dateien-Dokumentenformat, das Text und Grafik enthalten kann.
Lo!
-
moin,
Man kann mit PDF Dokumente erstellen, und dabei Schriftarten verwenden, die der Anwender nicht installiert zu haben braucht,
Nochmal zur Zweckbestimming _meiner_ Tabellen: Die gehören als Anlage zu
und sollen bei der Fehlersuche in Sachen Zeichenkodierung dienlich sein. Meine Tabellen sollen Zeichen nicht etwa so zeigen wie die aussehen könnten, sondern so zeigen wie sie der Browser darstellt. Daher auch mein Hinweis "Es ist möglich, dass der Browser nicht alle Zeichen darstellen kann" und ein weiterer Hinweis "...dass Sie der Browser fragt, ob entsprechende Sprachpakete installiert werden sollen, wenn Zeichen nicht dargestellt werden können".
Verwirrend finde ich, wenn eine Tabelle das Zeichen U+00AD zeigt, meine Browser zeigen das nämlich nicht.
Vielen Dank für Deine Hinweise,
Grüße an Alle,
Horst Schneehase-
Hi!
Verwirrend finde ich, wenn eine Tabelle das Zeichen U+00AD zeigt, meine Browser zeigen das nämlich nicht.
Das ist ein Mal-da-mal-nicht-Zeichen, denn es ist einerseits sehr scheu (SHY) und andererseits ist es der bedingte Umbruch. Man kann (besser könnte, wenn es denn die Browser alle mitmachten) damit Sollbruchstellen in Wörter einfügen, die normalerweise unsichtbar sind und erst an Zeilenende zu einem Bindestrich und Zeilenumbruch werden.
Lo!
-
Verwirrend finde ich, wenn eine Tabelle das Zeichen U+00AD zeigt, meine Browser zeigen das nämlich nicht.
Das haten wir doch erst vor kurzem: https://forum.selfhtml.org/?t=194152&m=1297676
Struppi.
-
-
-
-
-
-
-
-