Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Unicode 7.0: Das Internet bekommt…

Passt das dann immer noch in 16 Bit Unicode?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Passt das dann immer noch in 16 Bit Unicode?

    Autor: Bonita.M 17.06.14 - 14:51

    Oder liegen die Zeichen außerhalb?

  2. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Aison 17.06.14 - 14:55

    Nö, sieht man doch im Beispielbild mit den Fingerzeichen

    z.B. 1F596 ist ganz sicher nicht mehr 16 Bit.

  3. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: spagetti_code 17.06.14 - 15:11

    Aison schrieb:
    > z.B. 1F596 ist ganz sicher nicht mehr 16 Bit.

    Stimmt, sind immerhin schon 17!

  4. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Aison 17.06.14 - 15:24

    und was willst du uns damit sagen? Die Frage von Bonita.M ist nicht ganz unberechtigt. Da viele Anwendungen momentan nur 16 Bit Unicode unterstützen.

    Beispiel: In Java ist ein char auch nur 16bit. Deswegen muss man ab 17Bit mit High- und Low-Surrogates arbeiten. Das hat z.B. den Nachteil, dass man Stringlängen nicht mehr einfach so vergleichen kann, da es Zeichen gibt die plötzlich 2 char benötigen.

  5. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: körner 17.06.14 - 15:32

    Mein Gott dann ist das halt so.
    Wir haben nicht mehr 1985.

  6. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: doedel61 17.06.14 - 15:59

    Ja.
    Unicode hat erst mal nichts mit der Repräsentation der Zeichen im Speicher zu tun.

    Vermutlich leitest du das von UTF-16 ab. Das "Unicode Transfer Format" beschreibt die Abbildung der Zeichen im Speicher mit der Mindestlänge und Form in Bits.
    Bei UTF-16 ist das immer ein Wort, bei UTF-8 min. ein Byte. Reicht das nicht mehr, wird einfach drangehängt: dann hat ein Zeichen in UTF-16 zwei Worte, in UTF-8 ist die Länge prinzipiell variabel.



    1 mal bearbeitet, zuletzt am 17.06.14 16:01 durch doedel61.

  7. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Bonita.M 17.06.14 - 16:01

    doedel61 schrieb:
    --------------------------------------------------------------------------------
    > Ja.
    > Unicode hat erst mal nichts mit der Repräsentation der Zeichen im Speicher
    > zu tun.

    Doch, nach dem Auslesen aus einem UTF-xx-String hat man es dann mit fixen Größen zu tun. Und wenn die einzelnen chars in die ich auslese zu klein sind, dann passt's halt nicht.



    1 mal bearbeitet, zuletzt am 17.06.14 16:03 durch Bonita.M.

  8. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: tsp 17.06.14 - 16:06

    In UTF-8 oder UTF-16 hat die Länge der einzelnen 8 oder 16 Bit Words wie gesagt nichts mehr mit der Codepoint Länge zu tun. Die werden dann einfach bei UTF-8 in 1-4 Bytes oder bei UTF-16 in 1 - 2 Words codiert.

    Andererseits hat auch die Zahl der Codepoints nichts mehr mit der Zeichenlänge eines Strings zu tun, dafür müsste man dann erst wieder in Grapheme Cluster zerlegen, wobei die Repräsentierung einzelner Zeichen noch dazu nicht eindeutig ist und man noch darauf achten muss, vor Vergleichen die richtige Normalform zu wählen bzw. zu konvertieren (je nach dem mit welcher Software / alten Daten man Kompatibilität wahren will benötigt man dann noch entweder die kanonischen oder die compatibility Zerlegungen bei der Normalisierung).

    Die Zeiten wo man einfach über ein Array von char's iterieren konnte bzw. Strings einfach durch einen Byteweisen Vergleich vergleichen konnte sind seit Unicode definitiv vorbei ...

  9. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: bloody.albatross 17.06.14 - 16:12

    Aison schrieb:
    --------------------------------------------------------------------------------
    >
    > Beispiel: In Java ist ein char auch nur 16bit. Deswegen muss man ab 17Bit
    > mit High- und Low-Surrogates arbeiten. Das hat z.B. den Nachteil, dass man
    > Stringlängen nicht mehr einfach so vergleichen kann, da es Zeichen gibt die
    > plötzlich 2 char benötigen.

    Und warum willst du die Anzahl der Codepoints zweier Strings vergeleichen? Was bringt das? Die Anzahl der Glyphen bekommst du sowieso nicht so einfach, weil sich Glyphen aus mehreren Codepoints zusammensetzen können. Z.B. kann man ein Ä als 2 Codepoints schreiben: ein A und extra die zwei Punkte darüber. Für ordentliches Unicode-Vergleichen benötigst du (u.U. sprachabhängige) Collations.

    Dann wir auch oft der Nachteil angegeben, dass man bei UTF-16/UTF-8 nicht mehr per random access auf den 3. Codepoint zugreifen kann. Ja wann braucht man dass denn? Man braucht i.d.R. nur das durchgehen von einem Zeichen nach dem anderen (vorwärts oder rückwärts), und das geht immer. D.h. in den allermeisten Fällen ist es ausreichend und effizient wenn man seine Strings als UTF-8 im Speicher hält. (UTF-8 hat im Gegensatz zu UTF-16 und UTF-32 auch keine endian (Byteorder) Abhängigkeiten.)

  10. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: bloody.albatross 17.06.14 - 16:18

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > doedel61 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ja.
    > > Unicode hat erst mal nichts mit der Repräsentation der Zeichen im
    > Speicher
    > > zu tun.
    >
    > Doch, nach dem Auslesen aus einem UTF-xx-String hat man es dann mit fixen
    > Größen zu tun. Und wenn die einzelnen chars in die ich auslese zu klein
    > sind, dann passt's halt nicht.


    Wie? Wenn ich z.B. einen Codepoint aus einem UTF-8 String auslese (d.h. dekodiere) dann habe ich am Ende *einen* Codepoint (in einer min. 24 Bit großen Variable, d.h. i.d.R. in einem uint32_t) egal wie viele Bytes es in der UTF-Repräsentation hatte. Das ist mit UTF-16 genauso (nur halt statt 1 bis 4 Bytes hat UTF-16 2 oder 4 Bytes pro Codepoint). UCS2 kann (schon lange) nicht alle Unicode Codepoints darstellen aber UCS2 != UTF-16.

  11. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Bonita.M 17.06.14 - 16:30

    > Wie? Wenn ich z.B. einen Codepoint aus einem UTF-8 String auslese (d.h.
    > dekodiere) dann habe ich am Ende *einen* Codepoint (in einer min. 24 Bit
    > großen Variable, d.h. i.d.R. in einem uint32_t) egal wie viele Bytes es in
    > der UTF-Repräsentation hatte. Das ist mit UTF-16 genauso (nur halt statt 1
    > bis 4 Bytes hat UTF-16 2 oder 4 Bytes pro Codepoint). UCS2 kann (schon
    > lange) nicht alle Unicode Codepoints darstellen aber UCS2 != UTF-16.

    Du kannst z.B. nicht alle Zeichen aus einem UTF-16-String in ein Java-char packen. Das meinte ich.

  12. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: dahana 17.06.14 - 17:27

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Wie? Wenn ich z.B. einen Codepoint aus einem UTF-8 String auslese (d.h.
    > > dekodiere) dann habe ich am Ende *einen* Codepoint (in einer min. 24 Bit
    > > großen Variable, d.h. i.d.R. in einem uint32_t) egal wie viele Bytes es
    > in
    > > der UTF-Repräsentation hatte. Das ist mit UTF-16 genauso (nur halt statt
    > 1
    > > bis 4 Bytes hat UTF-16 2 oder 4 Bytes pro Codepoint). UCS2 kann (schon
    > > lange) nicht alle Unicode Codepoints darstellen aber UCS2 != UTF-16.
    >
    > Du kannst z.B. nicht alle Zeichen aus einem UTF-16-String in ein Java-char
    > packen. Das meinte ich.

    Stimmt, es passt immer nur ein Zeichen in ein Java-char.
    Ansonsten verstehe ich die Aussage nicht.
    String.charAt() liefert ein UTF-16 kodiertes char zurück.

  13. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Moe479 17.06.14 - 18:34

    ich verstehe den ganzen derart unpraktisch abgestuften codierungs-krimskrams eh nicht, einfach nen 'astronomischen' standard wie z.b. utf-1024 etablieren und sorgsam das nötigste an zeichen nach und nach in die zeichentabelle einfliessen lassen ... der mittelfinger und bereits ausgestorbene oder fantasie-zeichen gehören für mich übriegens nicht dazu - ja ich bin ein spielverderber, ich weiss ;)

    das hält dann jahrhunderte vor bevor man z.b. über utf-hastenichgesehen nachdenken muss, und btw: speicher ist billig!



    1 mal bearbeitet, zuletzt am 17.06.14 18:36 durch Moe479.

  14. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: picaschaf 17.06.14 - 19:21

    Sind hier soviele icu (oä.) Entwickler oder Leute die es sich künstlich schwer machen wollen unterwegs? Ich verstehe die ganze Aufregung nicht. Wenn ivh mit Unicode umgehe benutze ich die entsprechenden Libs (Qt mit icu Support, icu direkt,...) und brauche mich nicht um irgendwelche byte Zugriffe, Collation aware Sortierung etc. kümmern.

    Deren Entwickler kann ich aber durchaus verstehen wenn sie über die ganzen Regeln jammern ;) Ich bin eigentlich bisher nur einmal darüber gestolpert, mit git. OS X und Linux stellen Umlaute im Dateisystem offenbar anders dar (OSX mit extent, Linux nur mit dem Umlaut direkt) und das wurde von meiner Git Konfiguration nicht berücksichtigt. Aber alles kein großes Drama ;)

  15. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Der Super Maaan 17.06.14 - 19:29

    Ich wär ja schon bereit 1mio ¤ zu zahlen, wenn jemand 64 bit voll bekommen würde.

  16. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: picaschaf 17.06.14 - 19:37

    Ich schicke dir gerne meine Kontodaten. Gerade habe ich meinen Zeichensatz PICA-64 definiert. Abgeleitet von UTF-32 mit zusätzlich einem eigenen Zeichen für jedes Sandkorn. Wir wollen doch keine Sandissten sein. Und natürlich habe ich dabei auch an schwarze, weiße, gleiche, ungleiche, sandig beeinträchtigte weiße/schwarze/grüne, sowie -gleiche/ungleiche, intersandige, transsandige und alle möglichen kombinationen von allen gedacht.

  17. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Bonita.M 17.06.14 - 20:11

    > String.charAt() liefert ein UTF-16 kodiertes char zurück.

    Nein, nur ein char. Wenn es UTF-16 kodiert wäre müssten in den Rückgabewert ggf mehrere chars passen.

  18. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: QDOS 17.06.14 - 21:04

    picaschaf schrieb:
    --------------------------------------------------------------------------------
    > Sind hier soviele icu (oä.) Entwickler oder Leute die es sich künstlich
    > schwer machen wollen unterwegs?
    Künstlich vl. nicht: Ich hab mal versucht das ganze UTF Geraffel zu verstehen - hab dann aber frustriert aufgegeben. Mein Fazit damals wie heute: ich bleibe wo möglich bei ASCII, für alles darüber hinaus muss dann ne externe Library herhalten…

  19. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: Bonita.M 17.06.14 - 21:08

    Hä, die UTF-Encodings sind doch total simpel.

  20. Re: Passt das dann immer noch in 16 Bit Unicode?

    Autor: bloody.albatross 17.06.14 - 21:42

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Wie? Wenn ich z.B. einen Codepoint aus einem UTF-8 String auslese (d.h.
    > > dekodiere) dann habe ich am Ende *einen* Codepoint (in einer min. 24 Bit
    > > großen Variable, d.h. i.d.R. in einem uint32_t) egal wie viele Bytes es
    > in
    > > der UTF-Repräsentation hatte. Das ist mit UTF-16 genauso (nur halt statt
    > 1
    > > bis 4 Bytes hat UTF-16 2 oder 4 Bytes pro Codepoint). UCS2 kann (schon
    > > lange) nicht alle Unicode Codepoints darstellen aber UCS2 != UTF-16.
    >
    > Du kannst z.B. nicht alle Zeichen aus einem UTF-16-String in ein Java-char
    > packen. Das meinte ich.

    Dass das in Java so komisch ist hat historische Gründe. Zuerst dachte man 16Bit würde für alle möglichen Zeichen reichen und man hat UCS2 spezifiziert. Und somit haben Java, Windows NT und Qt sich das als basis ihrer Strings ausgesucht. Dann kam man drauf das 16Bit nicht reichen (und das UTF-8 eigentlich viel praktischer ist, wenn man eh multi Bytes hat). Weil es das einfachste war haben dann alle diese Systeme einfach auf UTF-16 umgesattelt und somit ist ein char in Java eigentlich ein UTF-16 Surrogate. Neue Sprachen wie Rust verwenden UTF-8, soweit ich weiß. Python 3 macht's wieder anders: Es wird das kleinste Encoding verwendet in dem sich der konkrete String ohne multibyte ausgeht (d.h. ISO-8859-1, UCS2 oder UCS4) und es wird davon abstrahiert, so dass der Python-User nix davon mitbekommt.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Interhyp Gruppe, München
  2. Kraftwerke Mainz-Wiesbaden AG, Mainz
  3. Interhyp Gruppe, Berlin, München
  4. AKKA Deutschland GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 204,90€
  2. täglich neue Deals bei Alternate.de
  3. (reduzierte Überstände, Restposten & Co.)
  4. 199,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Hyundai Kona Elektro: Der Ausdauerläufer
