Diskussion:Unicode/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Unicode/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Unicode/Archiv#Thema_1

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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.

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)

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)

Zeichensatz/Zeichenkodierung

Ist Unicode selber nicht ein Zeichensatz? Es legt die Zeichen fest und deren Codepoints, aber in diesem Artikel wird auch noch von UTF-X und den ISO-8859-X geredet.

Sind denn UTF-X und ISO-8859-X nicht Zeichenkodierungen, die die Codepoints aus dem Unicode-Zeichensatz auf Bytes abbilden?

IMHO wird in diesem Artikel nicht so sehr zwischen Zeichensatz und -kodierung unterschieden.

Alle Zeichenkodierungen sogar ASCII können doch Unicode, ASCII z. B. aber nur 128 Unicode-Codepoints, darstellen.

Vielleicht habe ich auch nur was falsch verstanden. Gruß --L'ottimo 20:09, 9. Apr. 2007 (CEST)

Das sollte eigentlich bei uns schon alles erklärt sein:

Zeichensatz, Zeichenkodierung. Hmm, nicht so prickelnd.

Liest Du Englisch? Dann hier: en:Character_encoding#Modern_encoding_model.

Mit anderen Worten, der UNICODE Standard definiert character repertoire, coded character set, character encoding form und character encoding scheme.

Pjacobi 20:19, 9. Apr. 2007 (CEST)

Danke, ich glaub ich hab's verstanden --L'ottimo 20:39, 9. Apr. 2007 (CEST)

Deutsche Bezeichnungen für Unicode-Symbole

... und zwar ausschliesslich mit lateinischen Buchstaben geschrieben, soweit möglich. --Reiner Stoppok 01:24, 6. Jun. 2007 (CEST)

Siehe auch: Traduction française officielle de l’ISO/CEI 10646 et Unicode

Ich möchte vorschlagen, für alle Unicode-Symbole systematisch deutsche Begriffe zu prägen, die dann hier auch verwendet werden dürfen. Ich hatte gerade Schwierigkeiten bei "Seagull below" aus dem IPA, was ich hemdsärmelig mit "Möwe unten" übersetzt habe, mir aber ein Redirect von "Möwe unten" bzw. "Möwe unten (IPA)" gelöscht wurde mit dem üblichen Hinweis auf die Trefferzahl bei Google. --Reiner Stoppok 17:48, 3. Jun. 2007 (CEST) PS: Dazu habe ich in der neusten amerikanischen Literatur einfach nichts gefunden ... :)

Das wäre Theoriefindung, die nach den Grundsätzen der Wikipedia nicht zulässig ist. --Thogo (Disk.) -- Sorgen? 19:23, 3. Jun. 2007 (CEST)

Ich meinte sowas hier: Liste von Unicode Zeichen, was bei en.wikipedia durchaus erlaubt ist. --Reiner Stoppok 20:28, 3. Jun. 2007 (CEST)

Ich schliess mich Thogo an, siehe auch Diskussion IPA--Patrick 20:30, 3. Jun. 2007 (CEST).

Ich möchte nur erreichen, dass man auch deutsche Bezeichnungen einführen darf. Wie würdest Du ein Lemma mit dem Unicode-Zeichen "Möwe unten" (IPA 407) hier bei de.wikipedia betiteln? --Reiner Stoppok 20:41, 3. Jun. 2007 (CEST) PS: Weiss jemand zufällig, wie ich rein technisch die "Möwe unten" (bei Seagull below) so in einen Schaukasten rechts hinbekomme, wie bei Halblangzeichen?

Neue und bisher unübliche Begriffe einzuführen ist in der Wikipedia aber ausdrücklich unerwünscht. Die englischen Bezeichnungen sind die einzigen vom Unicode-Konsortium vergebenen Namen und die deutschen Übersetzungen sind bei den meisten exotischen Zeichen auch in der jeweiligen Fachsprache nicht üblich. --RokerHRO 22:25, 3. Jun. 2007 (CEST)

Ich plädiere dafür, wortwörtliche Übersetzungen zuzulassen. Wenn man das Wort Begriff so definiert wie hier, dann kann man es bei großzügiger Auslegung durchaus mit Wikipedia:Theoriefindung in Übereinstimmung bringen. "Seagull below" und "Möwe unten" wären dann zwar nicht dasselbe Wort, wohl aber derselbe Begriff. Demnach war es auch gar nicht nötig, dass das Unicode-Konsortium die Bezeichnungen der einzelnen Zeichen für andere Sprachen als das Englische festgelegt hat. Sie haben nur die Begriffe geprägt und dafür die englische Sprache benutzt. Die Zuordnung dieser englischen Bezeichnungen zu entsprechenden deutschen war nicht mehr Aufgabe des Konsortiums. Das heißt aber meiner Meinung nach nicht, dass wir das nicht tun sollten. Im Gegenteil, ich finde, wir sollten nicht an den englischen Bezeichnungen kleben bleiben. Gismatis 05:33, 4. Jun. 2007 (CEST)

Du hast mich verstanden, lieber Gismatis: "Wir sollten nicht an den englischen Bezeichnungen [des Unicode-Konsortiums] kleben bleiben". --Reiner Stoppok 17:03, 4. Jun. 2007 (CEST)

  ̼ 

 ̼

@Reiner: Man kann ja die Übersetzung des englischen Fachbegriffs in den jeweiligen Artikel mit dazufügen (wie das bei allen fremdsprachlichen Lemmata üblich ist), aber als Lemma selbst sind sie nicht geeignet, weil sie weder in der Wissenschaft anerkannt sind noch im allgemeinen Sprachgebrauch verwendet werden. Im übrigen sollten die Artikel auch etwas mehr Information enthalten als die IPA-Nummer und die Aussprache (ich meine, einen Mehrwert zur Liste der IPA-Symbole). (Seagull below ist ein Beispiel, wie solche Artikel nicht aussehen sollten, aber dort passt wenigstens das Lemma.) Bspw. wie es zu gerade diesem Zeichen kam, wäre mal ganz interessant (natürlich nur, wenn es dafür Quellen gibt). Eigentlich muss es für IPA-Zeichen gar keinen eigenen Artikel geben, es reicht, wenn bspw. Seagull below in Linguolabialer Laut erwähnt wird. Möglicherweise kann es eine Weiterleitung von "Seagull below" darauf geben, das wäre sogar sinnvoll, (nicht aber eine Weiterleitung vom Zeichen selbst oder gar von der deutschen Übersetzung des Zeichennamens).

Das Problem ist doch auch, dass viele Zeichen sich graphisch fast überhaupt nicht unterscheiden. Solche Klärungen graphischer Unterschiede (die natürlch Zeichen mit verschiedenen Unicode-Nummern sind) können nicht alle bei IPA oder sonstwo stattfinden. Auch nicht die Klärungen der Tatsache, mit welchen Zeichen ein Zeichen x oft verwechselt wird usw. Für das Zeichen "Seagull below" muss es möglich sein, unabhängig von den Prägungen des Unicode-Konsortiums dafür auch deutsche Begriffe einzuführen. --Reiner Stoppok 17:03, 4. Jun. 2007 (CEST) PS: Es sollten aber zumindest Redirects von deutschen Übersetzungen erlaubt werden. "Möwe unten, eine Übersetzung die Sinn macht, wurde mir zum Beispiel unter dem Hintern wegglöscht." Von mir aus mit dem Hinweis/einer Kategorie: es gibt noch keinen deutschen Fachbegriff dafür. --Reiner Stoppok 17:24, 4. Jun. 2007 (CEST)

Das technische sollte kein Problem sein. Wenn du einen kleinen <div> erzeugst, und die Schriftgröße entsprechend hochsetzt, kann das durchaus sehr hübsch aussehen, siehe das grüne Kästchen rechts oben. Du kannst natürlich auch die Vorlage {{Zeichen|...}} verwenden, musst dann halt nur &nbsp;̼ in die Variable eintragen (das blaue Kästchen). --Thogo (Disk.) -- Sorgen? 00:48, 4. Jun. 2007 (CEST)

Danke, Thogo, ich bin Techniktrottel, werde mir aber Deine Adresse für Fachfragen "notieren". Ich wollte auch nochmal sagen, dass es nicht darum geht, grundsätzlich englischen Fachbegriffen auszuweichen, aber es muss hier auch zulässig sein, Neuprägungen zu schaffen. Auch wenn die nirgendwo zitiert werden. (Siehe auch Löschdiskussion Halblangzeichen oder die Bemerkungen zu "Möwe unten"). Und wenn man keine eigenen Artikel für solche Zeichen hat, dann erfährt man auch nicht, dass z.B. die beiden oben dargestellten Zeichen verschiedene Unicode-Nummern haben:

ǀ

|

Auch die drei hier unten dargestellten Zeichen haben verschiedene Unicode-Nummern:

ǀǀ

||

ǁ

Die Zeichen "ǀ" und "[[|]]" konnte sogar ein technisch vorgeschulter Herr neulich nicht unterscheiden (sie lassen sich auch "auf den ersten Blick" optisch nicht auseinanderhalten), und das erste nach seiner Auskunft nicht auf seinem Computer eintippen. Um so was geht es hier. Und diese damit verbundenen Problematiken lassen sich sich durch zusätzliche griffige deutsche Benennungen sowie durch erlaubte Einzelartikel zu den Zeichen umgehen oder zumindest beleuchten. --Reiner Stoppok 17:18, 4. Jun. 2007 (CEST)

Auf jeden Fall sollten in der entstehenden Liste_von_Unicode-Zeichen zumindest die deutsche Übersetzung dastehen. Welches die beste Übersetzung ist, könnten wir auf der dortigen Diskussionseite diskutieren. Was gerade das Beispiel Seagull below betrifft, so finde ich, dass entweder "Möwe darunter" oder "Möwe unterhalb" korrekter wäre, als "Möwe unten", da das Zeichen sich unter einem anderen Zeichen und sich damit darunter/unterhalb dieses Zeichens und nicht "unten" befindet.

Diese wörtlichen Übersetzungen können meiner Meinung nach auch als Lemma benutzt werden. Da allerdings der Widerstand dagegen offenbar sehr groß ist, könnte ich mir auch vorstellen, das Zeichen direkt als Lemma zu nehmen. Das wäre zwar bei den meisten Zeichen nicht sonderlich benutzerfreundlich. Man stelle sich zum Beispiel vor, es gäbe keinen Namen für das Ausrufezeichen. Das Lemma müsste "!" lauten. Außerdem können solche Artikel nicht vorgelesen werden. Aber es wäre meiner Meinung durchaus akzeptabel. Ich glaube sogar, dass es nicht mal zwingend notwendig ist, Weiterleitungen, sei es vom englischen Namen oder der deutschen Übersetzung anzulegen. Die meisten würden den Artikel sowieso von der Liste aus anwählen oder würden das Zeichen ins Suchfeld kopieren. Gismatis 01:23, 7. Jun. 2007 (CEST)

Meinst Du ǃ (bitte anklicken) oder ! (bitte anklicken)? ... :) ... --Reiner Stoppok 23:44, 7. Jun. 2007 (CEST)

Ich bin auch strikt gegen die Neubildung von Begriffen in WP, wenn diese "Artikel" überhaupt nötig sein sollten, dann bitte unter ihrem geläufigen englischen Namen. Und bitte keine Redirects von den Pseudo-Deutschen Namen auf die englischen Namen! (Du hast schon wieder damit angefangen...). Danke --Achim Jäger 22:47, 5. Jun. 2007 (CEST)

"Pseudo-Deutsche Namen" habe ich heute nicht verwendet. Da müsstest Du schon konkreter werden. Ich verstehe also: Du lehnst generell die Verwendung der deutschen Sprache für die Unicode-Zeichen bei de.wikipedia ab. Und Dich interessiert auch nicht die Möglichkeit, sich von den damit verbundenen Fesseln hier zu befreien. --Reiner Stoppok 23:58, 5. Jun. 2007 (CEST)

Was ist denn mit "Ziffer Null" (ist schon schnellgelöscht worden...)? WP ist absolut nicht der richtige Ort um sich von "Fesseln zu befreien". WP ist eine Enzyklopädie, da kann man nicht einfach Lemmata mal eben so frei neu erfinden, nur weil einem das gefällt. --Achim Jäger 00:12, 6. Jun. 2007 (CEST)

Du nennst die deutsche Bezeichung "Ziffer Null" für das Symbol "0" also einen "pseudo-deutschen Namen", wenn ich Dich recht verstehe, und lehnst deshalb ein Redirect von "Ziffer Null" auf die englischsprachige Unicode-Bezeichnung "Digit zero" bei de.wikipedia ab. --Reiner Stoppok 00:35, 6. Jun. 2007 (CEST) PS: Und für Zeichen wie ǁ würdest Du die gross geschriebene englische Bezeichnung Unicode Character 'LATIN LETTER LATERAL CLICK' o.ä. bevorzugen, in dem Fall, in dem Du gezwungen wärest, eine Klarstellung zu einem solchen Zeichen vorzunehmen?!

Und wenn Du Dir mal die verschiedenen Unicode-Versionen anguckst, dann gibt es auch keine "geläufigen englischen Namen", sondern immer nur der letzte ist der richtige. --Reiner Stoppok 01:14, 6. Jun. 2007 (CEST)

So sehr ich mich immer freue, wenn sich ein Journalist mal die Mühe macht (meist begegnet es mir im erweiterten journalistischen Bereich), einen englischen Begriff mal vernünftig ins Deutsche zu übertragen ("Atomwaffensperrvertrag"), statt das Original ("non proliferation treaty") oder "gerne" eine Nichtübersetzung ("Nichtproliferationsvertrag") zu verwenden, so wenig ist Wikipedia der Ort dafür, irgendwelche Begrifflichkeiten einzuführen, ob es nun darum geht, deutsche Übertragungen anzubieten, oder gänzlich neue Begriffe zu entwickeln. Nun sollen bestimmte Unicodesymbole offensichtlich benannt werden dürfen, ohne sie selber zu verwenden, was eh nur für den WP-internen Gebrauch sinnvoll sein kann (von extern wird ja niemand das Lemma finden). Zugegeben ein Problem, für das mir auch keine direkte Lösung einfällt, aber ich würde derartiges komplett aus dem Artikelraum raushalten wollen, dort gehören eben keine "Einführungen von Begriffen" hin. Es ist eine verdienstvolle Aufgabe, aber nicht die der WP, so etwas einzuführen. Bestenfalls in einem anderen Namensraum zum "internen Arbeiten" (dann auch gerne "untere Möwe", was in meinen Segelohren besser klingt als "Möwe unten"), wobei mir der passende nicht einfallen will. Aber es wäre, und bliebe, flapsiger Randgruppenjargon und damit nicht WP-relevant. -- Ulkomaalainen 09:19, 6. Jun. 2007 (CEST)

Lieber Ulkomaalainen! Mir fällt dazu ein, dass man mal die Bezeichnungen für die verschiedenen Symbole der verschiedenen Unicode-Versionen auf die ständige Verbesserung der englischen Begriffe hin durchchecken sollte. Daran kann man nämlich erkennen, mit welch rasantem Tempo diese Bezeichnungen ständig verbessert wurden. Und solch ein griffiges Arbeitsbesteck soll man sich auf deutsch nicht schaffen können? --Reiner Stoppok 17:49, 6. Jun. 2007 (CEST) PS: Um Weihnachten wurde ich mal gefragt, ob ich das Lied " Silent night" kennen würde ... Gute Nacht, kann ich da nur sagen!

Meine Meinung dazu: Eine Übersetzung eines fremdsprachlichen Begriffs nimmt derjenige vor, der den Begriff als Erster im Deutschen verwendet. Wenn eine Sache also bisher nur von fremdsprachlicher Fachliteratur abgehandelt worden ist und der erste Ort, an dem der Sachverhalt auf Deutsch dargestellt werden soll, zufälligerweise die Wikipedia ist, dann kommt halt der Wikipedia auch die Aufgabe zu, den fremdsprachlichen Begriff zu übersetzen. Und ich finde eine bloße Übersetzung eines fremdsprachlichen Begriffs ist wirklich anders zu bewerten, als die Einführung eines völlig neuen Begriffs oder Wortes. Gismatis 01:23, 7. Jun. 2007 (CEST)

das ganze ist ja richtig erschreckend, ich versteh ja die beweggründe, aber vor lauter panik, keine deutschen namen zu kennen, auf solche schnappsideen zu kommen, aber sowas von daneben.. sorry, wenn ich mich da so echauffier, es gibt schon lange einen - wenn auch nicht offiziellen, aber defacto - standard der deutschen namen, und das ist die internationalisierung, die Microsoft verwendet: das kleine tool Zeichentabelle bietet für jedes (ja! jedes) zeichen der font Arial Unicode MS in jeder sprachvariante, die die firma auf den markt gebracht hat, eine übersetzung.. "möve unten", so ein kindischer quatsch (Sellin auf Rügen hat Möve oben), der deutsche name von U+033C lautet Verbindungszeichen Doppelbogen unten - mit der bitte, sich mal die seite Wikipedia:Recherche sorgfältig durchzulesen, und den artikel Seagull below hab ich verschoben -- W!B: 08:09, 7. Jun. 2007 (CEST)
und, wer flegelt, soll auch was gutes tun: @Reiner Stoppok, fall Du nicht auf Windows arbeitest, ich steh Dir jederzeit zur verfügung, die namen rauszusuchen, schreib mir einfach.. gruß und btte nichts für ungut

 ̼

