Probleme mit boost::log - Zusammenhang von locale mit Codepage



  • Hiho,

    ich benutze ich in einem Programm boost::log, für welches ich eine Datei als "sink" angelegt habe, um Statusmeldungen in eine Datei zu schreiben. Intern verwenden wir überall std::wstring, dieses geht auch zum Logging ins boost::log rein.

    Bisher hat das alles gut funktioniert. Nun müssen wir aber eine Webschnittstelle anbinden und haben uns dazu eine REST-Bibliothek gesucht, welche die Nutzdaten als wstring herausgibt (UTF-16).
    Wenn wir diesen String nun Loggen wollen mit boost::log, fliegt eine Exception: Ausnahme ausgelöst bei 0x74201812 in ARViewer.exe: Microsoft C++-Ausnahme: boost::wrapexceptboost::log::v2s_mt_nt6::conversion_error bei Speicherort 0x45F2D7B8.

    Soweit ich das bisher verstanden habe, will boost::log den wstring in einen string konvertieren, da es nur byteorientierte Datenströme in eine Datei schreibt. Dazu nutzt es std::codecvt.
    Wenn ich nun das globale Locale auf ein UTF-8 setze und dieses dann auch bei boost::filesystem setze, funktioniert es auf einmal. Diese Lösung ist aber suboptimal, da ich schlecht abschätzen kann, ob das woanders Seiteneffekte hat. Wir haben z. B. bei Programmstart an sich das globale Locale auf "C" gesetzt, damit beim Einlesen von Textdateienm über andere Boost-Bibliothken der "." ein Komma bleibt und nicht zum Tausendertrennzeichen wird.

    Man kann bei der Sink von boost::log auch mit imbue direkt ein Locale setzen. Aber egal was ich da bisher probiert habe, die Exception flog immer weiterhin. Ich habe da keine Idee mehr, wie ich das ohne den "globalen Locale"-Ansatz lösen kann.

    Neben der vorliegenden Problematik verstehe ich den Zusammenhang der Codepage mit dem std::locale nicht. An sich ist locale ja da, um länderspezifische Formatierungen (Datumsaufbau, Komma-Spearator usw.) zu definieren. Was hat das mit der Codepage zu tun??? Ich habe versucht dazu genauere Infos zu suchen. Soweit ich das nun verstanden habe, ist das locale für std::string definiert, also immer für Stringpräsentationen basierend auf char*, nicht für wchar_t*. Wenn ich mein locale verändere, beeinflusse ich aber auch die Streams welche für wchar definiert sind. Also hängt das ja doch zusammen.

    Und eine andere Frage dazu: ich schrieb ja oben, dass wir "C" also globales locale gesetzt haben. Das ist ja eigentlich das alte ASCII. Aber Umlaute waren für das Log nie ein Problem. Wir haben auch testweise russische Buchstaben ins Log geschrieben, hat alles gefunzt. Nur mit dem Strings vom Webserver geht es auf einmal nicht.

    Wer kann evtl. etwas Licht ins Dunkel bringen?
    Vielen Dank!

    VG

    Pellaeon



  • push



  • @Pellaeon sagte in Probleme mit boost::log - Zusammenhang von locale mit Codepage:

    boost::wrapexceptboost::log::v2s_mt_nt6::conversion_error b

    Ohne Code Beispiel ist es sehr schwer was dazu zu sagen. Du bekommst eine Exception aber gibst nicht den Aufruf an, der die schmeißt. Das Stichwort heißt, minimales Beispiel um das Problem zu reproduzieren 😉

    Hast du hier schonmal gelesen: https://www.boost.org/doc/libs/1_58_0/libs/log/doc/html/log/tutorial/wide_char.html

    Sonst zeig doch mal an Code, was du bisher versucht hast.

    Ich könnte mir vorstellen, dass wenn der Logger UTF 16 kodierte Strings erwartet, aber UTF 8 bekommt, der eine Byte Folge als Steuerzeichen interpretiert (z.B. Datei Ende) und dann raus fliegt.


Anmelden zum Antworten