Diskussion:Unicode

aus Wikipedia, der freien Enzyklopädie

Symbole, diakritische Zeichen,Sonderzeichen, fremde Zeichen:

090: Z 091: [ 092: 093: ] 094: ^ 095: _ 096: ` 097: a 098: b 099: c

100: d 101: e 102: f 103: g 104: h 105: i 106: j 107: k 108: l 109: m

110: n 111: o 112: p 113: q 114: r 115: s 116: t 117: u 118: v 119: w

120: x 121: y 122: z 123: { 124: | 125: } 126: ~ 127:  128: € 129: 

130: ‚ 131: ƒ 132: „ 133: … 134: † 135: ‡ 136: ˆ 137: ‰ 138: Š 139: ‹

140: Œ 141:  142: Ž 143:  144:  145: ‘ 146: ’ 147: “ 148: ” 149: •

150: – 151: — 152: ˜ 153: ™ 154: š 155: › 156: œ 157:  158: ž 159: Ÿ

160: 161: ¡ 162: ¢ 163: £ 164: ¤ 165: ¥ 166: ¦ 167: § 168: ¨ 169: ©

170: ª 171: « 172: ¬ 173: ­ 174: ® 175: ¯ 176: ° 177: ± 178: ² 179: ³

180: ´ 181: µ 182: ¶ 183: · 184: ¸ 185: ¹ 186: º 187: » 188: ¼ 189: ½

190: ¾ 191: ¿ 192: À 193: Á 194: Â 195: Ã 196: Ä 197: Å 198: Æ 199: Ç

200: È 201: É 202: Ê 203: Ë 204: Ì 205: Í 206: Î 207: Ï 208: Ð 209: Ñ

210: Ò 211: Ó 212: Ô 213: Õ 214: Ö 215: × 216: Ø 217: Ù 218: Ú 219: Û

220: Ü 221: Ý 222: Þ 223: ß 224: à 225: á 226: â 227: ã 228: ä 229: å

230: æ 231: ç 232: è 233: é 234: ê 235: ë 236: ì 237: í 238: î 239: ï

240: ð 241: ñ 242: ò 243: ó 244: ô 245: õ 246: ö 247: ÷ 248: ø 249: ù

250: ú 251: û 252: ü 253: ý 254: þ 255: ÿ 256: Ā 257: ā 258: Ă 259: ă

260: Ą ą Ć ć Ĉ ĉ Ċ ċ Č č

270: Ď ď Đ đ Ē ē Ĕ ĕ Ė ė

280: Ę ę Ě ě Ĝ ĝ Ğ ğ Ġ ġ

290: Ģ ģ Ĥ ĥ Ħ ħ Ĩ ĩ Ī ī

300: Ĭ ĭ Į į İ ı IJ ij Ĵ ĵ

310: Ķ ķ ĸ Ĺ ĺ Ļ ļ Ľ ľ Ŀ

320: ŀ Ł ł Ń ń Ņ Ņ Ň ň ʼn

330: Ŋ ŋ Ō ō Ŏ ŏ Ő ő Œ œ

340: Ŕ ŕ Ŗ ŗ Ř ř Ś ś Ŝ ŝ

350: Ş ş Š š Ţ ţ Ť ť Ŧ ŧ

360: Ũ ũ Ū ū Ŭ ŭ Ů ů Ű ű

370: Ų ų Ŵ ŵ Ŷ ŷ Ÿ Ź ź Ż

380: ż Ž ž ſ ƀ Ɓ Ƃ ƃ Ƅ ƅ

390: Ɔ Ƈ ƈ Ɖ Ɗ Ƌ ƌ ƍ Ǝ Ə

und ff ;-) Ilja

---

Die ersten 128 Zeichen entsprechen dem ASCII-Zeichensatz.

Trifft das auch auf UTF-16 zu? AFAIK nicht. --Head 12:17, 15. Okt 2003 (CEST)

Das hat nichts damit zu tun, welches Transformation Format man benützt. Unicode ordnet bestimmten Nummern Glyphen zu. U0001 bis U0079 entsprechen den ASCII Zeichen. Die Darstellung in einem Transformation-Format sieht i.A. anders aus. --Hokanomono 15:36, 23. Okt 2003 (CEST)

Inhaltsverzeichnis 1 Code Points 2 Eingabemethoden 3 (mit leerzei... 4 Wieviele Zeichen? 5 Review: Unicode, 13. Dezember 6 Auf dem Weg zur Exzellenz? 7 Eigene Seite Codeblöcke 8 Quadrate 9 Was noch fehlt 10 Schriftart 11 Altgriechisch mit Unicode 11.1 Altgriechisch mit Unicode 12 Fraktur-Zwangsligaturen 13 Digraphen 14 Griechisch und Kyrillisch 15 Noncharacters 16 Programmierung 17 Verständlichkeit des Artikels 18 Implementierung 19 Kann mir jemand kurz und klar erklären... 20 Kombinationszeichen (Combining characters) 21 Unicodeeingabe bei GNOME

[Bearbeiten] Code Points

Der Artikel zu Unicode sagt nichts über Code Points aus, die aber ein essentielles Konzept des Standards sind.

Kann Unicode auch Zeichen aus dem Vietnamesischen, mit zwei diakritischen Zeichen darstellen? --Jan G 08:08, 5. Mai 2004 (CEST)

Aber selbstvverständlich. Für Vietnamesisch stehen kombinierte Zeichen in U+1E00 - U+1EFF zur Verfügung. Zum Stapeln beliebiger Diakritika braucht man OpenType, sollte in M$-Office klappen. - J

[Bearbeiten] Eingabemethoden

Wozu die Anleitung für "VI Improved"? Das ist was für die Doku des Programmes, wegen mir auch was für den "VI Improved" Wiki Eintrag, hat aber doch auf der Unicode-Seite nichts verloren! Wo kommen wir hin, wenn jeder beschreibt, wie man in diesem oder jenem Programm/Betriebssystem Unicode-Zeichen eingeben kann! Dors 14:02, 19. Mai 2004 (CEST)

Ich habe einen Artikel zu Codepoint verfasst. Ich hoffe ergefällt euch. --Lemmi04 12:29, 6. Dez 2004 (CET)

Hoffentlich gefällt Dir meine erweiterte einzeilige Fassung. - J

Ich wäre dafür, die Eingabemethoden (vim und andere) in Kurzform drinzulassen. Emacs habe ich eben mal berichtigt (es heißt M-x, nicht M-c, das ALT statt META habe ich aus populistischen Gründen stehenlassen, und der Befehl heißt ucs-insert und will hex). Eventuell ging es auch schon in 21.3, was ich übersprang, aber egal ist - 21.4 ist seit Februar draußen. Die Überschrift (Eingabemethoden) habe ich hier in die Diskussion gepackt. --Ralf Muschall 21:40, 28. Jul 2005 (CEST)

Nachtrag: In OOO fehlt bisher die Möglichkeit, Unicode einfach einzugeben (Alt festhalten und Nummer eingeben funktioniert nicht, Nummer (hex) eingeben und Alt-x auch nicht (abgesehen davon ist Alt-x bereits durch den Menüpunkt "Extras" belegt). Folgendes Macro geht, würde aber den Artikel nun wirklich überlasten:

sub ucsinsert
dim cursor as Object
dim tc as Object
dim s as string
cursor=ThisComponent.getCurrentController.viewcursor
tc=ThisComponent.Text.createtextcursor()
tc.gotoRange(cursor,False)
tc.goLeft(4,True)
s=tc.getString
tc.setstring(chr(clng("&H"+s)))
end sub

Das Macro nimmt die letzten genau 4 Zeichen, interpretiert sie als Hexzahl und ersetzt sie durch das Zeichen mit dem entsprechenden Codepoint.

Ich denke, es ist Zeit für einen ausgelagerten Artikel Unicode-Eingabemethoden, der das alles sammelt.

Bei Vim habe ich gleich noch digraph erwähnt. --Ralf Muschall 17:12:17, 29. Jul 2005 (CEST)

[Bearbeiten] (mit leerzei...

[Bearbeiten] Wieviele Zeichen?

Im Artikel steht "Nunmehr ist der Standard für 1.114.112 (= 2^20+2^16) Zeichen ausgelegt." 1.114.112=2^20. 2^20+2^16 =68719476736. Was stimmt nun?

Du kannst nicht rechnen. Frag Google:

http://www.google.de/search?hl=de&q=2%5E20&btnG=Suche&meta=

http://www.google.de/search?hl=de&q=2%5E20%2B2%5E16&btnG=Google-Suche&meta=

Pjacobi 14:32, 16. Nov 2004 (CET)

[Bearbeiten] Review: Unicode, 13. Dezember

Von Benutzer:Lemmi04 auf der Hauptseite eingetragen. --slg 20:28, 13. Dez 2004 (CET)

Ein Thema das mir am Herzen liegt, das aber notorisch schwierig zu behandeln ist. Der Artikel weist leider boch zahlreiche Ungenauigkeiten und Schwachstellen auf, ich hoffe einige davon beseitigen zu können.

• Geschichte kommt zweimal vor, in der Einleitung ein wenig Geschichte von Unicode, weiter unten Geschichte von Zeichenkodierungen allgemein.
• Das Verhältnis von ISO und Unicode scheint mir nicht ganz richtig dargestellt zu sein.
• Die Liste der Schriften ist sehr unvollständig, und sollte vielleicht augelagert werden.
• Wenn man sich die Listen, Weblinks und den HowTo-Abschnitt "Anwendung der Tabellen" wegdenkt, bleibt wenig Substanz, insbesondere werden eigentlich alle komplizierten Fragen ausgelassen.

Pjacobi 21:21, 13. Dez 2004 (CET)

Ich gebe mir ebenfalls Mühe, den Artikel nach und nach zu verbessern. Leider habe ich nicht die Muße, mich mal einen ganzen Tag dranzusetzen. Das Thema ist recht komplex, und eine Reduzierung auf einen angemessenen Umfang ist ein recht schwieriges Unterfangen, zumindest, wenn das Thema allgemeinverständlich abgehandelt werden soll. Hieran hapert es in weiten Teilen ganz besonders.

Essenziell wäre vornehmlich noch die Erklärung des Unterschieds Character - Glyph und der verschiedenen Kodierungen, UTF8, -16 und-32. Beim gegenwärtigen Aufbau des Artikels wüßte ich nicht, wohin damit. Die Rudi Mentäre (Otto Graf Vieh an die neudeutsche Reformschreibweise angelehnt) Auflistung von Codebereichen halte ich für verzichtbar.

Jirret

Ich stimme meinem Vorredner zu, die Kodierungsarten sollten erklärt werden. Gibt es keine Literatur zum Thema? Amazon meint, dass es da durchaus etwas gibt. Vielleicht kennt jemand einige davon und kann eins empfehlen. -- Dishayloo [ +] 20:03, 21. Jan 2005 (CET)

Guter Hinweis! Ich füge gleich einen Link zum offiziellen Unicode-Buch ein. --Jirret 16:15, 27. Jan 2005 (CET)

[Bearbeiten] Auf dem Weg zur Exzellenz?

Ich habe jetzt so einiges am Artikel getan. Wesentliches fällt mir im Moment nicht mehr ein, vielleicht noch ein bißchen Kleinkram und ein paar Illustrationen, siehe OpenType. Noch tiefer in die Materie einzusteigen hat meines Erachtens wenig Sinn. Ich habe mich bemüht, einige Aspekte repräsentativ abzuhandeln. Das Unicode-Buch umfaßt schlappe 1500 Seiten, und selbst da steht nicht alles Wichtige drin. Im übrigen bin ich nicht ganz sicher, ob ich alle Leerzeichen gefunden habe. Fehlt da noch was?

0020 SPACE
00A0 NO-BREAK SPACE
2000 EN Quad
2001 EM Quad
2002 EN SPACE
2003 EM SPACE
2004 THREE-PER-EM SPACE
2005 FOUR-PER-EM SPACE
2006 SIX-PER-EM SPACE
2007 FIGURE SPACE
2008 PUNCTUATION SPACE
2009 THIN SPACE
200A HAIR SPACE
200B ZERO WIDTH SPACE
202F NARROW NO-BREAK SPACE
205F MEDIUM MATHEMATICAL SPACE
2060 WORD JOINER
3000 IDEOGRAPHIC SPACE
FEFF ZERO WIDTH NO-BREAK SPACE --Jirret 05:25, 31. Jan 2005 (CET)

[Bearbeiten] Eigene Seite Codeblöcke

Ich bin dabei, eine eigene Seite mit sämtlichen Codeblöcken zu basteln. In diese werden auch Links zu den Charts integriert. Codeblöcke, die zwar definiert sind, bei denen aber die Normierung noch aussteht, werden mit eingebaut und, sofern schon Kodierungsvorschläge auf der ISO-WG 2-Webseite verfügbar sind, siehe Balinesische Schrift, werden die auch verlinkt. Das dürften gut 160 Zeilen werden, die den Hauptartikel meines Erachtens ziemlich verunstalten würden.
--Jirret 04:02, 5. Feb 2005 (CET)

Liste der Unicode Codeblöcke --Pjacobi 13:47, 5. Feb 2005 (CET)

[Bearbeiten] Quadrate

Trotz Decodiercode UTF-8 (MSIE 6.0) erscheinen manche Zeichen als Quadrate - Was tun? Danke! --Matt1971 23:17, 7. Feb 2005 (CET)

Mehr Fonts installieren.

Wenn das noch nicht hilft, Firefox installieren.

Pjacobi 23:29, 7. Feb 2005 (CET)

[Bearbeiten] Was noch fehlt

In ähnlicher Weise wie über die Kodierungskriterien gedenke ich, einen Überblick über das zum Unicode gehörende Regelwerk einzufügen. Das ist ziemlich viel Stoff, und eine vernünftige Auswahl will wohl überlegt sein. Einserseits hat es keinen Zweck, sich in Details zu verlieren, andererseits muß eine angemessen knappe Darstellung ausreichend exakt sein. Vermutlich werde ich im April dazu kommen.

Den Abschnitt „Geschichte“ gedenke ich um die Entstehungsgeschichte des Unicode-Consortiums zu ergänzen und nach Unicode Consortium zu verlagern. --Jirret 18:24, 10. Feb 2005 (CET)

[Bearbeiten] Schriftart

Gibts eigentlich keine kostenlose Unicodeschriftart, die den kompletten chinesischen / japanischen Schriftsatz beinhaltet? Suche verzweifelt danach.

Danke, Abdull

Wenn Du mit "komplett" meinst, einschließlich der Erweiterungen in en:GB 18030 ist es etwas eng. Ansonsten empfehle ich wegen der universellen Nützlichkeit en:TITUS Cyberbit Basic, die Downloadseite ist leider öfter mal überlastet. Weitere Möglichkeiten stehen ausführlich auf Alans Seite http://www.alanwood.net/unicode/fonts.html --Pjacobi 22:25, 19. Mai 2005 (CEST)

[Bearbeiten] Altgriechisch mit Unicode

ich habe den abschnitt in den artikel eingefügt, weil ich die ergebnisse meines "rumprobierens" nutzbar machen wollte. ich hoffe, das ist nicht zu praxisbezogen - wenn ja, kann es ja jemand auf die diskussionsseite stellen. ich denke aber, dass es nicht wenige benutzer gibt, die altgriechische wörter und sätze in der Wikipedia lesen und schreiben wollen. -- NeumonD 17:14, 31. Okt 2005 (CET)

Meiner Meinung gehört die Anleitung wie man Altgriechisch auf dem IE darstellt definitiv nicht hierher. Insbesondere als dass Du hierfuer ISO-8859-7 als Codetabelle benutzt und den IE dazu bringst die als Default zu benutzen. Das hat definitiv nichts mit Unicode zu tun. Im folgenden der originale Absatz. -- anonymous, 2005-12-14

[Bearbeiten] Altgriechisch mit Unicode

Die meisten Unicode-Schriften stellen nur diejenigen Buchstaben und Zeichen dar, die im Neugriechischen Verwendung finden (Unicode-Tabelle "Greek and Coptic" PDF). Es handelt sich um folgende Zeichen:

Α α Ά ά Β β Γ γ Δ δ Ε ε Έ έ Ζ ζ Η η Ή ή Θ θ Ι ι Ί ί Ϊ ϊ ΐ Κ κ Λ λ Μ μ Ν ν Ξ ξ Ο ο Ό ό Π π Ρ ρ Σ σ ς Τ τ Υ υ Ϋ ϋ Ύ ύ ΰ Φ φ Χ χ Ψ ψ Ω ω Ώ ώ ; ·

Die Eingabe dieser Zeichen kann z.B. so erfolgen, dass eine passende Unicode-Schriftart gewählt wird und dann das Tastenlayout auf Griechisch umgestellt wird.

Für das Schreiben und Darstellen altgriechischer Texte werden aber Sonderzeichen benötigt (Unicode-Tabelle "Greek Extended" PDF), die in vielen Unicode-Schriftarten nicht vorhanden sind. In der folgenden Testtabelle finden sich Beispiele – nur das oberste Zeichen gehört zum "normalen" Zeichensatz "Greek".

Zeichen	hexadez. Code	Beschreibung
ώ	03CE	Omega mit Akut
ῶ	1FF6	Omega mit Zirkumflex
ῴ	1FF4	Omega mit Akut und iota subscriptum
ᾦ	1FA6	Omega mit Zirkumflex, spiritus lenis und iota subscriptum

Benötigt werden aber auch die anderen Zeichen, insgesamt mindestens die folgenden:

ἀ ἁ ὰ ᾶ ἂ ἃ ἄ ἅ ἆ ἇ ᾳ ᾀ ᾁ ᾴ ᾲ ᾷ ᾄ ᾅ ᾂ ᾃ ᾆ ᾇ ἐ ἑ ὲ ἔ ἕ ἒ ἓ ἠ ἡ ὴ ῆ ἤ ἢ ἣ ἥ ἦ ἧ ῃ ῄ ῂ ῇ ᾐ ᾑ ᾔ ᾒ ᾕ ᾓ ᾖ ᾗ ἰ ἱ ὶ ῖ ἴ ἲ ἵ ἶ ἷ ὀ ὁ ὄ ὅ ὂ ὃ ὐ ὑ ὺ ῦ ὔ ὕ ὒ ὓ ὖ ὗ ὠ ὡ ὼ ῶ ὤ ὢ ὥ ὣ ὦ ὧ ῴ ῲ ῷ ᾠ ᾡ ᾤ ᾢ ᾥ ᾣ ᾦ ᾧ ` ᾿ ῾ ῍ ῎ ῏ ῟ ῞ ῝ ῍ ῎

