Hallo,
ich schreibe gerade einen kleinen Keyboard Simulator und habe jetzt
festgestellt, dass Windows 7 und Windows 10 offenbar unterschiedliche
Zeichensätze für Unicode Chars haben.
Eigentlich dachte ich, dass Unicode einheitlich sei?
Also, dass z. B. 0x2661 (Kartenspiel Herz-Symbol in hell) immer gleich
aussieht.
Leider ist dem nicht so. Unter Windows 10 erhalte ich mein Herz. Unter
Windows 7 aber nicht.
Ausserdem kann offenbar Windows 10 die Smileys (Unicode > 0xFFFF)
anzeigen. Bei Windows 7 erhalte ich nur sowas: [].
Hat da jemand eigene Erfahrungen gemacht?
Gruß Sammy D.J.
Sammy D.J. schrieb:> Eigentlich dachte ich, dass Unicode einheitlich sei?
Ist es. Aber damit die infantilen "Emoticons" funktionieren, muss es das
OS unterstützen. Windows 7 macht das halt nicht.
Andere Zeichen funktionieren, /wenn sie in der verwendeten Schriftart
enthalten sind/. Nicht jede mit Windows mitgelieferte Schriftart enthält
den vollständigen Unicode-Zeichensatz.
Rufus Τ. F. schrieb:> Windows 7 macht das halt nicht.
?!
Welche Zeichen werden von Windows 7 unterdrückt, wenn sie - wie Du
schreibst - in der verwendeten Schriftart enthalten sind?
Rufus Τ. F. schrieb:> Nicht jede mit Windows mitgelieferte Schriftart enthält> den vollständigen Unicode-Zeichensatz.
Bisher enthält keine Schriftart den vollständigen Zeichensatz.
Rufus Τ. F. schrieb:> Ist es. Aber damit die infantilen "Emoticons" funktionieren, muss es das> OS unterstützen. Windows 7 macht das halt nicht.
In dem Fall kann ich dann die Fehlersuche einstellen. Allerdings hätte
ich gedacht, dass sowas per Patch dann nachgeliefert wird.
T.roll schrieb:> Bisher enthält keine Schriftart den vollständigen Zeichensatz.
Ich hätte auch gedacht, wenn man sich schon die Mühe macht und
hunderttausende Zeichen katalogisiert und ausarbeitet, dass man dann so
schlau ist, und alle einfach in eine Datei überträgt, die universell
lesbar ist. Dann kann man das Ganze auch einfach per Kopie auf jedem
Rechner und OS installieren (und eben auch als Patch nachliefern).
Gruß Sammy D.J.
Sammy D.J. schrieb:> Ich hätte auch gedacht, wenn man sich schon die Mühe macht und> hunderttausende Zeichen katalogisiert und ausarbeitet, dass man dann so> schlau ist, und alle einfach in eine Datei überträgt, die universell> lesbar ist.
Du scheint das Konzept der Schriftarten ("Font") nicht verstanden zu
haben. Da reicht nicht eine Datei.
Rufus Τ. F. schrieb:> Du scheint das Konzept der Schriftarten ("Font") nicht verstanden zu> haben. Da reicht nicht eine Datei.
Du hast nicht verstanden, was ich damit sagen wollte:
Wenn man sich die Mühe macht, und jedem erdenklichen Zeichen genau einen
Zahlencode zuordnet, damit dann auch auf jedem PC immer das gleiche
Zeichen erscheint, dann bringt das nur was, wenn auch die entsprechenden
Zeichen von Haus aus auf jedem PC installiert sind. Denn sonst bleibt
das Alles nur graue Theorie.
In der Regel reicht es, dass die Vereinigungsmenge aller Glyphen aus
allen installierten Fonts die UniCodes möglichst weitgehend abdeckt.
Die Applikationen wie Browser oder Office-Tools suchen sich die Glyphen
aus einem möglichst ähnlichen Font.
Somit ist die Idee von Klaus eigentlich gelebte Praxis.
Unter Windows kann man Quivira oder Symbola für U+1F600–U+1F64F
(Emoticons) installieren, siehe z.B.
http://www.alanwood.net/unicode/fontsbyrange.html
> damit dann auch auf jedem PC immer das gleiche> Zeichen erscheint, dann bringt das nur was, wenn auch die entsprechenden> Zeichen von Haus aus auf jedem PC installiert sind. Denn sonst bleibt> das Alles nur graue Theorie.> offenbar unterschiedliche> Zeichensätze für Unicode Chars haben.>> Eigentlich dachte ich, dass Unicode einheitlich sei?>> Also, dass z. B. 0x2661 (Kartenspiel Herz-Symbol in hell) immer gleich> aussieht.
Das ist nicht die Idee von Unicode. Unicode ordnet einem abstrakten
Zeichen eine Nummer zu, sonst nichts. Wie das Zeichen dargestellt wird,
hängt von der Schriftart und der Rendering-Engine ab. Das ist für das
kleine "a" nicht anders als für das Kartenspiel-Symbol oder irgendwelche
Emoticons.
Sammy D.J. schrieb:
>Ausserdem kann offenbar Windows 10 die Smileys (Unicode > 0xFFFF)>anzeigen. Bei Windows 7 erhalte ich nur sowas: [].
Kann Win7 überhaupt mehr als UCS-2 bzw UTF16? Also mehr als
16bit-Zeichen?
Jens G. schrieb:> Kann Win7 überhaupt mehr als UCS-2 bzw UTF16? Also mehr als> 16bit-Zeichen?
UTF-16 hat die Möglichkeit, Zeichencodes mit mehr als 16 Bit mit Hilfe
mehrerer 16-Bit-Werte zu kodieren: https://de.wikipedia.org/wiki/UTF-16
Was aber nicht impliziert, dass alle Programme (oder alle Poster hier)
den Unterschied zwischen UCS-2 und UTF-16 kennen ...
@Sven B. (scummos)
>UCS2 ist eine Kodierung für Unicode. Wie jede andere Kodierung für>Unicode kann UCS2 den kompletten Unicode-Zeichensatz darstellen ...
Nein - nur die ersten 0xFFFF Zeichen. Unicode ist inzwischen weiter als
nur 0xFFFF.
@ Clemens L. (c_l)
>Jens G. schrieb:>> Kann Win7 überhaupt mehr als UCS-2 bzw UTF16? Also mehr als>> 16bit-Zeichen?>UTF-16 hat die Möglichkeit, Zeichencodes mit mehr als 16 Bit mit Hilfe>mehrerer 16-Bit-Werte zu kodieren: https://de.wikipedia.org/wiki/UTF-16
Ja. Aber benutzt Win7 UTF16? Eigentlich war es UCS-2, womit Windows (ab
WiNT, vielleicht auch schon Win95) groß geworden ist.
>Was nicht bedeutet, dass alle Programme den Unterschied zwischen UCS-2>und UTF-16 kennen ...
Solange die keine 16bit-Zeichen verwenden, die ein Multi-16bit-Zeichen
markieren, ist das auch erstmal kein Problem ;-)
@Torsten C. (torsten_c) Benutzerseite
>Jens G. schrieb:>> Kann Win7 überhaupt mehr als … 16bit-Zeichen?>Hast Du "UnicodeWin7.png" oben gesehen?
Ok, dann isses wohl UTF16.
Nicht der Wert selbst ist UTF16 (der Wert ist nur die Nummer des
Unicodezeichens), sondern Win7 scheint damit wohl UTF16 zu benutzen,
wenn es ein solches Unicodezeichen >U+FFFF handlen kann. UCS2 (was in
früheren Windowsversionen wohl benutzt wurde) könnte das eigentlich
nicht, da das normalerweise ein reiner Single-16bit-Code ist.
Jens G. schrieb:> Nicht der Wert selbst ist UTF16 (der Wert ist nur die Nummer des> Unicodezeichens), sondern Win7 scheint damit wohl UTF16 zu benutzen,> wenn es ein solches Unicodezeichen >U+FFFF handlen kann. UCS2 (was in> früheren Windowsversionen wohl benutzt wurde) könnte das eigentlich> nicht, da das normalerweise ein reiner Single-16bit-Code ist.
Alle Windows Versionen nehmen UTF16 Zeichen für Unicode > 0xFFFF. Dem
geht dann aber eine Wandlung des zu großen Zahlenwertes vorraus, so dass
zwei 16 Bit Werte entstehen - das nennt sich Surrogate Pair. Nach der
Umwandlung werden statt einem Wert eben zwei Werte nacheinander
gesendet.
Sammy D.J. schrieb:> … habe jetzt festgestellt, dass Windows 7 und Windows 10 offenbar> unterschiedliche Zeichensätze für Unicode Chars haben.
Nur 18 Beiträge später kommt die Auflösung vom TE selbst,
dass unter Win 7 'Surrogate Pairs' verwendet werden.
Ich erinnere mich, dass diese bei VBA nötig sind,
aber dass das mit Win 7 zu tun hat: Wieder was gelernt. :-) Danke.
Das dürfte von eher historischem Interesse sein, da die letzte sich
"Windows NT" nennende Version von Windows NT* schon 1996 herauskam.
*) alle nachfolgenden Versionen von Windows NT nennen sich nicht mehr
so, sondern verwenden das sehr konsistente Namensschema
2000->XP->Vista->7->8->10
Torsten C. schrieb:> Nur 18 Beiträge später kommt die Auflösung vom TE selbst,> dass unter Win 7 'Surrogate Pairs' verwendet werden.
Da hast Du mich falsch verstanden. Bei Windows 10 musst Du das genauso
machen. Ich wollte lediglich damit sagen, dass bei Werten > 0xFFFF
prinzipiell eben zwei Werte < 0XFFFF gesendet werden müssen - egal
welches Windows. Und die notwendige Umrechnung erfolgt eben über dieses
Surrogate Pair.
Das war auch nicht die Fragestellung, die da lautete: Warum gehts bei
Windows 10 und Windows 7 nicht?
Aber das ist ja jetzt auch beantwortet: Nur wenn auch der Zeichensatz
auf dem Betriebssystem installiert ist, kann auch was angezeigt werden.
Und da gibt es offenbar Unterschiede zwischen 7 und 10.
Rufus Τ. F. schrieb:> verwenden das sehr konsistente Namensschema> 2000->XP->Vista->7->8->10
Da kann ich Dir nur Recht geben: Wirklich sehr konsistent^^
Gruß Sammy D.J.
