Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

pyqt4: text ist utf-8, wird aber nicht richtig dargestellt

478 views
Skip to first unread message

Wolfgang Meiners

unread,
Jun 12, 2013, 9:27:14 AM6/12/13
to
Hallo Gruppe,

also: ich habe Python 3.3.0 unter OSX 10.6.8. Ich habe PyQt aus
PyQt-mac-gpl-4.9.4.tar.gz installiert.


Im Terminal liefert
locale:
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"

In der ./MacOSX/environment.plist ist der key LC_ALL mit dem Wert
de_DE.UTF-8 eingetragen. Ich lese Werte aus einer Datei, für die
file -I
text/plain; charset=utf-8
liefert. Trotzdem gibt pyqt in einem TreeView den folgenden String aus:
"Automatisch eingef�gter Text"

Ich möchte also einen String, von dem ich weiß, dass er
utf-8-formatierten Text enthält, darstellen. Aber das funktioniert nicht.
(Übrigens nur unter OSX nicht. Kopiere ich das Programm auf Ubuntu, ist
die Ausgabe korrekt)

Kennt jemand dieses Problem?
Wie mache ich es richtig?


Vielen Dank für alle Tipps
Wolfgang

Thomas Guettler

unread,
Jun 12, 2013, 11:04:49 AM6/12/13
to pyth...@python.org
Es fehlt der Quelltext wie du die Zeichenkette einliest. Vermutlich
ist das eine Bytefolge, und nicht ein Unicode-Objekt.

versuche das:

import codecs
fd=codecs.open(myfile, 'rt', 'utf8')
....

oder das Wandeln der Zeichenkette:
mystr.decode('utf8') # de-kodieren: also von byte-string zu unicode objekt.



--
Thomas Guettler http://www.thomas-guettler.de/

Wolfgang Meiners

unread,
Jun 13, 2013, 6:59:22 AM6/13/13
to

Danke erstmal für die Rückmeldung!

Am 12.06.13 17:04, schrieb Thomas Guettler:
> Es fehlt der Quelltext wie du die Zeichenkette einliest. Vermutlich
> ist das eine Bytefolge, und nicht ein Unicode-Objekt.
>

Der fehlt aus gutem Grund, die Situation ist nämlich etwas komplizierter
als ich sie hier dargestellt habe.
Aus einer Datei werden die Daten gelesen, mittels sqlalchemy in eine
Postgresql Datenbank übertragen, dort mittels sqlalchemy (von einem
weiteren Programm) ausgelesen und dargestellt. In der Datenbank steht
uft8, lasse ich sqlalchemy in eine Datei drucken, steht da utf8 - nur
beim Übergang zu pyqt kriege ich Darstellungsfehler.

> versuche das:
>
> import codecs
> fd=codecs.open(myfile, 'rt', 'utf8')
> ....
>
> oder das Wandeln der Zeichenkette:
> mystr.decode('utf8') # de-kodieren: also von byte-string zu unicode
objekt.
>

Was mich irritiert: Meine Strings haben kein attribute 'decode'. Jeder
Aufruf von feld.decode('utf-8') führt zu einer entsprechenden
Fehlermeldung. Das wird an python3 liegen. Um zu sehen, was eigentlich
in dem Feld steht, habe ich ein spezielles durch

str(bytes(item.bemerkung,'utf-8'))

ersetzt und bekomme als Ausgabe

b'Automatisch eingef\xc3\xbcgter Text'

Wie kann ich daraus also den String
'Automatisch eingefüger Text'
machen?

Danke für alle Tipps
Wolfgang


Andreas Perstinger

unread,
Jun 13, 2013, 8:22:39 AM6/13/13
to
On 13.06.2013 12:59, Wolfgang Meiners wrote:
> Was mich irritiert: Meine Strings haben kein attribute 'decode'. Jeder
> Aufruf von feld.decode('utf-8') führt zu einer entsprechenden
> Fehlermeldung. Das wird an python3 liegen.

Da Python3 zwischen Daten (Bytes) und Text (Strings) unterscheidet,
macht "decode" für String-Objekte keinen Sinn. "decode" ist nur
erforderlich, wenn Du Bytes in Strings umwandelst.
Siehe
http://docs.python.org/3.3/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit

> Um zu sehen, was eigentlich
> in dem Feld steht, habe ich ein spezielles durch
>
> str(bytes(item.bemerkung,'utf-8'))
>
> ersetzt und bekomme als Ausgabe
>
> b'Automatisch eingef\xc3\xbcgter Text'
>
> Wie kann ich daraus also den String
> 'Automatisch eingefüger Text'
> machen?

So wie es ausschaut, ist "item.bemerkung" ein UTF8-String:
>>> text = 'Automatisch eingefügter Text'
>>> bytes(text, 'utf-8')
b'Automatisch eingef\xc3\xbcgter Text'
>>> b'Automatisch eingef\xc3\xbcgter Text'.decode('utf-8')
'Automatisch eingefügter Text'

Dein Problem scheint also woanders zu liegen. Aber ohne Ausschnitte aus
Deinem Code wird Dir keiner wirklich helfen können.

Tschau, Andreas

Dr. Stefan Pfeiffer

unread,
Jun 13, 2013, 9:01:19 AM6/13/13
to Andreas Perstinger, pyth...@python.org
Very wild guess:
Steht in der Datenbank wirklich der korrekte String mit Umlaut? Ich kann mich gerade bei PostGreSQL erinnern, dass mir im phppgadmin korrekte Umlaute anzeigt wurden obwohl die in der DB schon kaputt waren. Da hat der Browser nämlich „intelligent“ korrigiert, und den wahren Fehler vor mir verschleiert. Habe damals ewig gesucht. Vielleicht dort noch mal sichergehen, dass du den Fehler wirklich beim Auslesen/Darstellen suchst, und nicht schon beim Reinschreiben in die DB.

Viel Erfolg,
Stefan



_______________________________________________
python-de maillist  -  pyth...@python.org
http://mail.python.org/mailman/listinfo/python-de

Wolfgang Meiners

unread,
Jun 13, 2013, 12:07:28 PM6/13/13
to
Am 13.06.13 15:01, schrieb Dr. Stefan Pfeiffer:
> Very wild guess:
> Steht in der Datenbank wirklich der korrekte String mit Umlaut? Ich kann
> mich gerade bei PostGreSQL erinnern, dass mir im phppgadmin korrekte
> Umlaute anzeigt wurden obwohl die in der DB schon kaputt waren. Da hat der
> Browser n�mlich �intelligent� korrigiert, und den wahren Fehler vor mir
> verschleiert. Habe damals ewig gesucht. Vielleicht dort noch mal
> sichergehen, dass du den Fehler wirklich beim Auslesen/Darstellen suchst,
> und nicht schon beim Reinschreiben in die DB.
>
> Viel Erfolg,
> Stefan
>

Hallo

Danke f�r den Input. Aber in der Datenbank stehen tats�chlich
utf8-Daten. Ich habe sogar nach Vorschlag von sqlalchemy.org die
postgesql.conf so angepasst, dass client_encoding passt:

(sqlalchemy nutzt Psycopg2)
Psycopg2 here will encode/decode string values based on the current
�client encoding� setting; by default this is the value in the
postgresql.conf file, which often defaults to SQL_ASCII. Typically, this
can be changed to utf-8, as a more useful default:
#client_encoding = sql_ascii # actually, defaults to database
# encoding
client_encoding = utf8

Es scheint aber viel verr�ckter zu sein: Auf der Suche nach einem
Minimalbeispiel habe ich mit Designer eine schlichte Dialogbox
aufgemacht, die nur ein Label mit dem Text '�tsch' enth�lt und diese mit
einem simplen Programm dargestellt. Das Ergebnis: _kein_
Darstellungsfehler. Dann habe ich die Dateien, die zu einer fehlerhaften
Darstellung f�hren, in diesen Pfad kopiert um mich schrittweise zu der
Stelle hochzuarbeiten, an der Fehler auftreten. Ab dieser Kopieraktion
habe ich auch in dem Minimalbeispiel einen Darstellungsfehler.

Ein weiteres Programm liefert ab sofort auch Darstellungsfehler. Es muss
irgendwie mit den Eigenschaften des Ordners zusammenh�ngen, in dem die
Datei steht. Ich habe aber keine Ahnung, wie.

Gr��e
Wolfgang

Wer sich das Programm ansehen will:

######################################################
#! python3
# -*- coding: utf-8 -*-

'''
Created on 12.06.2013

@author: wolfgang
'''


from PyQt4 import QtCore, QtGui
import minimal_ui as minimal_ui
import sys