Zur Darstellung dieser Zeichen ist möglicherweise eine besondere Einstellung des Internet-Browsers nötig, wenn nicht z. B. mit <FONT face="Palatino Linotype">...</FONT> eine für diese Zeichen geeignete Schriftart festgelegt wurde.

• Windows-Explorer: Unter "Extras" die "Internetoptionen" wählen, dann auf der Registerkarte "Allgemein" unter "Schriftarten" folgende Wahl treffen: "Sprachskript": Lateinischer Stamm; "Schriftart für Webseiten": Palatino-Linotype. Dann unter "Eingabehilfen" ein Häkchen setzen bei: "Schriftartangaben auf Webseiten ignorieren".

[Bearbeiten] Fraktur-Zwangsligaturen

Warum sind die Fraktur-Zwangsligaturen ch, ck und tz nicht im Unicode kodiert? --84.61.58.172 12:14, 18. Feb 2006 (CET)

Warum sollten sie?

Frag das die Leute vom Unicode-Konsortium. Ich nehme an, weil man nicht sämtliche Ligaturen mit aufnehmen wollte, die in irgendwelchen Schriften existieren. --RokerHRO 08:49, 31. Mai 2006 (CEST)

[Bearbeiten] Digraphen

Warum bekam der Digraph ch keinen eigenen Platz im Unicode? --84.61.9.7 10:44, 19. Feb 2006 (CET)

