Newbie Frage.. Python, Mac und Umlaute...
Ich suche schon einen Tag nach einer Antwort, aber habe leider noch keinen passenden Beitrag dazugefunden. Ich benutze eine Abwandlung der walktree() function aus dem Python Cookbook, um meinem Apple Mediaserver zu walken, und eine HTML datei zu erzeugen. Einige der Dateinamen sind nun in Deutsch, mit Umlauten. Ich schaffe es nicht mit Python 2.4.3 eine Seite zu erzeugen in der ein umlaut A ordentlich HTML entity encoded wird. Was mich wirklich verdutzt ist, das wenn ich einen loop for char in unicode string if isascii(char) == False: print char . mache, und da einen String mit Umlaut A reinschaufel (aus dem directory), kommt erst ein a, und dann 2 nicht ascii character. So sieht dann auch die website aus, hier der string erkaeltung (mit umlaut a eigentlich): Erka%CC%88ltung.mp4 (mit urllib.quote erzeugt). Macht keinen Sinn fuer mich. Wenn die os.path methoden mir einen unicode string geben sollten, dann ist doch nicht richtig... Ich habe nen haufen unicode erfahrung bin aber blutiger python neuling... habt also mitleid mit mir... Danke fuer jeden hinweis Frank _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Frank Mantek:
Einige der Dateinamen sind nun in Deutsch, mit Umlauten. Ich schaffe es nicht mit Python 2.4.3 eine Seite zu erzeugen in der ein umlaut A ordentlich HTML entity encoded wird.
Warum willst Du das tun? Die Angabe des richtigen charsets würde doch ausreichen. J. -- If I was Mark Chapman I would have shot John Lennon with a water pistol. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html> _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Tja, das dachte ich urspruenglich auch... aber wenn ich in die geschriebene Datei schaue (geoffnet als UTF8 datei, mit BOM etc), dann sieht das halt gar nicht richtig aus... Das ist z.B. der Hexdump: 44 00 69 00 65 00 20 00 6B 00 75 00 08 03 6E 00 D.i.e. .k.u...n. Da sollte eigentlich künstlich stehen, utf8 codiert. Vielleicht ist was an meiner Python installation kaputt? laut version ist es 2.4.3, aber ich komme immer in den ValueError handler, anstatt das xmlcharrefreplace ausgefuehrt wird. Oder irgendein encoding. Wenn ich z.B. den oberen string mit variable.encode('utf8') encode bekomme ich den : 'ascii' codec can't decode byte 0xcc in position 36: ordinal not in range(128) und ich bin etwas irritiert, da ich ja versuche utf8 zu encoden (habe auch UTF8 oder UTF-8 etc ausprobiert. Oder UTF-7, 16 etc . alles mit dem gleichen resultat). Das witzige ist, das wenn ich vom programm aus ein "print variable" mache, dann bekomme ich den umlaut... Frank (installation: das ist ein Mac, und da habe ich halt das letzte Python package installiert). On 10/8/06, Jochen Schulz <ml@well-adjusted.de> wrote:
Frank Mantek:
Einige der Dateinamen sind nun in Deutsch, mit Umlauten. Ich schaffe es nicht mit Python 2.4.3 eine Seite zu erzeugen in der ein umlaut A
ordentlich
HTML entity encoded wird.
Warum willst Du das tun? Die Angabe des richtigen charsets würde doch ausreichen.
J. -- If I was Mark Chapman I would have shot John Lennon with a water pistol. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html>
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFKNDq+AfZydWK2zkRAoWxAKCsgekH2CBOqvhS5mO7ZJjFZlqqlACdGjSe kIJzKSmuNDagfuZV7838sA0= =Hbuc -----END PGP SIGNATURE-----
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Frank Mantek wrote:
Tja, das dachte ich urspruenglich auch... aber wenn ich in die geschriebene Datei schaue (geoffnet als UTF8 datei, mit BOM etc), dann sieht das halt gar nicht richtig aus...
Das ist z.B. der Hexdump:
44 00 69 00 65 00 20 00 6B 00 75 00 08 03 6E 00 D.i.e. .k.u...n.
0x08 ist in ASCII ein Backspace, also ein Schritt rückwärts. Offenbar gibt es irgendeine Konvention, welche 0x0803 so interpretiert, dass die zwei Punkte über das vorhergehende Zeichen gesetzt werden. Du hast es also nicht mit einem einzelnen ü zu tun, sondern mit zwei seperaten Zeichen, aus welchen das ü grafisch zusammengesetzt wird. Ich habe keine Ahnung, ob es sich dabei um einen standard-Zeichensatz handelt, geschweige denn ggf. um welchen. Falls du das nicht irgendwie noch rauskriegst, wäre es wohl am sinnvollsten, solche Zeichenkombinationen selber in etwas vernünftiges umzuwandeln.
Da sollte eigentlich künstlich stehen, utf8 codiert.
Dein hexdump sieht nicht nach utf8 aus.
Das witzige ist, das wenn ich vom programm aus ein "print variable" mache, dann bekomme ich den umlaut...
Die Terminalsoftware beherrscht offenbar die entsprechende Konvention. -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Das heist also, das die os.getfiles etc, string zurueckliefern koennen, die in einem zeichensatz sind, die die codec funktionen nicht verstehen? Weird. Ich haette gedacht das die OS specifische python installation sich darum kuemmert -> soll heisen wenn ich ein file object habe, gehe ich davon aus das der dateiname in utf16 encoded ist. Silly me. Gibt es funktionen die mir sagen in welchem encoding ein string object ist? Beim durchblaettern von codec habe ich nix gefunden, aber das heist ja nix... Das mit 0x08 ist ein guter guess, und jup, das file sieht nicht nach utf8 aus - das ist ja das problemchen :). Mal schauen was ich damit mache.. Frank On 10/8/06, Georg Mischler <schorsch@schorsch.com> wrote:
Frank Mantek wrote:
Tja, das dachte ich urspruenglich auch... aber wenn ich in die geschriebene Datei schaue (geoffnet als UTF8 datei, mit BOM etc), dann sieht das halt gar nicht richtig aus...
Das ist z.B. der Hexdump:
44 00 69 00 65 00 20 00 6B 00 75 00 08 03 6E 00 D.i.e. .k.u...n.
0x08 ist in ASCII ein Backspace, also ein Schritt rückwärts.
Offenbar gibt es irgendeine Konvention, welche 0x0803 so interpretiert, dass die zwei Punkte über das vorhergehende Zeichen gesetzt werden. Du hast es also nicht mit einem einzelnen ü zu tun, sondern mit zwei seperaten Zeichen, aus welchen das ü grafisch zusammengesetzt wird.
Ich habe keine Ahnung, ob es sich dabei um einen standard-Zeichensatz handelt, geschweige denn ggf. um welchen. Falls du das nicht irgendwie noch rauskriegst, wäre es wohl am sinnvollsten, solche Zeichenkombinationen selber in etwas vernünftiges umzuwandeln.
Da sollte eigentlich künstlich stehen, utf8 codiert.
Dein hexdump sieht nicht nach utf8 aus.
Das witzige ist, das wenn ich vom programm aus ein "print variable" mache, dann bekomme ich den umlaut...
Die Terminalsoftware beherrscht offenbar die entsprechende Konvention.
-schorsch
-- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 08.10.06 13:45:14, Frank Mantek wrote:
Das heist also, das die os.getfiles etc, string zurueckliefern koennen, die in einem zeichensatz sind, die die codec funktionen nicht verstehen? Weird. Ich haette gedacht das die OS specifische python installation sich darum kuemmert -> soll heisen wenn ich ein file object habe, gehe ich davon aus das der dateiname in utf16 encoded ist. Silly me.
utf16-kodiert sieht das ganze auch aus, nur dass statt einem "ü" ein u und vmtl. 2 hochgestellte Punkte drin stehen.
Gibt es funktionen die mir sagen in welchem encoding ein string object ist? Beim durchblaettern von codec habe ich nix gefunden, aber das heist ja nix...
Nein, das kann nicht funktionieren. Man kann ohne zusaetzliche Informationen nicht sicher sagen welche Kodierung fuer eine gegebene Bytefolge benutzt wurde. Du kannst nur alle durchprobieren und dann schauen ob das Ergebniss passt.
Das mit 0x08 ist ein guter guess, und jup, das file sieht nicht nach utf8 aus - das ist ja das problemchen :). Mal schauen was ich damit mache..
<Vermutung>0x0803 ergibt nach korrekter Dekodierung ein Zeichen das ueber das vorangegangene geschoben wird und 2 Punkte darstellt. Such dir mal ne Zeichentabelle fuer Unicode und schau ob du das da findest bei utf16 Kodierung. Bei der Herkunft des komischen ü wuerde ich mal auf die Applikation tippen mit der die Datei erstellt wurde.</Vermutung> Hast du mal versucht mittels encode deine Bytefolge als utf-16 in einen Unicode-String zu uebersetzen? Andreas -- Make a wish, it might come true. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Ok, jetzt klappts. Das string object das ich von os.listdir() bekomme, muss ich: unicode_data = unicode(dateiname, 'utf8') unicode_data = unicodedata.normalize("NFC", unicode_data) und jetzt habe ich ein file das auch Firefox versteht :) Wunderbar. So ganz steige ich zwar noch nicht durch (wuesste gerne welcher codec da bei default auf meinem Mac benutzt wurde), aber das ist ein zweitrangiges Problem im moment. Herzlichen Dank Frank On 10/8/06, Andreas Pakulat <apaku@gmx.de> wrote:
On 08.10.06 13:45:14, Frank Mantek wrote:
Das heist also, das die os.getfiles etc, string zurueckliefern koennen, die in einem zeichensatz sind, die die codec funktionen nicht verstehen? Weird. Ich haette gedacht das die OS specifische python installation sich darum kuemmert -> soll heisen wenn ich ein file object habe, gehe ich davon aus das der dateiname in utf16 encoded ist. Silly me.
utf16-kodiert sieht das ganze auch aus, nur dass statt einem "ü" ein u und vmtl. 2 hochgestellte Punkte drin stehen.
Gibt es funktionen die mir sagen in welchem encoding ein string object ist? Beim durchblaettern von codec habe ich nix gefunden, aber das heist ja nix...
Nein, das kann nicht funktionieren. Man kann ohne zusaetzliche Informationen nicht sicher sagen welche Kodierung fuer eine gegebene Bytefolge benutzt wurde. Du kannst nur alle durchprobieren und dann schauen ob das Ergebniss passt.
Das mit 0x08 ist ein guter guess, und jup, das file sieht nicht nach utf8 aus - das ist ja das problemchen :). Mal schauen was ich damit mache..
<Vermutung>0x0803 ergibt nach korrekter Dekodierung ein Zeichen das ueber das vorangegangene geschoben wird und 2 Punkte darstellt. Such dir mal ne Zeichentabelle fuer Unicode und schau ob du das da findest bei utf16 Kodierung. Bei der Herkunft des komischen ü wuerde ich mal auf die Applikation tippen mit der die Datei erstellt wurde.</Vermutung>
Hast du mal versucht mittels encode deine Bytefolge als utf-16 in einen Unicode-String zu uebersetzen?
Andreas
-- Make a wish, it might come true.
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Georg Mischler sagte:
Frank Mantek wrote:
Tja, das dachte ich urspruenglich auch... aber wenn ich in die geschriebene Datei schaue (geoffnet als UTF8 datei, mit BOM etc), dann sieht das halt gar nicht richtig aus...
Das ist z.B. der Hexdump:
44 00 69 00 65 00 20 00 6B 00 75 00 08 03 6E 00 D.i.e. .k.u...n.
0x08 ist in ASCII ein Backspace, also ein Schritt rückwärts.
Offenbar gibt es irgendeine Konvention, welche 0x0803 so interpretiert, dass die zwei Punkte über das vorhergehende Zeichen gesetzt werden. Du hast es also nicht mit einem einzelnen ü zu tun, sondern mit zwei seperaten Zeichen, aus welchen das ü grafisch zusammengesetzt wird.
Ich habe keine Ahnung, ob es sich dabei um einen standard-Zeichensatz handelt, geschweige denn ggf. um welchen. Falls du das nicht irgendwie noch rauskriegst, wäre es wohl am sinnvollsten, solche Zeichenkombinationen selber in etwas vernünftiges umzuwandeln.
Das sieht mir eher nach UTF-16 aus. U+0308 ist ein freifliegender Umlaut:
unicodedata.name(u"\u0308") 'COMBINING DIAERESIS'
Um den loszuwerden (d.h. mit dem Zeichen davor (falls möglich) zu kombinieren, gibt es unicodedata.normalize():
unicodedata.normalize("NFC", u"a\u0308") u'\xe4'
Da sollte eigentlich künstlich stehen, utf8 codiert.
Dein hexdump sieht nicht nach utf8 aus.
Nö, eher UTF-16.
Das witzige ist, das wenn ich vom programm aus ein "print variable" mache, dann bekomme ich den umlaut...
Die Terminalsoftware beherrscht offenbar die entsprechende Konvention.
Servus, Walter _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (5)
-
Andreas Pakulat -
Frank Mantek -
Georg Mischler -
Jochen Schulz -
Walter Dörwald