class MyDialog(QtGui.QDialog, minimal_ui.Ui_Dialog):
def __init__(self, parent=None):
super(MyDialog, self).__init__(parent)
self.setupUi(self)
#self.textBrowser.append('�tsch')

app = QtGui.QApplication(sys.argv)
window = MyDialog()
window.show()
sys.exit(app.exec_())
######################################################

mit der minimal_ui:
#################################################################
# -*- coding: utf-8 -*-

# Form implementation generated from reading ui file 'minimal.ui'
#
# Created: Thu Jun 13 17:26:41 2013
# by: PyQt4 UI code generator 4.9.4
#
# WARNING! All changes made in this file will be lost!

from PyQt4 import QtCore, QtGui

try:
_fromUtf8 = QtCore.QString.fromUtf8
except AttributeError:
_fromUtf8 = lambda s: s

class Ui_Dialog(object):
def setupUi(self, Dialog):
Dialog.setObjectName(_fromUtf8("Dialog"))
Dialog.resize(400, 300)
self.label = QtGui.QLabel(Dialog)
self.label.setGeometry(QtCore.QRect(100, 110, 81, 41))
self.label.setObjectName(_fromUtf8("label"))

self.retranslateUi(Dialog)
QtCore.QMetaObject.connectSlotsByName(Dialog)

def retranslateUi(self, Dialog):
Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog",
"Dialog", None, QtGui.QApplication.UnicodeUTF8))
self.label.setText(QtGui.QApplication.translate("Dialog",
"�tsch", None, QtGui.QApplication.UnicodeUTF8))

#################################################################

Die Darstellung ist fehlerhaft (nachdem einmal die fehlerhafte Datei in
diesem Pfad war)

Vielleicht hat ja noch jemand eine Idee.
Wolfgang

Thomas Guettler

unread,
Jun 14, 2013, 2:41:00 AM6/14/13
to pyth...@python.org
Ich denke, Andreas hat vermutlich das Problem erkannt.

Prüfe doch mal wie lang die Zeichenkette von einem Umlaut ist: 'ä'.

Wenn es Unicode ist, dann ist die Zeichenkette ein Zeichen lang. Wenn
es utf8 ist zwei.

Gruß,
Thomas
> _______________________________________________
> python-de maillist - pyth...@python.org
> http://mail.python.org/mailman/listinfo/python-de


Wolfgang Meiners

unread,
Jun 14, 2013, 5:25:25 AM6/14/13
to
Ich komme der Lösung näher, habe sie aber noch nicht gefunden.

Für alle, die vielleicht noch eine Idee haben und mir diese mitteilen
wollen, die beiden "Beweisfotos":

https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/Foto1.png
https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/Foto2.png

Sie zeigen das Problem, mit dem ich zu kämpfen habe: Bei Foto1.png habe
ich das Programm aus dem Terminal gestartet, bei Foto2.png aus Eclipse
heraus aufgerufen. Das gleiche Programm, einmal mit und einmal ohne
Darstellungsfehler. Ich gehe mittlerweile davon aus, dass python und
pyqt und qt überhaupt gar keine Probleme mit utf8 haben, sondern dass es
am Font liegt und dieser das erforderliche Zeichen nicht kennt. Warum
die beiden Instanzen des gleichen Programms unterschiedliche Fonts
benutzen sollten, ist mir allerdings nicht klar.

Vielleicht hat ja noch jemand eine Idee. Ich bin für jeden Tipp dankbar.
Grüße
Wolfgang

Massa, Harald Armin

unread,
Jun 14, 2013, 5:34:00 AM6/14/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste
Wolfgang,

lass Dir mal

print sys.getdefaultencoding()

in ein Logfile schreiben, wenn Du aus Console oder Eclipse startest...

bester Gruß

Harald
> _______________________________________________
> python-de maillist - pyth...@python.org
> http://mail.python.org/mailman/listinfo/python-de



--

GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607

Amtsgericht Stuttgart, HRB 734971

Wolfgang Meiners

unread,
Jun 14, 2013, 5:45:02 AM6/14/13
to
Am 14.06.13 11:34, schrieb Massa, Harald Armin:
> Wolfgang,
>
> lass Dir mal
>
> print sys.getdefaultencoding()
>
> in ein Logfile schreiben, wenn Du aus Console oder Eclipse startest...
>
> bester Gruß
>
> Harald
>