Frag das die Leute vom Unicode-Konsortium. Ich nehme an, weil man nicht sämtliche Ligaturen mit aufnehmen wollte, die in irgendwelchen Schriften existieren. --RokerHRO 08:49, 31. Mai 2006 (CEST)

[Bearbeiten] Griechisch und Kyrillisch

Warum bekamen die griechische Schrift und die kyrillische Schrift getrennte Plätze im Unicode? --84.61.30.195 09:29, 9. Mär 2006 (CET)

Weil es verschiedene Alphabete sind. :-) --RokerHRO 08:49, 31. Mai 2006 (CEST)

[Bearbeiten] Noncharacters

Was ist mit den Kodepunkten U+FDD0-U+FDEF? --84.61.3.13 12:27, 23. Mai 2006 (CEST)

Sie wurden - wie viele andere Codepunkte auch - noch nicht "belegt". Man hat sich also bewusst Raum für spätere Erweiterungen offen gelassen, damit neue Zeichen, oder Zeichen, die man bisher "vergessen" hatte, leicht hinzufügen kann. --RokerHRO 08:49, 31. Mai 2006 (CEST)

[Bearbeiten] Programmierung

Für den Programmierer hat der UTF-8 gegenüber UTF-16 den Vorteil, daß er mit den klassischen mit einem 0 Byte abgeschlossenen Zeichenketten, wie sie in ANSI C verwendet werden, kompatibel ist. Auch braucht man bei der Speicherung in Dateien oder der Kommunikation über Netzwerke keine besonderen Vorkehrungen treffen, da es sich bei UTF-8 lediglich um eine Octet Folge handelt.

