Unicode problem

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 16:06

Hallo,

ich habe ein kleines (oder auch grosses) Verständnisproblem. ;)
Den Problemcode konnte ich auf eine Zeile reduzieren.

Code: Alles auswählen

# -*- coding: cp1252 -*-
# ... und alle weiter coding und encodings probiert.

print u": ".join(["copyright", "® Project 5"])
Output:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xae in position 0: ordinal not in range(128)

Warum funktioniert diese Zeile nicht?

Warum funktioniert:

Code: Alles auswählen

print u"copyright: ® Project 5"
copyright: ® Project 5


Was kann ich tun, damit dies ausgeführt wird?

Danke im voraus! :)
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Dienstag 24. Oktober 2006, 16:23

Das u vor dem "" bezieht sich nur auf den String, der zwischen die beiden anderen geschoben wird beim join. Wenn du das u auch vor "® Project 5" machst, geht es.
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 16:41

tiax hat geschrieben:Das u vor dem "" bezieht sich nur auf den String, der zwischen die beiden anderen geschoben wird beim join. Wenn du das u auch vor "® Project 5" machst, geht es.
Danke geht aber leider auch nicht (ganz):
Weder

Code: Alles auswählen

print u": ".join(["copyright", u"® Project 5"])
noch

Code: Alles auswählen

print u": ".join([u"copyright", u"® Project 5"])
aber nun geht:

Code: Alles auswählen

a = u": ".join(["copyright", u"® Project 5"])
was vorher nicht ging.

Aber wie kann ich das dann mit print ausgeben?
bei print bekomme ich immer noch die exception.
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Dienstag 24. Oktober 2006, 16:45

Letzteres geht bei mir:

Code: Alles auswählen

