boost::locale::translate und umlaute
-
@john-0 sagte in boost::locale::translate und umlaute:
Eine korrekte Transkodierung von UTF-32 auf UTF-8 muss eine Prüfung umfassen, ob die Werte die 21Bit Grenze überschreiten, alter Code tut das nicht, weil früher die kompletten 32Bit für Unicode reserviert waren und dann bis zu 6 Bytes für ein Zeichen verwendet wurden.
Hast du dafür belege? Soweit ich das weis ist eine Konvertierung von UTF-8 <->UTF-32 einfach möglich.
Aus der Unicode FAQ (http://unicode.org/faq/utf_bom.html#gen5)Which of the UTFs do I need to support?
A: UTF-8 is most common on the web. UTF-16 is used by Java and Windows. UTF-8 and UTF-32 are used by Linux and various Unix systems. The conversions between all of them are algorithmically based, fast and lossless. This makes it easy to support data input or output in multiple formats, while using a particular UTF for internal storage or processing.
-
@john-0 sagte in boost::locale::translate und umlaute:
Eine korrekte Transkodierung von UTF-32 auf UTF-8 muss eine Prüfung umfassen, ob die Werte die 21Bit Grenze überschreiten
Für eine korrekte Transkodierung von UTF-32 auf UTF-8 musst man gar nix prüfen. Wenn man es so implementiert dass zu hohe UTF-32 Werte in zu hohe (und zu lange) UTF-8 Werte übersetzt werden kann man es sogar verlustfrei hinbekommen, so dass der Bullshit 1:1 round-trippen kann.
Was oft die bessere Wahl ist, weil es bedeutet dass man Fehler nicht in dieser Schicht behandeln muss -- die auch meist kein praktisches Handling dafür machen kann. Statt dessen reicht man die Fehlerhaften Daten verlustfrei durch.
Und wenn man meint unbedingt eine Validierung bei der Konvertierung machen zu müssen, dann muss man nicht nur prüfen ob die Werte nicht zu hoch sind, sondern auch ob es nicht verbotenerweise UTF-16 Surrogates sind die als UTF-32 abgelegt sind.
-
@firefly sagte in boost::locale::translate und umlaute:
Hast du dafür belege? Soweit ich das weis ist eine Konvertierung von UTF-8 <->UTF-32 einfach möglich.
Das setzt immer voraus, dass man korrekte UTF-8 bzw. UTF-32 Strings hat. Nur wer garantiert Ihnen das? Solange man Daten verarbeitet die von außen angeliefert werden, sollte man darauf achten, dass sie auch korrekt sind. D.h. die Werte im Bereich des erlaubten liegen.
A: UTF-8 is most common on the web. UTF-16 is used by Java and Windows. UTF-8 and UTF-32 are used by Linux and various Unix systems. The conversions between all of them are algorithmically based, fast and lossless. This makes it easy to support data input or output in multiple formats, while using a particular UTF for internal storage or processing.
In der von Ihnen verlinkten Tabelle steht doch eindeutig, dass legale Unicdoes Strings (UTF-32) nur Zeichencodes zwischen 0x00000000 und 0x0010FFFF haben dürfen. Das wurde aber erst 2001 eingeführt. Wenn man sich mal zum historischen Vergleich RFC2044 anschaut, dann sieht man, dass UCS-4 auf UTF-8 bis zu 6 chars belegen durften. Das kann ein Problem sein, wenn alter Code mit neuer Puffergrößen benutzt wird (Pufferüberlauf ist möglich!). Ja, alter Code funktioniert immer noch korrekt, wenn man da nur Zeichen im heute erlaubten Bereich übergibt und die Puffer ausreichend groß sind.
-
@john-0 sagte in boost::locale::translate und umlaute:
Solange man Daten verarbeitet die von außen angeliefert werden, sollte man darauf achten, dass sie auch korrekt sind. D.h. die Werte im Bereich des erlaubten liegen.
Ich sehe eine einfache Transformation einer Representation in eine andere nicht als "Verarbeitung" an, speziell wenn sie verlustfrei und reversibelist. Ja, wenn man wirklich "verarbeitet", dann sollte man prüfen. Speziell wenn man Tabellenzugriffe mit dem Codepoint macht oder dergleichen. Und genau weil man an der Stelle sowieso prüfen muss, muss man beim schlichten Transformieren von UTF-32 nach UTF-8 nicht prüfen.
Man kann sich die Sache aber natürlich auch unnötig kompliziert machen wenn man möchte.
-
@hustbaer sagte in boost::locale::translate und umlaute:
Man kann sich die Sache aber natürlich auch unnötig kompliziert machen wenn man möchte.
Genau diese Denke führt zu den vielen Exploits.
-
@john-0
Wie soll das zu Exploits führen? Da kann nur 'was schief gehen, wenn zwei weitere Dinge dazukommen- Man validiert die Daten dort wo sie reinkommen nicht
- Man validiert die Daten dort wo ungültige Werte zu einem Problem führen könnten nicht
(1) halte ich für völlig OK. (2) halte ich für grob fahrlässig. AUSSER man arbeitet in einem Projekt wo vorgeschrieben ist dass sämtliche Daten dort wo sie ins System reinkommen validiert werden müssen. Wobei ich solche Vorgaben/Richtlinien für einen groben Fehler halte, da es oft nicht mit akzeptablem Aufwand (sowohl bei der Implementierung als auch zur Laufzeit) machbar ist.
Oder anders gesagt: Was zu Fehlern führt ist sich dort wo sie entstehen könnten darauf zu verlassen, dass andere Codeteile, die kein Problem mit ungültigen Daten bekommen können, diese bereits verifiziert hätten. So eine Annahme kann ich nur als naiv bis schlichtweg dumm einstufen.
Und da die hier diskutierte UTF-32-to-UTF-8 Konvertierung - WENN man sie passend implementiert - kein Problem mit ungültigen Codepoints bekommen kann, sehe ich auch keinen Grund da eine Validierung einzubauen. Kann man machen, muss man aber nicht. Und ich persönlich würde eher dahin tendieren nicht zu validieren und statt dessen aus allen 32 Bit Werten die reinkommen Output Bytefolgen zu generieren -- mit der "natürlichen" Fortführung der UTF-8 Kodierungsregeln.
-
@hustbaer sagte in boost::locale::translate und umlaute:
Und da die hier diskutierte UTF-32-to-UTF-8 Konvertierung - WENN man sie passend implementiert - kein Problem mit ungültigen Codepoints bekommen kann, sehe ich auch keinen Grund da eine Validierung einzubauen. Kann man machen, muss man aber nicht.
Es kostet faktisch nichts, und es verhindert Objekte mit ungültigen Zuständen zu erzeugen. Es bringt auch nichts das Problem irgend wie zu verschleppen – ungültige Zustände haben in einem Programm nichts zu suchen. Und genau das meinte ich mit diese Denke führt zu Exploits. Es bringt nichts das Problem zu verschieben, wenn man das sieht muss man es gleich eskalieren nur so ist man in der Lage auf systematische Fehler zu reagieren.
-
@john-0 sagte in boost::locale::translate und umlaute:
Es kostet faktisch nichts,
Ist mir klar.
und es verhindert Objekte mit ungültigen Zuständen zu erzeugen.
WTF? Das "Objekt mit ungültigem Zuständ" existiert bereits, man konvertiert bloss die Representation.
Es bringt auch nichts das Problem irgend wie zu verschleppen – ungültige Zustände haben in einem Programm nichts zu suchen.
Aha. Ist leider nicht mehr als Blablubb.
Und genau das meinte ich mit diese Denke führt zu Exploits.
Ebenfalls.
Es bringt nichts das Problem zu verschieben,
Doch, das bringt manchmal sehr viel. Weil man nicht unbedingt alle Fehler an allen Stellen gut behandeln kann.
wenn man das sieht muss man es gleich eskalieren nur so ist man in der Lage auf systematische Fehler zu reagieren.
Nein, muss man nicht. Und was genau meinst du mit "systematische Fehler"? Systematische Fehler so wie z.B. ..... äh, .... Eingabefehler? Blödsinn.
-
@hustbaer sagte in boost::locale::translate und umlaute:
WTF? Das "Objekt mit ungültigem Zuständ" existiert bereits, man konvertiert bloss die Representation.
this.
@hustbaer @john-0 Ich glaube ihr könntet Euch schön langsam darauf einigen, daß ihr Euch nicht einigen könnt.
-
@Swordfish sagte in boost::locale::translate und umlaute:
@hustbaer @john-0 Ich glaube ihr könntet Euch schön langsam darauf einigen, daß ihr Euch nicht einigen könnt.
Da widerspreche ich eindeutig nicht.