Dies kann mit Escape Sequenzen verglichen werden, wie sie schon lange bei Terminals oder Druckern Verwendung finden.

Diesen Absatz würde ich in der nächsten Zeit in den Artikel einfügen, falls niemand Einspruch erhebt.

Lehrig 09:33, 27. Mai 2006 (CEST)

Inwiefern das ein Vorteil gegenüber UTF-16 sein soll, kann ich noch nicht ganz erkennen. Bei UTF-8 sind die einzelnen Zeichen nicht mehr über "zeichenkette[i]" adressierbar, was automatisch auch alle str***-Funktionen nicht anwendbar werden lässt. Kompatibilität zu C-Strings ist also nicht gegeben. Gut, UTF-16 hat denselben Nachteil (Multi-Byte-Encoding). Von der Programmierung her am ehesten an C-Strings wäre noch UTF-32 mit seiner konstanten Zeichenlänge. --Christoph 11:19, 27. Mai 2006 (CEST)

Eben nicht. UTF-32 und UTF-16 heißt schon mal erst mal, daß man char durch entsprechende 32-Bit bzw. 16-Bit Typen ersetzen muß. Aber nicht an den Stellen, wo char im Sinne von "Byte" verwendet wird. Und man muß auf einmal streng zwischen der Länge (in Zeichen) und Größe (in Bytes) unterscheiden. Es ist also mit Neucompilieren nicht getan, man muß den Code komplett durchgehen und oft erheblich überarbeiten.

Bei utf-8 hingegen funktioniert praktisch alles "fast wie gewohnt", auch die str-Funktionen. Sicher, strlen z.B. liefert die Länge in Bytes, nicht in Zeichen, aber das macht in den allermeisten Fällen nichts, ist sogar oft das was man braucht. Nur code, der Zeichen einzeln manipuliert und eine 1:1-Beziehung zwischen Bytes und Zeichen/Glyphen annimmt, muß überarbeitet werden. Der ist aber eher selten. Oefe 14:11, 27. Mai 2006 (CEST)

Stimmt, so gesehen hast du Recht. Vielleicht wäre es dann noch sinnvoll, deinen Satz über die str-Funktionen einzubauen, damit nicht gleich der nächste drüber stolpert. --Christoph 16:14, 27. Mai 2006 (CEST)

Ihr habe Recht. str* Funktionen sind weiterverwendbar. Es brauchte eigentlich nur eine zusätzliche str Funktion "int strglyphlen(const char *string);". Alte Programme wie z.B. "cat" sind weiterverwendbar, nur der Termialemulator muss die UTF-8 Escape Sequenzen verarbeiten können. Beziehungsweise die Widget Funktionen. Und bei der socket Kommunikation braucht man nichts zu ändern. Keine "byte order" oder so. Alles portabel. Also lediglich eine Octet Folge. Lehrig 11:00, 28. Mai 2006 (CEST)

Vorschlag:

Für den Programmierer hat der UTF-8 gegenüber UTF-16 und UTF-32 den Vorteil,
daß er mit den klassischen mit einem 0 Byte abgeschlossenen Zeichenketten,
wie sie in ANSI C verwendet werden, kompatibel ist.
Auch braucht man bei der Speicherung in Dateien oder der Kommunikation über Netzwerke 
keine besonderen  Vorkehrungen treffen,
da es sich bei UTF-8 lediglich um eine Octet Folge handelt.

