Diskussion:UTF-8/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:UTF-8/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:UTF-8/Archiv#Thema_1

Java und UTF-8

Folgendes Java-Programm:

import java.io.*;

public class GenNull {
    public static void main(final String[] args) throws IOException {
        Writer out = new OutputStreamWriter(System.out, "utf-8");
        out.write(0);
        out.flush();
        out.close();
    }
}

Größe der entstehenden Datei: 1 Byte Inhalt der entstehenden Datei: 00-Byte

chris@riedquat:~/Java1.5/Unicode> java -version java version "1.5.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c) Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

Deshalb habe ich die Aussage, Java würde 0 nicht korrekt kodieren, gelöscht.

--ChristianHujer 19:51, 12. Apr 2004 (CEST)

• Allerdings schreibt dieses Programm auf System.out, was zwar in eine Datei umgeleitet werden kann (Umleitung hier durch das Betriebssystem nicht durch die JVM), aber gewöhnlich auf die Konsole geht. Ich habe es nicht getestet, vermute aber, dass ein Programm, das selber ein File öffnet und in dieses anstelle von System.out dem OutputStreamWriter übergibt, tatsächlich eine 2-Byte-Kodierung erzeugen würde. 195.93.66.16 10:36, 29. Apr 2004 (CEST)

---

Wer sich mit Java auskennt, weiß, dass es völlig egal ist, auf welcher Art von Stream ich meinen OutputStreamWriter zur Ausgabe von UTF-8 erzeuge. Die Kodierung nach UTF-8 erfolgt im OutputStreamWriter, nicht durch System.out.

Also einfach mal System.out durch new FileOutputStream(args[0]) ersetzen und mit Dateinamen aufrufen und nochmal prüfen:

import java.io.*;
public class GenNull2 {
    public static void main(final String... args) throws IOException {
        Writer out = new OutputStreamWriter(new FileOutputStream(args[0]), "utf-8");
        out.write('a');
        out.write(0);
        out.write('b');
        out.write('ü');
        out.flush();
        out.close();
    }
}

und siehe da, es funktioniert auch mit Dateien, nicht nur auf System.out. Fazit: Java kodiert das UTF-8 Null-Byte korrekt. Wer etwas anderes behauptet, soll erstmal einen Test-Case bereitstellen, bevor er wieder den UTF-8-Eintrag in der Wikipedia ändert ;-) --ChristianHujer 12:04, 2. Aug 2004 (CEST)

Man teste diesen Code:

import java.io.*;
public class GenNull3{
  public static void main(String[] args){
    try{
      DataOutputStream s =
        new DataOutputStream(new FileOutputStream("utftest.txt"));
      s.writeUTF("\u0000");
      s.close();
    }catch(IOException exc){
    }
  }
}

Mir ist nur die Methode DataOutput.writeUTF bekannt, die die 0 anders behandelt als es der UTF-8-Standard vorsieht (und natürlich ihr Gegenstück im DataInputStream). --SirJective 23:39, 21. Aug 2004 (CEST)

Für java.io.* gibt's eine einfache Regel: InputStream und OutputStream sind für Binärdaten, Reader und Writer für Text. DataOutput ist explizit (Doku!) für die Ausgabe von Binärdaten. Anwendungsgebiet von DataOutput und DataInput sind die (De)serialisierung von Java-Daten in einer - von der Byte Order auf Little Endian Maschinen mal abgesehenen - mit C möglichst einfach zu verarbeitenden Form. Daher die Modifikation: Weil der 0-Codepoint als Zwei-Byte-Zeichen kodiert wird, lassen sich Strings Null-terminieren, sehr praktisch für C. Für die Ausgabe von Text in normale Text-Dateien (Plain Text, XML etc.) sind aber Writer zu verwenden. Wer dafür DataOutput misbraucht, verwendet schlicht die falsche Klassen und braucht sich über Probleme nicht wundern. --ChristianHujer 11:44, 23. Aug 2004 (CEST)