Lieber W!B! Das Zeichen "Seagull below" (siehe Abb. rechts), was ich hemdsärmelig mit "Möwe unten" übersetzt habe, ist aber überhaupt kein Doppelbogen, denn bei einem Bogen reichen beide Ende bis ganz nach unten, was hier aber nicht der Fall ist. Solange Du das nicht beachtest, fürchte ich, ist Deine Weiterleitung von Seagull below nur verwirrend, ja falsch. Aus diesem Grund habe ich Deine m.E. falsche Microsoft-Benennung von "Seagull below" auf die Seite der Qualitätssicherung gesetzt. --Reiner Stoppok 13:31, 7. Jun. 2007 (CEST)

Nix gegen Microsoft, aber ich wüsste zu gerne, wo MS den deutschen Namen für das Zeichen herhat. Mich allein auf MS als Quelle zu verlassen, erzeugt in mir ein wenig Unbehagen. Schließlich sind MS schon des öfteren auch Übersetzungsfehler passiert (Das ist keine Kritik an MS, das kann jedem passieren. Unangenehm sind solche Pannen trotzdem.) Daher hätte ich gerne mehrere voneinander unabhängige Quellen für die Zeichennamen. --RokerHRO 08:56, 7. Jun. 2007 (CEST)

schon was gegen die, genau das ist ihr schmä, sie tuns einfach, setzten mit marktdominanz einen standard - und verdienen auch noch geld damit: bei 85% marktanteil ist MS die quelle -- W!B: 09:26, 7. Jun. 2007 (CEST)

Die zitierte Microsoft-Benennung "Verbindungszeichen Doppelbogen unten " für das Zeichen ist doch falsch: Bei einem Bogen gehen beide Enden bis ganz nach unten, entsprechend bei einem Doppelbogen. Und genau das müssen wir hier umgehen, unterwandern oder noch besser: bessermachen. --Reiner Stoppok 13:38, 7. Jun. 2007 (CEST) PS: Liebe Leute in Heiligendamm, sagt doch mal dem W!B, was eine Möwe ist, und wie die im Flug aussieht.

Eure Diskussion ist ja zur Zeit die lustigste auf WP (gaehn)... Nebenbei: Kreisbogen und Bogen (Architektur)#Segmentbogen. --Wrongfilter ... 21:07, 7. Jun. 2007 (CEST)

Du hier drüber! Das bei Microsoft heisst aber nicht Doppel"kreisbogen". --Reiner Stoppok 21:55, 7. Jun. 2007 (CEST) PS: Und was ist mit " ̯" (<= bitte vergrössern!) (U+032F, IPA 432)? Das ist ein Bogen! --Reiner Stoppok 21:55, 7. Jun. 2007 (CEST)

Du findest "Möve unten" also kindisch? Aber genau das bedeutet "Seagull below". Danke aber für den Hinweis mit Arial Unicode MS. Allerdings handelt es sich da offenbar um eigenständige Bezeichnungen, die sich nicht an die Unicode-Namen hält. Wir dürfen auf keinen Fall verschiedene Bezeichnungen durcheinanderbringen und immer genau unterscheiden zwischen einer Übersetzung und einer Bezeichnung anderer Herkunft. Gismatis 01:47, 8. Jun. 2007 (CEST)

Deutsche Übersetzung oder eigener deutscher Name?

Ein nicht zu unterschätzendes Problem ist, dass es für viele Unicode-Zeichen keine etablierten deutschen Namen gibt. Die englischen sind zwar in der englischen Bevölkerung oftmals ebensowenig bekannt wie die Zeichen selbst, aber immerhin sind die englischen Bezeichnungen normiert und somit eindeutig. Um das Beispiel SEAGULL BELOW zu nehmen: Wer diesen "Fachbegriff" benuzt, kann sich sicher sein, dass man das zugehörige Unicodezeichen eindeutig findet. Soll dieser nun mit "MÖWE UNTEN" oder "MÖWE DARUNTER" oder "MÖWE UNTENDRUNTER" übersetzt werden?
Ein anderes Beispiel sind die Anführungszeichen, deren genormte englische Namen sich an der Verwendung in der englischen Sprache orientieren. So ist LEFT DOUBLE QUOTATION MARK zwar im Englischen das linke (öffnende) Anführungszeichen, im Deutschen aber das schließende. Soll man dieses Zeichen nun mit "Linkes doppeltes Anführungszichen" übersetzen oder mit "Rechtes doppeltes Anführungszeichen" oder "öffnendes.." oder "schließendes.."? Es würde nur noch mehr Verwirrung stiften.
Wie würde man DASH übersetzen? mit "Strich"? Das könnte dann auch ein Schrägstrich sein, oder ein senkrechter Strich, welche im Englischen eigene Bezeichnungen haben: SLASH (STROKE) und BAR. Und jeden Zeichennamen mit DASH dieses Wort durch "waagerechter Strich" zu übersetzen wird arg lang und auch unübersichtlich.
Das Problem ist also deutlich komplexer und ich frage mich, ob wir uns das wirklich antun sollen. Bei Zeichen, die im Deutschen üblich sind und für die es eine gängige und eindeutige deutsche Bezeichnung gibt, stellt sich die Frage nicht. Aber selbst beim ¿ kann man sich streiten, ob man es als "umgedrehtes Fragezeichen" oder "umgekehrtes Fragezeichen", "kopfstehendes Fragezeichen" oder "spanisches öffnendes Fragezeichen" bezeichnen soll. Andere Zeichen, wie etwa das ª sind im Deutschen schon so unbekannt, dass überhaupt keine gängige deutsche Bezeichnung existiert, schlicht weil dieses Zeichen im Deutschen eben nicht benutzt wird und somit quasi unbekannt ist. Ein eingedeutschter Name für das Zeichen würde daran nichts ändern. --RokerHRO 08:50, 7. Jun. 2007 (CEST)

nochmal.. wird dürfen nicht übersetzen, sondern müssen recherchieren - muss ich Dir die namen auch noch raussuchen, um klarzustellen, das es die namen schon lange (und etabliert) gibt, und zwar seit etwa 1990? aber, wir könnten noch schauen, ob die ISO 10646 damals oder inzwischen eine deutschspachige regelung getroffen hat, die wäre dann natürlich sowieso verbindlich.. -- W!B: 09:26, 7. Jun. 2007 (CEST)

Das Zeichen ¿ hat bei en.wikipedia den Artikel Inverted question mark and exclamation point in Spanish, wunderbar, und alle können damit arbeiten und brauchen nicht weiter zu diskutieren. Hier aber muss alles lang und breit ausdiskutiert werden, wogegen ich nichts habe. Wogegen ich mich wehre, ist, die Flut von Löschanträgen, die gegen solche Leute anrollt, wenn man Artikel wie "umgedrehtes Fragezeichen" oder "umgekehrtes Fragezeichen", "kopfstehendes Fragezeichen" oder "spanisches öffnendes Fragezeichen" anlegt, oder von solchen Bezeichnungen ein Redirect zum "wikipedia-offiziellen" Stichwort macht. --Reiner Stoppok 13:46, 7. Jun. 2007 (CEST)

Der von dir angegebene engl. Wikipedia-Artikel behandelt aber schon ein bisschen mehr. Er erzählt die komplette Geschichte der beiden spanischen Zeichen ¡ und ¿ und das hat IMHO durchaus einen eigenen Artikel verdient. Wohingegen es Blödsinn wäre, die (gemeinsame) Geschichte usw. für diese beiden Zeichen sowoh bei ! als auch bei ? zu erzählen. Ich bin ja geneigt, ihn ins Deutsche zu übersetzen, aber ... wie sollte der Artikel dann heißen? Oder kann man das hier mit unterbringen? Ich glaube, letzteres würde genügen, dann entfällt auch die Suche nach einem geeigneten Lemmanamen. :-) --RokerHRO 10:58, 8. Jun. 2007 (CEST)

aber natürlich, mir wärs lieber, wir würden eine open-source quelle nutzen, aber ich glaub, Bitstream Cyberbit ist nicht internationalisiert, bin aber nicht sicher.. -- W!B: 09:44, 7. Jun. 2007 (CEST)

Das wird in der deutschen WP ganz einfach mit einem Satz im Artikel Fragezeichen erklärt. Und das redirect ¿ dahin haben wir auch. Das ist meiner Meinung nach völlig ausreichend.--Achim Jäger 14:33, 7. Jun. 2007 (CEST)

Wir müssen das Symbolbewusstsein hier mal gründlich erweitern. Ich zum Beispiel bin immer für eine strikte Trennung zwischen Symbol und Bedeutung. Und ʔ, ʡ, ʕ ʢ willst Du auch alle unter die Fragezeichen, lieber Achim Jäger? Das wird zu voll da, fürchte ich. Du machst damit sinnvoll angelegte Sammelartikel zur Müllkippe von Zeichenfetischisten. --Reiner Stoppok 19:56, 7. Jun. 2007 (CEST)

Deine Argumente überzeugen mich nicht. Zu der potenziellen Verwirrung: Deine Befürchtung, ein Zeichen könne nicht mehr gefunden werden, ohne die englische Bezeichnung, bezieht sich wohl eher auf das Gespräch unter Fachleuten, und um die mach ich mir ehrlich gesagt keine Sorgen. Es steht jedem frei, die englische Originalbezeichnung zu benutzen, wenn er fürchtet, anders könne es zu Missverständnissen kommen. Was dein Beispiel mit dem LEFT DOUBLE QUOTATION MARK betrifft, so würde es tatsächlich noch mehr Verwirrung stiften, wenn als Übersetzung "Rechtes doppeltes Anführungszeichen" angegeben würde, was zudem schlicht falsch übersetzt wäre. Die Übersetzung müsste natürlich "Linkes doppeltes Anführungszeichen" lauten. Über die unterschiedliche Verwendung in den verschiedenen Sprachen gibt der Artikel Anführungszeichen Auskunft. Und Dash heißt schlicht und einfach Gedankenstrich. Deine Sorge, die Übersetzung könnte zu lang und unübersichtlich (?) werden, scheint mir sehr gesucht.

Aber du hast natürlich recht, dass die Übersetzungsarbeit keine allzu leichte Angelegenheit ist. Aber diese Arbeit musst du dir ja auch nicht antun. Das erledigen Leute wie Reiner und ich. Natürlich gibt es oft mehrere Möglichkeiten, ein englisches Wort zu übersetzen. Aber dafür gibt es ja eine Diskussionsseite, wo die treffendste Übersetzung besprochen werden kann. Und vieles wiederholt sich auch: "above", "below", "inverted", "modifier letter" etc. Diese Begriffe müssen nur einmal übersetzt werden und können dann durchgängig verwendet werden. Das Ziel ist Einheitlichkeit. Gismatis 01:47, 8. Jun. 2007 (CEST) Und bitte Leute, setzt Leerzeilen zwischen eure Disskussionsbeiträge. Das verringert die Unübersichtlichkeit im Bearbeitungsfeld wenigstens ein bisschen. Und die korrekte Anzahl Doppelpunkte wären auch nicht schlecht!

Naja, wenn "Dash" stets "Gedankenstrich" bedeutet, dann ist die Übersetzung bei Minus nicht richtig.

Was die Anführungszeichen betrifft: Wenn du die Zeichennamen nicht wörtlich übersetzt, sondern die Anordnungen "links" und "rechts" an die Zielsprache anpassen willst, was machst du dann mit Zeichen, die in der Zielsprache gar nicht verwendet werden? Außerdem: wenn du “ (LEFT DOUBLE QUOTATION MARK) mit "Rechtes doppeltes Anführungszeichen" und ” (RIGHT DOUBLE QUOTATION MARK) mit "linkes doppeltes Anführungszeichen" übersetzt, finde ich das schon ziemlich verwirrend. Falsch ist es zudem auch noch, denn im Deutschen werden im Allgemeinen „ (DOUBLE LOW-9 QUOTATION MARK) als öffnendes und “ (LEFT DOUBLE QUOTATION MARK) als schließendes Anführungszeichen verwendet. --RokerHRO 11:11, 8. Jun. 2007 (CEST)

Nochmal, ich fordere ja genau die wörtliche Übersetzung. Hast du meinen Beitrag überhaupt richtig durchgelesen oder nur überflogen? Was den Artikel Minus betrifft: Dort werden die englischen Bezeichnungen nicht übersetzt sondern es werden andere deutsche Namen angegeben. Das ist ein fundamentaler Unterschied. Gismatis 12:14, 8. Jun. 2007 (CEST)

na dann noch einer, der zuerst mal WP:TF und WP:BLG lesen sollte (und zuviel textauszeichnung fett verwendet).. -- W!B: 07:00, 8. Jun. 2007 (CEST)

Seit wann verbieten WP:TF und WP:BLG Übersetzungen? Als Quelle können wir sogar Langenscheidts Taschenwörterbuch Englisch – Deutsch angeben. Und was sollte die Bemerkung mit der Textauszeichnung? Das ist lächerlich! Außerdem ist das ein sehr schlechter Stil von dir, mich nicht mal direkt anzusprechen. Gismatis 12:14, 8. Jun. 2007 (CEST)

stimmt, das war unschön, tut mir leid -- W!B: 13:55, 8. Jun. 2007 (CEST)

"stimmt, das war unschön, tut mir leid" (Benutzer:W!B:) --Reiner Stoppok 15:29, 8. Jun. 2007 (CEST)

Mich stört zwar ebenfalls dieses Festklammern an der englischen Bezeichnung, vor allem wenn mal wieder jemand meint, sie müsste unbedingt in Majusklen erfolgen, aber eine Übersetzung ist nicht unproblematisch. So wurde für viele Schriften der Name aus der englischen Transkription gebildet, die sich häufig von der deutschen Umschrift oder der sprachunabhängigen Transliteration unterscheidet, wenn es sowas jeweils überhaupt gibt. Außerdem ist teilweise eine wörtliche Übersetzung nicht sinnvoll, da die englische Bezeichnung einfach schlecht ist, z.B. weil sie aus älteren. evtl. lokalen Standards übernommen worden ist oder auch durch mangelnde Sachkenntnis. (Bei so einem komplexen Thema irren auch Experten ab und zu.) Ein gutes Beispiel dafür sind die bereits erwähnten Anführungszeichen, bei denen man sich besser durchgehend an die 6-9-Symbolik gehalten hätte.

Die nächste Frage, die die meisten hier zu verneinen scheinen, ist natürlich, ob Wikipedia der richtige Ort für solch eine Übersetzung ist, vielleicht sollte das eher auf Decode Unicode geschehen. Eine deutsche Ausgabe der betreffenden ISO-Norm bzw. eine DIN-Adaption wäre natürlich toll, wird es aber bis auf weiteres nicht geben, da niemand sich den riesigen Aufwand für den geringen Nutzen antut (d.h. bezahlt).

Microsofts Übersetzungen sind teilweise deutlich ad hoc und unprofessionell, aber man kann durchaus für ihre Aufnahme argumentieren, da Benutzer auf sie stoßen werden und danach suchen könnten – als Lemma taugen sie allerdings höchstens nach eingehender Prüfung. Christoph Päper 11:53, 8. Jun. 2007 (CEST)

@Gismatis: WP:TF und WP:BLG verbieten Übersetzungen: nach den Urheberrechtsgesetzen der EU ist eine übersetzung eine eigenleistung mit nötiger schaffenshöhe und daher geschützt: also ist jede übersetzung ein "erschaffen einer Primärquelle" - und genau das verbieten diese beiden richtlinien. bei texten ist jede übersetzung eine interpretation, und kann mit nötiger sorgfalt und angabe des originaltextes kontrolliert werden. wenn es sich aber um einen einzelnen begriff handelt, ist es echte begriffsfindung, weil der begriff damit erstmalig in die deutsche sprache eigeführt wird. das dürfen wir nicht: eine enzyklopädie beschreibt die welt, aber gestaltet sie nicht (immer nur auf "Primärquelle" einzelner themen bezogen, das die WP als ganzes die welt mitgestaltet, ist sowieso was anderes, darin verzetteln wir uns lieber garnicht, und das das ein heres ziel ist, gegen das überall verstossen wird, brauchen wir hier auch nicht erörten)

in dem fall ist es klar: es gibt seit 15 jahren die deutschen worte. deren qualität zu beurteilen, ist nicht aufgabe der WP - wie andernorts gesagt, wenn wir noch andere brauchbare quellen für übersetzungen ins deutsche haben, verschiedene übersetzungen gegeneinander abzuwägen, das passt dann schon, das ist Wikipedia:Recherche - nochmal (ich weiß, es ist hart, besonders in dem fall): jede schlechte information von ausserhalb der WP ist besser als eine, die die WP erfindet. also: fleissig suchen, es wär doch gelacht, wenn die MS-übersetzer die einzigen sind, die das je gemacht haben. wo sind unsere linuxer, wo die open-sourcler, und wo die sprachwissenschaftler, die auf der uni gelernt haben, wie jedes einzelne teil in fachkreisen heisst? ich trag noch immer auf die ISO 10646 an, die muss es doch deutsch geben - und wenn nicht, der tipp mit decodeunicode.org ist super: dort begriffe etablieren ginge schon, dann schreiben wir hier drüber, ohne uns unseren mühsam aufgebauten ruf zu zerstören ;) -- W!B: 13:55, 8. Jun. 2007 (CEST)