Dies kann mit Escape Sequenzen verglichen werden,
wie sie schon lange bei Terminals oder Druckern Verwendung finden.

Die Funktion "int strlen(const char *str);" liefert allerding die benötigten Bytes zurück und 
nicht die Anzahl der Glyphen. 
Eine entsprechende Funktion müsste in die string Funktionen aufgenommen werden.
Ansonsten brauchen alte Programme nicht von char auf int16 bzw. int32 umgestellt zu werden.

Nur die Terminalemulatoren bzw. die Widget Methoden müssen UTF-8 unterstützen.

Lehrig 11:16, 28. Mai 2006 (CEST)

Ich würde knapper formulieren: UTF-8 teilt Vor- und Nachteile herkömmlicher Multibyte Character Sets. --Pjacobi 12:16, 28. Mai 2006 (CEST)

Diese Formulierung ist insofern irreführend, da utf-8 gegenüber herkömmlichen Multibyte Character Sets zahlreiche Vorteile hat (s. [utf-8]-Artikel). Oefe 15:37, 28. Mai 2006 (CEST)

Den Vergleich mit Escape-Sequenzen finde ich nicht besonders glücklich, denn Escape-Sequenzen sind nicht so standardisiert und umständlicher in der Handhabung, da sie i.R. normale (druckbare und nicht druckbare) ASCII-Zeichen mit einer anderen Bedeutung belegen, z.B. würde in einer Sequenz ESC-M (hex 1B 4D) das "M" eben nicht als Buchstabe "M" ausgegeben werden. In utf-8 dagegen bedeutet ein Byte "4D" immer den Buchstaben M.

Auch den Absatz:

Eine entsprechende Funktion müsste in die string Funktionen aufgenommen werden.
Ansonsten brauchen alte Programme nicht von char auf int16 bzw. int32 umgestellt zu werden.

würde ich eher weglassen. Mit einer Funktion ist es sicher nicht getan. Wenn man wirklich Zeichen- oder gar Glyphenweise (was nicht dasselbe ist) arbeiten, oder z.B. Zeichen transformieren will (toupper), kommt man um die Verwendung der Unicode-Tabellen (entweder direkt oder über entsprechende Funktionen) nicht herum. Und in diesem Fall ist man wohl oft mit UTF-16 oder -32 besser bedient.

Der Punkt ist nur, dass viele Programme das entweder gar nicht machen, oder dazu entsprechende System-Funktionen bzw. GUI-Widgets benutzen, die als Schnittstelle durchaus utf-8 verwenden können. Oefe 15:37, 28. Mai 2006 (CEST)

Den Vergleich mit Escape-Sequenzen habe ich absichtlich gebracht. Denn es geht doch darum, dass der Leser das Prinzip versteht. Darüber hinaus werden Escape-Sequenzen durchaus zur Ausgabe von sonst nicht darstellbaren Zeichen verwendet. UTF-8 hat doch wahrscheinlich auch noch ein Hintertürchen offen gelassen, um es über die bisher maximal definierten 4 Byte hinaus zu erweitern. Lehrig 18:15, 28. Mai 2006 (CEST)

Ein Beispiel für ein Widget Set, das Unicode unterstützt ist Qt. Es verwendet durchgängig die QString Klasse, die Unicode verwendet [1]. Character sequenzen lassen sich in QString konvertieren: "QString fromUtf8 ( const char * str, int size = -1 )".

Zitat:

Conversions between 8-bit strings and Unicode strings
QString provides the following four functions that return a const char * version 
of the string as QByteArray: toAscii(), toLatin1(), toUtf8(), and toLocal8Bit().
 toAscii() returns an ASCII encoded 8-bit string.
 toLatin1() returns a Latin-1 (ISO 8859-1) encoded 8-bit string.
 toUtf8() returns a UTF-8 encoded 8-bit string. UTF-8 is a superset of 
 ASCII that supports the entire Unicode character set through multibyte sequences.
 toLocal8Bit() returns an 8-bit string using the system's local encoding.
To convert from one of these encodings, QString provides fromAscii(), fromLatin1(),
fromUtf8(), and fromLocal8Bit(). Other encodings are supported through QTextCodec.

Qt lässt sich nicht nur zur Programmierung von GUI's einsetzen, sondern auch zur Programmierung z.B. von Serversoftware ohne eigene Benutzeroberfläche.

Vielleicht sollte man sich an der Qt Dokumentation orientieren PS:Ich bin Benutzer Lehrig, hatte vergessen mich einzuloggen. 80.131.222.13 17:51, 28. Mai 2006 (CEST)

Ich bin gegen ein ausführliches "für Programmierer" Kapitel. Welche Unicode-Kodierung am einfachsten zu benutzen ist, entscheidet der Language Designer, welche im Projekt tatsächlich benutzt wird, der Software Architect. Am ehesten noch eine kurze Tabelle welche Unicode-Kodierung welchem nativem Datentyp in welcher Programmiersprache entspricht. --Pjacobi 17:58, 28. Mai 2006 (CEST)

Mit Verlaub, das halte ich für falsch. Erstens spielt es keine Rolle, wer in einer Firma XY die Entscheidung trifft. Wahrscheinlich ökonomische Erwägungen. Darüber hinaus ist ein Absatz für Programmierer gerade wichtig, weil viele Programmierer sich noch nicht mit der Kodierung und Verarbeitung nichtlateinischer Schriften auskennen. Das wird allerdings immer wichtiger. Lehrig 18:21, 28. Mai 2006 (CEST)

Eine Enzyklopädie ist kein Tutorial. Ausserdem gibt es bereits gute Tutorials. --Pjacobi 09:31, 29. Mai 2006 (CEST)

Ein kurzer Absatz über die Probleme, die Unicode ggü 1-Byte-Zeichensätzen macht und wie man sie lösen kann, ist sicher nicht verkehrt. Dieser sollte aber möglichst programmiersprachenunabhängig sein und muss nicht zu sehr in die Tiefe gehen. Verweise auf Artikel, die das Thema genauer behandeln können, halte ich da eher für angebracht. --RokerHRO 08:49, 31. Mai 2006 (CEST)