Voellig richtig. Dann kann diese Diskussion ja (mit dem Anfang dieser Seite) zusammengefasst werden. --SirJective 18:46, 23. Aug 2004 (CEST)

Java kennt 2 Formen von UTF-8 encoding, eine modifizierte die in einigen Funktionen verwendet wird und eine echte. Die echte wurde mit Java 1.5 auch so weit ausgebaut, dass sie keine Surrogat Code Units mehr erzeugt. Siehe dazu: JSR-204 und http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ --BerndEckenfels 07:57, 25. Mär 2005 (CET)

Umstellung der Wikipedia auf UTF-8

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)

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)

Danke für Deine Hilfe! :-) Kiki1701 01:50, 28. Jul 2004 (CEST)

Umstellung völlig misslungen - Wikipedia zerstört!

Sonderzeichen werden alle falsch dargestellt, wie konnte so etwas nur passieren?

Nicht alle, ganz ruhig. ÄüöÖ?! -- Breezie 08:47, 30. Jul 2004 (CEST)

Mal probieren im Browser die Zeichenkodierung umzustellen. Vielleicht ist da ISO8859-1 oder US-Ascii fest eingestellt. Auf Automatic umstellen oder gleich UTF-8 auswählen. Geht meist im Menü View/Ansicht. Unterpunkt "Character Coding"/"Zeichenkodierung" o.ä. . -- Schmiddschn 12:18, 30.Juli 2004 (CEST)

Die Seite http://de.wikipedia.org/w/wiki.phtml?title=Titel&action=purge (statt "Titel" den Namen der Seite eingeben) aufrufen, dann werden die alten, teilweise noch gespeicherten Seiten durch die neuen UTF8-Seiten ersetzt... Schaut auch mal unter Wikipedia:UTF-8-Probleme! Gruß, Rdb 12:24, 30. Jul 2004 (CEST)

Genau! Mein schöner Fisch ist im Eimer! Skandal! --Anathema <°))))>< 12:25, 30. Jul 2004 (CEST)

Hey, jetzt gehter plötzlich wieder? *froi* ;-) --Anathema <°))))>< 12:27, 30. Jul 2004 (CEST)

Zur Definition

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

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)

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)

UTF-8 mit/ohne BOM

Wikipedia schreibt :"Das gleiche Zeichen kann theoretisch auf verschiedene Weise kodiert werden. Jedoch ist nur die jeweils kürzeste mögliche Kodierung erlaubt"

Liege ich völlig falsch, oder ist diese Regel so nicht mehr aktuell? Soweit ich BOM verstanden habe, gibt es die Byte order für Multizeichen in einem Vorlauf der Datei an. Damit wäre die Reihenfolge festgelegt und würde nicht mehr dieser Regel folgen, oder? CJ de

Deine Frage ist mir unverständlich., Die Frage der Byte Order hat nichts mit der Frage der nicht-kürzesten Kodierung zu tun. --Pjacobi 19:06, 27. Jun 2005 (CEST)

Da ich keine vernünftige Definition für BOM und den Unterschied zwischen UTF mit und ohne finden konnte, stochere ich zugegeben etwas im Nebel. Ich habe BOM so verstanden, daß es ein "Vorspann" vor der eigentlichen Datei ist, der definiert auf welchen Bytes eines Mehrbytezeichens welche Informationen liegen. Diese feste Definition schien mir im Widerspruch zur Anforderung der kürzesten Kodierung zu stehen. CJ de

Das BOM (U+FEFF) ist für die Interpretation von UTF-8 bedeutungslos und war ursprünglich sogar verboten.

Die Unicode-FAQ schreibt [1]:

Where a BOM is used with UTF-8, it is only used as an ecoding signature to distinguish UTF-8 from other encodings — it has nothing to do with byte order.