gerade ausprobiert, liefert in beiden Fällen

utf-8

Es ist doch irgendwie merkwürdig.
Wolfgang

Wolfgang Meiners

unread,
Jun 14, 2013, 5:53:27 AM6/14/13
to
Am 14.06.13 11:45, schrieb Wolfgang Meiners:
Siehe auch

https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/Foto3.png

Wolfgang

Dinu Gherman

unread,
Jun 14, 2013, 6:08:43 AM6/14/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste
Wolfgang Meiners:

> Vielleicht hat ja noch jemand eine Idee. Ich bin für jeden Tipp dankbar.

Bist Du absolut sicher, dass in beiden Fällen dieselbe Font-Datei benutzt wird? Und/oder kannst Du Deinen Test mit Zeichen wiederholen, die keine Buchstaben mit diakritischen Zeichen sind? Nur so eine Idee...

Auf Macs gibt es auch erhebliche Unterschiede zwischen installierten 0815-Fonts wie Helvetica und dem, was Adobe dafür hält, auch wenn das mehr auf Glyphen-Ebene ist (und Du keinen Mac nutzt, ich weiß).

Gruß,

Dinu

Wolfgang Meiners

unread,
Jun 14, 2013, 7:23:06 AM6/14/13
to
Am 14.06.13 12:08, schrieb Dinu Gherman:
> Wolfgang Meiners:
>
>> Vielleicht hat ja noch jemand eine Idee. Ich bin für jeden Tipp dankbar.
>
> Bist Du absolut sicher, dass in beiden Fällen dieselbe Font-Datei benutzt wird? Und/oder kannst Du Deinen Test mit Zeichen wiederholen, die keine Buchstaben mit diakritischen Zeichen sind? Nur so eine Idee...
>

Nein, überhaupt nicht. Das Programm habe ich zwischen den beiden
Aufrufen nicht geändert und in der *.ui-Datei habe ich schon einen Font
festgelegt, der dann von beiden Aufrufen aus eigentlich auch genommen
werden sollte.

Wenn nun ein anderer Font genommen wird - wie finde ich das heraus?


> Auf Macs gibt es auch erhebliche Unterschiede zwischen installierten 0815-Fonts wie Helvetica und dem, was Adobe dafür hält, auch wenn das mehr auf Glyphen-Ebene ist (und Du keinen Mac nutzt, ich weiß).
>

Ich nutze einen Mac!

> Gruß,
>
> Dinu
>


Ich füge noch mal einen Link auf das aktuelle Testprogramm hier ein. Ich
glaube aber nicht, dass das einen Lösungshinweis enthält:

https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/minimal.zip

In der zip-Datei sind drei Dateien enthalten:
Archive: /Users/wolfgang/Dropbox/Public/Beweisfotos/minimal.zip
Length Date Time Name
-------- ---- ---- ----
1028 06-14-13 11:46 minimal.ui
1383 06-14-13 11:46 minimal_ui.py
688 06-14-13 11:49 minimalbeispiel.py
-------- -------
3099 3 files

Grüße
Wolfgang

Dinu Gherman

unread,
Jun 14, 2013, 7:59:47 AM6/14/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste
Wolfgang Meiners:

> Nein, überhaupt nicht. Das Programm habe ich zwischen den beiden
> Aufrufen nicht geändert und in der *.ui-Datei habe ich schon einen Font
> festgelegt, der dann von beiden Aufrufen aus eigentlich auch genommen
> werden sollte.
>
> Wenn nun ein anderer Font genommen wird - wie finde ich das heraus?

Gute Frage, kann ich aber für Qt nicht beantworten. Ich hatte meine
Probleme damals mit PIL und Bitmaps bzw. PDF.

> Ich nutze einen Mac!

Ah. Sorry, Thread-Verwechslung...

> Ich füge noch mal einen Link auf das aktuelle Testprogramm hier ein. Ich
> glaube aber nicht, dass das einen Lösungshinweis enthält:
>
> https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/minimal.zip

Ich versuche heut noch mal reinzuschauen...

Gruß,

Dinu

Wolfgang Meiners

unread,
Jun 14, 2013, 8:54:23 AM6/14/13
to
Am 14.06.13 13:59, schrieb Dinu Gherman:
>> https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/minimal.zip
>
> Ich versuche heut noch mal reinzuschauen...

danke.

>
> Gruß,
>
> Dinu
>