Ich halte garnichts von solchen Programmier-Tipps. Ich als Programmierer habe mich direkt auf der offiziellen Unicode-Homepage informiert, wo ich alle Informationen gefunden habe, die ich brauche (Es gibt sogar ausfuerliche Informationen darueber, wann man am besten welche Kodierung benutzten sollte). Die Wikipedia ist meiner Meinung nach definitiv KEIN Ort, wo man solches Spezialwissen verbreiten sollte, erst recht nicht, wenn schon eine sehr umfangreiche und gute Homepage existiert (die offizielle). RedNifre 17:28, 23. Aug 2006 (CEST)

[Bearbeiten] Verständlichkeit des Artikels

Nichts für ungut, aber nach zweimaligem Lesen des Artikels war mir hinterher immer noch nicht klar, was Unicode sein soll, bzw. hatte nur eine difuse Vorstellung davon, wie es funktioniert. Beispiel für eine verständliche Beschreibung: http://unicode.e-workers.de/. Bei diesem Artikel war mir nach ein mal querlesen klar, worum es bei Unicode geht und wie es aufgebaut ist.

Ich finde den von Dir angegebenen Artikel recht gelungen. Unglücklicherweise bin ich kein besonders guter Schreiber und es sollte ein anderer mal einen Absatz formulieren. Darin sollte auch dieses Zitat vorkommen.

Neben UTF-16 und UTF-32 ist auch das "USC Transformation Format 8 Bit" (UTF-8) gebräuchlich.  
UTF-8 kann jedes Unicode-Zeichen als Abfolge von Datenwörtern von je 8 Bit Länge ausdrücken. 
UTF-8 ermöglicht also die Umwandlung von 16 Bit- in 8 Bit-codierte Schriftzeichen. UTF-8 stimmt 
in den ersten 128 Zeichen mit dem "American Standard Code for Information Interchange" (ASCII)   
überein.

Vorschlag:

Unicode kommt in den Formen UTF-8, UTF-16 und UTF-32 vor. Bei UTF-8 kann jedes Unicode-Zeichen als Sequenz von 8 Bit Zeichen mit einem möglichen 0 Byte am Ende dargestellt werden. Dabei werden die ersten 128 Zeichen nach dem ASCII-Code dargestellt. Weitere Zeichen belegen 2 bzw. 4 Byte in Reihenfolge. Man kann mit dem UTF-8 Code bis zu 2^32 Zeichen darstellen. Bei UTF-16 bzw. UTF-32 werden int16 bzw. int32 Datentypen verwendet. Daher können 2^16 bzw. 2^32 Zeichen dargestellt werden. In der Code-Tabelle finden nach dem amerikanischen Zeichensatz die lateinischen Sprachen, griechische , kyrillische, hebräische, arabische, indische und andere Zeichensätze Platz. Es folgen die ostasiatischen Zeichensätze sowie Platz für tote Sprachen.

Die genaue Codierung ist für den Programmierer unerheblich, da es Bibliotheken gibt, mit denen die Unicode-Zeichen als Strings verarbeitet werden können. Beispielsweise erlaubt die QString Klasse der Qt Bibliothek die Verarbeitung von UTF-16-Zeichen und damit die Unterstützung aller lebenden Sprachen. In diesen Bibliotheken existieren Konvertierungsroutinen, mit denen UTF-8 codierte Zeichen in UTF-16 bzw. UTF-32 umgewandelt werden können und umgekehrt.

UTF-8 hat gewisse Vorteile gegenüber UTF-16 bzw. UTF-32. Zum Einen ist es aufwärtskompatibel zu der klassischen Textdarstellung in Programmiersprachen, weswegen die Unicode-Unterstützung ohne allzu großen Aufwand auch auf alte Programme angewendet werden kann. Zum Anderen handelt es sich bei UTF-8 um eine einfache Octet-Reihenfolge und man kann diese Octet-Reihenfolge über ein Netzwerk übertragen, ohne sich um die möglicherweise unterschiedliche Darstellung der Integer Datentypen auf den beteiligten Rechnersystemen kümmern zu müssen.

Falls dieser Vorschlag nicht euere Zustimmung finden sollte, bitte ich um einen Gegenvorschlag. Wie gesagt, ich bin nicht der beste Schreiber. Aber beim Programmieren lasse ich mir von keinem was vormachen :-) Lehrig 09:26, 29. Mai 2006 (CEST)

Absatz 1: Hä? Unicode hat immer einen potentiellen Zeichenvorrat von 17*2^16 - ein paar zerquetschte. Das ist unabhängig von der Verwendung von UTF-*, somit können alle UTF-* (sowie CESU-8 und GB18030) für alle Unicodebereiche benutzt werden. Das 0-Byte am Ende hat nichts mit Unicode zu tun.

Absatz 2: Wiederum der Fehler mit dem Zeichenvorrat

Absatz 3: Zu C-spezifisch, trifft z.B. nicht auf Java zu

Pjacobi 09:39, 29. Mai 2006 (CEST)

Gegenvorschlag ??? 2^16 bzw. 2^32 ist natürlich nur eine Phantasiegrösse, in der Realität muss natürlich noch was abgezogen werden. 0 Byte am Ende ist bei UTF-8 erlaubt und wichtig, für alte Programme !!! PS:Wir sollten hier auch keine endlose Grundsatzdiskussion führen. Was ist denn falsch an der obigen Darstellung ? Kann keine Widersprüche erkennen. Und C/C++ ist nun mal wichtig, evtl. wichtiger als Java oder andere Sprachen. 80.131.255.37 13:10, 29. Mai 2006 (CEST) ... Hach wieder das Login vergessen Lehrig 13:12, 29. Mai 2006 (CEST)

Der Unicode-Codepoint-Bereich ist mit U+000 bis U+10FFFF festgelegt. Alle UTFs können den gesamten Bereich abdecken. Alle Bytesequenzen die at face value zu einem Codepoint >0x10FFF führen sind illegal. Das 0-Byte am Ende ist eine C-Konvention und hat nichts mit UTF-8 zu tun. (U+0041, U+0000, U+0042, U+0000, U+0043) ist eine perfekt legale Folge von Unicodezeichen, die sich auch mit UTF-8 nicht C-String darstellen lässt. Ich schlage vor, wenn überhaupt, schreibst Du etwas in den Artikel C (Programmiersprache), da gibt es nämlich noch gar kein Kapitel zu Zeichensätzen und Unicode. --Pjacobi 13:20, 29. Mai 2006 (CEST)