Python 2.4.1 (#1, Sep 12 2005, 23:33:18)
[GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print u": ".join([u"copyright", u"® Project 5"])
copyright: ® Project 5
Auch Zuweisungen an Variablen sind kein Problem.
Hast Du das Problem auch schon auf Deiner Shell?

Gruß,
Christian

edit: Hast Du gerade, während ich schrieb, Deinen Post editiert oder habe ich ein Problem mit dem Browser, denn gerade habe ich den unteren Teil nicht gesehen?
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 16:56

CM hat geschrieben:Letzteres geht bei mir:

Code: Alles auswählen

Python 2.4.1 (#1, Sep 12 2005, 23:33:18)
[GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print u": ".join([u"copyright", u"® Project 5"])
copyright: ® Project 5
Auch Zuweisungen an Variablen sind kein Problem.
Hast Du das Problem auch schon auf Deiner Shell?
Hm in Pycrust Shell geht das,

Code: Alles auswählen

PyCrust 0.9.5 - The Flakiest Python Shell
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Startup script executed: C:\Dokumente und Einstellungen\SteinhaF\Anwendungsdaten\pycrust\startup
print u": ".join([u"copyright", u"® Project 5"])
copyright: ® Project 5
aber wenn ich von SciTE aus das mache:

Code: Alles auswählen

print u": ".join([u"copyright", u"® Project 5"])
sys:1: DeprecationWarning: Non-ASCII character '\xae' in file uc1.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Traceback (most recent call last):
  File "uc1.py", line 1, in ?
    print u": ".join([u"copyright", u"® Project 5"])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 11: ordinal not in range(128)
>Exit code: 1
CM hat geschrieben: Gruß,
Christian

edit: Hast Du gerade, während ich schrieb, Deinen Post editiert oder habe ich ein Problem mit dem Browser, denn gerade habe ich den unteren Teil nicht gesehen?
Nein, Du hast kein Problem mit Deinem Browser, ich habe tatstächlich noch nacheditiert. ;)
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Dienstag 24. Oktober 2006, 17:17

Habe eine Idee: Hast Du Deine Datei in einem ensprechenden Coding (UTF8 z. B.) auch gespeichert? Tritt das Problem auch auf, wenn Du ein solches Skript ausführst?

Wahrscheinlich wird das Problem nicht auftreten, wenn Du in SciTE eine Datei bereits in einem entsprechenden encoding abspeicherst und das Programm sonst wo ausführst, oder? (Also liegt die Ursache bei SciTE (Spekulation).)

Gruß,
Christian
Benutzeravatar
DatenMetzgerX
User
Beiträge: 398
Registriert: Freitag 28. April 2006, 06:28
Wohnort: Zürich Seebach (CH)

Dienstag 24. Oktober 2006, 18:21

wenn ich das encoding angebe habe ich in der konsole kein Prolbem

Code: Alles auswählen

>>> #-*- coding: utf-8 -*-
...
>>> print ': '.join(["copyright", "® Project 5"])
copyright: ® Project 5
>>>
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 19:49

DatenMetzgerX hat geschrieben:wenn ich das encoding angebe habe ich in der konsole kein Prolbem

Code: Alles auswählen

>>> #-*- coding: utf-8 -*-
...
>>> print ': '.join(["copyright", "® Project 5"])
copyright: ® Project 5
>>>
Hallo DatenMetzgerX,

Du hast die Unicode Spezifikation vergessen.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 24. Oktober 2006, 20:02

Francesco hat geschrieben:eigenartig, an meinem HeimPc tritt das nicht auf ich meine es funktioniert.
Hallo Francesco!

Das blöde ist, dass man nicht genau voraussagen kann, welches Encoding für die Ausgabe nach STDOUT verwendet werden muss. Das ist abhängig vom Betriebssystem, vom aufrufenden Programm usw...

Weiters ist es noch vom real verwendeten Encoding der Moduldatei abhängig.

Deshalb habe ich mir ein kleines Modul geschrieben, das beim Importieren das Coding von STDOUT herauszufinden versucht. Alles was dann als UNICODE-String an STDOUT (z.B. durch ``print``) übergeben wird, wird über einen Stream-Writer umgeleitet und so in das (hoffentlich) korrekte Ziel-Encoding umgewandelt.

Wenn du also mit Unicode-Strings arbeitest und an ``print`` immer nur Unicode-Strings übergibst, dann könnte dir evt der ``Encodinghelper`` weiter helfen.

Erklärung: http://gelb.bcom.at/trac/misc/wiki/Encodinghelper
Download: http://gelb.bcom.at/trac/misc/browser/e ... format=raw

Die Angabe des Encodings ist allerdings Pflicht. Deshalb hat dein Test im Scite nicht funktioniert.

In den meisten Fällen funktioniert es auch, dass Python UNICODE-Strings korrekt ausgibt. Und das ganz ohne fremde Hilfe.

Code: Alles auswählen

# -*- coding: iso-8859-1 -*-
print u": ".join([u"copyright", u"® Project 5"])
Allerdings nicht immer -- und dafür gibt es den ``encodinghelper``.

Code: Alles auswählen

# -*- coding: iso-8859-1 -*-
import encodinghelper
print u": ".join([u"copyright", u"® Project 5"])
mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 20:04

CM hat geschrieben:Habe eine Idee: Hast Du Deine Datei in einem ensprechenden Coding (UTF8 z. B.) auch gespeichert? Tritt das Problem auch auf, wenn Du ein solches Skript ausführst?

Wahrscheinlich wird das Problem nicht auftreten, wenn Du in SciTE eine Datei bereits in einem entsprechenden encoding abspeicherst und das Programm sonst wo ausführst, oder? (Also liegt die Ursache bei SciTE (Spekulation).)

Gruß,
Christian
Hallo Christian,

danke, leider macht das keinen Unterschied.

Code: Alles auswählen

# -*- coding: UTF-8 -*-
print u': '.join(["copyright", u"® Project 5"]) 
UnicodeDecodeError: 'utf8' codec can't decode byte 0xae in position 0: unexpected code byt
e

und von der console her bekomme ich den gleichen Error.

Hintergrund des ganzen ist:
Ich möchte "Unicode" Programme unter Ansi wxPython laufen lassen, auch Programme die eigentlich auf Unicode "bestehen" laut Autor.
Ich glaube das nicht einfach so.

1.,) ich mag Unicode nicht.
2.) Ich möchte kein wxPython Unicode build installieren.
(wenn's sein muss, kann ich immer noch mit wx.select oder so auswäheln, aber auch das möchte ich mir ersparen).

Notfalls möchte ich das Programm nämlich mit dem geringsten Aufwand
dahinbringen, dass ich es in der ansi version von wxPython ausführen kann. Ich möchte generell Python programme mit wenigen 10k als solche
behandeln, und nicht für jedes Mini Programm 5 MB als exe erstellt mit
py2exe herunterladen.

Ich hasse Unicode und encoding, utf-8, cp1252, iso-8859 und co. :)
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 24. Oktober 2006, 21:22

Hi Francesco!
Francesco hat geschrieben:leider macht das keinen Unterschied.

Code: Alles auswählen

# -*- coding: UTF-8 -*-
print u': '.join(["copyright", u"® Project 5"]) 
UnicodeDecodeError: 'utf8' codec can't decode byte 0xae in position 0: unexpected code byte
Du gibst im Kopf das falsche Encoding an.
Python glaubt, dass der Quellcode UTF8-codiert gespeichert wurde. Wenn vor einem String ein ``u`` steht, dann bedeutet das für Python, dass dieser String nach Unicode umgewandelt werden soll. Dafür braucht Python irgend einen Hinweis auf das Coding des Quellcodes. Steht im Kopf ``# -*- coding: UTF-8 -*-``, dann glaubt Python, dass der Quellcode UTF-8-codiert ist und wandelt auf Basis dieser Information von UTF-8 nach UNICODE um. Pech, wenn der Quellcode nicht UTF-8, sondern iso-8859-1- oder cp1252-codiert ist.

Im Kopf muss immer das korrekte Encoding stehen. Wenn du unter Windows eine Textdatei erstellst, dann ist diese automatisch cp1252-codiert. Ich verwende im Kopf aber meistens iso-8859-1, da dieses Coding ähnlich dem cp1252 ist und ich oft zwischen Windows und Linux hin und her wechsle.

Wenn du also deinen Quellcode nicht explizit nach UTF-8 umgewandelt hast, dann stimmt die Angabe im Kopf nicht.
Francesco hat geschrieben:1.,) ich mag Unicode nicht.
2.) Ich möchte kein wxPython Unicode build installieren.
Da unterscheiden wir uns ziemlich extrem. -- Ich verstehe nicht, warum es überhaupt eine ANSI-Version von wxPython gibt und ärgere mich immer wieder darüber.

