1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Mozilla: Kompakte String-Kodierung…

Und warum nicht UTF-8?

  1. Thema

Neues Thema Ansicht wechseln


  1. Und warum nicht UTF-8?

    Autor: LittleFox 22.07.14 - 14:24

    UTF-8 ist doch der perfekte Weg um ASCII-Zeichen mit 1 Byte und alle anderen mit mehr Bytes, je nachdem wie viele benötigt werden, abzuspeichern.
    Gibt es einen Grund hier Latin1 statt UTF-8 zu verwenden?

  2. Re: Und warum nicht UTF-8?

    Autor: nille02 22.07.14 - 14:34

    Das wird im Heise Artikel beiläufig eingeworfen.

    Firefox spart Speicher mit neuer String-Codierung

    > UTF-8 sei keine sinnvolle Alternative zu Latin 1 gewesen. Diese Codierung verwendet pro Zeichen zwischen einem und vier Byte, was etwa das Finden eines Zeichens in einem String erschwert.



    1 mal bearbeitet, zuletzt am 22.07.14 14:34 durch nille02.

  3. Re: Und warum nicht UTF-8?

    Autor: ewie 22.07.14 - 14:34

    Mit UTF-8 kann nur ASCII (7 Bit) mit einem Byte dargestellt werden, Latin1 verwendet 8 Bit wofür UTF-8 bereits 2 Byte benötigt (sofern Zeichen im Bereich 80h..FFh) darzustellen sind.
    Ich bin aber auch der Meinung, dass UTF-8 durchgängig eingesetzt werden sollte.

  4. Re: Und warum nicht UTF-8?

    Autor: DASPRiD 22.07.14 - 14:35

    Ich verstehe es auch nicht wirklich, UTF-8 hätte für mich auch mehr Sinn ergeben, als hier mal das eine und mal das andere encoding zu verwenden.

  5. Re: Und warum nicht UTF-8?

    Autor: LittleFox 22.07.14 - 14:36

    Ja etwas komplizierter ist es, stimmt.

  6. Re: Und warum nicht UTF-8?

    Autor: lisgoem8 22.07.14 - 14:53

    Ich sehe auch im UTF-8/Unicode mehr die Zukunft.

    Es hat sich eigentlich endlich überall etabliert. Zum Glück ist es aber hier nur intern. Und eigentlich mehr als Performance getrimmt. Solange der JS-Entwickler damit nicht konfrontiert wird, ist es eigentlich egal.

  7. Re: Und warum nicht UTF-8?

    Autor: redwolf 22.07.14 - 14:54

    Grund ist der Performanceverlust beim String-Compare.
    Wenn man von einem festen Datenblock ausgehen kann, also immer 1 bis 4 Byte pro Zeichen, dann lässt sich schneller die Länge der Eingabezeichenkette erkennen, ohne dass man sie von vorne bis hinten durchparsen muss um auf die Zeichenkettenlänge zu kommen.



    2 mal bearbeitet, zuletzt am 22.07.14 14:57 durch redwolf.

  8. Re: Und warum nicht UTF-8?

    Autor: redwolf 22.07.14 - 14:57

    UTF-8 kann bedeutet, dass die Länge der Zeichenkette nicht anhand des Speicherverbrauchs bemessen werden kann. D.h. das Suchalgorithmen immer die Zeichenkette von Anfang bis Ende lesen müssen um die Zeichenkettenlänge zu bestimmen. = Performanceverlust bei Suchalgorithmen.



    2 mal bearbeitet, zuletzt am 22.07.14 15:00 durch redwolf.

  9. Re: Und warum nicht UTF-8?

    Autor: rayo 22.07.14 - 15:21

    Aber ist ja mit UTF-16 (vorher) nicht anders, das verwendet auch 1 oder 2 code units.

    > The encoding is a variable-length encoding as code points are encoded with one or two 16-bit code units. (Wikipedia)

    Die Umstellung sei ja nicht wegen der Performance gemacht worden, sondern wegen des geringeren Speicherbedarfs. Da wäre UTF-8 aus meiner sicht besser, dann müsste man nicht immer überprüfen ist es nun Latin1 oder UTF-16.

  10. Re: Und warum nicht UTF-8?

    Autor: elgooG 22.07.14 - 15:31

    lisgoem8 schrieb:
    --------------------------------------------------------------------------------
    > Ich sehe auch im UTF-8/Unicode mehr die Zukunft.
    >
    > Es hat sich eigentlich endlich überall etabliert. Zum Glück ist es aber
    > hier nur intern. Und eigentlich mehr als Performance getrimmt. Solange der
    > JS-Entwickler damit nicht konfrontiert wird, ist es eigentlich egal.

    Ja, für Text mag es schon lange Standard sein, aber doch nicht für Programmcode. Der sollte fast immer und überall mit Latin1 abgedeckt werden können, wie die Analyse von Mozilla ja sehr schön zeigt. Deshalb spricht nichts dagegen.

    Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

  11. Re: Und warum nicht UTF-8?

    Autor: nille02 22.07.14 - 15:40

    rayo schrieb:
    --------------------------------------------------------------------------------
    > Die Umstellung sei ja nicht wegen der Performance gemacht worden, sondern
    > wegen des geringeren Speicherbedarfs.

    Warum soll das nicht der Performance geschuldet sein? Und eben die variable Breite von UTF macht es ja weniger sinnvoll als Latin1.

    Das ganze wird ja auch nur Intern genutzt, also nach außen hin ist alles noch weiterhin UTF16

  12. Re: Und warum nicht UTF-8?

    Autor: das sushi 22.07.14 - 15:43

    aber wem interessiert die länge der im endeffekt dargestellten zeichen? mich als programmierer interessiert ausschliesslich die größe im speicher, ein konkretes zeichen zu indizieren kommt auch sehr selten vor. meisst (z.b. beim parsen) muss der text sowieso zeichen für zeichen durchgegangen werden.

  13. Re: Und warum nicht UTF-8?

    Autor: rayo 22.07.14 - 15:51

    > , was unter anderem die Leistung verbessern kann. Letzteres sei zwar nicht das Hauptziel der Entwicklung gewesen, zeige sich dennoch in Benchmarks.

    Darum, steht im Artikel. Hauptziel war es weniger Speicher zu brauchen, was mit UTF-8 genau so erreicht werden könnte.

    Auch die Begründung im Blogbeitrag ist nicht so klar:
    > Gecko is huge and it uses TwoByte strings in most places. Converting all of Gecko to use UTF8 strings is a much bigger project and has its own risks.

    Hat er jetzt ja auch nicht gemacht, das würde mit UTF-8 auch gehen. Er schreibt nur UTF-8 -> UTF-16 sei komplizierter, aber wirklich Benchmarks hat er nicht.

    > Linear-time indexing: operations like charAt require character indexing to be fast. We discussed solving this by adding a special flag to indicate all characters in the string are ASCII, so that we can still use O(1) indexing in this case. This scheme will only work for ASCII strings, though, so it’s a potential performance risk. An alternative is to have such operations inflate the string from UTF8 to TwoByte, but that’s also not ideal.

    Linear-Time indexing haben sie jetzt auch nicht, wenn der Grund nicht Performance war, warum ist das ein Grund gegen UTF-8.

    > Converting SpiderMonkey’s own string algorithms to work on UTF8 would require a lot more work. This includes changing the irregexp regular expression engine we imported from V8 a few months ago (it already had code to handle Latin1 strings).

    Das ist einzig ein Grund warum latin-1 genommen wurde, V8 hat schon latin-1 code drin.


    Wenn der Grund die Speicherreduktion ist, spricht nur der Code von V8 gegen UTF-8. Nicht aber die Indexierung was jetzt auch nicht konstant ist (O(1))

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Anstalt für Kommunale Datenverarbeitung in Bayern (AKDB), München
  2. WITRON Gruppe, Neu-Isenburg bei Frankfurt/Main
  3. Endress+Hauser Conducta GmbH+Co. KG, Gerlingen (bei Stuttgart)
  4. Aptar Radolfzell GmbH, Radolfzell / Eigeltingen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Vivo X51 im Test: Vivos gelungener Deutschland-Start hat eine Gimbal-Kamera
