Diskussion:Unicode Transformation Format

message: Ich hatte eine kleine Änderung gemacht, welche zurückgezogen wurde. Ich verstehe nicht ganz warum, daher möchte ich mal folgenden Änderungsvorschlag diskutieren:
Original: "Mithilfe des 8. Bits kann ein längeres Unicode-Zeichen eingeleitet werden, was sich auf 2, 3 oder 4 Byte erstreckt."
Vorschlag: "Mit [der] Hilfe des 8. Bits kann ein längeres Unicode-Zeichen eingeleitet werden, welches sich [...]."
Ich bitte daher um eure Mithilfe. --Dicio 00:24, 3. Apr. 2009 (CEST)
replies: text: Der ganze Absatz ist ziemlich holprig/unglücklich formuliert. Es gibt keine "längeren Unicode-Zeichen", man könnte allenfalls sagen, dass "ein gesetztes 8. Bit eine Mehrbyte-Sequenz anzeigt, die ein Unicodezeichen >U+007F in 2 bis 4 Bytes kodiert" oder sowas in der Art. Damit vermeidet man das seltsame "mit Hilfe/mithilfe" ganz. --RokerHRO 13:09, 3. Apr. 2009 (CEST)
replies: text:  Wie wäre es mit folgendem Satz: „Bytes mit gesetztem höchstwertigen Bit gehören zu Unicodezeichen, die auf zwei bis vier Bytes aufgeteilt werden.“ Details stehen schließlich unter UTF-8. --Fomafix 13:20, 3. Apr. 2009 (CEST)
replies: text:  Stimmt. Darum frage ich mich, warum das hier überhaupt nochmal durchgekaut werden muss... :-/ --RokerHRO 20:34, 3. Apr. 2009 (CEST)
replies: text:  @ Formafix oder RokerHRO: Ich bin fachlich nicht ganz so gut bewandert in den Dingen. Wäre jemand von Euch beiden so nett die Änderung durchführen? --Dicio 01:53, 6. Apr. 2009 (CEST)
thread_title:  Rechtschreibung 

message: Der zentrale Schachtelsatz des Abschnitts
:„Es kodiert jedoch die ersten 160 Zeichen (65 Steuerzeichen und 95 graphischen Zeichen) in jeweils einem Byte an den bei EBCDIC üblichen Positionen, soweit existent, den restlichen Unicode-Vorrat analog zu UTF-8 in jeweils zwei bis fünf Bytes (bzw. bis sieben für Codepositionen, die schon mit UTF-16 nicht darstellbar sind, und daher wohl nie mit Zeichen belegt werden), an Positionen, die bei diversen EBCDIC-Codepages mit verschiedenen graphischen Zeichen belegt sind.“
ist mir recht unverständlich. Bezieht sich der Einschub „soweit existent“ auf was vorher steht oder auf was nachher steht? Liegen also die 160 - 128 = 32 Zeichen „Zugewinn“ im 1-Byte-Bereich gegenüber UTF-8 bei EBCDIC schon auf den Codepositionen 100xxxxx (=vorher); oder ist vielmehr gemeint, dass nicht der ganze Unicode-Vorrat auf UTF-EBCDIC-Systemen auch wirklich genutzt wird (=nachher)? Der Versuch einer Klärung auf EBCDIC scheiterte leider.
Das noch im selben Satz Folgende ist auch verwirrend. Soll „Es kodiert … den restlichen Unicode-Vorrat … an Positionen, die bei diversen EBCDIC-Codepages mit verschiedenen graphischen Zeichen belegt sind“ nun heißen, so wie es wörtlich dasteht, dass auf belegte Positionen kodiert wird, und die noch dazu wechseln? Doch wohl eher nicht, oder? Und schließlich geht der restliche Unicode-Zeichenvorrat ja wohl auch über eine recht beschränkte Zahl von Graphikzeichen hinaus. Ist in Wahrheit gemeint, dass bestimmte Ziel-Positionen von der Kodierung nicht getroffen, sondern vermieden werden sollten? Oder ist doch gemeint, dass ein Teil oder sämtliche der zu kodierenden Zeichen eben EBCDIC-Graphik-Zeichen sind?
Man sollte den Schachtelsatz unbedingt in kürzere Einzelsätze zerlegen, ein Gedanke pro Satz. Die enthaltene Parenthese „(bzw. bis sieben für Codepositionen, die schon mit UTF-16 nicht darstellbar sind, und daher wohl nie mit Zeichen belegt werden)“ gehört sowieso nicht auch noch in diesen Wust hinein, sie benennt ja ohnehin nur etwas Irreales, nämlich wie weit man die Kodierung theoretisch noch ausbauen könnte, aber eben noch nicht ausgebaut hat; das wäre eher etwas für einen Nachsatz. (Man beachte, dass wegen der 3-Bit-Präfixe in Folgebytes von UTF-EBCDIC der theoretische Umfang des Zeichenvorrates hierin bei  27*(8-3) = 235 liegt, bei UTF-8 jedoch mit seinen 2-Bit-Präfixe in Folgebytes bei 27*(8-2) = 242. Bei weiterem Ausbau müsste also zuletzt auch noch die Interoperabilität verletzt werden. Man wird sich da wohl hüten.)
Da UTF-EBCDIC systematisch etwas anders vorgeht als UTF-8, habe ich die vordem formulierte Analogie sprachlich schon etwas relativiert und in ihren Auswirkungen illustriert, soweit ich's mir auf eigene Kappe zugetraut habe. (Siehe Edit-Kommentar.) Beim restlichen Knoten schaue ich, wie oben beschrieben, nicht genügend durch für eigenständige Umformulierung.
-- Silvicola Diskussion Silvicola 11:13, 20. Dez. 2009 (CET)
thread_title:  Unverständliche Formulierung im Abschnitt „UTF-EBCDIC“ 

message: Guude
Was stimmt den nun?
* UTF = "Unicode Transformation Format"
* UTF = "UCS Transformation Format"
Laut UTF-8 ist UTF von "Universal Character Set Transformation Format" abgeleitet. Das "Unicode" auch mit "U" anfängt war dann eher Zufall. Auch der Standard rfc-3629 spricht nicht von UnicodeGruß Ingo --Istiller (Diskussion) 12:02, 29. Aug. 2016 (CEST)
thread_title:  "Unicode Transformation Format" oder "UCS Transformation Format" 

message: Es wird im Artikel bei heutigen Therabyte großen Speichern von dem ungeheuren Speicherbedarf bei UTF-32 gesprochen--2A02:908:1571:6DC0:A83B:C01C:D452:9FD4 08:49, 20. Jun. 2022 (CEST)
replies: text: UTF dient ja dazu, die derzeit 145.000 Unicode Zeichen abzuspeichern. Da reichen die 32 Bit pro Zeichen dicke, mit 64 Bit pro Zeichen würde nur unnötig Speicher verschwendet. -- Gerd Fahrenhorst (Diskussion) 18:18, 20. Jun. 2022 (CEST)
thread_title:  2022 noch immer kein UTF-64