Quelltext der Seite Diskussion:Unicode Transformation Format

{{Autoarchiv
|Alter             =730
|Ziel              ='Diskussion:Unicode Transformation Format/Archiv/1'
|Übersicht         =[[Spezial:Präfixindex/Diskussion:Unicode Transformation Format/Archiv|Archiv]]
|Mindestbeiträge   =1
|Mindestabschnitte =4
|Frequenz          =monatlich
}}

== Rechtschreibung ==

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. --[[Benutzer:Dicio|Dicio]] 00:24, 3. Apr. 2009 (CEST)

: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. --[[Benutzer:RokerHRO|RokerHRO]] 13:09, 3. Apr. 2009 (CEST)

:: 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]]. --[[Benutzer:Fomafix|Fomafix]] 13:20, 3. Apr. 2009 (CEST)

::: Stimmt. Darum frage ich mich, warum das hier überhaupt nochmal durchgekaut werden muss... :-/ --[[Benutzer:RokerHRO|RokerHRO]] 20:34, 3. Apr. 2009 (CEST)

:::: @ 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? --[[Benutzer:Dicio|Dicio]] 01:53, 6. Apr. 2009 (CEST)

== Unverständliche Formulierung im Abschnitt „UTF-EBCDIC“ ==

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 &hellip; den restlichen Unicode-Vorrat &hellip; 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  2<sup>7*(8-3)</sup> = 2<sup>35</sup> liegt, bei UTF-8 jedoch mit seinen 2-Bit-Präfixe in Folgebytes bei 2<sup>7*(8-2)</sup> = 2<sup>42</sup>. 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.

-- [[Benutzer:Silvicola|Silvicola]]&nbsp;<small>[[Benutzer Diskussion:Silvicola|Diskussion Silvicola]]</small> 11:13, 20. Dez. 2009 (CET)

== "Unicode Transformation Format" oder "UCS Transformation Format" ==
Guude<br/>
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 [https://tools.ietf.org/html/rfc3629 rfc-3629] spricht nicht von Unicode<br/>Gruß Ingo --[[Benutzer:Istiller|Istiller]] ([[Benutzer Diskussion:Istiller|Diskussion]]) 12:02, 29. Aug. 2016 (CEST)

== 2022 noch immer kein UTF-64 ==

Es wird im Artikel bei heutigen Therabyte großen Speichern von dem ungeheuren Speicherbedarf bei UTF-32 gesprochen--[[Spezial:Beiträge/2A02:908:1571:6DC0:A83B:C01C:D452:9FD4|2A02:908:1571:6DC0:A83B:C01C:D452:9FD4]] 08:49, 20. Jun. 2022 (CEST)
: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. -- [[Benutzer:Gerd Fahrenhorst|Gerd Fahrenhorst]] ([[Benutzer Diskussion:Gerd Fahrenhorst|Diskussion]]) 18:18, 20. Jun. 2022 (CEST)