Die Frage der nicht kürzesten Kodierung ist, ob für 'A' außer der Kodierung 00100001 auch die Kodierung 11000000__10100001 zulässig ist.

Pjacobi 12:13, 28. Jun 2005 (CEST)

Ich find wichtig, das UTF auch heuristisch mit extrem hoher Präzision erkannt werden kann - ich hab bisher aber nur einen englischen Link dazu parat. Wo passt das denn in den Text rein? --Martin Häcker 22:31, 8. Apr 2006 (CEST)

Abschnitt »UTF-8 im Internet«

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)

Unverständliches Technikbla

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)

10:38, 2. Jun 2006 (CEST)

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)

Was ist schlecht an UTF-8 ?

Ich erlebe es immer wieder, als nichts ahnender Surfer, der UTF-8 gegenüber nur Positive Gefühle hegt (und somit auch überall wo es nur geht UTF-8 ausgewählt habe) das andere Leute UTF-8 nicht mögen. Im IRC wird man beispielsweise regelmäsig blöd angemacht wenn man UTF-8 als Charset eingestellt hat, warum ? Wäre es nicht gerade im IRC Sinnvoll ein einheitliches Charset zu verwenden ? Dort treffen doch viele unterschiedliche Charsets, also ich meine Länder und verschiedene Sonderzeichen, auf einen Server zusammen. Meine Frage ist: Was ist (auch auf Webseiten) gegenüber UTF-8 auszusetzen ? --80.187.80.153 10:18, 16. Aug 2006 (CEST)

Auf Webseiten spricht IMHO gar nichts gegen die Verwendung von UTF-8, sofern der Header der HTML-Seite in den Meta-Tags die korrekte Kodierung angibt. Im IRC-Protokoll ist es jedoch nicht vorgesehen, die verwendete Kodierung mitzuteilen/auszuhandeln. Von daher müssen die Benutzer das unter sich aushandeln, sonst kommt nur Zeichensalat an. Und das erzeugt Unmut bei den Beteiligten. Man kann natürlich auch einen IRC-Clienten nehmen, der über eine Heuristik versucht, die Zeichenkodierung zu erraten und ggf. vor der Darstellung entsprechend umzuwandeln. Aber eine Heuristik ist selten perfekt. :-/ --RokerHRO 22:46, 17. Aug 2006 (CEST)

Intressanterweise gibts nur dort gemeckere wo Windows-Kids mit mIRC unterwegs sind. Letzeres ist in der Tat etwas bockig was die umstellung auf UTF-8 angeht, dementpsrechend ist das gejammere in mIRC dominierten Netzen groß. Ist man jedoch in irgendwelchen Unix-dominierenden Netzen unterwegs, wie z.B. freenode.net, wo der Anteil der mIRC clients <1% ist, beschwert sich niemand über UTF-8, ganz im gegenteil, man findet sogar ab und an in nem channel topic die anweisung das nur UTF-8 erlaubt ist.--De Mike 333 01:02, 3. Mär. 2007 (CET)

Das kenne ich aber ganz anders. gerade auf freenode in unix-basierten Channels ist man generell sehr negativ gegenüber UTF-8 eingestellt. Da wären zum Beispiel die BSD-Channel, oder auch die Perl- und C-Channel.

Ich muß DeMike 333 auch wiedersprechen. Gerade in Text-IRC-Clients ist UTF-8 absolute Hölle! Solche Clients wie xchat, die eine Heuristik verwenden, sind da eher kontraproduktiv, da man von deren Usern nur zu hören bekommt: "Bei mir gehts" (Egal, welches exotische Encoding verwendet wird) oder "Verwende nen anständigen Client", was ich persönlich erstmal als unverschämt finde und auch nicht hilfreich ist, da xchat nicht im screen laufen kann. Generell gesehen, was ist schlimm an UTF-8, es ist in manchen Anwendungsfällen massiv langsamer, gerade, wenn in Texten gesucht werden soll oder Texte sortiert werden. Konkrete Werte habe ich da nicht selbst zur Hand (Außer mein Gefühl, was aber hier wohl nicht zählt ;-) aber mit Google findet man da das ein oder andere Beispiel, das dann Unterschiede von 8 Minuten mit UTF-8 und 1 Minute mit ISO-8859-1 oder "C" angibt. -- Mowgli 15:59, 24. Feb. 2008 (CET)