Die Sache ist für mich ziemlich einfach. Bei der Unicode-Version von wxPython übergebe ich an wxPython Unicode-Strings und dann muss ich mich um nichts mehr kümmern. Wenn ich etwas von wxPython zurück bekomme, dann weiß ich, dass ich Unicode-Strings zurück bekomme. Das ist eine Konstante, die ich sehr schätze. Gerade auch im Zusammenspiel mit Datenbanken. Übergebe ich an ``psycopg2`` (=PostgreSQL) einen Unicode-String, dann kümmert sich psycopg2 darum, dass dieser korrekt in der Datenbank gespeichert wird.

Wenn ich mit der ANSI-Version von wxPython arbeiten möchte, dann muss ich mich immer darum kümmern, dass sich das Coding nicht verändert oder es gibt Probleme wenn ich unterschiedliche Betriebssysteme verwende usw. Ich muss wxPython mitteilen, welches Coding ich ihm übergebe, damit es mit den Umlauten "immer" und nicht nur meistens klappt.
``wx.SetDefaultPyEncoding(encoding)`` muss immer mit dem Encoding des Python-Moduls zusammenpassen, sonst gibt es ein Chaos. --> Fazit: nur die Unicode-Version von wxPython wäre mir lieber als dieses gemischte Doppel zwischen ANSI und UNICODE.
Francesco hat geschrieben:Ich hasse Unicode und encoding, utf-8, cp1252, iso-8859 und co. :)
Es ist auch ein sch... Thema. Wären alle Betriebssystemumgebungen UTF-8, dann gäbe es diese Probleme nicht. Ich hoffe, dass es in etwa zehn Jahren so weit ist, dass man von den Begriffen ANSI und ASCII nur mehr im Museum etwas hört.

lg
Gerold
:-)
Zuletzt geändert von gerold am Dienstag 24. Oktober 2006, 22:11, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Dienstag 24. Oktober 2006, 21:53

