Micro Sign wird nicht dargestellt
0 0 0 
Gunnar Bittersmann
0
0 Gunnar Bittersmann
0 
O'Brien
Micro Sign wird nicht dargestellt
hi,
komische Sache, hier funktioniert die Darstellung:
http://rolfrost.de/cgi-bin/ucdsearch.cgi?query=%2Bmicro&find=Zeichen+finden
das µ ist dabei mit Codepoint U+00B5
aber hier wird es nicht dargestellt:
http://rolfrost.de/cgi-bin/ucdsearch.cgi?query=%2Bmicro+%2Bsign&find=Zeichen+finden
obwohl der CP richtig ist. Die Umsetzung CP in Zeichen erfolgt ein beiden Fällen mit der Perlfuntion pack "U0U, $codepoit;
Möglicherweise Problem mit Perl Modul Text::Query, irgendwie muss der Fehler jedoch zu finden sein, der Valigator wirft auch das Handtuch.
Wenn jemand eine Idee hat, bitte melden.
Horst Rathlos
-
Hi,
http://rolfrost.de/cgi-bin/ucdsearch.cgi?query=%2Bmicro&find=Zeichen+finden
das µ ist dabei mit Codepoint U+00B5
Nein, ist es nicht
Die Bytes C2 B5 stehen im Quelltext.aber hier wird es nicht dargestellt:
http://rolfrost.de/cgi-bin/ucdsearch.cgi?query=%2Bmicro+%2Bsign&find=Zeichen+finden
obwohl der CP richtig ist.
Nein, ist er nicht.
http://validator.w3.org/check?uri=http%3A%2F%2Frolfrost.de%2Fcgi-bin%2Fucdsearch.cgi%3Fquery%3D%252Bmicro%2B%252Bsign%26find%3DZeichen%2Bfinden:
Sorry, I am unable to validate this document because on line 34 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.The error was: utf8 "\xB5" does not map to Unicode
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
hi Chris,
das µ ist dabei mit Codepoint U+00B5
Nein, ist es nicht
Die Bytes C2 B5 stehen im Quelltext.Danke! Indes, ich habe nicht die geringste Ahnung, wo _das_ jetzt herkommt. Der Codepoint stimmt jedenfalls, zum Vergleich habe ich mal die NCR neben die Bytes gelegt.
Da spinnt mir was dazwischen, einen Verdacht habe ich, mal überschlafen.
Danke für den Hinweis auf die bytes,
Hotti -
@@ChrisB:
nuqneH
das µ ist dabei mit Codepoint U+00B5
Nein, ist es nicht
??
Die Bytes C2 B5 stehen im Quelltext.
C2 B5 ist die Oktettsequenz von UFT-8-codiertem U+00B5.
The error was: utf8 "\xB5" does not map to Unicode
Ah, ISO-8859-1-codiertes U+00B5.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
hi,
Die Bytes C2 B5 stehen im Quelltext.
C2 B5 ist die Oktettsequenz von UFT-8-codiertem U+00B5.
Die sind ja sogar richtig.
The error was: utf8 "\xB5" does not map to Unicode
Ah, ISO-8859-1-codiertes U+00B5.
Ne, windows-1252, mit dieser Codierung wirds jedenfalls richtig angezeigt.
Also, wenn die Oktetten stimmen, warum wirft der validator das Handtuch? Und was bewegt den Browser (FF, IE) dazu, die windows-Codepage anzuziehen?
Hotti
-
Hi,
Also, wenn die Oktetten stimmen,
Tun sie im zweiten Falle nicht.
warum wirft der validator das Handtuch?
Deswegen:
The error was: utf8 "\xB5" does not map to Unicode
Ah, ISO-8859-1-codiertes U+00B5.
Und was bewegt den Browser (FF, IE) dazu, die windows-Codepage anzuziehen?
Niemand bewegt in der Hinsicht irgend jemanden.
Die Browser versuchen es als UTF-8 zu interpretieren, wie du angegeben hast.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hi,
Also, wenn die Oktetten stimmen,
Tun sie im zweiten Falle nicht.
warum wirft der validator das Handtuch?
Deswegen:The error was: utf8 "\xB5" does not map to Unicode
Ahh, jetzt isses klar. Da fehlt ein Byte, gesendet wird nur die Oktette B5. Gebraucht werden jedoch die Oktetten C2 B5. Also serverseitiges Probläm.
Niemand bewegt in der Hinsicht irgend jemanden.
Browser und Validator manuell auf windows-1252 umgeschaltet...
Die Browser versuchen es als UTF-8 zu interpretieren, wie du angegeben hast.
Sollnse auch, header stimmt ;)
Hotti
-
-
@@hotti:
nuqneH
Ah, ISO-8859-1-codiertes U+00B5.
Ne, windows-1252, mit dieser Codierung wirds jedenfalls richtig angezeigt.
Die Unterschiede zwischen ISO 8859-1 und windows-1252 sind dir immer noch nicht klar?
Tipp: In xB5 unterscheiden sie sich nicht.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
moin,
Ah, ISO-8859-1-codiertes U+00B5.
Ne, windows-1252, mit dieser Codierung wirds jedenfalls richtig angezeigt.
Die Unterschiede zwischen ISO 8859-1 und windows-1252 sind dir immer noch nicht klar?
Tipp: In xB5 unterscheiden sie sich nicht.Richtig! In diesem Fall 'B5'. Beim Euro jedoch nicht ;)
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
-
-
-
-
-
@@hotti:
nuqneH
Wenn jemand eine Idee hat, bitte melden.
Bist du nicht schon lange genug hier um wer weiß wie oft gehört zu haben, dass serverseitiger Code bei einem clientseitigen Problem nicht weiterhilft? Der Schluss, dass dies auch andersrum der Fall ist, sollte von dir doch zu erwarten sein.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
moin,
Wenn jemand eine Idee hat, bitte melden.
Bist du nicht schon lange genug hier um wer weiß wie oft gehört zu haben, dass serverseitiger Code bei einem clientseitigen Problem nicht weiterhilft? Der Schluss, dass dies auch andersrum der Fall ist, sollte von dir doch zu erwarten sein.
Fest steht seit gestern abend: Es ist ein serverseitiges Problem. Die Perlfunktion pack() erzeugt aus irgendeinem Grund nicht die richtigen UTF-8 Bytes aus dem Codepoint, welcher 100%ig richtig ist. Der Bug tritt sporadisch auf.
Schönen Tag,
Hotti-
Hi,
Die Perlfunktion pack() erzeugt aus irgendeinem Grund nicht die richtigen UTF-8 Bytes aus dem Codepoint, welcher 100%ig richtig ist.
pack "U0U, $codepoint;
Was enthält denn $codepoint genau und welchen Datentyp hat es?
Wieso verwendest du U0U und nicht einfach U als Template?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hi ChrisB,
danke der Nachfrage ;)
Die Perlfunktion pack() erzeugt aus irgendeinem Grund nicht die richtigen UTF-8 Bytes aus dem Codepoint, welcher 100%ig richtig ist.
pack "U0U, $codepoint;
Was enthält denn $codepoint genau und welchen Datentyp hat es?$codepoint hat hier einen numerischen Wert in dezimal.
Wieso verwendest du U0U und nicht einfach U als Template?
Aufgrund einer Empfehlung in der perldoc (Prefix "U0"). Es ist so, dass Template "U" nicht plattformübergreifend mit allen Perlversionen funktioniert, hinsichtlich Unicodeunterstützung hat halt auch Perl seine Geschichte.
Das Verzwickte ist, dass offensichtlich auch Template "U0U" manchmal nicht die richtigen Bytes liefert, beim µ kommen aus mir unbekannten Gründen manchmal die richtigen Bytes, manchmal eben nicht, obwohl der Code derselbe ist, der Codepoint stimmt (siehe NCR) und auch die Darstellung der Oktetten die zwei richtigen Bytes zeigt. Der Fehler ist schwer zu finden und liegt serverseitig nach meinem letzten Test. Ich habe das ersteinmal zurückgestellt und schicke bis zur Lösung des Problems NCRs.
Hotti
-
-
-
-
Hi.
Perlfuntion pack "U0U, $codepoit;
Nur um ganz sicher zu gehen: am fehlenden „n“ (oder einem sonstigen Vertipper im Quälcode) liegt es aber nicht?
Schönen Sonntag noch!
O'Brien--
Frank und Buster: "Heya, wir sind hier um zu helfen!"-
Hi.
Perlfuntion pack "U0U, $codepoit;
Nur um ganz sicher zu gehen: am fehlenden „n“ (oder einem sonstigen Vertipper im Quälcode) liegt es aber nicht?
Nun, nachdem ich auf dem CGI die utf-8-Oktettenanzeige (danke ChrisB) eingebaut habe und feststelle, dass die pack()-Funktion richtig arbeitet, muss ich daraus folgern, dass serverseitig alles OK ist. Jetzt bin ich total confusioniert ;)
Indes keinen Schritt weiter in der Hinsicht. Das Script tut vorerst mit numerischen Zeichenreferenzen als WorkAround (das Kamel).
Hotti
-