"rechtes Byte?"

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. (nicht signierter Beitrag von 193.96.33.242 (Diskussion) )

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)

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)

Da hast du allerdings recht. --j ?! 23:16, 10. Feb. 2008 (CET)

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)

Änderungen von Bugert

Hierher verschoben von meiner Diskussionsseite. --Fomafix 09:18, 16. Mai 2007 (CEST)

Deine Vorwürfe darf ich deutlichst bestreiten!

Vorteil und Rechtfertigung meiner Einfügung sind genau die gute und (schnelle) Verständlichkeit! Und was hier falsch sein soll bitte ich genau zu begründen. Werde es wieder zurücksetzen, abhalten könnte mich höchstens der subjektive Respekt vor einem Autor des Artikels, aber das trifft auf dich wohl nicht zu, oder? --Bugert 16:12, 15. Mai 2007 (CEST)

Du hast abgeändert:

Das gleiche Zeichen kann theoretisch auf verschiedene Weise kodiert werden

in

Ein Asciizeichen kann theoretisch auf 2 verschiedene Weisen kodiert werden

Der ursprüngliche Text ist genauer, denn es gibt nicht nur zwei Codierungen der Zeichen sondern mehr. Außerdem betrifft das auch nicht nur die Zeichen aus dem ASCII-Bereich, sondern gilt für alle Zeichen.

Der originale Text beschreibt die Codierung von Unicode in UTF-8. Dein Text wechselt zwischendurch in die Beschreibung einer Decodierung von einem UTF-8-Strom. --Fomafix 16:27, 15. Mai 2007 (CEST)

Also gibt es noch andere Zeichen, die mehrdeutig dargestellt werden könnten?? -welche ? Bzw. für welche Zeichen gäbe es noch mehr Kodierungen ? Inwieweit betreffen meine Sätze speziell die Strom-codierung ? --Bugert 16:57, 15. Mai 2007 (CEST)

1. Der Buchstabe ä (U+00E4), binär 00000000 11100100, lässt sich neben der korrekten UTF-8-Codierung mit 11000011 10100100 auch durch die Bytefolgen 11100000 10000011 10100100 oder 11110000 10000000 10000011 10100100 darstellen.

2. Deine Sätze in der Einleitung zur Codierung beschreiben die Decodierung, also eine Betrachtsweise ausgehend von den UTF-8-Bytefolgen, anstelle von den Unicode-Zeichen. Ich denke, dass zuerst die Codierung vom Prinzip erklärt werden sollte, bevor auf die Feinheiten der Decodierung eingegangen wird. Die Codierung an sich wird meines Erachtens nach der Tabelle ausführlich genug erklärt.

Ich mache Deine Änderungen rückgängig. Bitte vor weiterem Einstellen hier ausdiskutieren. --Fomafix 09:18, 16. Mai 2007 (CEST)

Pkt.1 : Du hast offenbar recht.Sorry. Danke. EOD

Pkt.2 : Sehe hier kein wirkliches Argument (obwohl ich weiss was Dich hier zwickst..). Verspreche vorm Revert hier nochmal zu argumentieren. --Bugert 15:01, 16. Mai 2007 (CEST)

URL-Kodierung

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)

Vorlage UTF-8 / Probleme mit UTF-8

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

NFD vs. NFC

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)

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)

Violinschlüssel

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)

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)

Das ist nicht der Violinschlüssel sondern der Bassschlüssel. (Der vorstehende, nicht signierte Beitrag stammt von 86.18.227.188 (Diskussion • Beiträge) 3:01, 5. Mai. 2008 (CEST))

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)