Deine Ausführungen betreffen Details, die keinen Programmierer interessieren müssen. Ausserdem wird Unicode ständig erweitert und wird auch unter Garantie in Zukunft noch Erweiterungen (vielleicht sogar über UTF-32 hinaus) erfahren. In der C (Programmiersprache) werde ich (nach deinem Vorschlag) einen Link setzen. Lehrig 15:05, 29. Mai 2006 (CEST)

Zu der Zahl der Codepoint s.u. Wenn Du nichts von Unicode verstehst, solltest Du vielleicht nicht versuchen, einen Artikel darüber zu schreiben. Es geht nicht um Details, sondern um richtig oder falsch. --Pjacobi 16:34, 29. Mai 2006 (CEST)

Als Programmierer sollte man sich schon mit den Details befassen. In Java sollte man daran denken, dass Codepoint 0 speziell kodiert wird (kein sauberes Unicode, aber nicht wirklich schaedlich), damit ein C-Programm nicht denkt, der String wuerde enden. Und in C muss man sich selbst darum kuemmern, dass evtl. im String vorhandene 0-Codepoints irgendwie (zum Beispiel durch eine Escape-Sequenz) behandelt werden, damit C damit klarkommt. Und dass Unicode noch extrem veraendert wird ist m.M.n. auch sehr unwahrscheinlich, da mann dann UTF-16 vergessen koennte. RedNifre 17:44, 23. Aug 2006 (CEST)

Den folgenden Beitrag werde ich in den Artikel über Unicode einfügen, wenn kein weiterer Benutzer Einwände geltend macht.

[Bearbeiten] Implementierung

Unicode kommt in den Formen UTF8, UTF-16 und UTF-32 vor. Bei UTF-8 kann jedes Unicode-Zeichen als Sequenz von 8 Bit Zeichen mit einem möglichen 0 Byte am Ende dargestellt werden. Dabei werden die ersten 128 Zeichen nach dem ASCII-Code dargestellt. Weitere Zeichen belegen zur Zeit 2 bzw. 4 Byte in Reihenfolge.

Man kann mit dem UTF-8 Code bis zu 2^32 Zeichen Brutto darstellen. Bei UTF-16 bzw. UTF-32 werden int16 bzw. int32 Datentypen verwendet. Daher können 2^16 bzw. 2^32 Zeichen Brutto dargestellt werden.

In der Code-Tabelle finden nach dem amerikanischen Zeichensatz die lateinischen Sprachen, griechische , kyrillische, hebräische, arabische, indische und andere Zeichensätze Platz. Es folgen die ostasiatischen Zeichensätze sowie Platz für tote Sprachen. Durch die Unterstützung der toten Sprachen musste UTF-16(ISO/IEC 10646) auf UTF-32 erweitert werden.

Die genaue Codierung ist für den Programmierer unerheblich, da es Bibliotheken gibt, mit denen die Unicode-Zeichen als Strings verarbeitet werden können. Beispielsweise erlaubt die QString Klasse der Qt Bibliothek die Verarbeitung von UTF-16-Zeichen und damit die Unterstützung aller lebenden Sprachen.

In diesen Bibliotheken existieren Konvertierungsroutinen, mit denen UTF-8 codierte Zeichen in UTF-16 bzw. UTF-32 umgewandelt werden können und umgekehrt.

UTF-8 hat gewisse Vorteile gegenüber UTF-16 bzw. UTF-32. Zum Einen ist es aufwärtskompatibel zu der klassischen Textdarstellung in Programmiersprachen, weswegen die Unicode-Unterstützung ohne allzu großen Aufwand auch auf alte Programme angewendet werden kann. Zum Anderen handelt es sich bei UTF-8 um eine einfache Octet-Reihenfolge und man kann diese Octet-Reihenfolge über ein Netzwerk übertragen, ohne sich um die möglicherweise unterschiedliche Darstellung der Integer Datentypen auf den beteiligten Rechnersystemen kümmern zu müssen.

Sinngemäss kann UTF-8 also als eine Art Escape Sequenz betrachtet werden, wie man Sie auch bei Terminalemulatoren oder Druckern antreffen kann. UTF-8 kann theoretisch auch auf mehr als 4 Zeichen erweitert werden.

Lehrig 15:05, 29. Mai 2006 (CEST)

Lese Dir bitte RFC 3629 durch. Dort wurde gegenüber RFC 2279 explizit der Raum der gültigen Codes für UTF-8 auf U+0000 bis U+10FFFF für alle Zeiten beschränkt. RFCs werden nicht mehr geändert.

UTF-8 könnte übrigens nicht nur 2³² sondern über 2³⁶ unterschiedliche Codes darstellen. Auch UTF-16 kann nicht nur 2¹⁶ Codes, sondern alle Codes von U+0000 bis U+10FFFF darstellen. --Fomafix 16:25, 29. Mai 2006 (CEST)

"für alle Zeiten beschränkt" Entschuldigung, aber nach meinen vernachlässigbaren Erfahrungen ist das totaler Blödsinn. JEDE Codierung muss PRINZIPIELL erweiterbar sein. Auch wenn das unter Umständen auch NIE erforderlich wird. PS: 640kB sollten für jeden Computer ausreichend sein :-) Lehrig 17:32, 29. Mai 2006 (CEST)

Wende Dich mit Deinem Anliegen an die Unicode-Mailingliste. Die Experten dort werden diesen Hinweisen ergriffen lauschen. Wir dokumntieren nur den vorliegenden Standard. --Pjacobi 18:00, 29. Mai 2006 (CEST)

Wir beide haben unsere gegenseitigen Auffassungen schon ausreichend diskutiert. Du hast auch keinen Gegenvorschlag gebracht. PS: Die heutigen Hüter des Unicode braucht man garnicht zu fragen. Fragen solltest Du die Generationen nach uns, die sich mit unserer Unicode Implementierung herumschlagen müssen. Trotzdem ist Unicode eine tolle Sache, weil es endlich gelungen ist, einen Konsens über die Codierung der Sprachen auf unserer Mutter Erde zu schaffen. Endlich ein Standard !!! Aber spätestens, wenn wir klingonisch und alle anderen Sprachen des Universums berücksichtigen müssen, wird Unicode erweitert werden müssen oder sogar obsolet werden. ... Aber langsam wird's philosophisch :-) Lehrig 18:24, 29. Mai 2006 (CEST)