jetzt ist mir eingefallen, wie ich das kurz sagen kann: wenn der artikel Möve unten heisst, machen wir uns lächerlich, wenn er Verbindungszeichen Doppelbogen unten heisst, macht sich die Firma Microsoft lächerlich, und wir berichten nur darüber - das ist der unterschied -- W!B: 14:28, 8. Jun. 2007 (CEST)

W!B, ich bin baff! Wie du über den Umweg der Urheberrechtsgesetze der EU und deren Definition von Übersetzungen als Primärquelle zum Schluss kommst, dass WP:TF und WP:BLG Übersetzungen verbieten, das ist schon erstaunlich! Dieser Kunstgriff ändert aber nichts. Dass das Urheberrechtsgesetz der EU Übersetzungen als Primärquelle definiert (was ich dir einfach mal glaube) ist nämlich völlig irrelevant. Das ist eine rein juristische Definition und für die enzyklopädische Arbeit hier nicht von Bedeutung. Auch bei der Übersetzung eines ganzen Textes müssen mitunter einzelne Begriffe übersetzt werden, die es in dieser Verwendung im Deutschen bisher nicht gab. Und selbst wenn man einen Begriff in der Originalsprache belässt, die Angabe einer Übersetzung erhöht die Benutzerfreundlichkeit, vor allem wenn es sich um einen Begriff aus einer anderen Sprache als englisch handelt. Hier ist ein Beispiel, und deren gibt es in der Wikipedia viele. Es bleibt dabei, WP:TF und WP:BLG verbieten Übersetzungen nicht. Gismatis 04:02, 9. Jun. 2007 (CEST)

汉语拼音文字? Im Lexikon steht phonetisches Alphabet der chinesischen Sprache, ich persönlich finds wörtlich etwas holprig, aber zeichenweise übersetzung hat auch ihre vorteile.. wenn Du was anderes meinst, was? -- W!B: 10:32, 9. Jun. 2007 (CEST)

Lieber W!B:! Ich bitte Dich um stärkere Konzentration. Bitte hübsch beim Thema bleiben. Du wirst bestimmt ein Dutzend sinnvoller Übersetzungen von dem zitierten "汉语拼音文字" zusammenbekommen, wenn Du nur anfängst, einmal richtig darüber nachzudenken. --Reiner Stoppok 14:42, 9. Jun. 2007 (CEST) PS: Welches Lexikon meintest Du hier?

Entdeckt: Der Artikel Breve (Unterzeichen) enthält folgenden Abschnitt:

Der Zeichensatz Unicode enthält die folgenden Zeichen mit Breve darunter:

• Großbuchstabe H mit Breve darunter (Ḫ) U+1E2A
• Kleinbuchstabe H mit Breve darunter (ḫ) U+1E2B
• Kombinierende Breve darunter (kann mit jedem Buchstaben kombiniert werden) U+ 032E

Da wurde also bereits völlig abseits dieser Diskussion munter übersetzt! Gismatis 04:36, 11. Jun. 2007 (CEST)

Bist Du da etwa überrascht? Da gibt es noch viel mehr von. --Reiner Stoppok 18:27, 11. Jun. 2007 (CEST) PS: Hier hat das Problem auch schon mal "jemand" im großen Stil gelöst: Traduction française officielle de l’ISO/CEI 10646 et Unicode.

Es gibt also die folgenden Möglichkeiten für die Benennung des rechts abgebildeten Unicode-Symbols falls man darüber einen Artikel schreiben möchte (Fallbeispiel: U+033C):

 ̼

(Diesen Wahlzettel bitte ergänzen und verbessern.):

1. "Verbindungszeichen Doppelbogen unten" (so bei Microsoft, siehe z.B. unten: Zeichentabelle "Arial Unicode MS")

**Die Qualität dieser Bezeichnung ist in diesem Falle fragwürdig, da es sich hier nicht um Bögen handelt. (Siehe auch Löschdiskussion 7.6.2007 )

2. "COMBINING SEAGULL BELOW" oder "Combining seagull below" (nach Unicode)

**Dazu die Fragen: Wie soll mit verschiedenen Bezeichnungen einzelner Symbole/Zeichen in den verschiedenen Unicode-Versionen umgegangen werden? Soll die GROSSSCHREIBUNG streng beibehalten werden? Die offizielle französische Übersetzung lautet 033C DIACRITIQUE MOUETTE SOUSCRITE

3. "Verbindungszeichen Möwe unten" (wörtliche Übersetzung der Unicode-Bezeichnung)

**Frage: Darf man mit solchen Neubenennungen Lemma anlegen, soll man Redirects von ihnen aus auf die "offiziellen" englischen Unicode-Bezeichnungen oder auf die deutschen "halboffiziellen" (und manchmal unpräzisen) Microsoft-Bezeichnungen machen? (Siehe auch: Verbindungszeichen).

4. Verwendung von Kurzwörtern im Text, hier z.B. das ebenfalls oft verwendete "Seagull below" (wobei die dt. wörtlich übersetzten Kurzbezeichnungen, wie beispielsweise "Möwe unten" oder auch "Möve unten", bei manchen auf Ablehnung stossen), aber nicht als Lemma.

Frage: Hiess das nicht mal "Seagull below" in einer alten Unicode-Version? Wie soll man mit den verschiedenen Benennungen einzelner Zeichen in den verschiedenen Unicode-Versionen umgehen? --Reiner Stoppok 21:11, 8. Jun. 2007 (CEST) PS: Hier eine Möwe unten, allerdings nicht im Flug abgebildet

5. Das Zeichen direkt als Lemma nehmen

Nachteil: Eingabeprobleme. Deutsche Namensgebung wird evtl. nicht ausreichend geklärt.

6. U+033C (die Unicode-Kodierung) als Lemma nehmen

Nachteil: Die Bezeichnung kann sich niemand merken. Deutsche Namensgebung wird evtl. nicht ausreichend geklärt.

7. Das Zeichen soll kein eigenes Lemma erhalten, sondern redirected werden nach Internationales Phonetisches Alphabet und dort eingebaut werden.

Eine derzeit häufig in den Löschdiskussionen vertretene Position. Das Problem ist, dass sich viele Unicode-Zeichen nicht eindeutig bestimmten Sachgruppen zuordnen lassen, wie es in diesem Falle die Lautzeichen des IPA wären. Viele Unicode-Sybole und -Zeichen haben mehrere Bedeutungen und gehören zu mehreren Sachgruppen.

8. Das Zeichen soll kein eigenes Lemma erhalten, sondern redirected werden zu einem Lemma über einen Unicode-Block und dort behandelt werden

9. Möwe (diakritisches Zeichen)

Siehe mein Beitrag am Ende des Abschnitts Weiteres zu Artikelnamen. Gismatis 04:14, 11. Jun. 2007 (CEST)

10. Keine sinnlosen Lemmata, keine sinnlosen Weiterleitungen. Ein eigenes Lemma nur fuer Zeichen mit "Alleinstellungsmerkmal", d.h. genuegend interessante Informationen existieren. Ansonsten nur Behandlung in Listen. Relevanzkriterien ausarbeiten und Aufnahme in WP:RK beantragen

11. Möwe unten (diakritisches Zeichen)

In Anlehnung an die offizielle französische Übersetzung DIACRITIQUE MOUETTE SOUSCRITE. So wird auch die Position genauer anzugeben.

(bitte diesen Wahlzettel ergänzen und verbessern, auch optisch)

Weblinks

• Unicode Character 'COMBINING SEAGULL BELOW' (U+033C)

• [2]

Datei:Verbindungszeichen Doppelbogen unten.jpg

Screenshot Zeichentabelle

____________________

Weiteres zu Artikelnamen

 ;) gut gekontert.. ich wär ja noch immer dafür, einen sammelartikel für den ganzen Block 0300–036F Combining Diacritical Marks unter Kombinierende diakritische Zeichen zu erstellen, damit drücken wir uns elegant vor dem namensproblem, bis die wogen sich geglättet haben, später teilen können wir immer noch, wenn der artikel dann die 150kB-Marke sprengt.. dann wissen wir vielleicht auch, in welcher sprache die zeichen überhaupt vorkommen, und was für einen sinn sie haben: Bußmann, Hadumod: Lexikon der Sprachwissenschaft. Stuttgart 2002 steht in Diakritische Zeichen, vielleicht hat der was - es wird wahrscheinlich heutzutage schon schwer, auch nur redirs der form U+036F anzulegen, und noch genug zeichen mit konfliktpotential (ich hätte ja noch immer ∮ redir Kurvenintegral gern, aber derzeit trau ich mich nicht, also bitte jetzt nicht anlegen).. -- W!B: 10:08, 9. Jun. 2007 (CEST)

Lieber Benutzer:W!B:! Bei dieser Diskussion hier geht es a) nicht speziell um Zeichen aus bestimmten Sprachen oder Schriften, b) nicht speziell um die Gruppe der diakritischen Zeichen aus Unicode, c) nicht darum, Grüppchen zu einzelnen Unicode-Blöcken zu bilden (obwohl diese Idee natürlich Sinn macht). Es geht einzig und allein darum, für diejenigen "Wikipedianer" Möglichkeiten auszudiskutieren, die für ein beliebiges Unicode-Zeichen Artikel schreiben möchten. --Reiner Stoppok 14:32, 9. Jun. 2007 (CEST) PS: "Der" von Dir zitierte Hadumod Bußmann ist übrigens eine Frau und hat im Lexikon der Sprachwissenschaft ganz andere Sorgen. Ich würde das Wort "Verbindungszeichen" (statt:Kombinierende) immer bevorzugen. Dazu habe ich auch ein Lemma angelegt.

oh, peinlich, ich bitte sie hiermit um verzeihung, ich bin da nicht heikel - was ich damit gemeint hab, ist, dass artikel zu gewissen unicodezeichen wohl sinnvoll sind, aber nicht prinzipiell. Du hast mit ! eh ein gutes beispiel gegeben (LA-seite): in dem fall hielte ich es sinnvoll, denn der sachverhalt „Rufzeichen“ ist nicht ident mit dem sachverhalt „!“ - Rufzeichen ist auch "¡", und "!" ist auch Fakultät, Klicklaut, … „Satzzeichen“ ist es dann keines - tatsächlich widerspricht der artikel jetzt den grundsatz ein artikel = ein sachverhalt (und in dem artikel fehlt die unicode nummer überhaupt) - ich denke dass es wichtiger wäre, sich auf den sachverhalt „Schriftzeichen“, statt auf „Unicodezeichen“ zu konzentrieren: unicode gibt ja nur einen standard vor - wie würde dann der artikel zum schriftzeichen «!» selbst heissen? ich denke, dass wär ein gutes beispiel, eine "Namenskonvention" für schriftzeichen-artikel zu entwickeln, die dann auf alle unicode-artikel funktionieren würde -- W!B: 05:15, 10. Jun. 2007 (CEST)

Eine Namenskonvention für Schriftzeichen ist nötig. Diese Diskussion hier sprengt den Rahmen dieser Diskussionsseite. Wie aus meinem Beitrag weiter unten klar wird, stimme ich dir zu, beim Anlegen von Artikeln von Schriftzeichen auszugehen und nicht so sehr von einzelnen Unicode-Zeichen. Gismatis 04:28, 11. Jun. 2007 (CEST)

PS ich hab eine überschrift eingefügt, und ausgerückt

.. und Verbindungszeichen find ich gut - sollen wir den wir die windows-übersetzung als redir ansetzen, oder mal aussen vorlassen? wenn die LA-disk den windows-namen bei U+036F akzeptiert, und auch, dass es einen artikel zu genau dem einen zeichen gibt, wäre er dann in dem fall auch relevant - akzeptiert sie in nicht, dann sollte er wohl auch rot bleiben? -- W!B: 05:19, 10. Jun. 2007 (CEST)

noch ein nachtrag, grad gefunden..: U+01C3 „Lateinischer Buchstabe retroflexiver Click“ (wie üblich, MS Zeichentabelle) ! steht nicht für den Klicklaut, sondern ! - er wird ersetzt durch dieselbe font, darum ist er nicht rot: das hiesse, formal gesehen ist das ein {badname}-problem, und müsst über eine BKL ! steht für.. gelöst sein, da aber das Rufzeichen weitaus primär ist, im artikel Ausrufezeichen ein {Dieser Artikel|beschreibt das Unicodezeichen U+0021; zu U+01C3 siehe Postalveolarer Klick.} stehen.. - und U+01C3 dorthin redirecten -- W!B: 05:47, 10. Jun. 2007 (CEST)

Wunderbar, was Du alles entdeckst. Aber mit der Verfeinerung der Wahlliste für einen demokratischen Abstimmungsprozess sind wir damit um keinen Millimeter weitergekommen. --Reiner Stoppok 15:02, 10. Jun. 2007 (CEST)

"Kombinierende Zeichen" heißen die Dinger in der Zeichenpalette von Apple. Aber auch "Verbindungszeichen" ist gut. Wichtig ist vor allem eins: Diese Zeichen gehen eine nicht mehr trennbare Verbindung mit dem Trägerzeichen ein. Anders formuliert: Sie wirken kombinierend. Das scheint mir das Hauptmerkmahl dieser Zeichen zu sein. Alle anderen modifizierenden Zeichen, die das nicht tun, heißen bei Unicode "Modifier letters". Gismatis 04:19, 11. Jun. 2007 (CEST)

Ich bin mir jetzt sicher, dass die Übernahme der Unicodebezeichnungen als Lemma, sei es in der Form des englischen Originals oder der deutschen Übersetzung der falsche Weg ist und nicht zu einer Einheitlichkeit führen kann. Was wir brauchen ist ein Schema, das sich auf alle diakritischen Zeichen (und nur um die geht es mir jetzt im Moment) anwenden lässt. Dazu Folgendes: Im Artikel Diakritisches Zeichen findet sich eine Auflistung diverser diakritischer Zeichen. Da steht dann z. B. „Komma, untergesetztes“, „Unterstrich“ und „Punkt darunter“ (da war jemand bereits sehr kreativ, von Einheitlichkeit keine Spur). Die haben alle eigene Artikel. Wenn man den Links folgt, kommt man zu den Artikeln Komma (Unterzeichen), Makron (Unterzeichen) und Punkt (Unterzeichen). Mit Hilfe des Begriffs „Unterzeichen“ wurde hier Einheitlichkeit erzielt. Inspiriert durch diese Einheitlichkeit schlage ich also vor, das Lemma zu einem Artikel über diakritische Zeichen nach einem der folgenden Schemas zu wählen:

• Name des diakritischen Zeichens z. B. Makron

Diese Möglichkeit eignet sich nur, wenn der Zeichenname bereits eindeutig ist. Deshalb sollte eher diese Möglichkeit zur Anwendung kommen:

• Name des diakritischen Zeichens (diakritisches Zeichen)

Für  ̼ also Möwe (diakritisches Zeichen). Ja, richtig! Möwe als Name des diakritischen Zeichens, genauso wie Breve, Akut usw. Man könnte auch die Bezeichnung „Unterzeichen“ aufgreifen:

• Möwe (Unterzeichen)

Daran finde ich problematisch, dass die Unterscheidung eines diakritischen Zeichens nach der Setzung über oder unter einem Buchstaben oft nicht relevant genug ist. Auch frage ich mich, woher die Bezeichnung „Unterzeichen“ stammt, und ich vermisse den Begriff „Überzeichen“ als Äquivalent zum „Unterzeichen“ für übergesetzte Diakritika. Mein Favorit wäre die zweite Möglichkeit, und die trage ich deshalb auch oben ein. Ich weiß, das führt jetzt einen neuen Ansatz ein. Aber deutlich wird der Vorteil dieser Methode, wenn es zu einem abstrakt betrachtet einzigen Zeichen mehrere Unicode-Zeichen gibt. Ein Beispiel ist das Zeichen Ring, zu dem es sogar einen Artikel gibt, wenn auch unter der auch nicht gerade deutschen Bezeichnung Kroužek. Auch behandelt der Artikel nur einen Teilaspekt dieses Zeichens. Der englische Artikel zeigt eher, was ich meine. In Unicode gibt es vier Ring-Zeichen: Allein stehend je oben und unten sowie kombinierend je oben und unten. Also: Vier Zeichen in Unicode = ein Zeichen abstrakt betrachtet = ein Artikel = ein Lemma. Es ist offensichtlich, dass hier die Unicode-Benennungen kein geeignetes Lemma bieten. Gismatis 04:05, 11. Jun. 2007 (CEST)

 Pro das erscheint mir ein ausgezeichneter ansatz - und das möchte ich auch sagen, mit dieser methode seh ich auch nicht mehr ein problem mit WP:TF, weil es sich (wie bei dem :en beispiel) eindeutig um einen "artikeltitel" handelt, der sofort klarstellt, dass "ring" deskriptiv als "ringförmig" gemeint ist und das zeichen fachlich jeweils spezifische namen hat - eben Kroužek, keinen in Å (und dort auch klargestellt) oder r̥ , und auch "ring below" ist dort nur überschrift - das würde ich ;) dann auch für Möwe (diakritisches Zeichen) gelten lassen, wenn er ausdrücklich klarstellt, dass das eine beschreibung im sinne des fachlich korrekten (weil gernormten) SEAGULL ist, und nicht der fachausdrück - so ists keine begriffsetablierung, weil dann niemand sagen kann: "in der WP steht Möwe, also heisst es so.." oder ein sprachwissenschaftler in zehn jahren in einer arbeit feststellt, dass der name am 11.06.2007 das erste mal im deutschen belegbar ist, und zwar in der WP.. -- W!B: 06:52, 11. Jun. 2007 (CEST)

