Diskussion:Universal Coded Character Set

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 21. Juli 2022 um 16:34 Uhr durch imported>Rainald62(228512) (→‎Vorschlag Erklärung des Unterschieds zwischen UTF-16 und UCS2).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Character Set = Encoding?

Das kann nicht stimmen: "Der Universal Character Set (UCS) ist eine Zeichenkodierung, die im internationalen Standard ISO/IEC 10646 definiert ist. Für alle praktischen Belange ist dies dasselbe wie Unicode."

Unicode ist keine Zeichenkodierung, sondern ein Zeichensatz. Ich weiss nicht genau, was UCS ist, aber so wie es da steht ist das sehr verwirrend. Wie soll eine Kodierung das gleiche wie ein Zeichensatz sein? Wenn UCS sowohl ein Zeichensatz als auch eine Zeichenkodierung ist, sollte man das auch so schreiben.

--Moritz Lenz 17:06, 31. Jul. 2008 (CEST)

Ein Zeichensatz bestimmt die DARSTELLUNG der Elemente, eine Zeichenkodierung gibt an, zu welcher Bedeutung (z.B. Buchstabe X) welcher Zahlencode gehört. In diesem Sinne ist Unicode eine Zeichenkodierung, und UCS ebenfalls. Der Satz ist also m.E. richtig. -- Gerd Fahrenhorst 22:08, 31. Jul. 2008 (CEST)
Aha, deswegen heißt es im Englischen auch "Character Set", zu deutsch "Zeichensatz", ist klar. --Carminox 22:28, 10. Apr. 2009 (CEST)

Zeichensatz und Kodierung sollten unterschieden werden:

"Unicode" etwa kann wohl als Zeichensatz gesehen werden, zu dem es verschiedene Kodierungen (z.B. UTF-8, UTF-16) gibt. Spontan würde ich sagen, ein Zeichensatz gibt u.a. an, welche Zeichen eingesetzt werden können. Eine Kodierung gibt an, wie Zeichen eines Zeichensatzes dargestellt werden. Z.B.: Zeichensatz als Menge von Tripeln (Zeichen, Name des Zeichens, Nummer / code point), Kodierung als Zuordnung von Zeichen eines bestimmten Zeichensatzes zu Darstellungen durch Bitfolgen z.B. für Verarbeitung auf Rechnern. So betrachtet ist in diesem Artikel an drei Stellen etwas vertauscht. Das mag umgangssprachlich nicht falsch sein, trägt aber nicht zur Klarheit bei. UCS sollte nicht als Kodierung bezeichnet werden, und UCS-2 könnte zwar zugleich auch Benennung eines Zeichensatzes sein, scheint mir aber in erster Linie eine Kodierung des Zeichensatzes UCS (bzw. der "Basic Multilingual Plane" als Teil davon) zu sein. --Ivo Dragotin (nicht signierter Beitrag von 88.64.50.74 (Diskussion) 03:14, 19. Feb. 2013 (CET))

Ein Character Set ist eine Menge von Zeichen (z. B. in Form von Vektorgrafiken) und ein Character Encoding ist eine Zuweisung der Form: ZEICHEN -> BYTE(S). Deswegen der Artikel ist eindeutig falsch. --217.81.202.200 19:37, 9. Mär. 2022 (CET)

UTF-16 != UCS-2

Siehe Diskusson unter UTF-16

--BerndEckenfels 08:45, 25. Mär 2005 (CET)

Unterschiede zu Unicode

Worin bestehen denn die "praktisch belanlosen" Unterschiede zwischen UCS und Unicode? --RokerHRO 00:00, 12. Mär. 2008 (CET)

In UCS-2 kann man "nur" die lebenden Sprachen kodieren, aber weder ägyptische Hieroglyphen noch die Keilschrift der Sumerer. Außerdem fehlen einige exotische bzw aus Einzelzeichen zusammen gesetzte Sonderzeichen. - Im konkreten Code ist in UCS-2 jedes 16-Bit-Wort genau ein Zeichen, während bei UTF-16 für ein Zeichen mehrere 16-Bit-Worte benötigt werden können. -- Gerd Fahrenhorst 22:28, 12. Mär. 2008 (CET)

Universal Character Set vs Universal Multiple-Octet Coded Character Set

Was ist nun richtig? --Seth Cohen 18:33, 12. Dez. 2010 (CET)

Allein mit 4 Worten verstehe ich die Frage nicht. Bitte ausführlicher fragen. Wo ist der Bezug zu DIESEM Artikel ? -- Gerd Fahrenhorst 20:07, 12. Dez. 2010 (CET)

Es geht darum, was die Langform der Abkürzung UCS ist. In diesem Artikel steht in der Überschrift "Universal Character Set", man liest anderswo allerdings auch "Universal Multiple-Octet Coded Character Set". Da hier explizit die ISO/IEC 10646 referenziert wird schlage ich vor, den dort verwendeten Begriff zu verwenden, und der lautet "Universal Coded Character Set". So steht es in der aktuellen Ausgabe (Fourth edition, 2014-09-01) aber auch schon in der Second edition 2011-03-15. -- Herbert Oppmann 15:46, 04. Aug. 2015 (CEST)

Es muss dringend klargestellt werden, dass UTF-16 und UCS-2 nicht dasselbe ist