theoretische Anzahl der codierbaren Zeichen

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)

Tatsaechliche Anzahl der codierbaren Zeichen

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)

Habs zu spät gesehen und auch die Zahl rausgelöscht, weil sie irreführend ist (siehe Löschungskommentar). -- Lars

Änderung in Zeile 65

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)

Hmm, kontrolliert hier noch jemand? --Soegel 15:01, 12. Nov. 2008 (CET)

Anmerkungen zur Tabelle UTF-Beispiele

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)

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)

0x9D ist bei Windows-1252 unbelegt [2], daher würde auch diese Darstellung ein nicht darstellbares/ungültiges Zeichen enthalten. --Fomafix 11:25, 13. Feb. 2009 (CET)

Wozu soll die letzte Spalte der Tabelle überhaupt gut sein? Daß Unsinn herauskommt, wenn man falsch dekodiert, ist doch offensichtlich. Ich schlage vor, die Spalte zu entfernen. --ulm 11:55, 14. Sep. 2009 (CEST)

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)

Verteilung UTF8-Bits auf Bytes

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)

Ä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)

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)

Geschichtlicher Abriss

... wäre auch interessant gewesen.

Rob Pike hat damals für das Betriebssystem Plan 9, eine Codierung von Unicode umgesetzt.

Hat hier die IETF mehr als nur Copy & Paste gemacht? --91.43.118.151 17:20, 29. Jan. 2010 (CET)

Ich nehme an da wurde mehr verändert. In meinem Hinterkopf ist eine dunkle Erinnerung daran, dass alle UTF-8 Codierungen aus druckbaren Zeichen bestehen würden - was u.a. bedeuten würden, dass die Kontrollzeichen 0-01F (000xxxxx) eben nicht mit der kürzestmöglichen Codierung dargestellt werden. Und sind 80-9F bzw. 100xxxxx nicht auch in vielen Codierungen (inklusive Unicode!) nicht druckbare Kontrollzeichen?

Die Erinnerung ist also nicht richtig - aber vielleicht trifft sie ja auf das System von Pike zu? Oder gab es mal eine Version von UTF-8, die mehrfache Codierungen (z.B. Zeilenumbruch U+0A = 00001010 = 11000000 10001010) erlaubte - und 100xxxxx als "druckbar" ansah?

93.220.103.167 07:31, 6. Jun. 2010 (CEST) 07:31, 6. Jun. 2010 (CEST) 07:30, 6. Jun. 2010 (CEST)

ISO-Norm veraltet und weiterer Link

---

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) Hakris, 21. Februar 2010.

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)

Tote Bereiche

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))

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)

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)

Die Binärzahl 11011100 (oder 220_dez oder DC_hex) 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)

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)

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

Unicode Transformation Format vs. UCS Transformation Format

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

Womöglich ja einfach beides. (Welle oder Teilchen..? :-) ). --85.179.130.0 15:12, 12. Jul. 2012 (MESZ)

UTF-2

UTF-2 ist ein Redirect auf auf UTF-8 - ohne ein sterbenswörtchen der Erklärung. --Itu 22:51, 18. Sep. 2011 (CEST)

Google ergab auf die Schnelle, dass utf2 ein veralteter Name für frühe UTF-8-Versionen war, z.B. hier: [3]. Ein bisschen mehr Recherche wäre aber angebracht. --RokerHRO 08:06, 19. Sep. 2011 (CEST)

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)

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)

Präfix 0x

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)

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)

Terminologie

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

UTF-8 Bytestrom problemlos in Mitte lesen nicht ganz richtig ?!

Im Artikel heißt es: "Somit kann ein Bytestrom auch in der Mitte gelesen werden, ohne dass es Probleme mit der Dekodierung gibt, was insbesondere bei der Wiederherstellung defekter Daten wichtig ist."

