Diskussion:UTF-8/Archiv

message: Wozu dient eigentlich die angekündigte Umstellung der Wikipedia auf UTF-8? Was für Änderungen bringt das mit sich? Kann mir das mal jemand erklären? Kiki1701 23:26, 27. Jul 2004 (CEST)
replies: text: Guckst du hier: Wikipedia:Umstellung auf Unicode und hier: http://mail.wikipedia.org/pipermail/wikide-l/2004-July/019162.html -- stw (Talk) 01:00, 28. Jul 2004 (CEST)
thread_title:  Umstellung der Wikipedia auf UTF-8 

message: ... die Anzahl der 1-Bits nach dem ersten Bit vor dem ersten 0-Bit der Anzahl an Folgebytes ...
Kann das mal bitte jemand mit Ahnung umformulieren, sodass ich es auch verstehe? Mit Dank --DreadVenturous 19:01, 2. Aug 2004 (CEST)
replies: text: Ich habe diesen Satz entfernt, da er (soweit ich das beurteilen konnte) keinen Sinn machte. Es stimmt, dass bei UTF-8 auch mitten im Datenstrom gelesen werden kann, aber bei einem einzelnen Byte 10xxxxxx kann man nicht herausfinden, ob es zu einem 2er, 3er oder 4er Multibyte gehört. --stw (Talk) 00:42, 3. Aug 2004 (CEST)
replies: text: Ist nun wieder etwas ausführlicher drin. Bei Unklarheiten einfach wieder ins Forum schreiben. Erläuterungen / Ergänzungen kommen bestimmt. --ChristianHujer 18:07, 25. Aug 2004 (CEST)
thread_title:  Zur Definition 

message: Kann mir jemand erläutern, was der Abschnitt »UTF-8 im Internet« im Großen und Ganzen soll?
: Im Internet wird immer häufiger die UTF-8-Kodierung verwendet. So unterstützt auch Wikipedia alle denkbaren Sprachen.
Was soll hier der zweite Satz?
: Auch in E-Mails ist bei einigen Programmen schon die UTF-8-Kodierung voreingestellt.
Ach, was für eine Information... Ist es eine Errungenschaft, dass ein E-Mail-Programm standardmäßig UTF-8 benutzt, anstatt ISO-8859-1 oder ISO-8859-15 zu verwenden, wenn diese ausreichen?
: Sie stellt sicher, dass auch Sonderzeichen unterschiedlicher Länder richtig übertragen und dargestellt werden.
Was hat der Satz dort zu suchen?
Im Übrigen, ist es wirklich sinnvoll, in diesem Kontext zu beschreiben, wie man UTF-8-Kodierung in HTML-Dokumenten per Meta-Element kenntlich macht? Der Hinweis bezüglich XML ist ja ziemlich nutzlos, weil UTF-8 Fallback ist. Ich bin dafür, diesen Abschnitt zu streichen. -- molily 20:26, 21. Jul 2005 (CEST)
thread_title:  Abschnitt »UTF-8 im Internet« 

message: Hilfe, was ist das für ein Satzungetüm?!
: Die code points U+D800-U+DBFF und U+DC00-U+DFFF sind als Low und High surrogates in der Unicode BMP reserviert (für UTF-16) und sollten entsprechend auch nicht codiert werden. z.B. wird U+10400 in UTF-16 als D801,DC00 dargestellt, sollte in UTF-8 aber als F0,90,90,80 und nicht als ED,A0,81,ED,B0,80 ausgedrückt werden.
Das ist der Wikipedia wirklich unwürdig. Kann das jemand ins Deutsche übersetzen? (Nicht nur die englischen Begriffe, den gesamten Sinn in eine menschenlesbare Sprache übertragen.) -- molily 03:24, 5. Sep 2005 (CEST)
thread_title:  Unverständliches Technikbla 

message: Ich habe ein wenig überarbeitet, und mich auch der -- schon recht alten -- Beschwerden in den obigen beiden Abschnitten angenommen. Allerdings wirkt wohl auch die neue Formulierung zu den Low and High Surrogates immer noch kyrptisch für Laien.  --Pjacobi 10:38, 2. Jun 2006 (CEST)
thread_title:  10:38, 2. Jun 2006 (CEST) 