Vielleicht auch einfach hier mit Lesen anfangen. --Pjacobi 16:40, 29. Mai 2006 (CEST)

Ich versuch's noch einmal, diesmal etwas produktiver:

• Wir haben einzelne Artikel zu UTF-8, UTF-16, UTF-32. Diese können gegebenenfalls einen Abschnitt "UTF-X in der Softwareentwicklung" vertragen. Wir haben auch einen Artikel Unicode Transformation Format der sich für den Überblick eignen würde, welche Sprachen, Bibliotheken und Betriebssysteme welches UTF unterstützen/vorziehen. Sehr vorsichtig (d.h. unter Beachtung von en:WP:NOR) könnten da Vor- und Nachteile dargestellt werden.
• Aber hier, in Unicode, sollte ein hypothetischer Abschnitt Softwareentwicklung sich um die Aspekte kümmern, die unabhängig von der Wahl des UTFs sind, da gibt es ja genug zu beachten: Rückwärts- und Vorwärtskompatibilität, Kompatibilitäts- und kanonische Äquivalent und Normalisierung, Bidi, Graphem- und Wortgrenzenerkennung, UCA, ...

Pjacobi 19:18, 29. Mai 2006 (CEST)

Das hört sich doch schon ganz anders an. Ich werde meine Zeilen an der entsprechenden Stelle eintragen und hier nur kleine Ergänzungen und Verlinkungen eintragen. Warum haben wir eigentlich so lange aneinander vorbei geredet ? Benutzer:Lehrig ist mal wieder nicht eingeloggt. 80.131.255.37 20:00, 29. Mai 2006 (CEST)

Die Diskussion wird in Unicode_Transformation_Format#Implementierung weitergeführt. Mit dem Auffassung von Pjacobi bin ich nicht einverstanden. Erst sollten sich noch andere Benutzer zu Wort melden, sonst kommen wir auf keinen grünen Zweig. Lehrig 08:12, 31. Mai 2006 (CEST)

Also in einem Artikel über Unicode sollte auf die verschiedenen "Unicode Transfer Formate" nur verwiesen werden, schließlich sind diese nur mögliche Kodierungen, um Sequenzen von Unicode-Zeichen zu speichern oder zu übertragen, mehr nicht.

Daher würde ich generell zwischen dem "Unicode" und seinen verschiedenen "Transfer-Formaten/-Kodierungen" unterscheiden. Unicode ist schlicht eine Codetabelle von Zahl zu Glyph und seinen Eigenschaften usw. Die Transferformate UTF-8, UTF-16 und UTF-32 beschreiben lediglich, wie man eine solche Zahl (aus de mdefinierten Wertebereich 0...10FFFF) übertragen kann. Diese Formate wurden zwar speziell für die Übertragung von (Sequenzen von) Unicode-Codepositionen (als Synonym für ein Zeichen) erdacht, aber prinzipiell ist denen die Bedeutung der Zahlen, die sie kodieren, egal. --RokerHRO 08:56, 31. Mai 2006 (CEST)

[Bearbeiten] Kann mir jemand kurz und klar erklären...

…was ich tun muss, damit ein Zeichen dessen „Unicode“ ich kenne, in einem Browser auch erscheint? -- Peter Steinberg 00:44, 14. Sep 2006 (CEST)

Wenn du etwa das Unicode-Zeichen U+20AC eingeben willst, schreibst du einfach €. Und es erscheint dann: ein €. Wie gewünscht. Du kannst natürlich auch mit nem Taschenrechner den hexadezimalen Codewert in eine Dezimalzahl umwandeln und dann € schreiben, da ältere Browser mit den Hexadezimal-Sequenzen u.U. nicht klarkommen. Das ergibt dann ebenfalls ein: € :-) --RokerHRO 10:21, 14. Sep 2006 (CEST)

[Bearbeiten] Kombinationszeichen (Combining characters)

Also wie das mit dem Kombinieren von Zeichen in Unicode ist, steht im Artikel nicht wirklich. Das Beispiel Combining Grapheme Joiner (CGJ) ist ein Spezialfall, der so speziell ist, dass er eher zur verwirrung beiträgt, weil die Grundlagen überhaupt nicht erklärt werden. In en gibt's wenigstens en:Combining character, wenn auch nicht Oma-tauglich und außerdem unvollständig. Hier einige Beispiele. Das Kombinationszeichen ist jeweils fett markiert:

Zeichenkodes	Darstellung	Beschreibung
U+0065 U+0337	e̸	Lange schräge Durchstreichung eines kleinen e
U+0078 U+0303	x̃	Tilde über kleinem x
U+0041 U+0361 U+0042	A͡B	Bogen über großem A und dem folgenden B
U+0041 U+0361 U+0078 U+0303	A͡x̃	Bogen über großem A und dem folgenden x mit Tilde
U+007A U+0304 U+0308	z̄̈	Kleines z mit Trema und Makron kombiniert
U+0063 U+034F U+0068	ch	Ch (Digraph) als zusammenhängend markiert

In vielen nicht-lateinischen Schriftarten tauchen weitere Kombinationszeichen auf.

Für Digraphen und Trigraphen gibt es das Kombinationszeichen "Combining Grapheme Joiner (CGJ)" (U+034F), wie leider etwas unverständlich schon im Artikel beschrieben.

-- Nichtich 12:06, 24. Okt. 2006 (CEST)

[Bearbeiten] Unicodeeingabe bei GNOME

Im Artikel stand folgender Abschnitt.

GNOME unterstützt die Eingabe über die Kombination Strg + Umschalttaste + <unicode> bzw. in neueren Versionen Strg+ U + <unicode>. Auch hier erfolgt die Eingabe in hexadezimaler Form.

Ich habe es unter einem aktuellen Gentoo mit Firefox 1.5.0.8 und gedit ausprobiert. Nur Strg + Umschalttaste + U + <unicode> funktioniert. Bei Strg + U + <unicode> wird beispielsweise in Firefox 1.5.0.8 die Seitenquelltextanzeige aufgerufen (Tataturkürzel Strg+U).

Ich habe Strg + Umschalttaste + U + <unicode> im Artikel ergänzt. Ob Strg + U + <unicode> irgendwann einmal irgendwie unter irgendwelchen Bedingungen funktionierte oder nicht, weiß ich nicht, weshalb ich es mal stehen gelassen habe. MfG Blaite 20:43, 2. Dez. 2006 (CET)