kann es sein, dass das Problem etwas mit utf-8 und utf-8-mac zu tun hat?
In der minimal_ui.py steht folgende Funktion:

def retranslateUi(self, Dialog):
Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog",\
"Dialog", None, QtGui.QApplication.UnicodeUTF8))
self.label.setText(QtGui.QApplication.translate("Dialog",\
"Ätsch", None, QtGui.QApplication.UnicodeUTF8))

die ich einfach mal ergänzt habe zu

def retranslateUi(self, Dialog):
Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog",\
"Dialog", None, QtGui.QApplication.UnicodeUTF8))
name='Ätsch'
self.label.setText(QtGui.QApplication.translate("Dialog", name,\
None, QtGui.QApplication.UnicodeUTF8))
print(bytes(name,'utf-8'))
print(bytes(self.label.text(),'utf-8'))


Das führt -mit Eclipse gestartet- zur Ausgabe
b'\xc3\x84tsch'
b'\xc3\x84tsch'

und im Terminal gestartet zur Ausgabe
b'\xc3\x84tsch'
b'\xef\xbf\xbdtsch'

Aber wo steckt der Fehler?

Wolfgang

Walter Dörwald

unread,
Jun 14, 2013, 9:30:22 AM6/14/13
to pyth...@python.org
On 14.06.13 14:54, Wolfgang Meiners wrote:
> Am 14.06.13 13:59, schrieb Dinu Gherman:
>>> https://dl.dropboxusercontent.com/u/5015890/Beweisfotos/minimal.zip
>>
>> Ich versuche heut noch mal reinzuschauen...
>
> kann es sein, dass das Problem etwas mit utf-8 und utf-8-mac zu tun hat?
> In der minimal_ui.py steht folgende Funktion:
>
> def retranslateUi(self, Dialog):
> Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog",\
> "Dialog", None, QtGui.QApplication.UnicodeUTF8))
> self.label.setText(QtGui.QApplication.translate("Dialog",\
> "Ätsch", None, QtGui.QApplication.UnicodeUTF8))
>
> die ich einfach mal ergänzt habe zu
>
> def retranslateUi(self, Dialog):
> Dialog.setWindowTitle(QtGui.QApplication.translate("Dialog",\
> "Dialog", None, QtGui.QApplication.UnicodeUTF8))
> name='Ätsch'
> self.label.setText(QtGui.QApplication.translate("Dialog", name,\
> None, QtGui.QApplication.UnicodeUTF8))
> print(bytes(name,'utf-8'))
> print(bytes(self.label.text(),'utf-8'))
>
>
> Das führt -mit Eclipse gestartet- zur Ausgabe
> b'\xc3\x84tsch'
> b'\xc3\x84tsch'
>
> und im Terminal gestartet zur Ausgabe
> b'\xc3\x84tsch'
> b'\xef\xbf\xbdtsch'
>
> Aber wo steckt der Fehler?

Hmm, b'\xef\xbf\xbd' ist ein "REPLACEMENT CHARACTER" in UTF-8. Evtl.
gibt's Probleme mit dem Encoding des Python-Skripts/Text-Editors?

Schreib doch mal in Deinem Sourecode

name='\xc4tsch'

statt

name='Ätsch'

Servus,
Walter

Wolfgang Meiners

unread,
Jun 14, 2013, 10:34:16 AM6/14/13
to
Am 14.06.13 15:30, schrieb Walter Dörwald:
gerade gemacht. Das ändert nichts. Darstellungsfehler bei Aufruf im
Terminal, korrekte Darstellung bei Aufruf in Eclipse. Also wenn ich das
richtig verstehe: Der Buchstabe 'Ä' wird von _pyqt_ nicht korrekt
erkannt und deshalb durch b'\xef\xbf\xbd' ersetzt. Wenn das so ist,
warum erkennt pyqt das Zeichen nicht? Gibt es irgendwo eine
Konfigurationsdatei, in der vielleicht ein anderes encoding
festgeschrieben ist?

Wolfgang


Reimar Bauer

unread,
Jun 14, 2013, 12:44:32 PM6/14/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste

Also eclipse setzt das encoding um, es ist nicht das default encoding das man sonst hat.
Der thread sollte googlebar sein, evtl. Gibts auch was dazu im Wiki, hab dazu schon mal was bei pyCologne erzählt.

Gruß
Reimar