Hyundai Kona Elektro
Der Ausdauerläufer

Der Hyundai Kona Elektro begeistert mit Energieeffizienz, Genauigkeit bei der Reichweitenberechnung und umfangreicher technischer Ausstattung. Nur in Sachen Emotionalität und Temperament könnte er etwas nachlegen.
Ein Praxistest von Dirk Kunde

  1. Elektroauto Porsches Elektroauto Taycan im 24-Stunden-Dauertest
  2. Be emobil Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt
  3. ACM City Miniauto soll als Kleintransporter und Mietwagen Furore machen

IT-Arbeit: Was fürs Auge
IT-Arbeit
Was fürs Auge

Notebook, Display und Smartphone sind für alle, die in der IT arbeiten, wichtige Werkzeuge. Damit man etwas mit ihnen anfangen kann, ist ein anderes Werkzeug mindestens genauso wichtig: die Augen. Wir geben Tipps, wie man auch als Freiberufler augenschonend arbeiten kann.
Von Björn König

  1. Verdeckte Leiharbeit Wenn die Firma IT-Spezialisten als Fremdpersonal einsetzt
  2. IT-Standorte Wie kann Leipzig Hypezig bleiben?
  3. IT-Fachkräftemangel Arbeit ohne Ende

Arbeit: Hilfe für frustrierte ITler
Arbeit
Hilfe für frustrierte ITler