Das freut mich sehr, dass ich es geschafft habe, einen Vorschlag zu bringen, dem du zustimmen kannst! Übrigens, wird das Zeichen eigentlich wirklich "Seagull" genannt, oder ist das nicht auch einfach eine beschreibende Erfindung des Unicode-Konsortiums? Ansonsten würden wir nämlich wieder Begriffsetablierung betreiben, wenn wir einfach schrieben, das Zeichen werde im Englischen "Seagull" genannt. Gismatis 03:15, 13. Jun. 2007 (CEST)

Unterzeichen klingt nach einer sehr holprigen Übersetzung, so als ob es zu gewissen Zeichen noch eine "Unterkategorie", nämlich "Unterzeichen" geben würde oder sowas, was natürlich Blödsinn ist.

Außerdem: Wie nennt man dann die Diakritika, die über oder neben dem Buchstaben stehen? Was wird z. B. aus COMBINING RING ABOVE? Ein Kombinationszeichen Ring drüber? Oder Kombinierender Ring drüber oder Ring (Überzeichen)? Ich finde "(Diakritisches Zeichen)" als Lemmazusatz vollkommen ausreichend, dort können dann die Varianten mit ABOVE und BELOW gemeinsam behandelt werden. Oder? --RokerHRO 11:09, 11. Jun. 2007 (CEST)

Richtig. In den allermeisten Fällen wird eine Aufteilung von Artikeln nach Plazierung des Zeichens nicht sinnvoll sein. Wenn es aber doch vorkommt, wie schon beim Makron (Unterzeichen), muss man das irgendwie im Lemma unterbringen. Die Bezeichnung "Unterzeichen" sollte nochmal überprüft werden. Als Alternative fände ich den lediglich beschreibenden Ausdruck "übergesetzt" eine gute Lösung.

Was mir an Makron (Unterzeichen) auch nicht so gefällt, ist, dass der Leser meinen könnte, beim Makron selbst handle es sich um ein Unterzeichen, was natürlich falsch ist. Korrekter wäre deshalb meiner Meinung nach das Lemma Makron als Unterzeichen. Gismatis 03:15, 13. Jun. 2007 (CEST)

Verzeiht mir, wenn ich Euch ins Wort falle. Der Vorschlag von Gismatis macht Sinn. Es ist ein Ausdruck, der sich sowohl von Microsoft als auch von Unicode losgelöst hat. Plastisch, leicht zu merken. Der Ausdruck "Verbindungszeichen", den Microsoft hier bei der Benennung dieses Zeichens mitverwendet (und auch für viele andere Zeichen), und der an sich nicht schlecht ist, ist in diesem Fall überflüssig, da die diakritischen Zeichen sowieso Verbindungszeichen bzw. "kombinierende Zeichen" (ein holpriger Ausdruck) sind. Das Wort "Verbindungszeichen" wäre prima dafür geeignet, ein oben, unten, rechts, links, Mitte usw. nachzustellen (statt Überzeichen, Unterzeichen, Mittezeichen (?) usw.). Das Problem sehe ich bei den Symbolen, die an mehreren Stellen vorkommen (die Möwe fliegt ja nur unten herum). Wie, lieber Gismatis, würdest Du mit der Möwe umgehen, gesetzt den Fall, sie würde auch oben und in der Mitte vorkommen, wie beispielsweise bei meinem (qualitativ minderwertigen und sicherlich noch umzubenennenden) Testballon Tilde (IPA)? Viele Bezeichnungen bei Unicode und Microsoft sind ja nur deshalb umständlich, weil sie sich von vielen ähnlichen Zeichen irgendwie abheben mussten. Irgendwie sollten wir uns deren Erfahrungen im Umgang mit der riesigen Zeichenmenge auch zunutze machen. Die bei "Tilde (IPA)" aufgeführten Beispiele für das Vorkommen in den Unicode-Namen sind keineswegs vollständig. --Reiner Stoppok 17:52, 11. Jun. 2007 (CEST) PS: Suchwort: RING (Unicode)

Welchen Ausdruck meinst du jetzt? Diakritisches Zeichen? Ich habe dir weiter oben in diesem Abschnitt schon geschrieben, dass ich diakritische Zeichen und Verbindungszeichen nicht wirklich für dasselbe halte. Es ist zwar oft dasselbe, weil für die Darstellung am Computer meist ein Verbindungszeichen zur Anwendung kommt. Der Ausdruck diakritisches Zeichen bezieht sich meiner Ansicht nach auf die Verwendung als Schriftzeichen, völlig unabhängis vom verwendeten Zeichensatz und von der Kodierung. Das bedeutet, das Zeichen ^ in â ist zwar ein diakritisches Zeichen, aber es ist kein Verbindungszeichen, da â als ein Zeichen kodiert ist. Der Begriff Verbindungszeichen (combining characters) bezieht sich demnach ausschließlich auf die Art des Zeichens am Computer, jedenfalls taucht der Begriff nur in dieser Verwendung in der Unicodetabelle auf. Dort bezieht er sich auf Zeichen, die mit dem Trägerzeichen verschmelzen.  ̂ (U+0302, COMBINING CIRCUMFLEX ACCENT) ist somit ein Verbindungszeichen ("kombinierendes Zeichen" gefällt mir übrigens besser). Für die Darstellung muss man es auf ein Leerzeichen setzen. Das Zeichen ^ (U+005E, CIRCUMFLEX ACCENT) braucht kein Trägerzeichen. Es kann zur Darstellung des abstrakten Zeichens Zirkumflex dienen, das heißt, wenn man einfach ein einzlnes Zirkumflex darstellen will. Oder liege ich hier falsch? Anders gefragt, bezieht sich "combining character" ausschließlich auf Unicode oder nicht?

Nun zu deiner Frage. Wenn ein diakritisches Zeichen in unterschiedlichen Plazierungen vorkommt (was meistens der Fall ist), würde ich zuerst die Verwendung in bestimmten Bereichen behandeln und innerhalb dieser Bereiche nach Plazierung, oder umgekehrt, je nach dem, was sinnvoller ist. Die Plazierung würde ich nur mit beschreibenden Worten behandeln. Für die Kodierung in Unicode würde ich einen separaten Abschnitt oder eine Tabelle einrichten, wo erläutert wird, welche Plätze das Zeichen in Unicode belegt. Was dein Artikel Tilde (IPA) betrifft, so frage ich mich, ob man nicht einfach im Artikel Tilde einen entsprechenden Abschnitt einrichten könnte. Alle Angaben zu Unicode würde ich sowieso im Artikel Tilde unterbringen, weil es um das Zeichen an sich ausschließlich im Hauptartikel gehen soll. Gismatis 03:15, 13. Jun. 2007 (CEST)

Wie weit soll man sich im Deutschen aber von ISO/CEI 10646 und Unicode selbst und von der offiziellen französischen Übersetzung von ISO/CEI 10646 und Unicode (Traduction française officielle de l’ISO/CEI 10646 et Unicode) entfernen? Und von den deutschen Microsoft-Bezeichnungen (Zeichentabelle: Arial Unicode MS)? Ich finde, es müsste bei de.wikipedia eine Art Metaebene für die deutschen Unicode-Bezeichnungen geben, um nicht völlig ins internationale teminologische Abseits zu geraten. Von dieser Ebene aus könnte man dann ja sehen, wo das Zeichen überall in Einzelartikeln vorkommt. Zugegebenermaßen sind nicht alle Symbole lexikontauglich für einen Einzelartikel. Wir müssen die Unicode-Zeichen doch aber des öfteren irgendwie benennen, ohne für sie gleich einen Artikel schreiben zu wollen. Lieber Gismatis, für mich wird das hier immer verwirrender ... --Reiner Stoppok 17:27, 13. Jun. 2007 (CEST) PS: "DIACRITIQUE MOUETTE SOUSCRITE" heisst das Verbindungszeichen Möwe unten (Combining seagull below) übrigens auf französisch.

Der Gegenstand ist komplexer, als wir gedacht haben. Zu deinen Fragen: Um die deutsche Übersetzung der Unicode-Bezeichnungen zu besprechen, ist die Diskussionsseite des Artikels Liste von Unicode-Zeichen geeignet. Außerdem empfehle ich die Schaffung einer Namenskonvention für Schriftzeichen. Wie weit soll sich die deutsche Bezeichnung der Unicode-Zeichen von der Originalbezeichnung entfernen? Antwort: So wenig wie möglich! Wo etablierte deutsche Bezeichnungen existieren, können wir diese verwenden. Wo dies nicht der Fall ist, halten wir uns am besten möglichst eng an die englische Originalbezeichnung. Dann können wir nichts falsch machen und die Gefahr des Vorwurfs der Begriffserfindung wird mit dem Hinweis begegnet, es handle sich lediglich um Übersetzungen, was aus dem Artikel auch klar werden muss. Alles andere ist nach den Wikipedia-Richtlinien nicht gestattet. Inwiefern diese Übersetzungen als offizielle Bezeichnungen aufgefasst werden und Eingang in die Fachsprache finden, ist nicht unser Problem. Die Wikipedia beeinflusst den Sprachgebrauch sowieso, indem sie zur Verbreitung von Begriffen und Bezeichnungen beiträgt. Und noch was: Vergiss Arial Unicode MS. Die dortigen Bezeichnungen können allenfalls als Inspiration dienen. Zuerst muss jetzt der Artikel Liste von (nicht der?) Unicode-Zeichen ausgebaut werden. Ich selbst werde mich bei der Artikelarbeit wahrscheinlich eher zurückhalten. Ich werde mich aber gerne an der Übersetzungsdiskussion beteiligen. In der neu zu schaffenden Namenskonvention Schriftzeichen kann diskutiert werden, wie verwandte Unicode-Zeichen in einem Artikel zusammengefasst werden, und wie die Lemmas lauten sollen. Soviel zu meinen Empfehlungen.

Ich hoffe, ich konnte mit dieser Antwort deine Verwirrung lindern. Die ganze Arbeit wird viel Zeit brauchen. Es gibt keine einfache Lösung. Wir werden noch viel diskutieren und überlegen müssen, und viele Fragen werden erst mit der Zeit beantwortet werden können. Gismatis 05:33, 16. Jun. 2007 (CEST)

Welcher Weg führt zu solch einer Namenskonventionfür Schriftzeichen? - Noch ein kurzer Zwischenruf: Liste von Unicode-Zeichen nur solange, wie sie nicht vollständig ist. Dann soll sie natürlich "Liste der Unicode-Zeichen" heissen! Die Arbeit daran schreitet ja bereits munter fort ...--Reiner Stoppok 11:32, 16. Jun. 2007 (CEST)

Zum Lemma äußere ich mich noch auf der Diskussionsseite. Was die Schaffung einer Namenskonvention betrifft, empfehle ich folgendes Vorgehen:

1. Richte eine Unterseite in deinem Benutzernamensraumm ein, z. B. Benutzer:Rainer_Stoppok/Baustelle, auf der die Namenskonvention aufgebaut werden kann
2. Lade auf Wikipedia_Diskussion:Namenskonventionen Interessierte dazu ein, bei der Schaffung der Namenskonvention mitzuarbeiten
3. Wenn die Namenskonvention Gestalt angenommen hat, kann sie nach Wikipedia:Namenskonventionen/Schriftzeichen verschoben werden

Gismatis 18:33, 16. Jun. 2007 (CEST)

Voilà! Bitte optisch und inhaltlich verbessern. --Reiner Stoppok 23:26, 16. Jun. 2007 (CEST) PS: Siehe auch Löschdiskussion 7.6.2007

ǃ versus ! (bitte anklicken)

Das erste Symbol ist kein Ausrufezeichen, das zweite kein Postalveolarer Klick. Soll man das erste Zeichen unter dem zweiten behandeln? --Reiner Stoppok 21:45, 10. Jun. 2007 (CEST)

Natürlich nicht! Ein Verweis auf das ähnlich/gleich aussehende (und wahrscheinlich auch aus dem Ausrufezeichen hervorgegangene) IPA-Zeichen für den Klicklaut ist aber durchaus angebracht, so wie es derzeit ja im Artikel ! auch gemacht worden ist. --RokerHRO 22:24, 10. Jun. 2007 (CEST)

ähem, toll, und wie hast Du das gemacht, bei mir hat das nicht geklappt - würd mich aber nicht wundern, wenn die MS-zeichentabelle das zeichen irgendwie verschluckt.. -- W!B: 06:56, 11. Jun. 2007 (CEST)

• [3]

Grundsatzdiskussion

Eigentlich sollte eine grundsätzliche Diskussion darüber geführt werden, ob Unicodezeichen als Einzellemma überhaupt relevant sind und danach unter welcher Bezeichnung. Eine Abstimmung über den Namen eines einzelnen Zeichens halte ich in diesem Zusammenhang offengesagt für Unsinn. Ich habe mich mal hier [4] dazu geäussert. Alauda 18:35, 9. Jun. 2007 (CEST)

Dieser Vorschlag kann übergangen werden und ist schon dadurch überholt, dass es bereits seit langem jede Menge Artikel dazu gibt. Offenbar hast Du die Diskussion hier obendrüber nicht verfolgt. Falls Dich das Thema überhaupt interessiert, schlage ich Dir vor, Dich zunächst einmal an den Standpunkten von Benutzer:Gismatis in dieser Diskussion zu orientieren. --Reiner Stoppok 18:58, 9. Jun. 2007 (CEST)

Hast Du eigentlich übersehen, dass dauernd Löschanträge gegen Unicodeartikel gestellt werden? So ganz überholt ist dieser Vorschlag wohl nicht, es sei denn, man will über jeden einzelnen Unicodeartikel eine Löschdiskussion führen, wie das jetzt der Fall ist und noch schlimmer werden könnte, wenn noch mehr Artikel angelegt werden. Scheinbar ist das auch kein Dauerstreit zwischen dir und Benutzer:Achim Jäger, da auch andere Benutzer Löschanträge gestellt haben. (Anmerkung: Stimmt. Die anderen aber aus (berechtigten) inhaltlichen Gründen. Nicht wegen der Überschrift des Lemmas. --Reiner Stoppok 20:27, 9. Jun. 2007 (CEST))

Im Prinzip ist es wichtig, dass

• Ein klarer Konsens über die Relevanz von Unicodeartikeln erzielt wird
• Ein klarer Konsens über die Bezeichnung der entsprechenden Lemma erzielt wird

Auf diesen Konsens kann man sich dann in Löschdiskussionen beziehen. Erst dann macht es Sinn weitere Artikel anzulegen. Ich habe auf der Löschseite z.B. den Vorschlag gemacht prinzipiell nur maximal 2-Byte-Zeichen als lemmatauglich anzusehen, damit es ein generelles und objektives Kriterium gibt, unter welchen Bedingungen Zeichen relevant sind und wir nicht 190000 Unicodeartikel verfassen. Alauda 19:19, 9. Jun. 2007 (CEST)

Wenn Du mein Freund sein willst, liest Du jetzt bitte, was Gismatis hier oben drüber so alles gesagt hat. (Ich selber war manchmal zu aufgeregt und habe mich von Studenten im Grundstudium und kräftigen Jünglingen, die hier nicht her gehören, zu weitschweifigen Diskussionen verleiten lassen. Das hier ist aber Männersache, da müssen echte Kerle ran.) Vielleicht schreibst Du mal einen Artikel zu den "2-Byte-Zeichen", damit Dir alle folgen können. Wir waren hier obendrüber bereits schon so weit, die wesentlichen Standpunkte umrissen zu haben, daher war ein neuer Absatz überflüssig. Oben liegt ein Wahlzettel aus. Bitte verfeinere den mal mit. Dann können "wir" später sagen: Wir (der egal-jetzt-mal-wie-viel-Unicode-Zeichen-Fan-Club) haben uns auf diese Richtlinien in der Diskussion geeinigt. Und wer dagegen anstinken will, der bekommt dann von allen eins auf die Nase, bis das Blut spritzt. --Reiner Stoppok 20:12, 9. Jun. 2007 (CEST)

Den Artikel zu Zwei-Byte-Zeichen gibts schon: [5]. Alauda 20:41, 9. Jun. 2007 (CEST)

Ich hatte angenommen, darin seien schon alle Zeichen erfasst?! Bitte Sprache "entinformatiken". --Reiner Stoppok 21:04, 9. Jun. 2007 (CEST)

Beitrag zur Diskussion: U+033C bei decodeunicode: *[6]

Ich glaube aber kaum, dass sich da die englische Benennung nach der deutschen gerichtet hat ... --Reiner Stoppok 03:02, 23. Aug. 2007 (CEST)

Redirects von den Unicode-Zeichen auf die beschreibenden Artikel

Ich möchte vorschlagen, dass von jedem Unicode-Zeichen ein Redirect auf den beschreibenden Artikel angelegt wird. igel+- 17:01, 3. Jun. 2007 (CEST)

Behalten. --Reiner Stoppok 17:08, 3. Jun. 2007 (CEST)

Okay, dann fang doch schonmal mit U+0000 bis U+0031 an und trage mehr Informationen zusammen, als bereits bei Steuerzeichen steht. :-/ --RokerHRO 22:31, 3. Jun. 2007 (CEST)

Da sind doch viele nützliche Redirects gerade in der Löschdiskussion. - Wer bereinigt denne mal die technischen Schwierigkeiten bei: Liste von Unicode-Zeichen? --Reiner Stoppok 00:11, 4. Jun. 2007 (CEST)

