Hallo Listlinge,
existiert auch eine deutsche wxPython ML (die englische kenne ich) oder ist das hier der richtige Platz, um wxPython Fragen zu stellen?
Grüße Andreas
Andreas Kaiser wrote:
Hallo Listlinge,
existiert auch eine deutsche wxPython ML
Nein.
(die englische kenne ich)
Und ist wahrscheinlich am ergiebigsten ...
oder ist das hier der richtige Platz, um wxPython Fragen zu stellen?
Ja.
-- Gerhard
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo,
ich benutze folgendes Programm um aus einem HTML-String den Inhalt zu extrahieren:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
import formatter import htmllib import StringIO
def html2Text(htmlText):
fp = StringIO.StringIO() w = formatter.DumbWriter(fp) # gibt einfach nur text aus f = formatter.AbstractFormatter(w) # vermittelt zu w
# parse HTML und erzeuge Aufrufe nach f p = htmllib.HTMLParser(f) p.feed(htmlText) p.close()
return fp.getvalue()
html=""" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//DE"> <html> <head> <meta content="text/html; charset=iso-8859-1" http-equiv=Content-Type> </head> <body> <h1>Überschrift</h1>Text im Body <p>Paragraph</p> </body> </html>"""
res= html2Text(html) print res
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<
Das funktioniert auch wunderbar bis auf die Tatsache, daß Ü nicht zum "Ü" umgesetzt wird, "Ü" wird durch '\xdc' ersetzt, was aber kein "Ü" ist. Dachte zuerst StringIO() wäre dran schuld, aber das konnte ich ausschließen.
Goolge konnte mir auch nicht weiterhelfen....
Gruß, Uwe
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Uwe Schmitt wrote:
Das funktioniert auch wunderbar bis auf die Tatsache, daß Ü nicht zum "Ü" umgesetzt wird, "Ü" wird durch '\xdc' ersetzt, was aber kein "Ü" ist. Dachte zuerst StringIO() wäre dran schuld, aber das konnte ich ausschließen.
In Latin-1 is \xdc durchaus ein Ü.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Uwe Schmitt wrote:
Hallo,
ich benutze folgendes Programm um aus einem HTML-String den Inhalt zu extrahieren: [...] Das funktioniert auch wunderbar bis auf die Tatsache, daß Ü nicht zum "Ü" umgesetzt wird, "Ü" wird durch '\xdc' ersetzt, was aber kein "Ü" ist. Dachte zuerst StringIO() wäre dran schuld, aber das konnte ich ausschließen. [...]
Auf deiner Konsole ist ein anderer Zeichensatz wie^als in dem HTML-Dokument eingestellt (iso-8859-1).
Probier mal (hab ich mir von Martin abgeschaut):
#v+ import formatter import htmllib import StringIO import unicodedata
def html2Text(htmlText):
fp = StringIO.StringIO() w = formatter.DumbWriter(fp) # gibt einfach nur text aus f = formatter.AbstractFormatter(w) # vermittelt zu w
# parse HTML und erzeuge Aufrufe nach f p = htmllib.HTMLParser(f) p.feed(htmlText) p.close()
return fp.getvalue()
html = "Ü"
res= html2Text(html)
print unicodedata.name(unicode(res, "iso-8859-1")) #v-
==> C:\tmp>python uml.py LATIN CAPITAL LETTER U WITH DIAERESIS
Die Umwandlung funktioniert also korrekt.
-- Gerhard
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
print unicodedata.name(unicode(res, "iso-8859-1")) #v-
==> C:\tmp>python uml.py LATIN CAPITAL LETTER U WITH DIAERESIS
Die Umwandlung funktioniert also korrekt.
O.K., danke fuer die flotte Antwort. Wie krieg ich jetzt eine Mail, die einmal einen Klartext-Part hat und das gleiche via HTML-Part konsistenz dekodiert ??? Hintergrund ist, daß ich Mails auf Stichwörter untersuchen will, und das unabhängig davon, ob die Nachricht als Klartext, HTML, oder beides vorliegt ??? Und das am besten unabhängig davon ob die Mail aus den USA oder China stammt ....
Das Unicode-Zeugs ist mir teilweise immer noch nicht so recht klar....
Gruß, Uwe.
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
"Uwe Schmitt" rocksportrocker@gmx.de writes:
Wie krieg ich jetzt eine Mail, die einmal einen Klartext-Part hat und das gleiche via HTML-Part konsistenz dekodiert ???
[...]
Und das am besten unabhängig davon ob die Mail aus den USA oder China stammt ....
Du musst beim Verarbeiten der Email stets aufzeichnen, in welcher Kodierung der Text versendet wird. Für MIME-Text-Parts steht das im charset=-Feld, für HTML steht das entweder a) im <?xml-Header, b) im <META http-equiv-Header, oder c) im MIME-Type (charset=)
Wenn Du mit dem htmllib-Dumbwriter HTML in Text umwandelst, bekommst Du einen Byte-String, genauso, wie wenn Du Dir einen text/plain-Teil betrachtest (nachdem evtl. ein Content-transfer-encoding aufgelöst wurde).
Wenn Du also eine Byte-String-Version B des Texts hast sowie die Kodierung K, dann kannst Du mittels
U = unicode(B, K)
die Unicode-Version des Texts ermitteln. Diese solltest Du zur Suche nach Stichwörtern verwenden. Dann klappt es auch mit den asiatischen Nachbarn.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi,
Wenn Du also eine Byte-String-Version B des Texts hast sowie die Kodierung K, dann kannst Du mittels
U = unicode(B, K)
die Unicode-Version des Texts ermitteln.
Dein obiges Beispiel in IDLE:
unicode("äöü", "cp437")
UnicodeError: ASCII encoding error: ordinal not in range(128) (Python 2.2.2, Win2k)
Irgendwie fehlt mir der rote Faden. Gibt es ein empfehlenswerte Einführung? Unicode macht mir auch immer Probleme.
Sehe ich folgendes bisher richtig:
Python unterstützt für Strings nur noch 7-Bit, alle Zeichen über 127 müssen Unicode sein? Also sobald ich ein Umlaut habe, brauche ich Unicode?
Wie verhalten sich die vielen in Python vorhanden Fkt/Module etc., die irgendwo Strings erwarten?
Gibt es noch eine Möglichkeit, zu 8 Bit-Strings zu kommen, die ganz ohne Unicode (wie früher, sag ich mal :-) mit Umlauten umgehen können?
Dein obiges Beispiel in IDLE:
unicode("äöü", "cp437")
UnicodeError: ASCII encoding error: ordinal not in range(128) (Python 2.2.2, Win2k)
Seltsam, auf der Commandline gehts:
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
unicode("ä", "latin-1")
u'\x84'
Ein Problem in IDLE?
Klaus Meyer km-news1@onlinehome.de writes:
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
unicode("d", "latin-1")
u'\x84'
Ich nehme mal an, hier war ein Umlaut? Das hat *nicht* funktioniert: u'\x84' ist *kein* Umlaut. Die Konsole verwendet nämlich kein Latin-1.
Ein Problem in IDLE?
Ja; IDLE erlaubt keine Umlaute in Quelltext.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus Meyer km-news1@onlinehome.de writes:
unicode("dö", "cp437")
UnicodeError: ASCII encoding error: ordinal not in range(128) (Python 2.2.2, Win2k)
Das liegt daran, dass man in IDLE keine Umlaute eingeben kann. Ich empfehle, stets die Hexadezimalversion in String-Literalen zu verwenden, also \xRS.
Irgendwie fehlt mir der rote Faden. Gibt es ein empfehlenswerte Einführung? Unicode macht mir auch immer Probleme.
http://www.jorendorff.com/articles/unicode/python.html http://www.reportlab.com/i18n/python_unicode_tutorial.html http://www.python.org/peps/pep-0100.html
Sehe ich folgendes bisher richtig:
Python unterstützt für Strings nur noch 7-Bit, alle Zeichen über 127 müssen Unicode sein?
Falsch. Python-Byte-Strings enthalten Bytes im Bereich 0..255. Welche Zeichen diese Bytes bedeuten hängt von der verwendeten Kodierung ab (Latin-1, CP437, ASCII, UTF-8).
Also sobald ich ein Umlaut habe, brauche ich Unicode?
Falsch. Du kannst einen Umlaut auch mit Bytestrings kodieren - allerdings gibt es mindestens 4 verschiedene Repräsentationen für o-umlaut (Latin-1=CP1252, CP437, CP850, UTF-8, MacRoman, ...)
Wie verhalten sich die vielen in Python vorhanden Fkt/Module etc., die irgendwo Strings erwarten?
Die verhalten sich alle richtig... Was genau bedeutet die Frage?
Gibt es noch eine Mvglichkeit, zu 8 Bit-Strings zu kommen, die ganz ohne Unicode (wie früher, sag ich mal :-) mit Umlauten umgehen können?
Klar. Du musst Dich bloss entscheiden, welche Kodierung Du verwenden willst.
Wenn Du Dich beispielsweise für CP850 entscheidest, wirst Du mit HTML-Files Schwierigkeiten bekommen, die iso-8859-1 verwenden; verwendest Du iso-8859-1, bekommst Du mit der Windows-Konsole Probleme. Die Probleme kann man alle lösen - allerdings muss man sie zuerst verstehen.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Martin,
Das liegt daran, dass man in IDLE keine Umlaute eingeben kann.
Hm, wenn ich da ein Umlaut eingebe, dann nimmt er das aber ohne Probleme an und zeigt es mir am Bildschirm in IDLE an. Ich vermute mal, kodiert nach Latin-1, weil das der Win-Standard ist?
Falsch. Python-Byte-Strings enthalten Bytes im Bereich 0..255.
Puh, dann bin ich ja erstmal beruhigt ;-) Also so? a = "abc" #Das wäre dann 8 Bit. Bis 7 Bit ASCII kodiert, alles darüber muss #durch eine Codepage interpretiert werden
a = u"abc" #intern 16 (oder 32?) Bit/Zeichen, vermutlich UTF-16?
Zeichen diese Bytes bedeuten hängt von der verwendeten Kodierung ab (Latin-1, CP437, ASCII, UTF-8).
Was bedeutet aber "verwendete Kodierung". So wie es aussieht, verwendet Python per Default ASCII? Kann ich die "verwendete Kodierung" global für ein Script umschalten, oder muss man das für jeden String (sobald mehr als ASCII) explizit mit encode() machen? Gibt es einen Py-Befehl, um mir die default-Kodierung ausgeben zu lassen?
o-umlaut (Latin-1=CP1252, CP437, CP850, UTF-8, MacRoman, ...)
OK. Gibt es Empfehlungen, welche CP man für Win-Programme und welche für Linux-Programme verwenden kann? Meines Wissen verwendet Win Latin-1.
Klar. Du musst Dich bloss entscheiden, welche Kodierung Du verwenden willst.
OK, ich will Latin-1, wie stelle ich das für meinen Script global ein? ;-)
Danke für Deine Antwort und für die Links, werde ich mir bestimmt noch anschauen!
Hi Klaus,
Hm, wenn ich da ein Umlaut eingebe, dann nimmt er das aber ohne Probleme an und zeigt es mir am Bildschirm in IDLE an. Ich vermute mal, kodiert nach Latin-1, weil das der Win-Standard ist?
ich wäre da ziemlich vorsichtig! Ich verwende IDLE nicht, hab' aber mal sehr schlechte Erfahrungen damit gemacht. In meiner Version (kann sein, daß die älter war) gab's Probleme, wenn man Nicht-ASCII Zeichen löschen wollte. Intern werden die wohl als zwei Zeichen (utf-8?) gespeichert, d.h. du mußt zweimal Backspace drücken. Machst du das nicht und speicherst das File, schmiert IDLE ab und dein File ist leer!!! Wie gesagt: Es kann sein, daß der Fehler inzwischen behoben ist, aber für mich war's eine sehr unschöne Erfahrung.
a = "abc" #Das wäre dann 8 Bit. Bis 7 Bit ASCII kodiert, alles darüber muss #durch eine Codepage interpretiert werden
Jein, du hast einen String mit 8bit Werten. Theoretisch kann es auch ein gif oder sowas sein. Sinn ergeben die Daten erst im richtigen Kontext.
a = u"abc" #intern 16 (oder 32?) Bit/Zeichen, vermutlich UTF-16?
Hab' gerade mal in der Doku gesucht, aber keine Default Kodierung gefunden. Keine Ahnung wie so ein String kodiert ist, aber bei der unicode Funktion, kannst du ein Encoding angeben.
Zeichen diese Bytes bedeuten hängt von der verwendeten Kodierung ab (Latin-1, CP437, ASCII, UTF-8).
Genau, nur mußt du dir klar machen, daß diese Kodierung nicht an dem String hängt. Angenommen du hast einen Unicodestring mit chinesischen Zeichen:
tmp = u"\xenige\xcodes\xfür\xchinesische\Zeichen" out = tmp.encode('utf-16') print out
encode verwandelt tmp in eine 8bit String, mit den utf-16 Werten. Das dieser String utf-8 kodiert ist, ist ihm jetzt nicht mehr anzusehen, d.h. du mußt es dir merken. Wenn du jetzt eine Datei mit dem codecs Modul mit utf-8 öffnest und den String dort 'rein schreibst, hast du heilloses Chaos, das ganz allein in deiner Verantwortung liegt. Du solltest dir auch klar machen, daß ASCII Strings gleichzeitig gültige utf-8 Strings sind. Ich hab' schon mehrfach Code für englische Texte geschrieben und war der Meinung alles wäre richtig. Und beim ersten Umlaut hat's mich dann erwischt.
Was bedeutet aber "verwendete Kodierung". So wie es aussieht, verwendet Python per Default ASCII? Kann ich die "verwendete Kodierung" global für ein Script umschalten, oder muss man das für jeden String (sobald mehr als ASCII) explizit mit encode() machen? Gibt es einen Py-Befehl, um mir die default-Kodierung ausgeben zu lassen?
Meines Wissens verwendet die aktuelle Python Version iso-latin-1. Bei 2.3 wird man das Encoding für Sourcefiles angeben können, im Detail angeschaut hab' ich mir das aber noch nicht.
o-umlaut (Latin-1=CP1252, CP437, CP850, UTF-8, MacRoman, ...)
OK. Gibt es Empfehlungen, welche CP man für Win-Programme und welche für Linux-Programme verwenden kann? Meines Wissen verwendet Win Latin-1.
Meiner Meinung nach hängt das davon ab, was du vorhast. Wie Martin schon geschrieben hat: Wenn du das Problem erstmal richtig verstanden hast, findet sich auch eine Lösung!
OK, ich will Latin-1, wie stelle ich das für meinen Script global ein? ;-)
Wie oben beschrieben verwendet Python meines Wissens per default iso-latin-1. Dein Problem ist eher, daß dein Ausgabemedium (z.B. Console) etwas anderes erwartet.
Ich hoffe das war hilfreich und ich hab' dich nicht ganz verwirrt! ;-)
Gruß, Achim
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Klaus Meyer km-news1@onlinehome.de writes:
Hm, wenn ich da ein Umlaut eingebe, dann nimmt er das aber ohne Probleme an und zeigt es mir am Bildschirm in IDLE an. Ich vermute mal, kodiert nach Latin-1, weil das der Win-Standard ist?
Nein, er kodiert nach ASCII, weil das sys.getdefaultencoding() ist.
Manch einer wird vorschlagen, dieses zu ändern; ich empfehle, diese Vorschläge zu ignorieren, zumindest bis Du alle Konsequenzen überschaust.
a = "abc" #Das wäre dann 8 Bit. Bis 7 Bit ASCII kodiert, alles darüber muss #durch eine Codepage interpretiert werden
Alles stets durch eine Codepage interpretiert. Es könnte auch EBCDIC sein, in welchem Fall auch Zeichen <128 nicht ASCII wären.
a = u"abc" #intern 16 (oder 32?) Bit/Zeichen, vermutlich UTF-16?
Üblicherweise 16-bit, also 2 Byte pro Zeichen.
Zeichen diese Bytes bedeuten hängt von der verwendeten Kodierung ab (Latin-1, CP437, ASCII, UTF-8).
Was bedeutet aber "verwendete Kodierung". So wie es aussieht, verwendet Python per Default ASCII?
Hängt vom Kontext ab. In der Regel ist Python die Kodierung völlig schnuppe, und es ist Sache der Anwendung, die Bytes zu interpretieren. Gibt man sie beispielsweise auf ein Terminal-Fenster aus, so interpretiert dieses die Bytes, und sie bekommen dann die Bedeutung, die sie im Terminal-Fenster haben, usw.
Kann ich die "verwendete Kodierung" global für ein Script umschalten, oder muss man das für jeden String (sobald mehr als ASCII) explizit mit encode() machen?
Weder noch. Welche Kodierung Bytes haben ist eine Frage der Interpretation; das ist nicht inherent in den Bytes drin.
Wenn Du beispielsweise in einem Text-Editor Umlaute eingibst, legt der Text-Editor diese Zeichen auf der Festplatte in einer Bytefolge ab. Python liest sich diese Bytes durch, und erzeugt eine interne Repräsentation, die Byte-für-Byte mit der auf der Festplatte identisch ist.
Wenn es sich also um Python-Quelltext handelt, und der wird in der "ANSI-Codepage" (cp1252) abgespeichert, weil der Editor notepad.exe ist, sind die Umlaute zur Laufzeit cp1252-kodiert. Wenn diese Bytes dann in einem Terminal ausgegeben werden, werden sie als cp850 interpretiert - die gleichen Bytes haben also eine andere Interpretation, und Python hatte damit gar nichts zu tun - es reicht die Bytes einfach nur durch.
Gibt es einen Py-Befehl, um mir die default-Kodierung ausgeben zu lassen?
Gibt es, sys.getdefaultencoding(). Die spielt allerdings nur im Zusammenhang mit Unicode eine Rolle. Sei U ein Unicode-String und B ein Byte-String, so ist
U + B
das gleiche wie
U + unicode(B, sys.getdefaultencoding())
Wenn Python nicht in (oder von) Unicode-Strings konvertieren muss, bleiben Bytes stets und immer uninterpretiert.
In IDLE findet man allerdings ein anderes Beispiel für Unicode-Konvertierung: IDLE verwendet intern Unicode, und muss u.U. in Bytestrings umwandeln - dann wird ebenfalls sys.getdefaultencoding() verwendet.
o-umlaut (Latin-1=CP1252, CP437, CP850, UTF-8, MacRoman, ...)
OK. Gibt es Empfehlungen, welche CP man für Win-Programme und welche für Linux-Programme verwenden kann? Meines Wissen verwendet Win Latin-1.
So ungefähr, ja. Windows verwendet viele Kodierung - Du redest vermutlich über die westeuropäischen Windows-Versione (Deutsch, Französisch, Spanisch, usw). Diese verwenden immer noch zwei Kodierungen: CP1252 (im Fenstersystem) und CP850 (in der Konsole). CP1252 ist ungefähr das gleiche wie Latin-1.
Klar. Du musst Dich bloss entscheiden, welche Kodierung Du verwenden willst.
OK, ich will Latin-1, wie stelle ich das für meinen Script global ein? ;-)
Gar nicht. Du musst einfach nur darauf achten, dass alle Strings immer Latin-1 sind, und akzeptieren, dass Du sie nicht auf der Konsole ausgeben kannst (weil die cp850 verwenden, wenn Du nicht setcp.exe aufrufst).
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Wie verhalten sich die vielen in Python vorhanden Fkt/Module etc., die irgendwo Strings erwarten?
Die verhalten sich alle richtig...
Hm, Im Prinzip ja, denn da es ja zB für Tkinter, obwohl schon lange in Python vorhanden, in der Py-Doku immer noch keine richtige Beschreibung gibt, ist natürlich jedes Verhalten "richtig" ;-)
Bei der Rückgabe von Strings aus Entry und Filedialoge habe ich folgendes festgestellt:
Es sind Bytestrings, solange die Filenamen oder Tex im Entry ohne Umlaute sind, sonst sind es Unicode-Strings. Vermutlich ist das Verhalten so "richtig"?
Beim umgekehrten Weg, Ausgabe mit insert() in Widgets wie Entry oder Text, habe bisher noch keine Unicode-Errors gesehen, obwohl doch zB Print schnell einen Unicode-Error wirft. Hm, das Verhalten von Tkinter bleibt hier etwas unklar. Es scheint mir ein Latin-1-Default zu geben für Bytestrings mit darin enthaltenen Zeichen > 127.
Zur Erzeugung von Unicode-Strings gibt es zB die folgenden 2 Methoden:
unicode("String", "encode") u"String"
Im ersten Fall kann man einen Encoder angeben, aber nach welchem System wird eigentlich bei u"" encodet? Hier muss doch ein Default wirken?
unicode("Götter", "latin-1")
u'G\x94tter'
unicode("Götter", "cp850")
u'G\xf6tter'
a=u"Götter" a
u'G\x94tter'
Klaus Meyer wrote:
Es sind Bytestrings, solange die Filenamen oder Tex im Entry ohne Umlaute sind, sonst sind es Unicode-Strings. Vermutlich ist das Verhalten so "richtig"?
Es ist zumindest Absicht: Hätte Python 2.0 stets und immer Unicode-Objekte aus Tcl zurück gegeben, wäre zuhauf Tkinter-Code kaputt gegangen.
Deshalb gibt es die Regel: Wenn das Ergebnis ASCII ist, wird ein Bytestring zurück gegeben. Ansonsten, wenn das Ergebnis ein "korrekter" nicht-ASCII-String ist (also inten in Tcl UTF-8-kodiert), wird ein Unicode-String zurückgegeben. Ansonsten (nicht-ASCII nicht-UTF-8) wird ein Bytestring zurück gegeben.
Weil Python 2.0 das so gemacht hat, muss es aus Rückwärtskompatibilität so bleiben. Allerdings wird Python 2.3 vermutlich öfter Unicode zurückgeben, nämlich immer, wenn Tcl einen richtigen String zurückgibt (und nicht lediglich ein Objekt, das eine Stringrepräsentation hat). Richtige Strings werden in Tcl 8.4 allerdings selten verwendet.
Beim umgekehrten Weg, Ausgabe mit insert() in Widgets wie Entry oder Text, habe bisher noch keine Unicode-Errors gesehen, obwohl doch zB Print schnell einen Unicode-Error wirft. Hm, das Verhalten von Tkinter bleibt hier etwas unklar. Es scheint mir ein Latin-1-Default zu geben für Bytestrings mit darin enthaltenen Zeichen > 127.
Tkinter gibt Byte-Strings als Byte-String und Unicode-Strings als Unicode-Strings an Tcl weiter. Tcl seinerseits interpretiert Byte-Strings in Abhängigkeit von der Tcl-Version, das ist auch bei Tcl undokumentiert. Es geht ungefähr so: Wenn der String aussieht wie UTF-8, ist es UTF-8, ansonsten ist es die Plattform-Kodierung ("encoding system"). Das ist fatal, wenn man Unicode-Strings und nicht-ASCII-Bytestrings in einem Entry-Feld mischt: dann erhält man einen String mit gemischter Kodierung.
Dieses Problem vermeidet man am besten, indem man immer Unicode-Strings, oder höchstens ASCII-Byte-Strings an Tcl übergibt.
Zur Erzeugung von Unicode-Strings gibt es zB die folgenden 2 Methoden:
unicode("String", "encode") u"String"
Im ersten Fall kann man einen Encoder angeben
Was man hier angibt ist ein *Dekoder*.
decode: bytestring->unicodestring encode: unicodestring->bytestring
aber nach welchem System wird eigentlich bei u"" encodet? Hier muss doch ein Default wirken?
Gar nicht. unicode(u) ist idempotent (wie auch str(s), int(i) usw.) unicode(u, "codec") ist falsch.
Deshalb kann man bei Tkinter-String-Ergebnissen immer
r = unicode(r)
schreiben: Ist es ein Byte-String, so ist er ASCII-kodiert, und unicode(r) konvertiert ihn korrekt (sofern das system default encoding nicht geändert wurde); ist es ein Unicode-String, so macht unicode(r) gar nichts.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Irgendwie fehlt mir der rote Faden. Gibt es ein empfehlenswerte Einführung?
Vorsicht Eigenwerbung:
http://p-nand-q.com/e/unicode-faq-de.html
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Gerson,
danke, die habe ich gestern Nacht noch mit Google entdeckt (obwohl relativ weit hinten im Suchergebnis, wuste ja nicht, das es schon eine faq gibt :-) .
Kleine Anmerkung:
Dieser Satz:
Was sind Encodings? Das Encoding ist eine Vorschrift, wie ich die Zahlen als Bytes repräsentiere.
Hier muss es doch sicher Zeichen heißen, und nicht Zahlen?
Und hier:
Leider hat auch die Win32-Console so seine Probleme mit Sonderzeichen.
ihre Probleme, nicht seine ;-)
Aber danke für Deine FAQ, schon eine deutliche Hilfe (soweit ich das bisher verstanden habe).
Was sind Encodings? Das Encoding ist eine Vorschrift, wie ich die Zahlen als Bytes repräsentiere.
Hier muss es doch sicher Zeichen heißen, und nicht Zahlen?
Meiner Meinung nach nicht unbedingt. Ein Buchstabe wird duch eine Zahl repräsentiert, die im Speicher aber auf unterschiedliche Arten dargestellt wird. Das Zeichen mit dem Unicodewert 12345 (was auch immer das ist) hat in utf-8 eine andere Byte Darstellung als in utf-16. Wobei sich an dem Wert 12345 nichts ändert.
Gruß, Achim
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Klaus,
Was sind Encodings? Das Encoding ist eine Vorschrift, wie ich die Zahlen als Bytes repräsentiere.
Hier muss es doch sicher Zeichen heißen, und nicht Zahlen?
Wie ich die Zeichen als Zahlen repräsentiere, wird vom Unicode-Konsortium bestimmt: Du malst komische Kringel auf Papier, sprichst es <gräßlicher Gurgellaut> aus; und überzeugst eine Gruppe Wichtiger Personen (TM) in irgendeinem Hinterzimmer, dafür eine eigene Zahl zu vergeben (wenn man so darüber nachdenkt: Wäre 'ne prima Aktionskunstaktion).
Wie du diese Zahl als Bytes repräsentierst, ist dann das Encoding.
Ich gebe aber zu, daß ich diese Unterscheidung nicht wirklich stringent durchgehalten habe ;)
Ciao, Gerson
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo,
Danke für alle Antworten und Links!
Hier noch zum Abschluss ein kleiner Effekt:
Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32
u"abc\xe4".encode("latin-1")
'abc\xe4'
"abc\xe4"
'abc\xe4'
print "abc\xe4"
abcä
"abc\xe4".encode("latin-1")
Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128)
Warum ASCII-Decoding error, ich habe doch latin-1 angegeben? Ich hätte erwartet, das der String unverändert rauskommt.
Klaus Meyer km-news1@onlinehome.de writes:
"abc\xe4".encode("latin-1")
Traceback (most recent call last): File "<stdin>", line 1, in ? UnicodeError: ASCII decoding error: ordinal not in range(128)
Warum ASCII-Decoding error, ich habe doch latin-1 angegeben?
encode: Eingabe ist Unicode-String, Ausgabe Byte-String decode: Eingabe ist Byte-String, Ausgabe Unicode-String
Aufgrund einer m.E. unglücklichen Verallgemeinerung kann man auch für Byte-Strings encode aufrufen. Die Semantik von
B.encode(C)
ist
unicode(B).encode(C)
(damit hat man wieder die normale .encode-Semantik); dies wiederum bedeutet
unicode(B, sys.getdefaultencoding()).encode(C)
Es ist die Konvertierung in Unicode die den Fehler liefert (deshalb auch "ASCII *decoding* error", obwohl Du .encode rufst.
Ciao, Martin
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo,
ein paar Gedanken zur Beziehung zwischen Bytes und Zeichen ...
Klaus Meyer wrote:
Was sind Encodings? Das Encoding ist eine Vorschrift, wie ich die Zahlen als Bytes repräsentiere.
Hier muss es doch sicher Zeichen heißen, und nicht Zahlen?
In diesem Kontext sind mit "Zahlen" wohl die Zahlencodes von Unicode gemeint. Unicode ordnet jedem in Unicode (genauer: der jeweiligen Unicode- Version) bekannten Zeichen eine bestimmte Zahl zu.
Meiner Meinung nach ist es am sichersten, Python-Strings einfach nur als Daten (Byte-Folgen) anzusehen. Leider versteht man unter einem String traditionell eher eine Folge speziell von Zeichen, nicht einfach von Bytes.
Strings im Sinne von Bytefolgen hat man z. B. hier:
bild_datei = open('mypic.jpg', 'rb') bild = bild_datei.read() bild_datei.close()
bild enthält nun eine Bytefolge, die das Bild repräsentiert; der größte Teil davon ist aber nicht sinnvoll als lesbares Zeichen zu interpretieren.
Kaum anders ist es hierbei:
text_datei = open('python_tipps.txt') text = text_datei.read() text_datei.close()
Bis auf die Umwandlung von Zeilenende-Codes des Betriebssystems in das Byte 0x0a wird hier auch einfach nur eine Bytefolge gelesen. Der Variablen- name text gibt zwar einen Hinweis auf die Verwendung dieser Daten, aber es handelt sich, aus Sicht von Python, dennoch nicht um Zeichen. (Ok, das ist eine stolze Behauptung, aber ich lasse es mal so stehen ;-) ).
Um zu wissen, welche Zeichen in der Datei stehen (genauer gesagt: welche Zeichen diese Bytefolge repräsentiert), muss man das Encoding der Bytefolge kennen. Das Encoding gibt an, wie die Bytefolge in eine Zeichenfolge umzuwandeln ist bzw. umgekehrt. Diese Umwandlung ist möglich mit der Funktion unicode:
unicode_text = unicode(text, encoding) # encoding ist bspw. 'latin1'
In unicode_text steht nun eine Folge von Zeichen. Dafür ist die Bytefolge, die interne Repräsentation der Zeichen, nicht mehr bekannt (bzw. von der Python-Implementierung abhängig).
Zusammenfassung: "Normale" Python-Strings sind zunächst einmal nur Bytefolgen. Ob ein String Zeichen repräsentiert bzw. welche, hängt von der Interpretation des Strings aus Sicht der Anwendung ab. Andererseits sind Unicode-Strings Zeichenfolgen und nicht von einer bestimmten Interpre- tation abhängig.
Stefan
_______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (11)
-
"Martin v. Löwis" -
Achim Domma (ProCoders) -
Andreas Kaiser -
Gerhard Haering -
Gerhard Häring
-
Gerson.Kurz＠t-online.de -
Klaus Meyer -
martin＠v.loewis.de
-
Stefan Schwarzer -
Uwe Schmitt -
Uwe Schmitt