Wolfgang Meiners

unread,
Jun 15, 2013, 6:41:54 AM6/15/13
to
also ich bin ziemlich ratlos.

zunächst einmal mein momentaner Stand:

ich habe ein Minimalbeispiel, einfacher Dialog mit einem Label und einem
Textfeld, in beide schreibe ich Text mit Umlauten ('Ätsch')

das ganze wird korrekt dargestellt, wenn ich das Programm aus eclipse
heraus aufrufe.

Das ganze wird fehlerhaft dargestellt, wenn ich das Programm aus dem
Terminal aufrufe. Dabei wird aus 'Ätsch' (b'\xc3\x84tsch') ein
'�tsch' (b'\xef\xbf\xbdtsch') und das erste Zeichen ist ein Replacement
Character.

Das heißt doch, das von python3 richtig übergebene Zeichen wird von pyqt
als nicht darstellbar interpretiert und durch das Replacement Character
ersetzt. Aber nur, wenn das Programm vom Terminal aus aufgerufen wird.

Das deutet auf einen Konfigurationsfehler im Terminal hin.
locale liefert
wolfgangslaptop:~ wolfgang$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"

und es gibt in ./MacOSX/environment.plist einen Key LC_ALL mit dem Wert
de_DE.UTF-8. Das sollte eigentlich so passen.

Nun habe ich gedacht, lass doch das ganze mal unter einem anderen User
laufen und erhalte dort (gleiches locale)

#########################################################################
wolfgangslaptop:src adminloc$ python3 minimalbeispiel.py
Sat Jun 15 12:24:04 wolfgangslaptop.fritz.box Python[3948] <Error>:
kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors
as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to
the WindowServer, _CGSDefaultConnection() is NULL.
b'\xc3\x84'
utf-8
0041 0308
test: b'\xc3\x9f'
2013-06-15 12:24:05.229 Python[3948:d07] An uncaught exception was raised
2013-06-15 12:24:05.230 Python[3948:d07] Error (1002) creating CGSWindow
2013-06-15 12:24:05.232 Python[3948:d07] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason: 'Error
(1002) creating CGSWindow'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff81065784
__exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff83976f03
objc_exception_throw + 45
2 CoreFoundation 0x00007fff810655a7
+[NSException raise:format:arguments:] + 103
3 CoreFoundation 0x00007fff81065534
+[NSException raise:format:] + 148
4 AppKit 0x00007fff802ddf52
_NSCreateWindowWithOpaqueShape2 + 473
5 AppKit 0x00007fff80272691 -[NSWindow
_commonAwake] + 1214
6 AppKit 0x00007fff802901c9 -[NSWindow
_makeKeyRegardlessOfVisibility] + 96
7 AppKit 0x00007fff8029013e -[NSWindow
makeKeyAndOrderFront:] + 24
8 QtGui 0x000000010292c593
_ZN14QWidgetPrivate8show_sysEv + 1123
9 QtGui 0x00000001029ecd38
_ZN14QWidgetPrivate11show_helperEv + 408
10 QtGui 0x00000001029ed06f
_ZN7QWidget10setVisibleEb + 511
11 QtGui 0x0000000102e38737
_ZN7QDialog10setVisibleEb + 103
12 QtGui.so 0x00000001023707fc
_ZN10sipQDialog10setVisibleEb + 108
13 QtGui.so 0x0000000102386318
meth_QWidget_show + 104
14 Python 0x00000001000de02e
PyEval_EvalFrameEx + 29774
15 Python 0x00000001000df1b8
PyEval_EvalCodeEx + 2296
16 Python 0x00000001000df27f
PyEval_EvalCode + 63
17 Python 0x000000010010639b
PyRun_FileExFlags + 187
18 Python 0x00000001001066b6
PyRun_SimpleFileExFlags + 598
19 Python 0x000000010011d783 Py_Main + 3203
20 Python 0x0000000100000e0e 0x0 + 4294970894
21 Python 0x0000000100000c54 0x0 + 4294970452
)
terminate called after throwing an instance of 'NSException'
Abort trap
#########################################################################

Kann jemand diese Fehlermeldung interpretieren und mir sagen, ob ich
eher einen Fehler in der Konfiguration des Terminals suchen muss, oder
einen Fehler in pyqt?

Ich bin für jeden Tipp dankbar
Wolfgang

Reimar Bauer