Ich zweifele ein wenig an dem Nutzwert dieser Liste... --RokerHRO 11:51, 4. Jun. 2007 (CEST)

Es geht bei dieser Liste nur um eine Demonstration für die Diskussion hier drüber (siehe oben). --Reiner Stoppok 17:07, 4. Jun. 2007 (CEST)

Beitrag zur Diskussion: *[7]

 ;) -- W!B: 14:57, 5. Jul. 2007 (CEST)

Eine Katastrophe mehr! --Reiner Stoppok 17:12, 5. Jul. 2007 (CEST)

Wieso?

Siehe Anm. oben. --Reiner Stoppok 03:03, 23. Aug. 2007 (CEST)

Weitere Links einfügen?

Die offiziellen Kodierungsvorschläge enthalten teilweise recht wertvolle Informationen zu den einzelnen Zeichensystemen. Vielleicht wäre es sinnvoll, nach und nach Links zu diesen Vorschlägen auch bei bereits kodierten Bereichen einzufügen, soweit sie verfügbar sind.
Ich wüßte gern, was andere Wikipedianer davon halten. Lohnt der Aufwand? --Jirret 22:47, 10. Feb 2005 (CET)

Mal ins Unreine gedacht, würde ich sagen, dass wäre zuviel des Guten. Wäre es nicht mit viel geringerem Aufwand fast genausogut, auf das Dokumentenverzeichnis und die Roadmap zu linken? --Pjacobi 23:21, 10. Feb 2005 (CET)

Die Roadmap ist komplett verlinkt. Für mich selbst ist es einigermaßen praktisch, die internen und externen Links gleich nebeneinander zu finden. Ich habe für mich die Dokumente mit den ach so aussagekrftigen Namen Nxxx.pdf ordentlich benannt, und so wäre die Verlinkung der älteren Vorschläge nicht allzu aufwendig, da sich die Links nur durch die Ziffern hinter N unterscheiden. Die Frage ist, ob es nützt. Nun, in den nächsten Wochen bin ich ohnehin mit existenzwichtigen Dingen ausgelastet, u. A. Mitarbeit an einem Kodierungsvorschlag. --Jirret 00:00, 11. Feb 2005 (CET)

Farben

Siehe unbedingt Wikipedia:Farben! Gibts für die Farben im Artikel irgendeinen triftigen Grund? Ich setz mir den Artikel auf die todo-list, in ein paar Tagen werden die getilgt. --BLueFiSH ?! 13:51, 13. Sep 2005 (CEST)

     Füür den ganzen Artikel gibt es keinen vernünftigen Grund mehr. Jirret 17:03, 13. Sep 2005 (CEST)

Wieviele Zeichen?

Hier stimmt irgendwas nicht:
"Sie bilden ein Präfix zu den bisherigen, 16 Bit langen Codepoints und vervielfachen (genauer: ver-256-fachen) so die Menge der unterscheidbaren Codepoints. [...]. Somit sind nun maximal 1.114.112 ([...]) Zeichen [...] vorgesehen (UCS-4, 32 Bit)."
Wenn ich 2^16 (=65.536) ver-256-fache, komme ich auf 16.777.216, nicht auf 1.114.112. --Thomas Landauer 19:21, 08. Dec. 2007 (CET)

Im Artikel steht auch, dass der 16-Bit Code um ein 8-Bit Präfix erweitert wurde. Damit ergeben sich doch 24 Bit (U+00xxxx bis U+FFxxxx) und damit 2^24=16M an Möglichkeiten oder? MGispert (Der vorstehende, nicht signierte Beitrag stammt von 89.48.56.141 (Diskussion • Beiträge) 1:59, 15. Nov 2007) Fomafix 13:16, 15. Nov. 2007 (CET)

Ich habe kein Dokument gefunden, bei dem die Anzahl der Planes auf 256 festgelegt wurde. Die einzelnen Unicode Transformation Formate haben unterschiedliche theoretische Obergrenzen. Für UTF-8 wurde in RFC 3629 explizit die Obergrenze auf U+10FFFF festgelegt und damit gegenüber dem Vorgänger RFC 2279 eingeschränkt.

Außerdem halte ich folgenden Satz für missverständlich:

Bezüglich der Codepoints ist Unicode eine Untermenge von ISO 10646: Während ISO 10646 Zeichencodes mit bis zu 31 Bit zulässt, sind bei Unicode maximal 21 Bit erlaubt.

Die Obergrenze liegt bei U+10FFFF. 0x10FFFF lässt sich mit 21 Bit darstellen, aber umgekehrt gilt nicht, dass alle 21-Bit-Zahlen gültige Unicode-Codepoints darstellen. --Fomafix 13:16, 15. Nov. 2007 (CET)

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)

„grundsätzlich keine Ligaturen und zusammengesetzte Zeichen“?

Im Text steht: Grundsätzlich wurden und werden keine Ligaturen und sonstige zusammengesetzte Zeichen kodiert, auch wenn die Gründe für diese Politik nicht von jedermann verstanden werden. Lediglich zum Zwecke der Kompatibilität mit älteren Zeichensätzen sind Ligaturen und zusammengesetzte Zeichen enthalten. Hä?! Für Ligaturen gibt es doch eigens den Unicode-Block Alphabetische Präsentationsformen (und andere), und es sind massenhaft aus Buchstaben und Diakritika zusammengesetzte Zeichen kodiert: ä, á, à, â, ą usw. usf. Was soll dieser Satz? --Daniel Bunčić 12:06, 19. Nov. 2007 (CET)

Zeichen mit Diakritika sind keine Ligaturen. Siehe Ligatur (Typografie). --RokerHRO 12:42, 19. Nov. 2007 (CET)

Das ist mir schon klar, habe ich auch nicht behauptet. Im Artikel steht aber, dass „Ligaturen und sonstige zusammengesetzte Zeichen“ grundsätzlich nicht kodiert würden. Sowohl Ligaturen als auch sonstige zusammengesetzte Zeichen sind aber massenhaft in Unicode vorhanden. Der Satz ist m. E. also falsch. Ich lösche ihn jetzt; wenn jemand weiß, was er sollte, kann er ihn ja in verständlicherer Form wieder einfügen. --Daniel Bunčić 12:57, 19. Nov. 2007 (CET)

Der Satz stimmt schon. Früher waren zusammengesetzte Zeichen erlaubt (Ligaturen waren das noch nie, sind aber aus Kompatibilitätsgründen enthalten), seit Unicode 3.0 hat sich diese Regelung aber geändert, sodass keine zusammengesetzten Zeichen und Ligaturen mehr erlaubt sind. -- Prince Kassad 15:50, 19. Nov. 2007 (CET)

Was sind denn bitteschön diese "zusammengesetzten Zeichen", und welche "Ligaturen" sind angeblich nicht erlaubt? Nenne mir doch bitte mal jemand Beispiele! --Daniel Bunčić 16:03, 19. Nov. 2007 (CET)

Zusammengesetzte Zeichen (ich bevorzuge das Wort "vorgefertigt", da es näher am englischen precomposed ist) kann man in mehrere Gruppen einteilen: die häufigste im westlichen Bereich, und auch die, die hier gemeint ist, besteht aus einem Zeichen und einem Diakritikum. Ä, ö und ü sind drei Beispiele für zusammengesetzte Zeichen aus dieser Kategorie. Zu den Ligaturen: die folgenden Ligaturen sind in Unicode, aber eigentlich nicht erlaubt (wenn ich nichts übersehen habe): IJ, DŽ, Dž, dž, LJ, Lj, lj, NJ, Nj, nj, DZ, Dz, dz, և, ff, fi, fl, ffi, ffl, ſt, st, ﬓ, ﬔ, ﬕ, ﬖ, ﬗ, ﭏ -- Prince Kassad 18:58, 19. Nov. 2007 (CET) (Nachtrag: bald kommt eine detaillierte Auflistung der Kategorien, in die man vorgefertigte Zeichen einteilen kann)

Hier, wie versprochen, die Einteilung, erstmal nach dem Unicode-Konsortium, da man diese sorglos und ohne TF-Bedenken in den Artikel einbauen kann:

• <initial>, <medial>, <final>, <isolated> - Diese vier Kompatibilätstypen sind spezifisch für das Arabische (da es neben Mongolisch die einzige in Unicode enthaltene Schrift ist, die verschiedene Formen je nach der Position des Zeichens hat), und zeigen jeweils Anfang, Mittel, Schluss- und isolierte Formen an. In den beiden Blöcken der arabischen Präsentationsformen kann man zahlreiche Zeichen finden, die so kategorisiert sind. Da Unicode erwartet, dass Schriften dies mit OpenType o. ä. erledigen, sind diese Zeichen Kompatibilitätszeichen.
• <wide> und <narrow> - Jeweils voll- und halbbreite Zeichen sind hier enthalten, die meisten aus ostasiatischen Kodierungen. Der Unicode-Block Halbbreite und vollbreite Formen besteht ausschließlich aus Zeichen dieser Kategorien, in einigen anderen Blöcken lassen sich noch weitere Zeichen finden. Unicode hält diese Zeichen für Schriftvariationen und kategorisiert sie daher entsprechend.
• <small> - Kleine Formen von Buchstaben. Hier scheint das Unicode-Konsortium nur die Zeichen des Unicode-Blockes Kleine Formvarianten einsortiert zu haben, obwohl es noch einige andere kleine Varianten gibt. Hier erwartet Unicode, dass man schlichtweg die Schriftgröße verändert.
• <square> - Diese Kategorie enthält Zeichen, die aus mehreren Buchstaben bestehen, und quadratisch angeordnet sind. Da quadratische Zeichen ein Merkmal von CJK sind, sind auch nur in den CJK-Blöcken solche Zeichen enthalten, vor allem im Unicode-Block CJK-Kompatibilität. Unicode kategorisiert diese Zeichen als Kompatibilitätszeichen, allerdings gibt es keine Möglichkeit, sie zu ersetzen (jedenfalls keine, die mir bekannt ist).
• <vertical> - Hier sollten ursprünglich Zeichen einsortiert werden, die gedreht wurden, um das vertikale Schreiben von Han-Ideographen zu unterstützen. Unicode geht davon aus, dass der Software-Renderer die Zeichen, wenn nötig, drehen kann, weswegen sie zu den Kompatibilitätsbuchstaben zählen.
• <circle> - Es gibt unzählige eingekreiste Zeichen in Unicode, z. B. der Unicode-Block Umschlossene alphanumerische Zeichen, oder auch der Unicode-Block Umschlossene CJK-Zeichen und -Monate. Hier erwartet Unicode, dass man entweder U+20DD (Kombinierender Kreis) oder mit Software die Buchstaben einkreist.
• <noBreak> - Laut Unicode sind nicht umbrechende Leerzeichen äquivalent zu umbrechenden Leerzeichen, was natürlich totaler Schwachsinn ist.
• <fraction> - Hier sind Brüche wie ¼ oder ½ einsortiert. Laut Unicode soll dies mit OpenType unter Verwendung des Bruchstrichs U+2044 geschehen (so wie es auch schon in teuren Schriften praktiziert wird), dementsprechend werden diese Zeichen als Kompatibilitätszeichen kategorisiert.
• <subscript> und <superscript> - Jeweils hochgestellte und tiefgestellte Zeichen, also vor allem Zeichen aus dem Unicode-Block Hoch- und tiefgestellte Zeichen und dem Unicode-Block Spacing Modifier Letters. Obwohl sie technisch gesehen Kompatibilitätszeichen sind, da man auch mit Markup hoch- und tiefgestellte Zeichen bilden kann, werden sie bis heute zur Aufnahme im Unicode akzeptiert.
• <compat> - verschiedene Kompatibilitätszeichen, u. a. Ligaturen und Zeichen, die bereits als ein anderes ähnliches oder identisches Zeichen vorhanden sind, aber aus Kompatibilitätsgründen vorhanden sind (vor allem Unicode-Block CJK-Ideogramme, Kompatibilität).
• <font> - Zeichen, die ausschließlich auf Schriftvariationen basieren, wie das hebräische Pluszeichen. Vor allem der Unicode-Block Mathematische alphanumerische Symbole enthält solche Zeichen.
• <canonical> - Zeichen, die sich bereits durch eine Kombination aus einem Zeichen und eine oder mehrere Diakritiken bilden lassen (also z. B. ä, ö oder ü). Hangul-Silben fallen auch unter diese Kategorie. Da Unicode die Verwendung von Diakritiken stark bevorzugt, sind solche Zeichen Kompatibilitätszeichen.

-- Prince Kassad 20:08, 19. Nov. 2007 (CET)

Lieber Prince Kassad, vielen Dank für Deine Erläuterungen. In etwas adaptierter Form sollte man sie in den Artikel einbauen, denn wenn ich den gelöschten Satz nicht verstanden habe, dann gehe ich einfach mal davon aus, dass ich nicht der Einzige war. (Nur eine kleine Korrektur: IJ, DŽ, Dž, dž, LJ, Lj, lj, NJ, Nj, nj, DZ, Dz, dz sind keine Ligaturen, sondern Digraphen, die einfach eine gemeinsame Codeposition bekommen haben (vermutlich, um die Hin-und-Her-Transliteration zwischen serbischen lateinischen und kyrillischen Texten zu erleichtern). Ligaturen sind nur և, ff, fi, fl, ffi, ffl, ſt, st, ﬓ, ﬔ, ﬕ, ﬖ, ﬗ, ﭏ, weil dort tatsächlich zwei Zeichen miteinander verbunden werden sollen.) --Daniel Bunčić 22:51, 19. Nov. 2007 (CET)

Spalte E

Statt der E/nicht-E Spalte würde ich vorschlagen, dort die Unicode-Version zu nennen, die diesen Block erstmals benutzte, statt "E" dann die erwartete Version. --Pjacobi 23:21, 27. Dez. 2007 (CET)

Gute Idee. Wir haben hier ja einige Experten, einen davon sollte man insbesondere entsperren. Ob er überhaupt noch mal wiederkommt, ist eine andere Frage.

Es gibt eigentlich auch noch mehrere Entwurfsstadien, von angedacht bis nahezu umgesetzt, das könnte man in etwa von E1 bis E3 oder so ausdrücken, wenn man es mit der aktuellsten Situation abgleicht.

Bei den einzelnen Charts wäre noch zu erläutern, welche Fonts den Bereich überhaupt schon abdecken.

Nur zum Vergleich wären eigentlich auch für die einzelnen Blöcke - zusätzlich - Anschauungstafeln in Commons gut, wenn der Font das lizenzmässig zulässt.

Zum anderen würde ich auch gerne noch eine Spalte in die Tabelle einfügen, die den Sprachcode des korrespondierenden Schwesterprojekts anzeigt.

Letztendlich weiss ich aber nicht, ob man den Schwung noch mal hinkriegt. Insbesondere fanden die meisten Diskussionen auf einer Seite statt, die auch weggelöscht wurden. – Simplicius ☺ 00:01, 28. Dez. 2007 (CET)

Unicodeblöcke sind keine Schriftsysteme, trotz der häufigen 1:1 Übereinstimmung. Es gibt deshalb keine "Schwesterprojekte" in bestimmten Unicodeblöcken -- was zum Schriftsystem zu sagen ist, gehört in den Artikel. In den Unicodeblockartikel (oder Listeneintrag) gehört nur Erwähnenswertes zur gewählten Kodierung. Z.B. grandfathered from ... --Pjacobi 00:06, 28. Dez. 2007 (CET)

Vorweg, könntest du bei Benutzer:Prince Kassad vielleicht eine Nachricht hinterlassen, an welchen admin er sich da so wenden könnte, wenn er sich früher als in 60 Tagen wieder entsperren lassen könnte.

Ok, du hast Recht. Mein Gedanke war, wenn da steht "Hebräische Schrift", hätte man "he" vermerken können, bei "Tamilischer Schrift" "ta" usw. aber man muss jetzt erst mal sehen, wieviel Motivation weggelöscht wurde. Unicode ist definitiv ein Mehrpersonenprojekt. – Simplicius ☺ 00:36, 28. Dez. 2007 (CET)

Codeblöcke <-> Sprachen