Viele ITler sind frustriert, weil ihre Führungskraft nichts vom Fach versteht und sie mit Ideen gegen Wände laufen. Doch nicht immer ist an der Situation nur die Führungskraft schuld. Denn oft verkaufen die ITler ihre Ideen einfach nicht gut genug.
Von Robert Meyer

  1. IT-Forensikerin Beweise sichern im Faradayschen Käfig
  2. Homeoffice Wenn der Arbeitsplatz so anonym ist wie das Internet selbst
  3. Bundesagentur für Arbeit Informatikjobs bleiben 132 Tage unbesetzt

  1. Bundesregierung: Altmaiers Vision der Europa-Cloud heißt Gaia-X
    Bundesregierung
    Altmaiers Vision der Europa-Cloud heißt Gaia-X

    Viele kleine Cloud-Anbieter aus ganz Europa sollen sich in einem offenen Netzwerk miteinander verbinden. Das Ziel: eine Europa-Cloud zu erschaffen, die ein Gegenstück zu Amazon, Alibaba, Google und Microsoft ist. Die Bundesregierung soll dabei eine Schlüsselrolle übernehmen.

  2. Samsung: Galaxy A30s mit 25-Megapixel-Kamera kostet 280 Euro
    Samsung
    Galaxy A30s mit 25-Megapixel-Kamera kostet 280 Euro

    Mit dem neuen Galaxy A30s bringt Samsung ein weiteres Smartphone im unteren Mittelklassebereich in den Handel: Das Gerät kommt mit einer Dreifachkamera, einem großen Akku und einem Fingerabdrucksensor im Display. Bei der Auflösung spart Samsung leider.

  3. E-Rally Cup: Opel stellt elektrisches Rallyeauto vor
    E-Rally Cup
    Opel stellt elektrisches Rallyeauto vor

    Opel will die Popularität seines kommenden Elektroautos durch einen Rallye-Markenpokal stärken und hat nun das passende Fahrzeug auf Basis des Corsa-e vorgestellt.


  1. 10:56

  2. 10:41

  3. 10:22

  4. 10:00

  5. 09:42

  6. 09:27

  7. 08:45

  8. 08:17