unread,
Jun 15, 2013, 5:24:24 PM6/15/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste



2013/6/15 Wolfgang Meiners <Wolfgang...@web.de>

also ich bin ziemlich ratlos.

zunächst einmal mein momentaner Stand:

ich habe ein Minimalbeispiel, einfacher Dialog mit einem Label und einem
Textfeld, in beide schreibe ich Text mit Umlauten ('Ätsch')

das ganze wird korrekt dargestellt, wenn ich das Programm aus eclipse
heraus aufrufe.


Hast Du das Sonderzeichen in eclipse getippt?
Wenn Du das Programm mit vim oder was anderem als eclipse anschaust, wie wird
das Sonderzeichen dargestellt?

Gruß
Reimar
 
Wolfgang

Wolfgang Meiners

unread,
Jun 16, 2013, 8:54:00 AM6/16/13
to
Am 15.06.13 23:24, schrieb Reimar Bauer:
> 2013/6/15 Wolfgang Meiners <Wolfgang...@web.de>
>
>> also ich bin ziemlich ratlos.
>>
>> zunächst einmal mein momentaner Stand:
>>
>> ich habe ein Minimalbeispiel, einfacher Dialog mit einem Label und einem
>> Textfeld, in beide schreibe ich Text mit Umlauten ('Ätsch')
>>
>> das ganze wird korrekt dargestellt, wenn ich das Programm aus eclipse
>> heraus aufrufe.
>>
>>
> Hast Du das Sonderzeichen in eclipse getippt?
> Wenn Du das Programm mit vim oder was anderem als eclipse anschaust, wie
> wird
> das Sonderzeichen dargestellt?

Das Sonderzeichen wurde in eclipse getippt. Wenn ich vim oder cat oder
sonstwas im Terminal nehme, wird es richtig dargestellt.

Ich bin mir sicher, das Problem ist überhaupt gar kein python problem
(unter Ubuntu12.04 gibt es keine Darstellungsfehler), sondern hat mit
der Kommunikation zwischen OSX-Terminal und OSX-gui zu tun. Im Terminal
ist alles auf utf-8 eingestellt und passt auch zusammen. In der gui
dagegen nicht. Eclipse weiß aus seinen Einstellungen, dass der Text
utf-8 ist und überträgt das richtig in die gui. Wenn ich das Programm
direkt aufrufe, gibt es Darstellungsfehler. Ich habe aber keine Ahnung,
wo ich das richtig einstellen kann. Sucht man mit google, so findet man
viele Poster, die immer dann verzweifeln, wenn es um Verbindungen
zwischen Terminal und gui geht (z.B. bei ssh-Tunneln u.ä.) Und was aus
einem ssh-Tunnel kommt, kann auch eclipse nicht richtig umsetzen.
Dadurch ist mir der Darstellungsfehler zunächst aufgefallen, denn ich
lese meine utf-8-Daten aus einer Datenbank, zu der ich mich mit einem
ssh-Tunnel verbinde.

>
> Gruß
> Reimar
>


Grüße
Wolfgang

Stefan Behnel

unread,
Jun 18, 2013, 1:36:11 AM6/18/13
to Die Deutsche Python Mailingliste
Andreas Perstinger, 13.06.2013 14:22:
> On 13.06.2013 12:59, Wolfgang Meiners wrote:
>> Was mich irritiert: Meine Strings haben kein attribute 'decode'. Jeder
>> Aufruf von feld.decode('utf-8') führt zu einer entsprechenden
>> Fehlermeldung. Das wird an python3 liegen.
>
> Da Python3 zwischen Daten (Bytes) und Text (Strings) unterscheidet, macht
> "decode" für String-Objekte keinen Sinn. "decode" ist nur erforderlich,
> wenn Du Bytes in Strings umwandelst.
> Siehe
> http://docs.python.org/3.3/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit
>
>
>> Um zu sehen, was eigentlich
>> in dem Feld steht, habe ich ein spezielles durch
>>
>> str(bytes(item.bemerkung,'utf-8'))
>>
>> ersetzt und bekomme als Ausgabe
>>
>> b'Automatisch eingef\xc3\xbcgter Text'
>>
>> Wie kann ich daraus also den String
>> 'Automatisch eingefüger Text'
>> machen?
>
> So wie es ausschaut, ist "item.bemerkung" ein UTF8-String:

Ganz bestimmt nicht, sonst würde