message: Kann mal jemand sagen, was ein "rechtes Byte" bzw. ein "rechtes Bit" ist? Eindeutiger wäre ja wohl, von "least significant" bzw. "most significant" zu sprechen.
:Nein, in diesem Fall ist tatsächlich von der Position des Bytes die Rede. Denn es geht um Byte-Ketten, nicht um Mehrbytewerte (Words). --jpp ?! 12:40, 14. Nov. 2006 (CET)
replies: text: Hm, eigentlich geht es ja um die Position in einer Abfolge. Waeren da nicht Ausdruecke wie "erstes Byte"/"letztes Byte" angebrachter? Schliesslich sind die Bytes ja nicht "rechts oder links" angeordnet...84.177.241.61 22:10, 10. Feb. 2008 (CET)
replies: text: Da hast du allerdings recht. --j ?! 23:16, 10. Feb. 2008 (CET)
replies: text: gemeint ist: 'rechtes Bit' rechtes (letztes) Bit des Byte. 'rechtes Byte': rechtes (letztes) Byte der Bytes, die gemeinsam zu einem Unicode-Zeichen gehören. Vorschlag: statt "Bei mehreren Bytes für ein Zeichen werden die Bits rechtsbündig angeordnet – das rechte Bit des Unicode-Zeichens steht also immer im rechten Bit des letzten UTF-8-Bytes." dieses: "Innerhalb eines Bytes stehen die Bits, die der Kodierung eines Unicode-Zeichen dienen, rechts - die linken Bits sind Steuerzeichen. Die Grenze zwischen links und rechts variiert. Das letzte Bit einer Kodierung eines Unicode-Zeichens ist gleich dem letzten Bit des letzten Bytes die gemeinsam das Unicode-Zeichen Repräsentieren." ... zugegeben nicht einfacher - aber zumindest eindeutiger. --Fredric 20:07, 3. Jan. 2010 (CET)
thread_title:  "rechtes Byte?" 

message: Eine längere Diskussion zur Benutztung von UTF-8 in URL-Kodierungen wurde nach Diskussion:URL-Kodierung#UTF-8 verschoben. -- JonnyJD 01:42, 29. Mai 2007 (CEST)
thread_title:  URL-Kodierung 

message: Für Artikel mit Problemen mit der Darstellung von UTF-8, gibt es die Vorlage , die man am Ende eines Artikels platzieren kann. Jón talk / contribs 09:17, 23. Jul. 2007 (CEST)
thread_title:  Vorlage UTF-8 / Probleme mit UTF-8 

message: Vielleicht sollte auch darauf eingegangen werden, dass für einige Zeichen UTF-8 mehrere Darstellungsformen erlaubt. So benutzt bspw. Windows für Umlaute ein Zeichen (NFC), während Mac OS X' Dateisystem zwei Zeichen benutzt (NFD). Dies führt z.B. zu Problemen in Subversion bei Benutzung von Umlauten in Dateinamen und Benutzung auf verschiedenen Plattformen. 84.145.45.171 12:25, 9. Aug. 2007 (CEST)
replies: text: Unter Linux ist sogar beides moeglich, so dass man mehrere Dateien mit dem gleichen Namen im selben Verzeichnis haben kann. :-/ 88.68.213.86 06:35, 30. Mär. 2008 (CEST)
thread_title:  NFD vs. NFC 

message: Warum ist hinter dem Violinschlüssel ein Fragezeichen und kein Violinschlüssel? (Der vorstehende, nicht signierte Beitrag stammt von 79.206.161.244 (Diskussion • Beiträge) 12:46, 1. Dez 2007) Fomafix 13:46, 1. Dez. 2007 (CET)
replies: text: Das 𝄞 (U+1D11E MUSICAL SYMBOL G CLEF) ist kein Fragezeichen, sondern ein Violinschlüssel. Dieses Zeichen wird derzeit nur von sehr wenigen Schriftarten unterstützt. Wenn die Browser ein Zeichen nicht darstellen können, weil es in der (in allen) Schriftarten nicht vorhanden ist, dann wird ein Ersatzzeichen angezeigt. Der Firefox verwenden ein Fragezeichen als Ersatzzeichen. --Fomafix 13:46, 1. Dez. 2007 (CET)

