Seite 1 von 1

Umgehung des Unicode-Konvertierungsfehlers

Verfasst: Dienstag 19. September 2006, 10:27
von chaka
hi,

ich bin ein rel. python-neuling und hatte das problem, unicode-strings richtig zu konvertieren. durch dieses forum habe ich zwar einige interessante ansätze gefunden, den fehler (... character > 128 ...) habe ich dennoch nicht wegbekommen (z.b. bei: 'K\xfcchenmaschine').

ich habe mich ein wenig herumgespielt und bin auf eine extrem simple lösung gestoßen:
>>> print string.replace(u'K\xfcchenmaschine', u'\ffk', ' ')
Küchenmaschine
... wobei der suchstring (hier: u'\ffk') irgend ein unicode-string sein kann :!:

Verfasst: Dienstag 19. September 2006, 10:43
von jens
Schau mal hier:
[wiki]Tipps und Tricks#Unicode[/wiki]

Verfasst: Dienstag 19. September 2006, 10:59
von chaka
danke, kannte ich bereits - hat aber nicht funktioniert.

Verfasst: Dienstag 19. September 2006, 11:15
von jens
Kennst du auch schon [wiki]Von Umlauten, Unicode und Encodings[/wiki](War nicht verlinkt)

Re: Umgehung des Unicode-Konvertierungsfehlers

Verfasst: Dienstag 19. September 2006, 11:45
von BlackJack
chaka hat geschrieben:ich bin ein rel. python-neuling und hatte das problem, unicode-strings richtig zu konvertieren. durch dieses forum habe ich zwar einige interessante ansätze gefunden, den fehler (... character > 128 ...) habe ich dennoch nicht wegbekommen (z.b. bei: 'K\xfcchenmaschine').

ich habe mich ein wenig herumgespielt und bin auf eine extrem simple lösung gestoßen:
>>> print string.replace(u'K\xfcchenmaschine', u'\ffk', ' ')
Küchenmaschine
Wofür soll dass den bitte eine Lösung sein? Das macht nichts anderes als:

Code: Alles auswählen

In [21]: print u'K\xfcchenmaschine'
Küchenmaschine
Nur das hier keine sinnlose Ersetzung durchgeführt wird. :roll:

Verfasst: Dienstag 19. September 2006, 11:46
von chaka
ja, kenne ich - habe auch brav die zeile
# -*- coding: cp1250 -*-
im script. nützte alles nichts :(

zur weiteren erklärung: ich will mittels "xlrd" xls-dateien/daten auslesen und in eine postgre-db schreiben. vielleicht macht das "miniweich"-programm intern irgend welche speziellen zeichen für umlaute, die nicht so leicht gemappt werden können ?

Verfasst: Dienstag 19. September 2006, 12:23
von jens
Wie bei [wiki]Unicode[/wiki]steht, ist der beste Weg intern in unicode zu arbeiten.
Also du mußt herrausfinden in welchem Encoding die XLS Daten gespeichert sind. Mit dem Wissen kannst du die Daten in unicode wandeln. Die Unicode Daten kannst du dann verarbeiten. Vor dem speichern in der DB wandelst du es in das Encoding der DB...

Verfasst: Dienstag 19. September 2006, 13:06
von chaka
ich denke, ich verstehe den mechanismus jetzt:

der aufruf von string.replace... wandelt offensichtlich intern den unicode aufs string format um (ich glaube mich dunkel an ein string/unicode gemeinsames buffer-objekt zu erinnern). jedenfalls funktionierts so, warum ist mir im augenblick egal ;)

Verfasst: Dienstag 19. September 2006, 16:20
von BlackJack
Was immer Du auch in dem Quelltext machst den Du hier nicht zeigst, die Ersetzung die Angeblich eine Lösung für irgend etwas ist, ändert an der übergebenen Unicode-Zeichenkette rein gar nichts:

Code: Alles auswählen

In [28]: string.replace(u'K\xfcchenmaschine', u'\ffmk', ' ')
Out[28]: u'K\xfcchenmaschine'
Diese Ersetzung hat absolut keinen Effekt, ausser ein wenig Rechenzeit zu verbrauchen und den Leser zu verwirren.

Verfasst: Mittwoch 20. September 2006, 11:30
von chaka
BlackJack hat geschrieben:Was immer Du auch in dem Quelltext machst den Du hier nicht zeigst, die Ersetzung die Angeblich eine Lösung für irgend etwas ist, ändert an der übergebenen Unicode-Zeichenkette rein gar nichts:

Code: Alles auswählen

In [28]: string.replace(u'K\xfcchenmaschine', u'\ffmk', ' ')
Out[28]: u'K\xfcchenmaschine'
Diese Ersetzung hat absolut keinen Effekt, ausser ein wenig Rechenzeit zu verbrauchen und den Leser zu verwirren.

leider muss ich dir recht geben, funktioniert offensichtlich nur bei ausgabe in der konsole :( , aber nicht für die weiterverarbeitung.

war eben zu vorschnell, ohne wirklich zu testen. sorry.

Verfasst: Mittwoch 20. September 2006, 19:04
von murph
wieso solltest du damit nicht weiterarbeiten können?
das programm, das unicode kann, kann mit dem \xfc genausoviel anfangen wie mit dem ü, das ist für das Programm gleichwertig!