bytes(item.bemerkung,'utf-8')

nicht funktionieren. Außerdem sagte Wolfgang bereits, dass das Objekt keine
"decode" Methode hat. Also ist es ganz sicher kein (UTF-8 kodierter)
Byte-String sondern ein bereits dekodierter Unicode-String.

Es scheint also, dass der Datenbanktreiber bereits die Dekodierung
vornimmt. Ggf. sollte Wolfgang sich hier die Konfiguration nochmal
anschauen, aber so wie es aussieht scheint dort alles zu funktionieren. Der
String verhält sich ja völlig korrekt.

Also, nächste Vermutung wäre einfach die Darstellung in Qt, vielleicht ein
falscher Font, wie bereits vermutet wurde, der das Zeichen einfach nicht
anzeigen kann. Warum auch immer.

Stefan

Wolfgang Meiners

unread,
Jun 18, 2013, 4:13:49 AM6/18/13
to
Ich habe mittlerweile einen Workaround gefunden, der auf meinem System
funktioniert, aber eigentlich quatsch ist. Wenn ich einen String strg an
pyqt übergeben will, schreibe ich

strg.encode('utf-8').decode('latin-1')

und er wird korrekt dargestellt. Wenn ich aber einen String aus pyqt
übernehme, dann ist das ein korrektee Unicodeobjekt, das ich mit
print(...) richtig ausdrucken kann. Übergebe ich diesen String wieder an
pyqt, so kriege ich Darstellungsfehler - es sei denn, ich wandle wie
oben um.

Noch mal zur Sicherheit eine Verständnisfrage: wenn
print('\xc3\x84') im Termianl zu 'Ä' führt, dann stellt das Terminal
utf-8 dar?

Vielleicht nutzt ja jemandem diese Information, um den Knoten in meinem
Hirn aufzulösen.

Wolfgang

Reimar Bauer

unread,
Jun 18, 2013, 7:46:56 AM6/18/13
to Wolfgang Meiners, Die Deutsche Python Mailingliste
Python 3.2.3 (default, Oct 19 2012, 20:10:41)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = '\xc3\x84'
>>> type(a)
<class 'str'>
>>> print(a)
Ä

2013/6/18 Wolfgang Meiners <Wolfgang...@web.de>:

Marek Kubica

unread,
Jun 18, 2013, 8:52:37 PM6/18/13
to Die Deutsche Python Mailingliste
On Tue, 18 Jun 2013 13:46:56 +0200
Reimar Bauer <rb....@gmail.com> wrote:

> Python 3.2.3 (default, Oct 19 2012, 20:10:41)
> [GCC 4.6.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a = '\xc3\x84'
> >>> type(a)
> <class 'str'>
> >>> print(a)
> Ä

Auf Python 2 funktioniert das so sogar, aber macht auf Python 3
natürlich keinen Sinn.

Ä ist Unicode-Codepoint U+00C4, wenn man das in UTF-8 dekodiert dann ist
sind das die beiden Bytes 0xc3 gefolgt von 0x84.

Wenn man aber Python 3 sagt es soll U+00C3 (Ã, LATIN CAPITAL LETTER A
WITH TILDE) und U+0084 (<control>) darstellen, dann kommt Quatsch
raus. Besser man sagt Python 3 es soll 0xc3 0x84 darstellen:

Python 3.3.2 (default, May 21 2013, 15:40:45)
[GCC 4.8.0 20130502 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = b'\xc3\x84'
>>> type(a)
<class 'bytes'>
>>> print(a.decode('utf-8'))
Ä

grüße,
Marek

Wolfgang Meiners

unread,
Jun 19, 2013, 2:56:49 PM6/19/13
to
Problem gelöst.

Ich habe gerade die neuesten Versionen von python (python3.3.2) und PyQt
(PyQt 4.10.2) installiert und danach tritt mein Darstellungsproblem
nicht mehr auf.

Leider weiß ich nun nicht, ob es eher an python3.3.0 gelegen hat, oder
an PyQt 4.9.6. Ist jetzt aber auch nicht mehr so wichtig.

Danke für alle Tipps. Das Thema encoding in Python sorgt ja doch für das
eine oder andere Fragezeichen und gerade bei python3 gibt es noch nicht
so viele, die kompetente Hilfestellung geben können (hab ich jedenfalls
den Eindruck).

Wolfgang
0 new messages