3. fstream für Unicode?!

fstream für Unicode?!

  • D

    Artchi schrieb:

    Es sind zwar doppelt breite chars, aber mehr auch nicht.

    Was willst du mir damit sagen? Was fehlt denn sonst noch zur Unicodeunterstützung?

    0
  • R

    doppelt breite chars? Wie was wo? Bei mir ist sizeof(wchar_t) 4 🙂

    Aber Artchi hat schon recht, dass eine vernünftige Unicode Implementierung in der C++ Std Library fehlt. Ich schreibe gerade an einer Bibliothek, die Plattformunabhängig sein und auch von mehreren Compilern unterstützt werden soll. Windows hat wchar_t in der Regel 16Bit groß, da es noch für den veralteten UCS-2 Standard ausgelegt ist. Der GCC hat in neuen Versionen 32Bit wchar_t, also UCS-4.

    Um Unicode für Windows zu unterstützen muss man UTF-16 nehmen, aber für Multibyte Zeichensätze ist die Standard Library noch weniger ausgelegt.

    Das ist alles unportabel und unangenehm zu benutzen. Man kann sich nicht auf wchar_t verlassen, da einem unter Windows die wstrings und co einem um die Ohren fliegen können etc.

    Und mit Unicode Librarys für C++ sieht es auch mager aus. ICU gibt es da von IBM, aber das wurde wohl von Java Programmierern für C++ geschrieben. sf.net/projects/ustring gibt es noch, aber das Projekt ist im Alpha Stadium und seit 2000 nicht mehr upgedatet worden, sprich es sieht ziemlich tot aus und die Library unterstützt nur Unicode 3.0 (Unicode 4.0 kam ja auch erst später).

    Selbst boost bietet da wohl noch nichts. Unicode macht mir echt kopfschmerzen!

    Ach und das sonst vieles noch nicht einmal für wchar_t angepasst ist spricht für sich. Okay, unter Unix wird in der Regel eh UTF-8 erwartet, aber unter Windows wird ja UCS-2 benutzt. Das ist alles nicht so optimal.

    0
  • ?

    @kingruedi
    Du sagst es! Ich fühl mich deshalb auch von UNIX so dermaßen angepisst das kann sich keiner vorstellen!

    0
  • R

    da schrieb:

    @kingruedi
    Du sagst es! Ich fühl mich deshalb auch von UNIX so dermaßen angepisst das kann sich keiner vorstellen!

    😕

    0
  • D

    So, ich nochmal zu dem Thema. Das klappt so nicht, wie das dort beschrieben ist. Wenn ich nen Unicodestring übergebe, der asiatische Zeichen beinhaltet, dann wird der ANSI-String nix und als folge davon kann ifstream die datei auch nicht öffnen...
    Was mach ich jetzt? Kann nciht die ganze blöde Lib umschreiben, so dass sie andere Funktionen nutzt. Also das ist ja mal echt ne ziemliche Scheiße... Was haben sich die STL-macher dabei gedacht??

    0
  • R

    Du könntest deinen eigenen Filestream implementieren, der wstrings als Dateinamen akzeptiert.

    0
  • D

    ja klar 😉
    Ne, das ist mir zu aufwendig. ich glaub, ich verwende nen ganz bösen hack:
    http://lists.boost.org/MailArchives/boost/msg52452.php

    0
  • D

    Ach ne, das ist auch doof...
    Hast du grad zufälligerweise nen selbst implementierten filestream zur hand?
    Schreib den bestimmt nich from scratch...

    0
  • H

    dEUs schrieb:

    Hast du grad zufälligerweise nen selbst implementierten filestream zur hand?

    Ich sehe nicht, wie dir hier ein filestream helfen soll. Dein Problem ist doch die Zuordnung zwischen einem Unicode-Namen und einer physischen Datei. Mal abgesehen davon, dass sowas wenn überhaupt in einen streambuffer gehört, scheint mir das auch im höchsten Maß BS-abhängig zu sein. Wenn dein BS das nicht unterstützt sehe ich nicht, wie du da weiterkommen willst. Du brauchst imo also eine passende BS-Funktion, die dir ein File-Deskriptor (oder ein FILE-Handle o.Ä.) liefert. Das lesen aus der Datei ist dann wiederum kein Problem. Neben den wstreams, findest du im Netz dafür auch unzählige Filtering-Streambuffer.

    0
  • H

    BTW: Schau auch nochmal hier.

    0
  • D

    Hallo,

    ich war jetzt ganz böse und hab aus meiner STL einfach die basic_[if/f/of]stream-Klassen rauskopiert, den internen Filebuffer auf ne eigene Klasse geändert (geänderte basic_filebuf) und diese ruft beim Öffnen jetzt eine andere Funktion auf. Eine, die intern nicht fopen aufruft, sondern FOpen, welches als fopen bei Nicht-Unicode-Build und _wfopen bei Unicode-Build definiert ist. Und natürlich alle open-Funktionen und CTors auf TCHAR geändert. Und dann tut das ganze auch. Da das eh nur unter Windows laufen muss, tut das.

    Bei deinem Link weiss ich nciht worauf ich das Augenmerk legen soll. Ist ein bisschen arg viel.
    Meinst du möglicherweise diese Aussage:

    C++ considers that the system has a single character type. It makes no
    assumptions about this type, except that it is a single type. Any time
    information is passed to or from the system, this is the type that is
    used. Thus, filebuf requires that the name of the file have this type,
    and that all reads and writes to and from the file are done in this
    type. This type is called "char". And I repeat, not only must all
    filenames be char[], all transfers to and from the system take place as
    transfers of char

    Das wiederum besagt, wenn ich es richtig verstanden habe, dass ich auch mit der char-variante der streams Dateien öffnen kann, die Unicodezeichen enthalten. Richtig?
    Nur leider tut das nciht 🙄

    0
  • ?

    Ne, tut's auch nicht.

    [...] and that all reads and writes to and from the file are done in this
    type.

    Mit Standard-Mitteln kommst du da IMHO nicht weiter, du musst auf Betriebssystem-Funktionen zurückgreifen.

    0
  • H

    Optimizer schrieb:

    Ne, tut's auch nicht.

    [...] and that all reads and writes to and from the file are done in this
    type.

    Mit Standard-Mitteln kommst du da IMHO nicht weiter, du musst auf Betriebssystem-Funktionen zurückgreifen.

    Das schließt aber nicht aus, dass du dazwischen mit anderen Typen arbeiten kannst. Siehe dazu die Konvertierungsmöglichkeiten der locale-facets.
    Einfacher ist hier aber ein Filtering-Streampuffer, also ein weiterer Streampuffer der zwischen dem Stream und dem eigentlichen Puffer liegt. Dort kannst du beliebige Character-Konvertierungen durchführen.
    Du brauchst aber BS-funktionen, für das öffnen von Dateien. Zumindest wenn du Namen verwenden willst, die sich nicht in den narrow-Zeichensatz konvertieren lassen bzw. nicht konvertiert werden sollen.

    Bei deinem Link weiss ich nciht worauf ich das Augenmerk legen soll. Ist ein bisschen arg viel

    Auf zwei Dinge:

    http://www.boost.org/libs/filesystem/doc/faq.htm (FAQ: Why aren't wide-character names supported?) sowie auf die Beiträge von J. Kanze.

    0
  • D

    HumeSikkins schrieb:

    http://www.boost.org/libs/filesystem/doc/faq.htm (FAQ: Why aren't wide-character names supported?) sowie auf die Beiträge von J. Kanze.

    Ja, diesen Beitrag der boost-FAQ hab ich mir schon angeschaut. Jetzt weiss ich wenigstens, wieso das in der STL so ist.

    0
Anmelden zum Antworten