Vivo X51 im Test
Vivos gelungener Deutschland-Start hat eine Gimbal-Kamera

Das Vivo X51 hat eine gute Kamera mit starker Bildstabilisierung und eine vorbildlich zurückhaltende Android-Oberfläche. Der Startpreis in Deutschland könnte aber eine Herausforderung für den Hersteller sein.
Ein Test von Tobias Költzsch

  1. Software-Entwicklung Google veröffentlicht Android Studio 4.1
  2. Jetpack Compose Android bekommt neues UI-Framework
  3. Google Android bekommt lokale Sharing-Funktion

5G: Nokias und Ericssons enge Bindungen zu Chinas Führung
5G
Nokias und Ericssons enge Bindungen zu Chinas Führung

Nokia und Ericsson betreiben viel Forschung und Entwicklung zu 5G in China. Ein enger Partner Ericssons liefert an das chinesische Militär.
Eine Recherche von Achim Sawall

  1. Quartalsbericht Ericsson mit Topergebnis durch 5G in China
  2. Cradlepoint Ericsson gibt 1,1 Milliarden Dollar für Routerhersteller aus
  3. Neben Huawei Telekom wählt Ericsson als zweiten 5G-Ausrüster

Big Blue Button: Das große blaue Sicherheitsrisiko
Big Blue Button
Das große blaue Sicherheitsrisiko

Kritische Sicherheitslücken, die Golem.de dem Entwickler der Videochat-Software Big Blue Button meldete, sind erst nach Monaten geschlossen worden.
Eine Recherche von Hanno Böck