text: Falsch. 𝄞 (U+1D11E MUSICAL SYMBOL G CLEF) ist ein Violinschlüssel, siehe: http://www.fileformat.info/info/unicode/char/1D11E/index.htm --Fomafix 09:28, 5. Mai 2008 (CEST)
thread_title:  Violinschlüssel 

message: Im Quelltext stand folgende Rechnung (etwas ergänzt):
: 7*6+0 -> 2^42 = 4.398.046.511.104
: 6*6+0 -> 2^36 =    68.719.476.736
: 5*6+1 -> 2^31 =     2.147.483.648
: 4*6+2 -> 2^26 =        67.108.864
: 3*6+3 -> 2^21 =         2.097.152
: 2*6+4 -> 2^16 =            65.536
: 1*6+5 -> 2^11 =             2.048
: 0*6+7 -> 2^7  =               128
: =================================
:               = 70.936.234.112 + 4.398.046.511.104
das zusammenzuzählen ist allerdings Unsinn, da das eine unmachbare willkürliche Zusatzbelegung für die mehrfach codierbaren Unicode-Zeichen erfordern würde (U+1 = "00000001" = "11000000 10000001" = "11100000 10000000 10000001"). Was die Tabelle bei "in Klammern theoretisch möglich" aussagt, ist, dass man nur mit Doppelbytefolgen alleine 2^11 verschiedene Zeichen kodieren kann (11000000 10000000 bis 11011111 10111111 = U+0 bis U+(2^11-1). Dazu die Ein-Byte-Codes 0-127 nochmal dazuzuzählen und zu behaupten, man könne mit maximal zwei Bytes 2^11 + 128 Zeichen kodieren, macht keinen Sinn. --androl ☖☗ 13:37, 19. Feb. 2008 (CET)
thread_title:  theoretische Anzahl der codierbaren Zeichen 

message: Ich habe gerade die "1.114.112" aus dem ersten Absatz geloescht, da das definitiv zu viel ist. Zum Beispiel kann UTF-16 theoretisch maximal nur 1.112.064 "Zeichen" kodieren. Aber auch das ist zu viel, da hier noch die ganzen verbotenen Zeichen wie "U+FFFE" (verdrehtes BOM) drin stecken. Zieht man die 66 Noncharacters ab kaeme man auf 1.111.998 moegliche Unicode-Zeichen. Ich bin mir aber nicht sicher, ob das wirklich die richtige Anzahl ist. Mehr sind es auf keinen Fall, aber vielleicht muss man noch mehr abziehen? Weiss da jemand Genaueres? RedNifre 19:53, 5. Mai 2008 (CEST)
thread_title:  Tatsaechliche Anzahl der codierbaren Zeichen 

message: Ich denke hier liegt ein Verdreher vor.
das Beispiel war:
1110xxxx 10xxxxxx 10xxxxxx
Aber die zwei 1-Bits, die die Folgebytes angeben sind ja nach dem höchsten 1-Bit und vor dem höchsten 0-Bit.
und nicht:
"nach dem höchsten 0-Bit vor dem höchsten 1-Bit."
ich hoffe ich sehe das richtig so.
Soegel 09:51, 10. Nov 2008 (CEST)
replies: text: Hmm, kontrolliert hier noch jemand? --Soegel 15:01, 12. Nov. 2008 (CET)
thread_title:  Änderung in Zeile 65 

message: Ich finde den Artikel sehr gut gemacht. Nur stolpert der Autor bei der Darstellung der Zeichen über sein eigenes Thema. 
Er muss davon ausgehen, dass die Darstellung der Zeichen selbst (eben oft auch in UTF8) auf dem Zielsystem für die letzten zwei Beispiele scheitert. 
Vorschlag: eine Spalte "beabsichtigtes Zeichen" einführen und dort die korrekte Zeichen als Bild einfügen (.gif, .png...)
somit wäre sichergestellt, dass jeder sehen kann, wie es aussehen müsste.
Dahingegen könnte die jetzige letzte Spalte überschrieben werden als: "so stellt Ihr Programm diese Codierung dar:"
Gruss
Cosy
: Die letzte Spalte wird auf keinem Computer der Welt 'richtig' dargestellt (und das ist hier zur Demonstration auch so gewollt), denn "bei eingeschaltetem ISO-8859-1-Encoding" wird Unicode - bis auf die ASCII-Zeichen - immer falsch dargestellt. --Daniel Bunčić 11:38, 12. Feb. 2009 (CET)
replies: text:  Vielleicht sollte in der letzten Spalte die Darstellung in Windows-1252 wählen werden, dann wären keine C1 Controls (U+0080 bis U+009F) dabei. --Fomafix 12:39, 12. Feb. 2009 (CET)
replies: text:  0x9D ist bei Windows-1252 unbelegt , daher würde auch diese Darstellung ein nicht darstellbares/ungültiges Zeichen enthalten. --Fomafix 11:25, 13. Feb. 2009 (CET)

text: Ich habe die letzte Spalte herausgenommen, da sie zudem noch falsch war. Beispielsweise würde das €-Zeichen bei falscher Dekodierung nach Latin-1 als U+00E2 U+0082 U+00AC (â¬) erscheinen, und nicht wie behauptet als U+00E2 U+FFFD U+00AC (â�¬). Das Zeichen U+FFFD gibt es in Latin-1 nicht. --ulm 16:52, 21. Sep. 2009 (CEST)
thread_title:  Anmerkungen zur Tabelle UTF-Beispiele 

message: Vorschlag Kodierung: 
"Es muss grundsätzlich zwischen der UTF-8-Kodierung (auf Byte- bzw. Bit-Ebene) und der Bitfolge eines Unicode-Wertes unterschieden werden. UTF-8 unterteilt die 8 Bits eines Bytes in Steuerbits (vergl. Escape-Mechanismus) am Anfang und den folgenden Bits, die der eigentlichen Zeichen-Kodierung dienen (bei ASCII sind alle Bits Zeichenbits). Eine führende "0" zeigt an, dass die folgenden 7 Bits Zeichen-Bits sind. Diese 7 Bit entsprechen auch exakt der ASCII-Kodierung bis zum Wert 127. (Eine Interpretation gemäß ASCII führt, auf Grund der führenden 0, also zum gleichen Ergebnis.) Eine führende "1" zeigt an, dass die Bitfolge des Unicode-Wertes auf (die Zeichen-Kodierung-Bereiche) mehrerer Bytes aufgeteilt wird (ASCII: 1 Byte pro Zeichen). Die Anzahl der führenden Einsen (des ersten Bytes) entspricht der Anzahl der Bytes, die für die Zeichen-Kodierung verwendet werden. Die zugehörigen folgenden Bytes beginnen mit "10". (Der Bereich der Steuerbits endet also immer mit einer "0")..."
Zwei statt einer Tabelle: Bitfolge als Spalte und Bemerkung als Überschrift.
Meinungen bitte
--Fredric 20:29, 17. Dez. 2009 (CET)
replies: text: Ähem... wozu? Die Kodierung und damit die Bedeutung der oberen Bits jedes Bytes des utf8-kodierten Bytestroms ist doch im Artikel bereits beschrieben, nur einfacher(!). Was genau vermisst du? --RokerHRO 22:00, 17. Dez. 2009 (CET)
replies: text:  einfacher? Der Einleitungsabschnitt ist kürzer, ja - aber auch unverständlich, weil eben zu kurz bzw. die Informationen, die alles verständlich machen, kommen erst hinter der Tabelle in der Auflistung. Was mir auf jeden Fall fehlt, ist die explizite Differenzierung in Steuer- und Zeichen-Bits als Gegensatz zu ASCII - am Anfang. Auch muss viel früher dargestellt werden, dass die Zeichenbits nicht nur über mehrere Bytes verteilt sind, sondern auch (hintereinander weg gelesen) von den Steuerbits unterbrochen werden - das wird im Artikel erst durch die zweite farbliche Tabelle auf intuitive Weise klar. In der Auflistung heißt es immerhin rechtsbündig aber auch nicht ausführlich - schließlich kann man das auch so interpretieren, dass im Startbyte die Länge definiert wird und danach dann gar keine Steuerbits mehr kommen. Und dass bis Wert 127 das gleiche raus kommt, ist zwar wichtig und interessant aber erst dann angebracht, wenn das System an sich verständlich dargestellt wurde. Dazu gehören dann aber auch einige Beispiele, was passiert wenn ASCII / UTF-8 falsch angegeben ist, also falsch interpretiert wird. --Fredric 23:00, 17. Dez. 2009 (CET)
thread_title:  Verteilung UTF8-Bits auf Bytes 

message: ----
Die im Artikel über UTF angegebene ISO/IEC-Norm ist veraltet. 
Inzwischen gibt es die Ausgabe 2003 von 
ISO/IEC 10646, Information technology - Universal Multiple-Octet Coded Character Set (UCS).
zu finden in: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html   
Dort ist UTF in Anhang D.
Zu RFC 3629 ("UTF-8"), siehe http://tools.ietf.org/html/rfc3629; Stand 2003.
Ferner möchte ich empfehlen, unter den weiterführenden Webseiten noch die folgende aufzunehmen, die tabellarisch viele UTF-8-Codes zu den Unicodes auflistet. Fand ich sehr nützlich, wenn die Adresszeile meines Browsers nur UTF-8-Salat anzeigt:
 http://www.utf8-zeichentabelle.de
Vielleicht noch einen Hinweis: Bei Unterseiten von Internetseiten wird in der Adresszeile meiner Browser (egal ob im Internet-Explorer oder im Firefox) statt Unicodezeichen der Original-UTF-8-Code angezeigt mit einem Prozentzeichen eingefügt. Kann mir jemand sagen, wie ich  den Browser einstellen muss, dass ich statt UTF-8 die ursprünglichen Umlaute und Zeichen angezeigt bekomme?
--Hakris 22:32, 21. Feb. 2010 (CET)
replies: text: Also bei mir ist das keinn UTF-8 Salat, sondern die hexadezimale Nummer des Zeichens, z.B. Leerzeichen = %20 Oder meinst du punycode? 93.220.103.167 08:16, 6. Jun. 2010 (CEST)
thread_title:  ISO-Norm veraltet und weiterer Link 

message: Ich habe bemerkt das Java SE und J2ME unterschiedlich kodieren. Am Beispiel 'Ü' (220) verwendet SE zwei Bytes und ME ein Byte.
220 entspricht 11011100, wenn man die ersten drei Bits betrachtet müsste ein folge Byte kommen welches mit 10 beginnt. Allerdings beginnt kein Unicode-Zeichen mit 10. Verliert UTF-8 so nicht eine grosse Anzahl an Möglichkeiten wenn Bereiche wie 1100000 bis 11011111 ohne folge Byte nicht genutzt werden? Hier sind es nur 32. Aber wenn man den Bereich 11100000 10000000 bis 1110111 10111111 ohne zweites folge Byte betrachtet sind es schon 512 Möglichkeiten. Bei 11110 ohne viertes folge Byte sind es 32768 Möglichkeiten. Total also 33312 oder etwas mehr als 15 Bit Möglichkeiten welche zu kürzeren Kodierung verwendet werden könnten. 
Weshalb gibt es diese Lücken?
Falls 'Ü' mit nur 8 Bits korrekt kodiert ist muss folgender Satz gelöscht bzw. angepasst werden: "Ist das höchste Bit des ersten Bytes 1, handelt es sich um ein Mehrbytezeichen, also ein Unicode-Zeichen mit einer Zeichennummer größer als 127." (nicht signierter Beitrag von 89.217.36.116 (Diskussion) 08:09, 18. Sep. 2010 (CEST)
replies: text: Hi, bei UTF sind nur die Werte 0 bis 127 mit 1 Byte (8 Bit) codiert, siehe Tabelle im Artikel. Das Zeichen Ü hat irgendeinen Wert größer 128, wird also in UTF8 mit mehr als einem Byte codiert.--wdwd 11:18, 18. Sep. 2010 (CEST)
replies: text: Theoretisch wäre 'Ü' als 11000011 10011100 kodiert. Es würden jedoch keine Konflikte entstehen wenn 'Ü' nur als 11011100 kodiert wäre. In J2ME ist "Ü".getBytes().length nur Eins, und in der Desktop Version Zwei. 89.217.36.116 08:01, 19. Sep. 2010 (CEST)
replies: text:  Die Binärzahl 11011100 (oder 220dez oder DChex) ist die Kodierung des Ü im Zeichensatz ISO 8859-1. Möglich, dass Java2ME eben kein UTF-8 benutzt, da es für die Mobilgeräte, für die es gedacht ist, zu ressourcenfressend ist. --RokerHRO 13:03, 19. Sep. 2010 (CEST)
replies: text: Scheint als ob du Recht hast. 220 bzw. -36 lässt sich problemlos in 'Ü' umwandeln. Mit dem zwei Byte Code habe ich es allerdings nicht geschafft, er wurde immer als zwei Zeichen angezeigt. In Java SE sollte es aber irgendwie möglich sein. 188.155.90.122 03:34, 21. Sep. 2010 (CEST)

text: Eine Frage ist aber immer noch offen. Wozu dienen die toten Bereiche? 188.155.90.122 05:12, 21. Sep. 2010 (CEST)
thread_title:  Tote Bereiche 

message: Was ist nun richtig? --Seth Cohen 18:32, 12. Dez. 2010 (CET)
replies: text: Womöglich ja einfach beides. (Welle oder Teilchen..? :-) ). --85.179.130.0 15:12, 12. Jul. 2012 (MESZ)
thread_title:  Unicode Transformation Format vs. UCS Transformation Format 

message: UTF-2 ist ein Redirect auf auf UTF-8 - ohne ein sterbenswörtchen der Erklärung. --Itu 22:51, 18. Sep. 2011 (CEST)
replies: text: Google ergab auf die Schnelle, dass utf2 ein veralteter Name für frühe UTF-8-Versionen war, z.B. hier: . Ein bisschen mehr Recherche wäre aber angebracht. --RokerHRO 08:06, 19. Sep. 2011 (CEST)
replies: text: Diese Bezeichnung hat womöglich damit etwas zu tun, daß bei diesem Zeichensatz 2 Hex-Zeichen (8 Bit) für jedes Klarzeichen genutzt wird. Oder damit sind nur die ersten 2 Zeichenblökke gemeint, welche auch in UTF-8 enthalten und diese beiden Zeichensätze so ferträglich (oder kompatibel) zueinander machen – so scheint das jedenfalls die fon dir genannte Seite zu beschreiben (wenn diese durch den Google-Übersetzer gejagt wird). --85.179.130.0 15:20, 12. Jul. 2012 (MESZ)
replies: text: Nein. Es gab vorher ein Format namens UTF-1, das diverse Schwächen hatte. Und die verbesserte Version bekam dann eben die nächste "Versionsnummer": UTF-2. Erst später kam man auf die Idee, das UTF-8 zu nennen, da man Unicode-Zeichen in "8-Bit-Einheiten" kodiert. --RokerHRO (Diskussion) 08:01, 13. Jul. 2012 (CEST)
thread_title:  UTF-2 

message: In einer Tabelle werden Hex-Zahlen mit führendem "0x" geschrieben - das ist aber die C-Schreibweise für Hex-Zahlen. Also sollte entweder statt 0xC3 einfach C3 - wie es jeder HEX-Editor auch darstellt - geschrieben werden oder zumindest ein Hinweis, welche Schreibweise das ist. --83.135.95.143 18:12, 8. Sep. 2012 (CEST)
replies: text: In der Überschrift steht bereits das in der Spalte Hexadezimal gemeint ist. Ich habe den Präfix 0x [ entfernt]. Danke für den Hinweis. --Fomafix (Diskussion) 20:15, 8. Sep. 2012 (CEST)
thread_title:  Präfix 0x 

message: "In UTF8 besteht das Sonderzeichen aus zwei Bytes, die in ASCII den Zeichen Ã und ¶ entsprechen."
-> ASCII geht nur bis 127 und beinhaltet diese Zeichen nicht. Gemeint ist wohl ANSI.
"Denn das Zeichen mit dem Hexadezimalwert F6 gibt es im UTF8-Zeichensatz nicht."
-> UTF8 ist kein Zeichensatz, sondern eine Kodierung von Unicode Codepoints.
--91.66.98.216 00:37, 16. Dez. 2013 (CET)
thread_title:  Terminologie 

message: "In anderen Sprachen ist der Speicherbedarf in Byte pro Zeichen größer, wenn diese vom ASCII-Zeichensatz abweichen: Bereits die deutschen Umlaute erfordern zwei Byte;"
Diese Textpassage sollte angepasst werden.
Der Zeichensatz ISO-8859-1 bspw. oder auch alle LATIN-Zeichensätze sind jeweils 8 Bit groß und enthalten alle deutschen Umlaute.
Ist also imho faktisch falsch. (nicht signierter Beitrag von 79.227.120.234 (Diskussion) 15:48, 24. Dez. 2015 (CET)
replies: text: Hier geht’s aber nun mal um UTF-8 und um keinen anderen Zeichensatz. Und da brauchen die Umlaute zwei Byte. Ergo, alles richtig. LG, ℳ웃79 ✍ 16:20, 24. Dez. 2015 (CET)
thread_title:  "Bereits deutsche Umlaute erfordern 2 Byte" 

message: ist hierzu eine Liste oder ein histoischer Abriss verfügbar? (nicht signierter Beitrag von 90.186.1.11 (Diskussion) 16:29, 17. Jan. 2016 (CET)
thread_title:  Welche Betriebssysteme und Progammiersprachen unterstützen  UTF-8  

message: * Unicode wird von einigen älteren Browsern nicht oder nicht korrekt unterstützt (Internet Explorer 3, Netscape Navigator 3, aber auch Internet Explorer 5.1 unter MacOS 9). Viele dieser Browser unterstützen allerdings auch kein CSS, so dass die (aktuelle) Wikipedia und der Rest des Internets mit ihnen ohnehin nur eingeschränkt nutzbar sind; Entsprechend selten sind diese Browser heute noch im Internet anzutreffen. (nicht signierter Beitrag von 90.186.1.11 (Diskussion) 16:29, 17. Jan. 2016 (CET)
thread_title:  Nachteile von Unicode 

message: Welche Bewandnis hat der Link "utf8everywhere manifesto"? Abgesehen von Propaganda... .yxzxzyzyyz. (Diskussion) 11:08, 31. Okt. 2017 (CET)
thread_title:  Weblinks 

message: <<Das Internet Mail Consortium (IMC) empfiehlt, dass alle E-Mail-Programme UTF-8 darstellen und senden können.[4] Im Jahr 2008 wurde diese Empfehlung allerdings immer noch nicht global befolgt.>>
Kann jemand, der Bescheid weiß beifügen, ob das jetzt, 2019, immer noch so ist?                                      
--2A02:120B:2C75:A650:6AC9:CFAB:99DE:9C47 08:54, 3. Mai 2019 (CEST)
replies: text: Es gibt soviel unterschiedliche Software, die irgendwas mit E-Mail zu tun hat, dass dir das wohl niemand sicher sagen kann. Klar ist, wenn eine Software neu geschrieben wird, ist UTF8-Support keine Hürde mehr. Aber bei „alter“, lang entwickelter Software, die es schon vor 2008 gab und nie dahingehend erneuert wurde, kann es auch heute noch Inkompatibilitäten/Probleme geben. LG, ℳ웃79 10:02, 3. Mai 2019 (CEST)
thread_title:  2008 war es so...    ... und heute? 

message: Warum wird hinter der Längencodierung 0 (ASCII)/11-1111(Start)/10 (Folgebyte) immer eine 0 angehängt?
also 110 - 11110 (Start).
Hier werden ja im Grunde unnötigerweise Bits verschwendet oder ist es aus Gründen der Eindeutigkeit nötig? Sieht auf den ersten Blick so aus, als ob auch das Weglassen eines 0-Bits nichts an der Eindeutigkeit ändert. --94.134.251.62 16:29, 28. Sep. 2020 (CEST)
replies: text: Es ist aus Gründen der eindeutigen Dekodierbarkeit notwendig. Wenn eine Multibytesequenz mit dem Byte F8hex anfängt (Binär: 11111000), wie willst du sonst wissen, wie viele Bits das "Präfix" sind, und was bereits zu den kodierten Datenbits gehört, wenn da kein Nullbit die beiden Bereiche trennt? --RokerHRO (Diskussion) 09:33, 18. Dez. 2020 (CET)
thread_title:  Längencodierung