Es gibt Codeblöcke, die Alphabete enthalten, die nur von einer einzigen Sprache genutzt werden. Dieser Fakt kann jeweils in dem Artikel über diesen Codeblock (genauer: über dieses Alphabet) erwähnt werden. Andersrum wäre das schon eher möglich: Welche Zeichen aus welchen Codeblöcken werden von einer Sprache X benutzt. Je mehr von diesen "Verknüpfungsdaten" man aber reinnehmen will, um so mehr reift in mir der Wunsch nach einer richtigen relationalen Datenbank, die solche Zusammenhänge dann mit wenigen SQL-Abfragen ausspuckt, anstatt dass hier hunderte von Tabellen, verstreut über mindestens ebensoviele Artikel manuell gepflegt werden müssen. :-/ WikiData now! ;-( --RokerHRO 00:45, 28. Dez. 2007 (CET)

Schriftsysteme. Sprachen != Schriftsytem und Schriftsyteme != Codeblöcke. Codeblöcke sind zwei "nicht wirklich das Gleiche"-Stufen von Sprachen entfernt. --Pjacobi 02:05, 28. Dez. 2007 (CET)

Ich glaube, dass ist Roker auch einigermaßen klar.

In diesem Artikel (Liste der Unicode-Blöcke) sind die Unicode-Blöcke ja nun ganz gut verlinkt.

Generell könnte man eigentlich, wie von Prince Kassad vorgeschlagen,

auf die acht Artikel für die reinen Nummernbereiche eigentlich verzichten.

Sollte man das auch mal in Wikipedia:Löschprüfung so sagen?

Ich fürchte, es geht dort unter. – Simplicius ☺ 12:59, 28. Dez. 2007 (CET)

Doppelung der Blöcke-Liste

Lieber Cäsium137, was soll denn diese Änderung? Wozu brauchen wir denn plötzlich wieder eine Liste der Unicode-Blöcke mit den (nun plötzlich per Vorlageneinbindung gedoppelten) gleichen Informationen wie im Artikel Unicode? Diese Liste war ja vorher im gleichnamigen Artikel drin und ist dann nach Diskussion hierher verschoben worden, woraufhin der Spezialartikel gelöscht wurde; nun haben wir plötzlich eine völlig unnötige Redundanz. --Daniel Bunčić ^? ♥ ± 06:09, 15. Mär. 2008 (CET)

Da Du offenbar nicht darauf antworten möchtest und es Dir nach eigener Aussage „egal“ ist, stelle ich jetzt die ursprüngliche Version wieder her. --Daniel Bunčić ^? ♥ ± 11:28, 16. Mär. 2008 (CET)

Han-Vereinheitlichung

Angeblich hilft der hier rückgängig gemachte Link nicht weiter. Aber anscheinend der rote (nicht mit einem Artikel hinterlegte), oder wie muss ich das verstehen? --Flingeflung 06:43, 2. Mai 2008 (CEST)

Ich verlinke Kirgisische Schrift auch nicht auf Kirgisen, nur weil der erstere Link rot ist. -- Prince Kassad 11:13, 2. Mai 2008 (CEST)

Klar, dafür lassen sich beliebig viele Beispiele anbringen. Aber mit welcher Begründung soll der Link auf Han-Chinesen nicht weiterhelfen? Meiner Meinung nach ganz sicher mehr als das für den Laien nichtssagende "Han-Vereinheitlichung". Durch den Link hätte man wenigstens eine Vorstellung, worum es überhaupt geht. --Flingeflung 12:07, 2. Mai 2008 (CEST)

Durch den Link hätte man wenigstens eine Vorstellung, worum es überhaupt geht. - Nein, man hätte keine Ahnung, was die Han-Vereinheitlichung sein soll, und der Link wäre sogar irreführend, weil das Han in Han-Vereinheitlichung nichts mit den Han-Chinesen zu tun hat. -- Prince Kassad 12:46, 2. Mai 2008 (CEST)

Aha. Da liegt der Hase im Pfeffer. Da du anscheinend weißt, worum es bei der Han-Vereinheitlichung geht, wäre es hilfreich, wenn du dies der Öffentlichkeit kundtätest. Danke. --Flingeflung 10:07, 3. Mai 2008 (CEST)

Review vom 13. April bis 28. Mai 2008

Ich hab den Artikel vom Stil verbessert, Quellen eingefügt, wo nötig, die Liste ausgelagert und den Abschnitt Kritik hinzugefügt. Ich bin mir jetzt nicht sicher, was an dem Artikel noch zu tun ist, damit er eventuell bei den Lesenswerten kandidieren kann. -- Prince Kassad 22:06, 13. Apr. 2008 (CEST)

Ich habe zwar eine große Abneigung gegen das Thema Unicode an sich, finde den Artikel aber sehr gut und engagiert gemacht. Das könnte noch was werden. --FrancescoA 09:41, 18. Apr. 2008 (CEST)

Das Logo als JPG sieht nicht sonderlich sauber aus. Besser wäre, die Grafikwerkstatt würde davon ein SVG erstellen. Steerpike 12:25, 28. Apr. 2008 (CEST)

Kurze Stichpunkte:

• "Viel Kritik ging der Han-Vereinheitlichung zugrunde" ist wohl unglücklich formuliert.
  •  Ok
• "Herkömmliche Computer-Zeichencodes umfassen einen Zeichenvorrat von entweder 128 (7 Bit) Codepositionen wie der sehr bekannte ASCII-Standard oder 256 (8 Bit) Positionen, wie z. B. ISO 8859-1" -- Und herkömmliche MBCS?
  •  Ok Mehrbyte-Zeichenkodierungen haben eine sehr große Bandbreite von darstellbaren Zeichen (von zwei- bis zweiundzwanzigtausend ist alles da), daher hab ich die Aussage auf westliche Zeichensätze beschränkt.
• Vergleich der Herangehensweise und Quasi-Scheitern von ISO 2022 gehört zur Geschichte
  • Davon höre ich zum ersten Mal, ISO 2022 feiert weiterhin einen Siegeszug in Japan.
    • teilweise  Ok (siehe unten)
• Der Fall Phönizisch kommt doppelt vor. M.E. den "Kritik"-Abschnitt auflösen und die die einzelnen Punkte im Text behandeln, z.B. einen Abschnitt "Han-Vereinheitlichung" machen.
• "Siehe auch" (wie immer) überflüssig, "Zitierte Normen" unter Einzelnachweise bringen, Weblinks ausdünnen.
  •  Ok

--Pjacobi 10:07, 7. Mai 2008 (CEST)

Ich hab mal versucht, die Vorschläge in den Artikel zu übernehmen. -- Prince Kassad 17:34, 7. Mai 2008 (CEST)

Re ISO 2022: Ich meine damit die (gescheiterte) Idee, dass ISO 2022 alle Zeichensatze der Welt assimilieren sollte, indem sie als per Esc erreichbare Seiten dem Standard hinzugefügt werden. --Pjacobi 17:45, 7. Mai 2008 (CEST)

Der Satz ist jetzt drin, ich suche nur noch nach Quellen. -- Prince Kassad 18:07, 7. Mai 2008 (CEST)

hroest

Hier ist eine kurze Kritik von einem Laien. Ich fand den Artikel sehr spannend und einige Sachen sind mir aufgefallen:

• Mehrmals wird von der Han-Vereinheitlichung gesprochen, manchmal auch von der Han Unification :-) und nur einmal wird andeutungsweise erklärt, was das genau ist; und dann nur mit dem Nebensatz, dass sie in Japan umstritten ist und ausserdem versteckt in den Kodierungskritirien. Das scheint mir definitiv verbesserungswürdig - d.h. Quellen einfügen, was und wer für und dagegen spricht und vor allem, was es genau ist. Wenn es so wichtig ist, wieso dann nicht separat erklären?
  •  Ok es gibt jetzt einen Artikel Han unification -- Prince Kassad 11:48, 13. Mai 2008 (CEST)
• Die Absätze in "Kodierungskriterien" scheinen etwas unzusammenhängend und könnnten eventuell, wie bereits oben erwähnt, vielleicht ausgelagert werden.
• "...wurde der „Combining Grapheme Joiner“ CGJ (U+034F) eingeführt. Der Name bedeutet eigentlich das Gegenteil." Das Gegenteil von was genau? Der Satz ist etwas unglücklich formuliert.
  •  Ok Ich weiß auch nicht, was mit "Gegenteil" gemeint war, deswegen hab ich den Satz kurzerhand ersetzt.
• Versionen von Unicode:ist grösstenteils eine uninformative Liste. Hier könnte man eventuell erklären, wann welche Schriftzeichen dazugekommen sind?
  •  Ok hoffe, es gefällt dir so. -- Prince Kassad 19:22, 11. Mai 2008 (CEST)
• zweimal, in "Codes, Speicherung und Übertragung" und in "Gliederung in Ebenen und Blöcke" werden die Ebenen erwähnt - wieso kann "Gliederung in Ebene und Blöcke" nicht weiter oben stehen und genauer erklären, wie die verschiedenen Ebenen erhalten werden. Auch die Graphik ist etwas verwirrend - stellt sie nun BMP dar, also nur die erste Ebene wie in der Bildunterschrift erwähnt und die Blöcke sind die verschiedenen Codebereiche? Wo sind dann die anderen Ebenen und wieso fehlen alle zwischen plane 2 und 14?
  • Planes zwischen 2 umd 14 werden jetzt erwähnt.
• Zwar werden die doppelt kodierte identische Glyphen angesprochen, aber es ist nicht klar, wie das Problem nun gelöst wurde - sind sie auch doppelt vorhanden?
  •  Ok -- Prince Kassad 21:41, 14. Mai 2008 (CEST)

Im grossen und ganzen ist es aber ein wirklich solider und informativer Artikel, dessen Struktur man noch verbessern könnte. Gruss und Lob an die Autoren. --hroest 00:55, 11. Mai 2008 (CEST)

Hab jetzt einiges erledigt, der Rest kommt morgen dran. -- Prince Kassad 01:20, 11. Mai 2008 (CEST)

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

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)

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)

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)

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

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".

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)

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)

Aus Diskussion:Liste der Unicode-Blöcke verschobene Diskussionen

Namen gesucht

Ich bemühe mich zwar redlich, jedoch wird es mir nicht unbedingt gelingen, die deutschen Namen verschiedener aufgeführter Zeichensysteme herauszufinden. Sicher weiß der eine oder andere Mitschreiberling hie und da mehr als ich. Wer das Editieren des im Editionsmodus reichlich unübersichtlichen Artikels scheut, möge seine Erkenntnisse einfach hier ablegen. --Jirret 07:41, 7. Feb 2005 (CET)

Einzelartikel zu Unicodeblöcken

Obwohl ich die roten Wikilinks zu den Einzelartikeln (auch aus Faulheit) belassen habe, heißt das keineswegs automatisch, dass diese in ihrer zur Zeit gelöschten Form wiederhergestellt werden sollen. Weitere Diskussion hierzu bitte auf Wikipedia Diskussion:WikiProjekt Unicode. --Pjacobi 23:19, 27. Dez. 2007 (CET)

Codeblöcke <-> Sprachen