Danke für die Mühe, diesen Artikel zu formulieren. Leider werden manche Leser missgeleitet, es kann der Eindruck entstehen (so geschehen bei meinem Projektleiter), als wären UCS-2 und UTF-16 dasselbe. Mag sein, dass die Codepages identisch sind, aber die Codierung ist grundverschieden.

UCS-2 ist eine Fixed-Byte Codierung. Jeder Glyph hat genau zwei Bytes. UTF-16 ist eine flexible Codierung. Ein einzelner Glyph kann zwei, aber auch mehr Bytes lang sein.

Die Unterscheidung wird benötigt, weil es Computersysteme gibt, die in höheren Schichten ein komplexes Format, wie UCS-8/16 anbieten (auch das nicht immer), aber intern in der Systemschicht mit einfachen formaten, wie z.B. UCS-2 arbeiten. Bei UCS-2 kann tief in der Systemsoftware eine einfache Lookup-Table mit 2-Byte-Schlüsseln in den Glyphenspeicher Verweisen. Also z.B. eine std::map<int16, glyph*>. (Beleg: So z.B. der Fall bei den Embedded Software Produkten meines Arbeitgebers, die auf dem Betriebssystem VxWorks basieren. Nicht alle Computer basieren auf Windows und Wikipedia darf den Anspruch haben allgemeingültig zu sein.).

Ich gehe davon aus, dass moderne Systeme in der Systemschicht erst UTF-8/16 in UCS-4 gewandelt wird und dann über eine std::map<int32, glyph*> auf den Glyphen gegriffen wird. Ich weiss genau, dass es aber Systeme gibt, die UTF-8/16 erst in UCS-2 wandeln, bevor sie in die std::map<int16, glyph*> greifen. Ein solches mir bekanntes System stammt schlichtweg aus der Zeit, als Unicode noch in 2 Byte reingepasst hatte, deswegen Int-16 statt Int-32. Und um als Systemsoftwareentwickler mit diesem Thema begrifflich adequat umgehen zu können braucht man die Unterscheidung zwischen UCS-2/UCS-4/UTF-16 ...

Wenn ich mal Zeit habe, mache ich einen Formulierungsvorschlag. (nicht signierter Beitrag von 195.124.31.219 (Diskussion) 15:32, 13. Jul 2016 (CEST))

UCS-Standard = UCS (Zeichensatz) + Zeichenkodierungen

Es sollte im Artikel klargestellt werden, dass der UCS-Standard sowohl einen Zeichensatz als auch verschiedene Zeichenkodierungen definiert. Der Zeichensatz heißt UCS und stimmt (heutzutage) mit Unicode überein. Die Kodierungen sind UTF-8, UTF-16 und UTF-32 (= UCS-4). Das ist schön klar auf Seite 1 des Standards dargestellt (bis auf die Bezeichnung UCS-4; die wird erst in Abschnitt 9.4 genutzt). Historisch gesehen gibt es auch die Kodierung UCS-2, die man wohl am ehesten im Kopf hat, wenn man nach UCS sucht. Die englische Wikipedia erwähnt im englischen UCS-Artikel auch, dass auch UTF-1 in alten Versionen des UCS-Standards definiert war, aber hierzu habe ich keine Quellen geprüft.

Ich denke, die Unklarheiten im Artikel rühren daher, dass nicht konsequent Zeichensatz und -kodierungen auseinandergehalten werden und dass nicht gesagt wird, dass der UCS-Standard sowohl einen Zeichensatz als auch mehrere Kodierungen definiert. Auch die meisten Diskussionsbeiträge scheinen von diesem Problem verursacht zu sein. --141.12.67.123 17:49, 6. Mär. 2019 (CET)

Vorschlag Erklärung des Unterschieds zwischen UTF-16 und UCS2

Folgenden Satz nach dem derzeit dritten (Nach der Revision 2011...) einfügen: Jedes UCS2-Zeichen hat den gleichen Binärcode wie das UTF-16 Zeichen, aber nicht jedes UTF-16 Zeichen kann in UCS2 dargestellt werden.

wieso UCS2 überhaupt noch relevant ist

Ich mußte erst die Diskussionen lesen um zu verstehen wieso UCS2 überhaupt noch relevant ist...--91.119.231.35 14:57, 28. Apr. 2020 (CEST)

Weder der Artikel noch die Diskussion geben das her. Der Artikel kann es nicht, weil er UCS2 als obsolet bezeichnet. Das trifft aber nur zu, wo es um Interoperabilität geht. Für die interne Repräsentation von Unicode-Zeichenketten wird UCS2 immer noch benutzt. Nur ein Bsp.:
In der Programmiersprache Python sind Zeichenketten-Objekte (Strings) 'immutable'. D.h., für eine Änderung, selbst wenn die Länge unverändert bleibt, muss ein neues Objekt angelegt werden. Einer der Vorteile ist, dass 'man' (die Implementierer der Sprache oder von Bibliotheken) entscheiden kann, Strings je nach Inhalt als UCS1, UCS2 oder UCS4 kodieren kann. Das spart meist Platz und oft auch Rechenzeit, indem spezialisierte Funktionen nicht für jedes Zeichen entscheiden müssen, mit wie vielen Bytes es kodiert ist.[1] --Rainald62 (Diskussion) 18:34, 21. Jul. 2022 (CEST)