Was ist z.B. wenn ich einen Bytestrom habe der ausschließlich aus 2-Byte zeichen besteht? Hier kann ich nicht mehr ohne weiteres entscheiden, ob es Little- oder Big-Endian ist, das geht nur dann, wenn zwischendrin auch ein 1- oder 3-Byte Zeichen kommt. Ich muss mir ansonsten erst beide Texte ausgeben lassen und einer Sprachanalyse unterziehen ... (nicht signierter Beitrag von 213.55.176.143 (Diskussion) 09:32, 10. Feb. 2015 (CET))

Bei einem Bytestrom gibt es kein Little- oder Big-Endian. Ein Bytestrom besteht immer aus einer Folge von Bytes. --Fomafix (Diskussion) 10:09, 10. Feb. 2015 (CET)

Ok das ist mir schon klar. Aber genau deswegen ist es ja problematisch zu sagen, dass UTF-8 a) kein BOM benötigt bzw. b) mittendrin gelesen werden kann. Woher weiß ich denn, ob der Stream Little- oder Big-Endian Zeichen enthält? Wie schon gesagt, sobald es eine Mischung aus 1,2 oder 3-Bytezeichen ist kann ich es mir ableiten, weil ich bei Auftreten einer 1-Byte--3-Byte--1-Byte Sequenz genau ableiten kann, welche Endiannes benutzt wird (die 2 Folgebytes der 3-Byte-Sequenz lassen sich dann eindeutig dem Startbyte des 3-Byte-Zeichens zuordnen). Wenn aber nur ausschließlich 2- oder nur ausschließlich 3- oder nur ausschließlich 4-Byte-Zeichen enthalten sind ist es nicht mehr länger eindeutig, weil die Folgebytes jeweils entweder dem vorherigen Start- oder dem darauffolgenden Start-Byte zugeordnet werden können. Sicherlich ist es meistens richtig, zu sagen dass UTF-8 mittendrin gelesen werden kann. Ich meine eben nur, dass die Aussage nicht immer richtig ist, es sei denn ich übersehe irgendetwas, was ich versuchen wollte mit der Diskussion darüber zu klären :-) .... die einzige Möglichkeit die ich jetzt gerade noch sehe ist die, auf das allerletzte Byte im Strom zu vertrauen, dass es auch tatsächlich das letzte Byte im Text ist, dann wiederum bin ich in der Lage die Endiannes zu bestimmen und den Text richtig zu interpretieren. (nicht signierter Beitrag von 46.127.207.218 (Diskussion) 11:14, 15. Feb. 2015 (CET))

Nochmal: UTF-8 setzt auf einen Strom von 8-Bit-Worten. Wenn diese 8-Bit-Bytes in einem 16-Bit-Wort oder einem 32-Bit-Wort gespeichert werden, dann sind die höherwertigen Bits alle 0. Wenn solche 16- oder 32-Bit-Ströme Big- oder Little-Endian kodiert werden, dann sind die 0-Bytes entweder davor oder danach. Die Endianess ist an jeder Stelle erkennbar, denn nur das Little-End enthält Bits ungleich Null.

Was Du vermutlich im Kopf hast ist der Gedanke, was passiert, wenn ein normaler 8-Bit-Datenstrom als 16- oder 32-Bit-Datenstrom mit Big- oder Little-Endian interpretiert wird. Dass da natürlich Datenmüll herauskommt ist klar. --Fomafix (Diskussion) 11:50, 15. Feb. 2015 (CET)

"Bereits deutsche Umlaute erfordern 2 Byte"

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

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)

Welche Betriebssysteme und Progammiersprachen unterstützen UTF-8

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))

Nachteile von Unicode

• 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))

Weblinks

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

2008 war es so... ... und heute?

<<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)

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)

Längencodierung

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)

Es ist aus Gründen der eindeutigen Dekodierbarkeit notwendig. Wenn eine Multibytesequenz mit dem Byte F8_hex 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)