Es gibt Codeblöcke, die Alphabete enthalten, die nur von einer einzigen Sprache genutzt werden. Dieser Fakt kann jeweils in dem Artikel über diesen Codeblock (genauer: über dieses Alphabet) erwähnt werden. Andersrum wäre das schon eher möglich: Welche Zeichen aus welchen Codeblöcken werden von einer Sprache X benutzt. Je mehr von diesen "Verknüpfungsdaten" man aber reinnehmen will, um so mehr reift in mir der Wunsch nach einer richtigen relationalen Datenbank, die solche Zusammenhänge dann mit wenigen SQL-Abfragen ausspuckt, anstatt dass hier hunderte von Tabellen, verstreut über mindestens ebensoviele Artikel manuell gepflegt werden müssen. :-/ WikiData now! ;-( --RokerHRO 00:45, 28. Dez. 2007 (CET)

Schriftsysteme. Sprachen != Schriftsytem und Schriftsyteme != Codeblöcke. Codeblöcke sind zwei "nicht wirklich das Gleiche"-Stufen von Sprachen entfernt. --Pjacobi 02:05, 28. Dez. 2007 (CET)

Ich glaube, dass ist Roker auch einigermaßen klar.

In diesem Artikel (Liste der Unicode-Blöcke) sind die Unicode-Blöcke ja nun ganz gut verlinkt.

Generell könnte man eigentlich, wie von Prince Kassad vorgeschlagen,

auf die acht Artikel für die reinen Nummernbereiche eigentlich verzichten.

Sollte man das auch mal in Wikipedia:Löschprüfung so sagen?

Ich fürchte, es geht dort unter. – Simplicius ☺ 12:59, 28. Dez. 2007 (CET)

Weitere mögliche Spalten für die Tabelle

(und/oder Fakten für die Einzelartikel). Hat jemand die Unicode-"Datenbank" in eine sinnvolle abfragbare Datenbank importiert? Dann könnte man z.B. den "Füllgrad" der einzelnen Blöcke -- in Einzelartikeln auch den Füllgrad im Laufe der Unicode-Versionen -- aufzeigen. --Pjacobi 13:11, 28. Dez. 2007 (CET)

Gescheiterte KLA Disk vom 8. Juni 2008

Unicode [ˈjuːnɪkoʊd] ist ein internationaler Standard, in dem langfristig für jedes sinntragende Schriftzeichen bzw. Textelement aller bekannten Schriftkulturen und Zeichensysteme ein digitaler Code festgelegt wird. Ziel ist es, die Verwendung unterschiedlicher und inkompatibler Kodierungen in verschiedenen Ländern oder Kulturkreisen zu beseitigen.

Unicode wird laufend um Zeichen weiterer Schriftsysteme ergänzt. ISO 10646 ist die von ISO verwendete praktisch bedeutungsgleiche Bezeichnung des Unicode-Zeichensatzes; er wird dort als Universal Character Set (UCS) bezeichnet.

Nach einem mehr oder weniger erfolgreichen Review bin ich mal mutig und stelle den Artikel hier rein. -- Prince Kassad 15:49, 1. Jun. 2008 (CEST)

 Kontra Sicher, Du hast Dir viel Mühe gegeben, aber der große Wurf ist es leider nicht. Im historischen Teil beschreibst Du sauber, die Schwächen und Probleme von ASCII und Co. (obwohl gerade der in den 1980ern sicher dominantere EBCDIC nicht namentlich genannt wird) und führst aus, dass dies zum Ende des letzten Jarhunderts zu Problemen beim Datenaustausch führte. Daraus ergibt sich aber im Umkehrschluss, dass diese heute nicht mehr bestehen, was so ja aber nicht zutreffend ist, weil der Schlenker fehlt, was geändert wurde (manchmal muss man Dinge auch explizit beschreiben). Völlig unterbelichtet ist und bleibt aber, was denn nun der grundlegende Unterschied zwischen ASCII und Co. und Unicode ist - zumindest in einer Art, dass auch Laien dies nachvollziehen können. Du erwähnst in diesem Kontext die Escape-Sequenzen, schreibst dann aber, dass diese sich nicht durchsetzen könnten - in ebenso ausführlicher Form (oder eher noch ausführlicher) hätte auch beschrieben werden müssen, wie dies mit Unicode gelöst wurde. Sicher ist zwar interessant, dass auch ägyptische Hieroglyphen mit Unicode dargestellt werden können - aber das ist m.E. ein Randproblem, welches unter eine Überschrift wie Besonderheiten und Kuriositäten passt, heute aber im eigentlichen Text verschwimmt. Von oben nach unten lesbar und verständlich ist der Artikel leider nicht. --Hmwpriv 13:11, 2. Jun. 2008 (CEST)

• kontra - ich habe gerade eben den Kopf dieser Seite editiert und dabei irgendwelchen Unicode kaputtgemacht. Ich vermisse Hinweise, daß Unicode nach wie vor Probleme bereitet. --RalfR → BIENE braucht Hilfe 20:02, 2. Jun. 2008 (CEST) Immer noch IE 6? sугсго 12:58, 3. Jun. 2008 (CEST)
• nicht lesenswert; Unterstützung und Verbreitung heute kommt viel zu kurz. sугсго 12:58, 3. Jun. 2008 (CEST)

Abwartend Ich hätte eigentlich als Laie ein pro gegeben; Exzellent ist der Artikel noch nicht aber durchaus lesenswert. Nachdem ich den Artikel schon im Review gelesen habe und er sich nochmals stark verbessert hat, würde ich ihn zu den besseren Artikeln in Wikipedia zählen. Er ist sehr informativ und interessant gerade weil er ein Thema behandelt, über das wohl wenige Menschen nachdenken aber trotzdem sehr wichtig ist in der täglichen Arbeit. Ich frage mich jetzt beim erneuten durchlesen des Artikels, ob Wikipedia wirkliche in Benutzerhandbuch sein soll und deshalb der Abschnitt " Eingabemethoden" nicht etwas gekürzt werden könnte? Anscheinend bemängeln aber hier einige Leute, dass der Artikel noch substanzielle Lücken hat (was ich schlecht beurteilen kann) und deshalb zuerst einmal ein abwartend. Gruss --hroest 05:11, 4. Jun. 2008 (CEST)

 Kontra Zuviel denglisches Kauderwelsch. Ein Artikel für die, die es schon wissen. Die können hier kurz nachschlagen. Arabisch ist bidirektional?-- Kölscher Pitter 07:39, 4. Jun. 2008 (CEST)

Abwartend Ich habe mit den wichtigen Teil durchgelesen und habe keine groben Fehler gefunden, aber ich möchte mich dem oben gesagten anschließen - ich denke es gibt noch ein wenig mehr zu dem Thema zu sagen. Man könnte sich unseren exzellenten Artikel Mojibake als Anstoß nehmen und die Problematik bei den Vorgängern von Unicode darlegen. Ein paar Punkte, die mir beim Durchlesen aufgefallen sind:

• "[...] um länderspezifische Sonderzeichen abzubilden." - Den Begriff "Sonderzeichen" finde ich im Kontext von Unicode etwas altbacken. Sonderzeichen sind von mir aus nicht darstellbare Zeichen und Kommandobefehle wie in ASCII, aber ein Ö als Sonderzeichen anzusehen finde ich einfach nicht korrekt.
• "[...] bei westlichen Zeichenkodierungen liegt diese Grenze meistens bei 128 (7 Bit) Codepositionen [...]" - außer ASCII fällt mir hier nicht viel ein. Gibt es da was? Ansonsten würde ich das anders formulieren. Aus meiner Sicht ist ASCII der Urvater und alle anderen Kodierungen beheben nur das Manko der fehlenden regionalen Zeichen, jeder für sein Klientel.
• "[...] (die Reformen Mitte des 20. Jahrhunderts – chinesische Kurzzeichen und japanische Shinjitai – sind dagegen durch unterschiedliche Codes repräsentiert)." - Ist das hier notwendig? Also wurde das bewusst gewählt, oder ist das aus Gründen der Kompatibilität so entstanden? Dann wäre die explizite Nennung unpassend. Angebracht wäre der Hinweis, dass es Ausnahmen gibt um "Round-Trip-Konvertierungen" zu erlauben.
• "In der Praxis werden hier wohl überwiegend sprachspezifische Schriftarten verwendet, und die zeichnen sich schon durch außergewöhnliche Dateigrößen aus." - Also quasi Vereinheitlichung um MBs zu sparen? Hmm.
• "[...] dazu zählen unter anderem auch die Chữ nôm, die früher in Vietnam benutzt wurden." - Hier ist vorallem wichtig, dass es solche Zeichen sind, die nicht bereits durch diese für Chinesisch abgedeckt werden, also solche die man in Vietnam dazu erfunden hat.

Die von Sychro angesprochene Unterstützung sollte auch nicht unter den Tisch fallen. Technisch gibt es heute noch Systeme, welche mit der Unterstützung hadern. Das fängt bei Betriebsysteme an, Programmiersprachen sind heute noch nicht so weit volle Unterstützung zu liefern. Als Google 5.1 dieses Jahr unterstützte war das den Medien eine Meldung wert...

UTF-16 hat nicht nur wegen Java Bedeutung, sondern ist als Kodierung für Schriften geeignet, die nicht im niedrigen 8-Bit-Raum angesiedelt sind. UTF-8 vs. UTF-16 entspricht mE gerade "westliche Sprachen vs. den Rest der Welt".

Abschließen: zu viel Denglisch kann ich nicht nachvollziehen. --chrislb 22:43, 5. Jun. 2008 (CEST)

 Neutral Einige Anmerkungen:

• Einzelheiten von Eingabemethoden sollten hier nicht erklärt werden ("Wikipedia ist weder Anleitung noch Ratgeber")
• Die Unterstützung in Anwendungssoftware und Betriebssystemen sollte dagegen ausführlicher beschrieben werden. Dass Word Unicode unterstützt, erfährt man nur dadurch, dass es auch hexadezimal eingegeben werden kann.
• wird vor allem von Wissenschaftlern und ostasiatischen Ländern scharf kritisiert - was für Wissenschaftler?
• Die Rezeption in Japan ist mit durchaus umstritten auch sehr knapp dargestellt. Inwieweit Unicode dort trotzdem verwendet wird, wäre auch interessant.
• Ein Widerspruch: 1993 wurde das Tibetische aus dem Standard entfernt vs. Gegenüber anderen Normen gibt es bei Unicode die Besonderheit, dass einmal kodierte Zeichen niemals wieder entfernt werden.
  •  Ok
• In der Praxis werden hier wohl überwiegend sprachspezifische Schriftarten verwendet - wieso "wohl", und was ist der Bezug zur Dateigröße im nächsten Halbsatz?
  •  Ok -- Prince Kassad 17:06, 7. Jun. 2008 (CEST)
• Der Begriff Surrogate-Paare müsste erklärt werden.
• Einige Artikel zu im Text erwähnten Schriften könnten noch verlinkt werden.

--08-15 23:44, 6. Jun. 2008 (CEST)

Artikel ist lesenswert (Version)--Ticketautomat 10:25, 8. Jun. 2008 (CEST)

Exakte Anzahl an Unicode-Zeichen?

Wieviele Zeichen sind eigentlich theoretisch erlaubt? 1.114.112 ist auf jeden Fall zu viel. Zieht man die Surrogates (nicht darstellbar mit UTF-16 und in den anderen UTFs verboten) und die 66 Noncharacters (generell verboten) ab, so bleiben 1.111.998 gueltige Zeichen. Ist das die tatsaechliche Anzahl an theoretisch gueltigen Zeichen, oder sind es weniger? RedNifre 19:58, 5. Mai 2008 (CEST)

Nö, die Zahl stimmt genau: Pro plane 2 hoch 16 Zeichen mal 17 planes. (nicht signierter Beitrag von 78.34.1.172 (Diskussion | Beiträge) 22:39, 21. Apr. 2009 (CEST))

KODIERUNGSKRITERIEN

Warum wird mein Eintrag nicht akzeptiert? Unicode kümmert sich absolut nicht um den Zeichenvorrat von Schriftarten sondern nur um die Kodierung von Schriftzeichen. Daß eine Schriftart mehrfach kodierte identische Glyphen enthalten kann, ist für den Standard von relativ geringem Belang. Gerd (nicht signierter Beitrag von 78.34.1.172 (Diskussion | Beiträge) 00:42, 24. Apr. 2009 (CEST))

Meinst du diese Bearbeitung? (Bitte immer Versionsunterschied angeben.) Also eine Löschung des ganzen Abschnitts hätte ich ja noch verstanden, aber so ergab das keinen Sinn. Deine Anmerkungen treffen an sich zu. Aber der sehr kurze Abschnitt dient ja nur der Verdeutlichung. Gismatis 02:45, 24. Apr. 2009 (CEST)

Ich finde den kleinen Absatz eigentlich ganz gut, da er den Unterschied zwischen Graphem und Glyphe illustriert. Allerdings braucht man zur mehrfachen Kodierung einer Glyphe in einer Schrift keinen Unicode. Es geht hier aber ausschließlich um den Standard. Gruß Gerd (nicht signierter Beitrag von 78.34.1.172 (Diskussion | Beiträge) 03:22, 24. Apr. 2009 (CEST))

Weblinks

Soll derhier bei den Weblinks aufgenommen werden: http://www.isthisthingon.org/unicode/index.php ? -- 80.136.114.230 23:36, 30. Mär. 2008 (CEST)

Dieser hier wurde abgelehnt, und ich weiß nicht warum: www.decodeunicode.org . Imho ist die Seite fast schon unverzichtbar wenn man sich mit Unicode beschäftigt. Ich hatte die Seite vergessen und dann wiedergefunden: in der ENGLISCHEN wikipedia... (warum such ich überhaupt noch auf deutsch?) 89.53.51.245 (23:18, 28. Apr. 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Drei von 1000 Gründen, www.decodeunicode.org hier nicht aufzuführen:

• Weil www.decodeunicode.org nur ein Wiki ist.
• Weil www.decodeunicode.org Dutzende Kopien aus der Wikipedia enthält, ohne Autoren und Quellen zu nennen.
• Weil auf unicode.org alle diese Information aus der offiziellen Quelle verfügbar sind.

--91.62.113.152 23:28, 28. Apr. 2009 (CEST)

Kritik

Also ich finde den Abschnitt "Kritik" unglücklich. Das ist immer die äußerst behelfsmäßige Methode, NPOV zu leisten. Einfach einen Abschnitt Kritik dranbacken. Naja. Aber konkreter: Die Ägyptische-Hieroglyphen-Frage erscheint ein mir ein bischen zu sehr vom Hörensagen vorgetragen zu sein. Welche Wissenschaftler in welchen Veröffentlichungen? Gibt Stellungnahmenn der "zuständigen" Fachvereinigungen? --Pjacobi 23:48, 6. Jun. 2008 (CEST)

Ser ganze Abschnitt ist für das Gesäß. Im wesentlichen werden hir nur Dinge unnötig breitgewalzt, die lediglich einer kleinen Anmerkung in einem vernünftigen Zusammenhang bedürfen und dort teilweise auch schon stehen, z.B. phönizisch. Gerd (nicht signierter Beitrag von 78.34.1.172 (Diskussion | Beiträge) 22:39, 21. Apr. 2009 (CEST))

Die Kritik muss auf jeden Fall verbessert und belegt werden. Es ist erklärtes Ziel von Unicode, Schriftsysteme anstatt von Sprachen zu kodieren. Deutsch und Finnisch sind ebenfalls nicht verwandt und ich höre dennoch keine Proteststürme, dass für beide (und all die anderen das lateinische Alphabet verwendenden Sprachen) dieselben Zeichen verwendet werden. Das Konsortium bemüht sich[8], die Kritik an der CJK-Vereinheitlichung ausführlich zu widerlegen. Die Nennung der fünf versehentlich doppelt kodierten Zeichen hört sich angesichts zahlreicher durch Kompatibilität zu älteren Standards hervorgerufener Unstimmigkeiten und hunderttausender unbelegter Codepunkte doch sehr danach an, als müsse man auf Teufel komm raus ein Haar in der Suppe finden. Fakt ist doch, dass Unicode schlicht alternativlos ist und sich auf dem besten Wege befindet, alle anderen Zeichendarstellungsstandards ein für alle Mal obsolet zu machen. --Phst 17:51, 22. Mai 2009 (CEST)

Informationsmüll

Glaubt etwa irgendjemand, es trage zum Verständnis von Unicode bei, zu wissen, daß Unicode und ISO 10646 früher einmal unterschiedliche Codebereiche definiert hatten? Von ähnlichem Gehalt an nützlicher Information ist die ... und-dann-Liste (Geschichte des Unicode) und der reichlich bekloppte Absatz Kritik. (nicht signierter Beitrag von 78.34.9.118 (Diskussion | Beiträge) 18:51, 16. Sep. 2009 (CEST))

Was einmal relevant war, bleibt relevant. Deswegen ist es auch prinzipiell falsch, in den Kleinkeckersdorfartikeln Bürgermeister Meier zu streichen, sobald Bürgermeister Müller gewählt wurde. Aber dieses prinzipiell sollte uns nicht davon abhalten, die Artikel leserfreundlich zu gestalten, und eventuell, alles was früher mal galt, heute aber nicht mehr, in Geschichte von Unicode auszulagern. Dort muss es dann auch kein Aschenputteldasein führen, sondern kann in aller Ausführlichkeit dargestellt werden.

Der Kritik-Absatz. Ja. Da müsste man mal in den Archiven stöbern, ob ich mich jedes Jahr oder nur jedes zweite Jahr beklagt habe. Könnte eigentlich auch in Geschichte von Unicode ausgelagert werden, das es Geschichte ist.

--Pjacobi 22:43, 17. Sep. 2009 (CEST)

Satz entfernt

„Am häufigsten wird es in Form von UTF-8 eingesetzt, das zunehmend für Websites und von Webbrowsern genutzt wird, um länderspezifische Zeichen abzubilden.“ – Habe diesen Satz entfernt, da er in dieser Kürze unrichtig ist und meiner Meinung nach nicht in der Einleitung stehen sollte. Tatsächlich basieren die meisten führenden Technologien (Windows, Mac OS X, Java, .NET…) auf UTF-16. Für diesen Artikel spielt die Verbreitung einzelner Kodierungsschemata gar keine Rolle, da es sich um ein technisches Detail handelt. --Phst 17:15, 22. Mai 2009 (CEST)

Seht euch mal die letzte Änderung im Artikel an! Löschung, schnell, aus POV

Da verlangt ein Formalist Quellen dafür, dass es sich (nur) um so und soviel Sprachen und Zeichen handelt. Das steht doch im Artikel. Jetzt suche ich Hände ringend (!) nach Quellen, dass diese paar Kritiker des Unicode eine Minderheit sind. Rechnet mal nach! Wer hat denn den Absatz mit den Kritikern wegen ein paar chinesischer Zeichen verfasst? Stehen da drin Quellen? Wer hat, als der Absatz erschien, nach Quellen gefragt und diese harsche pauschale angebliche Kritik des gesamten Unicode mangels "Quellen" stracks gelöscht? M.E. geht es um den Sinn des Unicode. --Hans Eo 21:22, 23. Aug. 2010 (CEST)

Wer hat denn den Absatz mit den Kritikern wegen ein paar chinesischer Zeichen verfasst? Stehen da drin Quellen? - Klar, sogar ein ganzer Haufen. Sofort sichtbar, fast nicht zu übersehen. -- Prince Kassad 22:53, 23. Aug. 2010 (CEST)

Prince Kassad: ja, Einzelnachweise 28, 29 und 30 meinst Du wohl. Habe die einigermassen durchgelesen (dabei meine Kenntnisse der Han-Zeichen etwas aufgefrischt). Am kürzesten ist Nr. 30, Zusammenfassung der Ergebnisse. Danach hat man sich über fast Alles geeinigt. Schon vor ein paar Jahren. Was bleibt von dem Riesenaufstand, der im Artikel behauptet wird, übrig? --Hans Eo 15:26, 17. Sep. 2010 (CEST)

Ich kann wetten, das Thema wird spätestens dann wieder auf der Tagesordnung stehen, wenn der nächste Haufen Zeichen zur Kodierung ansteht. Erfahrungsgemäß gibt es dann immer Konflikte, weil immer irgendwelche Fehler auftauchen. -- Prince Kassad 18:42, 17. Sep. 2010 (CEST)

Wette schon im Voraus gewonnen! Aber muss dann gleich eine Generalkritik gegen den ganzen Unicode formuliert werden? --Hans Eo 15:23, 22. Sep. 2010 (CEST)

Bedenke dabei, dass 75% vom ganzen Unicode nur aus diesen chinesischen Zeichen bestehen. Das ist mehr als die Hälfte. -- Prince Kassad 16:12, 22. Sep. 2010 (CEST)

Löschung von Lateinischer Buchstabe gestrecktes C (eigenes Lemma) und Lateinischer Buchstabe retroflexer Klick (Redirect auf Klick (Phonetik))

Leute, hier sind jede Menge Admins am werkeln, die systematisch deutsche Bezeichnungen kaputtmachen und die die Sache nicht im geringsten interessiert. Wie sollen wir denen mal den Unterschied zwischen "Wort" und "Begriff" klarmachen? --Reiner Stoppok 17:12, 5. Jul. 2007 (CEST) PS: Siehe auch aktuelle Löschprüfung.

Dieser Abschnitt kann archiviert werden. -- Prince Kassad 15:49, 13. Jan. 2011 (CET)

Junicode Schriftarten

Quellen von Unicode-Schriften siehe Weblinks.
Wo sind die denn hin? Ich sehe da keine Links zu Schriften. --Makkonen 12:28, 1. Aug. 2007 (CEST)

Dieser Abschnitt kann archiviert werden. -- Prince Kassad 15:49, 13. Jan. 2011 (CET)

Wieso grad 17 Planes?

Wer ist auf die verrückte Idee gekommen, ausgerechnet 17 Planes zu je 2¹⁶ Codepoints zuzulassen? 16 Planes wäre ja noch nachvollziehbar, das würde in 20 Bits oder 5 Hexziffern passen. Aber 17 Planes? Was hat es grad mit dieser Anzahl auf sich? --RokerHRO (Diskussion) 16:50, 23. Jul. 2012 (CEST)

Das kann ich sagen. Man musste Rücksicht auf UTF-16 nehmen, der eigentlich zwei-bittig ist und daher normalerweise nur 65.536 Zeichen unterstützen würde. Nun hatte man aber einen Bereich von U+D800 bis U+DFFF frei (2048 Zeichen) - die hat man dann zur Hälfte aufgeteilt. So ergeben sich genau 1024 * 1024 = 1.048.576 Zeichen, die durch die Kombination zweier Zeichen aus diesen beiden Bereichen darstellbar sind - genau 16 Planes zusätzlich zu der bereits bestehenden Plane 0. -- Liliana • 16:56, 23. Jul. 2012 (CEST)

Ich weiß zwar nicht, was du mit "zwei-bittig" meinst, aber egal. Ich dachte, Unicode wäre älter als ein "Unicode Transfer Format". So oder so, die Antwort auf meine Frage gehört IMHO in den Artikel (incl. Quellen), nicht auf die Diskussionsseite. Oder? --RokerHRO (Diskussion) 19:04, 23. Jul. 2012 (CEST)

Der Mechanismus wurde in Unicode 2.0 eingeführt, vorher hatte man vor (wie schon im Artikel steht), mit 2^16 Zeichen auszukommen. Der Mechanismus mit high and low surrogates führt natürlicherweise zu einem Gesamtzeichenvorrat von 2^16 + 2^(2n) (Krümelpieker: Eigentlich 2^16 + 2^(2n) - 2^(n+1)). Es blieb dann nur noch n festzulegen. War bestimmt eine interessante Sitzung, aber ich habe noch keinen Bericht darüber gelesen. Anyway, zum Schluss kam n=10 und damit die heute noch gültige Zahl. --Pjacobi (Diskussion) 19:47, 23. Jul. 2012 (CEST)

Eure Argumentation mit dem Zeichenumfang, den eine Surrogat-Kodierung (die wir heute als UTF-16 kennen), abdecken kann, klingt durchaus plausibel. Aber gibt es dafür auch seriöse Quellen oder ist das eure Privattheorie? ;-)

Denn mit der gleichen Argumentation hätte man ja eine Kodierung erdenken können, die eben 3 16-Bit-Einheiten nimmt, die kann dann entweder mehr Zeichen abdecken, oder kommt mit weniger "Codespace" für die Surrogates aus.

--RokerHRO (Diskussion) 07:34, 24. Jul. 2012 (CEST)

Weil es keine Sekundärliteratur gibt, lässt sich eben nicht so viel zum Thema schreiben. Außer man wertet aus, wie sich der Unicode-Standard von Version zu Version geändert hat, die Diskussionen auf der Unicode-Mailinglist. Es gab ja auch zu jeder major version ein gedrucktes Buch. Ich habe noch v3.0 im Schrank, in dem das Verhalten der Surrogate Pairs beschrieben wird, es als Mechanismus vorgestellt um weitere 2^20 Zeichen abzudecken ohne auf 32-Bit Codes überzugehen und schließlich gesagt wird, dass noch keine Zeichen in diesem Bereich zugewiesen sind. --Pjacobi (Diskussion) 09:31, 24. Jul. 2012 (CEST)

Anzahl der Zeichen?

Ich lese hier: "die heutigen 1.114.112 Zeichen". In der Tabelle sind es dann etwas über hundertzehntausend (sechsstellig). Das könnte ein Fehler sein. Bin Leserin, kein Autor, deshalb hier. Vielen Dank (nicht signierter Beitrag von 194.8.219.19 (Diskussion) 16:57, 10. Jan. 2013 (CET))

erledigtErledigt -- Liliana • 17:05, 10. Jan. 2013 (CET)

Aussprachen von Unicode

Auf der Seite wird ohne Quellenangabe als amerikanische Aussprache [ˈjuːnɪkoʊd] angegeben. Eine solche Aussprache mit nachtonigem [-ɪ-] anstatt [-i-] ist zwar möglich, wird aber seit Jahrzehnten beiderseits des Atlantiks als veraltet betrachtet. John Wells gibt in seinem Longman Pronouncing Dictionary (3., aktuelle Auflage) nur noch [ˈjuːnikəʊd] für britisches und [ˈjuːnikoʊd] für amerikanisches Englisch an. (Sein längst verstorbener prominenter Vorgänger Daniel Jones hatte in solchen Fällen noch [-ɪ-] angegeben und das als einziges nordenglisches Merkmal in der ansonsten südostenglisch basierten Received Pronunciation beschrieben.)

Ebenfalls ohne Quellenangabe wird als deutsche Aussprache [ˈuːnɪko:də] angegeben. Ich halte das für sehr merkwürdig, und das nicht nur wegen des im Deutschen in offener Silbe unmöglichen Vokals [ɪ] und des typographisch falschen Doppelpunkts anstatt eines IPA-Längungszeichens mit dreieckigen Punkten. Zwar findet sich für dieses Wort weder im Deutsches Aussprachewörterbuch von Maria Krech et. al. noch im Duden Aussprachewörterbuch ein eigener Eintrag, doch geben beide übereinstimmend für Code und alle seine Ableitungen [koːt] an. Auch das anfangsbetonte englische Element Uni- findet sich in Einträgen wie Unit und Union Jack regelmäßig als [ˈjuːn...].

Ich habe die Ausspracheangaben jetzt wie folgt abgeändert: „Aussprachen: am. Englisch [ˈjuːnikoʊd], brit. Englisch [ˈjuːnikəʊd], deutsch [ˈjuːnikoːt]“. LiliCharlie (Diskussion) 12:29, 22. Sep. 2013 (CEST)

Zur deutschen Aussprache gibt es eine interessante Diskussion auf der Diskussionsseite von "Code". Es geht um die Auslautverhärtung.--Explosivo (Diskussion) 04:35, 27. Dez. 2013 (CET)

vim/ Linux

Also mein vim startet mit Strg + v den visuellen Blockmodus, das ist zumindest in debian so Standard. Könnte das sich geändert haben oder so? Was aber fehlt, ist dass man in Linux-/ X11-Umgebungen für gewöhnlich Strg + Shift + u gefolgt von einem Zahlencode drücken kann, um Unicode-Zeichen einzufügen, und das überall, auch in vim. Außerdem - der Vollstädigkeit halber - können in vim viele Sonderzeichen als sog. Digraph eingegeben werden, man drücke Strg + K und zwei Tasten (z.B. + und - für ±). Ähnlich funktioniert die Compose-Taste, aber dazu gibt es bestimmt schon Wikipedia-Material. 37.201.100.160 05:25, 14. Sep. 2014 (CEST)

Aussprache des Lemmas

@Florian Blaschke: Ich gebe dir vollkommen Recht, ich selbst habe die Aussprache ohne /j-/ auch noch nie gehört. Andererseits ist sie die erste, die der Duden nennt. Lieben Gruß —LiliCharlie (Disk.) 18:30, 3. Jul. 2016 (CEST)

Ja, habe ich gesehen, auch wenn der Duden da etwas undeutlich formuliert. Aber „Unicode“ ist nun mal ein englisches Lehnwort, und auf deutsch wird beispielsweise „User“ ja auch mit [j] am Anfang ausgesprochen, und, wie Du im Archiv angemerkt hast, gilt dasselbe für „Unit“ und „Union Jack“. Ich habe den Eindruck, der Duden gibt hier eine Aussprache rein auf dem Papier an, sozusagen präskriptiv, ohne sie empirisch belegt zu finden. Vielleicht gibt es die [j]-lose Aussprache bei allen diesen Wörtern, aber gehört habe ich sie noch nie, unabhängig vom Bildungshintergrund. Als Kompromiß könnten wir aber das [j] einklammern. --Florian Blaschke (Diskussion) 18:44, 3. Jul. 2016 (CEST)

Können wir tun. — Ich hatte hier schon einmal eine Diskussion über die Aussprache(n) dieses Worts, die du unter Diskussion:Unicode/Archiv#Aussprachen von Unicode nachlesen kannst. Lieben Gruß —LiliCharlie (Disk.) 18:53, 3. Jul. 2016 (CEST)

@Zinnmann: Du hast damals das /j/ entfernt – möchtest Du Dich zur Diskussion äußern? Ich halte es nicht für sonderlich sinnvoll, eine ungebräuchliche Aussprachevariante zu präsentieren – aber vielleicht ist sie ja nicht so ungebräuchlich, wie LiliCharlie und ich dachten. --Florian Blaschke (Diskussion) 19:10, 3. Jul. 2016 (CEST)

Im Fall von Unicode hab ich's auch noch nie gehört, aber es gibt in DACH definitiv (tendenziell aber nicht nur ältere) Leute, die sprechen Unix ohne /j/ aber mit langem /u:/, dito "unixartig", "unixoid", etc. Hab ich schon oft gehört. Dessen ungeachtet liefert aber auch Duden an der Stelle nur die engl. Aussprache. Möglich, dass so jemand instinktiv auch bei Unicode verfahren würde, aber es ist nicht gängig und ich sehe auch keinen Grund, das hier zu berücksichtigen, schon gar nicht auf Kosten der üblicheren Aussprache. -ZT (Diskussion) 08:42, 4. Jul. 2016 (CEST)

User und Unicode habe ich auch schon mit der für deutsche Worte üblichen Aussprache gehört, bei Unicode sogar nicht so selten. Ich würde die "deutsche" Aussprache aber einfach weglassen: Wer's so aussprechen will kann sich eh am Wort selbst orientieren. So auch bei Uniform, Unicast, Unicredit, unidirektional, unierte Kirchen, Unifeeder, UEFI Unifikation, Unilever, Uniklinik, Unimog, Unisono; Bis auf Unicast (manchmal) und UEFI (in Langform) würde ich selbst die alle mit deutschem 'U' aussprechen. Nur bei Uniper ist eine (englisch ausgesprochene, so würde ich's auch sprechen) IPA-Angabe im Artikel. --nenntmichruhigip (Diskussion) 09:16, 4. Jul. 2016 (CEST)

