nicht angemeldet
Utf-8 Unicode
Hallo,
stimmt meine Sichtweise so:
Zeichenkodierung, zb. UTF-8 = vereinfacht gesagt eine Kodierngsverfahren, welches konktrete Bytewerte auf Codepoints mapped
(zb. den Bytewert c2 b7 auf die Unicode-Kodierung U+00B7)
Zeichensatz, z.b. Unicode = eine Menge von Zeichen (Zeichenvorrat), der einem bestimmten Zweck dienlich ist. Zum Beispiel die Menge aller von Menschen gesprochenen Sprachen (Unicode) oder die Menge aller westeuropäischen Sprachen (Latin = Iso8859-1).
Frage:
wie ist hier die Schriftart zu sehen (z.b. Arial) und wie wird diese intern in einem Computersystem mit dem konkreten Bytewert verknüpft? Geschieht das auch über die Zeichenkodierung?
-
Hallo,
Frage:
wie ist hier die Schriftart zu sehen (z.b. Arial) und wie wird diese intern in einem Computersystem mit dem konkreten Bytewert verknüpft? Geschieht das auch über die Zeichenkodierung?ah, seh schon. Passiert über den Bytewert und die interne Zuweisung zu einer Schriftart*. Gut, dann ist das schonmal klar.
*Weiß jemand, wie das geschieht? Passiert das über einen definierten Wert? Hat jede Schriftart eine eindeutige ID? Einen eindeutigen Namen hat sie ja, also wird es darüber laufen, schätze ich.
-
Tach!
Zeichenkodierung, zb. UTF-8 = vereinfacht gesagt eine Kodierngsverfahren, welches konktrete Bytewerte auf Codepoints mapped
(zb. den Bytewert c2 b7 auf die Unicode-Kodierung U+00B7)Bei Unicode spricht man vom Codepoint, wie du ja schon gesagt hast. Das Wort Unicode-Kodierung dafür zu verwenden, führt eher zu Verwirrung. Die Codepoints sind im Prinzip nur theoretische Nummern. Für praktische Anwendbarkeit muss man sie in eine computerlesbare Form bringen, das geschieht durch eine der Unicode-Kodierungen UTF-x. Diese legen fest, wie der Codepoint durch Bytes (oder penibler: Oktetts) repräsentiert wird.
wie ist hier die Schriftart zu sehen (z.b. Arial) und wie wird diese intern in einem Computersystem mit dem konkreten Bytewert verknüpft? Geschieht das auch über die Zeichenkodierung?
Das ist vom internen Aufbau der Schriftart abhängig (Dateiformat). Sinnvoll ist es, etwas Unicode-basierendes zu verwenden. Aber bevor Unicode ansetzte, die Welt zu erobern, gab es auch schon Schriftarten(dateien), und da wird sicherlich irgendein anderes Kodierungs-/Nummerierungssystem verwendet worden sein.
ah, seh schon. Passiert über den Bytewert und die interne Zuweisung zu einer Schriftart*. Gut, dann ist das schonmal klar.
*Weiß jemand, wie das geschieht? Passiert das über einen definierten Wert? Hat jede Schriftart eine eindeutige ID? Einen eindeutigen Namen hat sie ja, also wird es darüber laufen, schätze ich.Als Programmierer kommt man nur mit den Font-Namen in Berührung. Ob da systemintern noch etwas umgesetzt wird, ist mir nicht bekannt und auf meiner Ebene auch nicht weiter wichtig. Weiter muss das Betriebssystem von selbst wissen, wenn es eine Zeichenfolge auf den Schirm malen soll, wie diese konkret kodiert ist. Üblicherweise geht das aus den Parametern der anzusprechenden Funktionen hervor, welche Kodierung übergeben werden muss.
Im Übrigen haben wir im Wiki einen Themenkomplex Zeichenkodierung beschäftigt. In der Einleitung dazu sind auch die Begrifflichkeiten erklärt. Schau doch mal, ob das jetzt mit deinem Wissen übereinstimmt.
dedlfix.
-
Hi,
Im Übrigen haben wir im Wiki einen Themenkomplex Zeichenkodierung beschäftigt. In der Einleitung dazu sind auch die Begrifflichkeiten erklärt. Schau doch mal, ob das jetzt mit deinem Wissen übereinstimmt.
ah, super, danke. Dann sind die restlichen 5% Unklarheit auch noch (fast) beseitigt.
-
-
-
eine Kodierngsverfahren, welches konktrete Bytewerte auf Codepoints mapped
Und umgekehrt, korrekt.
Zeichensatz, z.b. Unicode = eine Menge von Zeichen (Zeichenvorrat), der einem bestimmten Zweck dienlich ist.
Der Zeichenvorrat ist nur *ein* Bestandteil von Unicode. Da stecken noch viele Regeln zur Textverarbeitung drin.
Zum Beispiel die Menge aller von Menschen gesprochenen Sprachen (Unicode)
Nein, der Zeichenvorrat behandelt Schriften, nicht Sprachen.
wie ist hier die Schriftart zu sehen (z.b. Arial) und wie wird diese intern in einem Computersystem mit dem konkreten Bytewert verknüpft?
So war es früher. Verknüpfung mit bloßen Bytewerten ist mit der Ankunft von Unicode aus der Mode gekommen.
Geschieht das auch über die Zeichenkodierung?
Nein, für die Umwandlung von abstrakten Unicodetext zu konkreten Glyphen sorgen Anwendung (z.B. Calligra), Renderingsystem (z.B. FreeType) und Toolkit (z.B. Qt). Das ist eine sehr komplexe Angelegenheit. Das Thema wird besser einleuchten, wenn du mal selber eine OpenType-Schriftart erstellst.
-
Moin,
ein Zeichensatz beschreibt die äußere Form, also wie etwas dargestellt wird (optisch). Unicode ansich definiert die Bedeutung eines bestimmten Wertes in der Unicode-Tabelle, also wofür dieser dort in der natürlichen Sprache steht. Die UTF-Geschichten dienen der Transformation der "Unicode-Daten". So bildet UTF-8 diese Codepoints aus der Unicode-Tabelle auf einen Octett-Stream ab. Dieser hat wiederum eine bestimmte Bedeutung, die bei der Interpretation zu beachten ist.
Unicode im allgemeinen Gebrauch ist auf ~1 Mio Zeichen begrenzt. Diese Restriktion hat auch was mit den ganzen Transformationen zu tun, um ein gewisses Maß an Integration zu gewährleisten (UTF-8, UTF-16). Neben UTF wird dir auch noch UCS ins Auge gesprungen sein, das liegt an den zwei Instanzen, die sich für Unicode-Definitionen zuständig fühlen.
Bei Windows-Systemen triffst du häufig auf UTF-16, Bei Unix-Systemen auf UTF-32/UTF-8, und im Internet häufig auf UTF-8. Der Grund hierfür sind die bereitgestellten APIs der unterschiedlichen Systeme. UTF-8 eignet sich besonders für die Übermittlung von Unicode-Daten, da man hier nicht auf eine mögliche Byte-Order achten muss.
Ab Visual Studio 2013 wird übrigens auf Multibyte-Strings verzichtet, dass ist eine spezielle Form von Kodierung auf Windows-Systemen.
-
Tach!
ein Zeichensatz beschreibt die äußere Form, also wie etwas dargestellt wird (optisch).
Nö, das ist im Font geregelt. Ein Zeichensatz sagt nur aus, welche Zeichen enthalten sind. Ob es konkret auf dem Bildschirm ohne Schnörkel oder mit Serifen oder sonstwie dargestellt wird, ist Sache der Schriftart. Die Font-Datei enthält nun zu einer mehr oder weniger großen Menge von Zeichen die technischen Informationen, wie es auf den Bildschirm (oder Druckerpapier) zu malen ist.
Ein Zeichen hat allerdings implizit eine gewisse Form, sonst könnte man es nicht als solches erkennen. Das nützt aber einem Computer nicht viel, der braucht irgendwelche Daten zu diesem Zeichen. Und davon gibt es eine Menge unterschiedlicher Arten, je nachdem, was man tun will (Datenverarbeitung, Zeichen auf Bildschirm bringen, optische Darstellung von Zeichen erkennen, was auch immer).
Unicode im allgemeinen Gebrauch ist auf ~1 Mio Zeichen begrenzt. Diese Restriktion hat auch was mit den ganzen Transformationen zu tun, um ein gewisses Maß an Integration zu gewährleisten (UTF-8, UTF-16).
Welchen praktischen Gebrauch meinst du? Könntest du etwas konkreter erklären, was das bedeutet?
Neben UTF wird dir auch noch UCS ins Auge gesprungen sein, das liegt an den zwei Instanzen, die sich für Unicode-Definitionen zuständig fühlen.
Ja, kann man aber vernachlässigen.
Bei Windows-Systemen triffst du häufig auf UTF-16, Bei Unix-Systemen auf UTF-32/UTF-8, und im Internet häufig auf UTF-8. Der Grund hierfür sind die bereitgestellten APIs der unterschiedlichen Systeme. UTF-8 eignet sich besonders für die Übermittlung von Unicode-Daten, da man hier nicht auf eine mögliche Byte-Order achten muss.
Und vor allem, weil es kompatibel zu ASCII ist, und man so wenigstens auf lateinischen Buchstaben basierende Texte größtenteils lesen kann.
Ab Visual Studio 2013 wird übrigens auf Multibyte-Strings verzichtet, dass ist eine spezielle Form von Kodierung auf Windows-Systemen.
Meinst du MBCS (Multibyte Character Sets)? Nun, da muss man zu Verständnis dieses Satzes etwas weiter ausholen. Systeme mit mehr als 256 Zeichen (zum Beispiel Chinesisch und Japanisch) benötigen logischerweise auch mehr als 256 Möglichkeiten, kommen also mit 1-Byte-Kodierungen nicht aus. Deswegen haben sich neben den für die (w/r)estliche Welt spezialisierten 1-Byte-Zeichenkodierungen auch asiatische Pendants mit mehr als 1 Byte pro Zeichen gebildet. Die Unterstützung für diese ist allerdings gemäß http://msdn.microsoft.com/en-us/library/vstudio/5z097dxa(v=vs.120).aspx nicht eingestellt sondern nur in ein Add-On verschoben worden. Da es sich um MFC-Bibliotheken handelt, betrifft das im Prinzip auch nur "herkömmliche" Programme, für .NET war ja schon immer Unicode die Grundlage.
dedlfix.
-
Moin dedlfix,
Unicode im allgemeinen Gebrauch ist auf ~1 Mio Zeichen begrenzt. Diese Restriktion hat auch was mit den ganzen Transformationen zu tun, um ein gewisses Maß an Integration zu gewährleisten (UTF-8, UTF-16).
Welchen praktischen Gebrauch meinst du? Könntest du etwas konkreter erklären, was das bedeutet?
Anders gesagt, für allgemein gebräuchliche Zeichen reichen ~1 Mio aus. Aus rein technischer Sicht könnte Unicode mehr definieren.
siehe auch http://www.unicode.org/faq/utf_bom.html
Ab Visual Studio 2013 wird übrigens auf Multibyte-Strings verzichtet, dass ist eine spezielle Form von Kodierung auf Windows-Systemen.
... Die Unterstützung für diese ist allerdings gemäß http://msdn.microsoft.com/en-us/library/vstudio/5z097dxa(v=vs.120).aspx nicht eingestellt sondern nur in ein Add-On verschoben worden.
Wobei ich noch irgendwo gelesen habe, dass sich Projekte damit nicht kompilieren lassen, auch wenn eine entsprechende Option in den Projekteinstellungen noch vorhanden ist. Eine Unterstüztung heißt ja auch erstmal, dass man "irgenwas" damit noch machen kann. Zum Beispiel das Einlesen von Daten die auf MBCS beruhen.
Da es sich um MFC-Bibliotheken handelt, betrifft das im Prinzip auch nur "herkömmliche" Programme, für .NET war ja schon immer Unicode die Grundlage.
Für Windows auch. Sofern ich mich recht erinnere, beruht der Windows Kernel ab NT auf UCS2 (also der BMP) und später auf UTF-16. Ob die Daten allerdings wirklich korrekt sind, wird erst bei der Darstellung selbiger überprüft (wenn überhaupt). Die String-Routinen auf nativem C++ waren aber auch schon immer ... bescheiden.
-
-