Meine Antwort auf Deinen vorigen Beitrag ist unten.
Zuletzt geändert von Francesco am Mittwoch 25. Oktober 2006, 08:37, insgesamt 1-mal geändert.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Dienstag 24. Oktober 2006, 22:15

Francesco hat geschrieben:ich muss mir das morgen nochmals alles in Ruhe durchlesen :)
Hi Francesco!

Damit dir der Lesestoff nicht ausgeht ;-)

- http://www.python-forum.de/topic-5095.html
- http://www.python-forum.de/post-44228.html#44228

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Mittwoch 25. Oktober 2006, 08:19

gerold hat geschrieben:
Francesco hat geschrieben:ich muss mir das morgen nochmals alles in Ruhe durchlesen :)
Hi Francesco!

Damit dir der Lesestoff nicht ausgeht ;-)

- http://www.python-forum.de/topic-5095.html
- http://www.python-forum.de/post-44228.html#44228

lg
Gerold
:-)
Danke Gerold für Deine schönen Erläuterungen! :)
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

Mittwoch 25. Oktober 2006, 08:36

Hallo Gerold
gerold hat geschrieben:
Francesco hat geschrieben:1.,) ich mag Unicode nicht.
2.) Ich möchte kein wxPython Unicode build installieren.
Da unterscheiden wir uns ziemlich extrem. -- Ich verstehe nicht, warum es überhaupt eine ANSI-Version von wxPython gibt und ärgere mich immer wieder darüber.
Also ich ärgere mich nicht darüber, dass es eine Unicode Version GIBT. ;)
gerold hat geschrieben: Die Sache ist für mich ziemlich einfach. Bei der Unicode-Version von wxPython übergebe ich an wxPython Unicode-Strings und dann muss ich mich um nichts mehr kümmern. Wenn ich etwas von wxPython zurück bekomme, dann weiß ich, dass ich Unicode-Strings zurück bekomme. Das ist eine Konstante, die ich sehr schätze. Gerade auch im Zusammenspiel mit Datenbanken. Übergebe ich an ``psycopg2`` (=PostgreSQL) einen Unicode-String, dann kümmert sich psycopg2 darum, dass dieser korrekt in der Datenbank gespeichert wird.
Kann ich nicht wiedersprechen. Nur eines: Wenn ich sicher bin,
dass keine Übersetzung erfolgt und alles auf Englisch halte, warum solle
ich dann Unicode verwenden? Überall ein u vorsetzten u"String".
Oder muss ich das eh nicht?
gerold hat geschrieben: Wenn ich mit der ANSI-Version von wxPython arbeiten möchte, dann muss ich mich immer darum kümmern, dass sich das Coding nicht verändert oder es gibt Probleme wenn ich unterschiedliche Betriebssysteme verwende usw. Ich muss wxPython mitteilen, welches Coding ich ihm übergebe, damit es mit den Umlauten "immer" und nicht nur meistens klappt.
``wx.SetDefaultPyEncoding(encoding)`` muss immer mit dem Encoding des Python-Moduls zusammenpassen, sonst gibt es ein Chaos. --> Fazit: nur die Unicode-Version von wxPython wäre mir lieber als dieses gemischte Doppel zwischen ANSI und UNICODE.
Na ja, ich werde meine Ansicht nochmals überdenken, Deine Argumente sind gut. ;)
gerold hat geschrieben:
Francesco hat geschrieben:Ich hasse Unicode und encoding, utf-8, cp1252, iso-8859 und co. :)
Es ist auch ein sch... Thema. Wären alle Betriebssystemumgebungen UTF-8, dann gäbe es diese Probleme nicht. Ich hoffe, dass es in etwa zehn Jahren so weit ist, dass man von den Begriffen ANSI und ASCII nur mehr im Museum etwas hört.

lg
Gerold
:-)
Hat Unicode dann irgendwelche Nachteile?

Meine Abneigung resultierte auch, dass es immer wieder Probleme bei wxPython Programmen gab, die die Unicode wxPython Dist. verwendeten.
Bei Ansi gab es dies nicht.

Servus,
Antworten