Ankündigung

Einklappen
Keine Ankündigung bisher.

Python3: Allgemeines Problem mit doppelten Encodings

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Python3: Allgemeines Problem mit doppelten Encodings

    Ich werd noch irre...

    Python3 ist ja toll, die Ordnung mit bytes und str ist auch eigentlich gut. Allerdings ist es lästig, dass ein str.decode nicht mehr existiert, da ja alles eh einheitlich UTF-8 ist. Gleiches mit bytes.encode - gibts nicht.

    Ich habe in seltenen Fällen bei der Squeezebox das Problem, dass die Sender schon UTF-8 enkodierte "binary" senden. Wenn dann in einen "str" gewechselt wird, werden allerdings alle UTF-8 Escapes nochmals enkodiert. Heraus kommt ein "str":

    Code:
    00%3A04%3A20%3A27%3Aca%3A1f playlist newsong Ihr%20h%C3%83%C2%B6rt%201LIVE
    Das "%C3%83%C2%B6" ist ein doppelt UTF-8 enkodiertes "ö". Leider kriege ich es dank Python3 nicht hin, den String nochmals zu "dekodieren". Auch Umwege über bytes (muss zwangsenkodiert werden...) und memoryview scheitern. Einzig bliebe ein wahnsinniger Umweg über list comprehensions und chr/ord.

    http://forum.httrack.com/readmsg/18923/index.html beschreibt das Encoding-Problem recht genau.

    Gibts noch andere Möglichkeiten?

    Grüße
    Robert
    HM-KNX - KNX-Interface für Hörmann Garagentorantriebe: http://www.ing-budde.de

    #2
    Hallo Robert,

    eine Lösung habe ich hier nicht. Ich kann leider nur etwas klugscheißen.

    Das eigentliche Problem ist doch: Es gibt einen Informationskanal in dem unterschiedliche Kodierungen benutzt werden. Z.Z. hast du anscheinend zwei. Einmal ASCII (ohne Umlaute?) und einmal utf-8. Hier könnte man natürlich utf-8 einmal dekodieren und dann wieder enkodieren, da ASCII eine Teilmenge von utf-8 ist.
    Eventuell klappt das auch noch bei iso-8859 enkodierten Daten. Aber irgendwann hört es dann mal auf.

    Das Problem an dieser Stelle lässt sich daher nicht am Empfänger der Nachricht lösen, sondern muss an der Quelle gelöst werden.

    Wenn du das Problem im Empfänger lösen willst, dann müsstest du Charset detection betreiben: Charset detection - Wikipedia, the free encyclopedia.

    Das Problem der Quelle rührt wahrscheinlich daher, dass die Strings dort schon UTF-8 enkodiert angeliefert werden und der Client die Bytes einfach so weitergibt, da er selbst nicht weiß wie es enkodiert ist.

    Grüße
    Mike

    Kommentar


      #3
      Hi Robert,

      Zitat von Robert Beitrag anzeigen
      Gibts noch andere Möglichkeiten?
      hast Du schon mal mit decode('unicode-escape') probiert? Was kommt da raus?

      Bis bald

      Marcus

      Kommentar

      Lädt...
      X