Mit der Methode „habe ich so schon mal gehört“ kommen wir hier keinen Zoll weiter. Das ist dasselbe, wie zu behaupten „habe ich schon einmal als Unikode geschrieben gesehen“. Solche Beobachtungen sagen nichts über Häufigkeit und Akzeptabilität in unserer 100-Millionen-Sprachgemeinschaft insgesamt, selbst wenn zehn oder hundert Wikipedianer dieselbe Beobachtung gemacht zu haben vermeinen. — Nach einiger Überlegung möchte ich deshalb vorschlagen, gar keine deutsche Aussprache anzugeben, was enzyklopädisch korrekt widerspiegeln soll, dass das Wort bisher noch nicht nach einer entsprechenden Untersuchung eines repräsentativen Korpus gesprochener Sprache in eines der verlässlicheren Aussprachewörterbücher des Deutschen aufgenommen worden ist – im Gegensatz zum Englischen. Lieben Gruß —LiliCharlie (Disk.) 16:14, 4. Jul. 2016 (CEST)

Ist Duden nicht verlässlich genug? Stefan8410 (Diskussion) 22:31, 4. Jul. 2016 (CEST)

Der Aussprache-Duden ist es, aber der Rechtschreib-Duden weicht ziemlich oft von den dort gegebenen Angaben ab. (Ähnliches gilt übrigens fürs Englische: auf das berühmte Oxford English Dictionary kann man sich in Fragen der Aussprache ebenfalls nicht verlassen.) Lieben Gruß —LiliCharlie (Disk.) 00:07, 5. Jul. 2016 (CEST)

Vielleicht hast Du recht. Eine echte separate deutsche Aussprachetradition scheint es ohnehin nicht zu geben. Allgemein versucht man halt, denke ich, die englische Aussprache anzunähern, so gut man es eben kann (wobei englische Lehnwörter im deutschsprachigen Kontext u. U. doch stärker angepaßt werden: akkurates [ˈjʊunikʰoʊd] klingt da vielleicht zu gestelzt und unnatürlich oder gar angeberisch) oder, wenn man sich dieser nicht bewußt ist, liest man das Wort womöglich tatsächlich wie „Uni“ (oder aber auf „Juni“ reimend, also mit langem /uː/) + „Code“. --Florian Blaschke (Diskussion) 01:55, 5. Jul. 2016 (CEST)

Ja, es geht bei diesem Wort, dessen Häufigkeit klar weit jenseits des Grund- oder Aufbauwortschatzes liegt, hauptsächlich ums Lesen, und bei Wörtern, die die Sprachbenutzer durch das Medium der Schrift kennenlernen, ist mit allen möglichen spelling pronunciations zu rechnen, doch kann man die wohl kaum alle empfehlen. Lieben Gruß —LiliCharlie (Disk.) 07:32, 5. Jul. 2016 (CEST)

Wie auch immer man das korrekt aussprechen mag … ganz sicher falsch ist es, hier einen j-Laut beim Buchstaben U als deutsche Aussprache darzustellen. LG, ℳ웃79 ^✍ 21:15, 1. Aug. 2016 (CEST)

Warum? Lieben Gruß —LiliCharlie (Disk.) 21:49, 1. Aug. 2016 (CEST)

weil der ju-Laut englisch ist?!? „wird im Deutschen verwendet“ ist auch etwas anderes als „ist deutsche Aussprache“. Darum. LG, ℳ웃79 ^✍ 21:56, 1. Aug. 2016 (CEST)

Die Aussprache mit Auslautverhärtung ([-t] statt [-d]) ist entschieden deutsch und sicher nicht englisch. Auch an anlautendem [ˈjuː-] wie in Jugend ist nichts Undeutsches. Und auch, dass hier von der üblichen Buchstaben-Laut-Zuordnung abgewichen wird, kennen wir aus urdeutschen Wörtern wie Duisburg [ˈdyːs-] oder vierzig [ˈfɪr-]. Lieben Gruß —LiliCharlie (Disk.) 22:23, 1. Aug. 2016 (CEST)

Ich meine nicht, dass es keinen ju-Laut im Deutschen gibt. Ich weiß nicht, wie Du darauf kommt. Ich meine, dass das Aussprechen eines großen U am Wortanfang als ju-Laut statt als u-Laut nicht deutsch sondern englisch ist. Wenn nichts mehr zum Artikel kommt, erwarte keine weitere Antwort. LG, ℳ웃79 ^✍ 19:52, 2. Aug. 2016 (CEST)

Wenn du vom Buchstaben U schreibst, schreibst du nicht von der Aussprache, sondern von der Rechtschreibung. Die Rechtschreibung wird gelegentlich geändert, während die Aussprache erhalten bleibt. Beispiele: Cakes > Keks; Bureau > Büro; Centrum > Zentrum; Mayonnaise > Majonäse usw. (Sprachwissenschaftler bezeichnen die gesprochene Sprache als primär: Es gibt keine Schreiben ohne Sprechen, aber natürlich sehr wohl Sprechen ohne Schreiben.) Lieben Gruß —LiliCharlie (Disk.) 20:36, 2. Aug. 2016 (CEST)

Es gibt keine Wikipedia ohne sinnlose Diskussionen, die völlig den Fokus verloren haben, aber natürlich sehr wohl sinnlose Diskussionen, die völlig den Fokus verloren haben, ohne Wikipedia. 🤗  LG, ℳ웃79 ^✍ 10:10, 3. Aug. 2016 (CEST)

ℳ웃79 schrieb mit grüner Hervorhebung, die ich hier durch Fettschrift wiedergebe: „... dass das Aussprechen eines großen U am Wortanfang als ju-Laut statt als u-Laut nicht deutsch sondern englisch ist.“

Sinnvoll wäre hier allein eine Formulierung wie: „... dass die Schreibung von [ˈjuː-] am Wortanfang als großes U nicht deutsch sondern englisch ist.“

Es folgt die formelle Erklärung für diesen Umstand: Die aktuellen Regeln des Rats für deutsche Rechtschreibung bestimmen im Kapitel 2.1 „Die Beziehung zwischen Schreibung und Lautung“: „Die Zuordnung von Lauten und Buchstaben orientiert sich an der deutschen Standardaussprache.“ Es wird nicht umgekehrt bestimmt, dass sich die Laut-Buchstaben-Zuordnung an der Schreibweise orientieren würde. Und daraus folgt, dass ein Wort wie Unicode zwar eine unregelmäßige und meinetwegen auch „undeutsche“ Schreibung haben mag, dass aber umgekehrt eine Schreibung nichts am Status der Aussprache ändert, denn die Aussprache hat den Vorrang und orientiert sich grundsätzlich nicht an der Schreibweise, wie du auch meinem oben angeführten Beispiel [ˈfɪrtsɪç] (geschrieben <vierzig> und nicht etwa <virrzig>) hättest entnehmen können. Die in Duden, Band 6: Das Aussprachewörterbuch als einzige standardsprachliche verzeichnete Aussprache [ˈfɪrtsɪç] ist und bleibt eine deutsche Aussprache, auch wenn seine Schreibweise von der regelmäßigen Laut-Buchstaben-Zuordnung abweicht und insofern meinetwegen „undeutsch“ genannt werden darf.

Es fällt auf, dass – obwohl die Aussprache des als <Unicode> geschriebenen Wortes hier schon wiederholt ausführlich diskutiert wurde – du der einzige bist, der die Auffassung vertreten hat, [ˈjuːnikoːt] sei keine deutsche Aussprache. (Würdest du das auch behaupten, wenn der Rat für deutsche Rechtschreibung die Schreibweise <Juni-Kot> empfehlen würde?) – Von seiner phonologischen Struktur her ist [ˈjuːnikoːt] durch und durch deutsch, sehr viel deutscher als etwa [byˈroː] oder [majoˈnɛːzə] (geschrieben <Büro> und <Majonäse>), die von der im deutschen üblichen Betonung der ersten Stammsilbe abweichen.

Wenn sich keine neuen Aspekte ergeben (z.B. die Publikation einer Studie oder eines aktuellen Aussprachewörterbuchs mit neuen Erkenntnissen) setze ich in ein paar Tagen wieder die Formulierung ein, auf die wir uns hier in mehreren Diskussionen geeinigt hatten. Lieben Gruß —LiliCharlie (Disk.) 15:56, 3. Aug. 2016 (CEST)

Unabhängig davon ob der ju-Laut jetzt deutsch ist oder nicht, wo genau steht jetzt dass es nicht vereinzelt auch [ˈuːnikoːt] ausgesprochen wird, bzw warum hast du diese im Artikel entfernt? Stefan8410 (Diskussion) 22:32, 13. Aug. 2016 (CEST)

Das haben wir oben diskutiert. Niemand hat hier bestritten, dass nicht auch vereinzelt [ˈuːnikoːt] ausgesprochen wird. Ich persönlich habe auch schon eine Aussprache wie [yniˈkɔd] à la française gehört. Die bloße vereinzelte Existenz von Aussprachevarianten lässt diese aber nicht zur „Standardaussprache“ im Sinne der weit über 100 Seiten langen Einführung zum Aussprache-Duden werden, einer „Einheitsaussprache, die vor allem die Aussprache geschulter Rundfunk- und Fernsehsprecher wiedergibt“. Letztlich geht es der Redaktion des Aussprache-Dudens hierbei um Orthoepie, der lautlichen Parallele zur Orthographie. Lieben Gruß —LiliCharlie (Disk.) 23:07, 13. Aug. 2016 (CEST)

Umlaut vs. Treema

Der Deutsche Umlaut lässt sich nicht durch ein Trema ersetzten. Siehe auch Umlaut und Trema. Das Umlautzeichen sorgt für eine Verschiebung des Lautwerts, hingegen sorgt das Trema dafür, den Vokal getrennt auszusprechen. Es handelt sich als um zwei völlig verschiede Zeichen und Bedeutungen. (nicht signierter Beitrag von 62.91.28.98 (Diskussion) 09:32, 5. Okt. 2021 (CEST))

Das stimmt so nicht. Hier muss zwischen Zeichen und Bedeutung (=Verwendung) unterschieden werden. Es sind zwei verschiedene Verwendungen des gleichen Zeichens:

• Das Zeichen heist Trema
• eine Verwendung ist die Kennzeichnung eines Umlauts.
• eine Weitere die Kennzeichnung von Diärese oder Hiat.

ÅñŧóñŜûŝî (Ð) 22:11, 7. Okt. 2021 (CEST)