Encoding-Problem

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Montag 29. September 2008, 09:01

Naja, in der ersten Zeile steht natürlich:

Code: Alles auswählen

# -*- coding: iso-8859-1-*-


Das hatte ich jetzt weggelassen.

Die Quelltextdatei erstellt habe ich mit MyEclipse, habe dort aber bisher noch nirgends gesehen, dass ich das Coding irgendwo einstellen kann und hab da auch noch nie was daran geändert... :S
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Montag 29. September 2008, 09:16

Nutzte auch Eclipse. Man kann ein Encoding angeben. Ich meine es steht auf UTF-8

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Montag 29. September 2008, 10:00

ah ... okay... habs gefunden ...

steht was von cp1252, also hab ich das coding in der ersten Zeile jetzt auch daraugf gesetzt. Gibt nun zumindest keinen Fehler mehr beim ß mehr.

Was allerdings bleibt sind die hyroglypen in der Datenbank, nur dass JETZT sogar 2 Zeichen pro Umlaut beansprucht werden.

:(
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Montag 29. September 2008, 10:11

meneliel hat geschrieben:2 Zeichen pro Umlaut

So macht es UTF-8 nunmal ;) Je nach unicode Zeichen wird es mit bis zu 4 Zeichen gespeichert, siehe: http://de.wikipedia.org/wiki/Utf8

von [wiki]Unicode#UmgangMitDaten[/wiki]:
Der beste Weg, mit Daten umzugehen, ist der folgende:

* möglichst früh die externen Daten in Unicode wandeln
* intern alle Daten in Unicode belassen
* erst bei der Ausgabe von Daten von Unicode in das Ziel-Encoding wandeln

In deinem Fall heißt das die csv Daten in unicode wandeln und der Datenbank als UTF-8 übergeben.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Montag 29. September 2008, 10:34

auch das probiert ....
also py-Datei oben cp1252 angegeben.
csv-Datei als iso-8859-1 geöffnet
in unicode gewandelt, danach in utf-8 ...

Wann und wie steht weiter oben in dem Thread.

nun seh* ich 4 Zeichen je Umlaut, aber immer noch keine Umlaute :(


* (im SQL-Developer und in ArcGIS, welches die Daten später verarbeitet.)
BlackJack

Beitragvon BlackJack » Montag 29. September 2008, 11:27

Hast Du nur die Kommentarzeile geändert? Passt der Kommentar auch zur tatsächlich verwendeten Kodierung in der Quelltextdatei? Was Du bisher über das Testprogramm verraten hast, spricht eher dafür, das die Quelltextdatei UTF-8 kodiert ist.

Welche Kodierung wird in der CSV-Datei verwendet? Und welche Kodierung erwartet die Datenbank?

Fragen über Fragen und ich habe den Eindruck du probierst nur herum und hast den Zusammenhang zwischen Bytes, Kodierungen und Zeichen noch nicht ganz verstanden.
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Montag 29. September 2008, 12:23

Hab das Zeugs alles gelesen.

Die Kommentarzeile hab ich nun geändert, weil ich im MyEclipse gesucht habe, welches Encoding verwendet wird. Hab bisschen gesucht und an 2 STellen stand cp1252. Da ist damit meine Py-Files erstelle, nehm ich an, dass das dann auch das richtige Encoding für die Kommetarzeile ist.
Seit dem komtm für den Test-String, der direkt im Code steht, auch keine Fehlermeldung mehr für das ß.

Das Coding für die Datenbank hat mein DBA mir gesagt, war sehr kryptisch und der Leonidas hat mir das freundlicher Weise in cp1252 übersetzt :)

Das Coding der csv ... nun ... k.A. wie ich das rausbekomme. Excel sagt mir ist ANSI und eine liebe weiterer Quelle meinte auch, ist iso-8859-irgendwas.

Anhand weiterer lieber Tipps hier und dem lesen des Wikis, bin ich dann darauf gekommen, wie ich das jetzt mache.

Nur komm ich absolut nicht weiter :(

Wenn ich IRGENDWAS utf-8 setze wird alles nur noch kryptischer, ich wüsste nicht, wo irgendwas utf-8 kodiert her kommen soll.

Verwende nun daher auch wieder cp1252 für die Py-Datei, lese die csv als iso ein, decode das in unicode, wandel das in cp1252 um und schreibe in die DB .. und hab nun pro Umlaut ein "Sonderzeichen".

Irgendwo stimmt da nun was noch nicht, ich weiß nur nicht an welcher Stelle. Ich sitze da jetzt seit Donnerstag dran und komm kaum weiter, nur dass ich inzwischen ein bisschen mehr Plan von dem Coding Zeugs habe, wenn auch noch nicht vollständig durchgestiegen bin.
Zuletzt geändert von meneliel am Dienstag 30. September 2008, 13:03, insgesamt 1-mal geändert.
BlackJack

Beitragvon BlackJack » Montag 29. September 2008, 13:41

Also lass uns doch einfach nochmal von vorne Anfangen, bzw. von Hinten. Der Weg ist ja `CSV-Datei → Programm → Datenbank` und bei jedem '→' müsste umkodiert werden, bzw. beim ersten Pfeil in Unicode und beim zweiten dann wieder in Bytes.

Nimm mal ``test = u'\xe4'``, das ist völlig sicher ein 'ä' als Unicode-Objekt und versuche das so in die Datenbank zu bekommen, dass es in ArcGIS auch als 'ä' erscheint. Oder alternativ frage mal ein Datum mit einem 'ä' aus der Datenbank ab und schau nach wie das kodiert ist, also welchen Bytewert die DB dafür liefert.

Als zweiten Schritt suchst Du Dir in der CSV-Datei ein 'ä' und schaust mal, wie die Zeichenkette, also eigentlich Bytefolge als `repr()` aussieht. Am besten mal zeigen, dann wissen wir welchen Bytewert oder vielleicht auch welche Byte*werte* in der CSV-Datei stehen.
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Dienstag 30. September 2008, 11:18

Hallo BlackJack,

Ich habe mal angefangen und versucht das ``test = u'\xe4'`` in die Datenbank zu schreiben. Nur vorsichtshalber mal der Code dazu und auch noch der meiner KLasse, die das Schreiben in die DB übernimmt, wer weiß, vielleicht liegt ja auch dort das Problem:

Code: Alles auswählen

# -*- coding: cp1252 -*-
db = DB()
test = u'\xe4'
x = test.encode("cp1252")
insert_string = "INSERT INTO ADRESSEN (PfBezNr) VALUES('%s')" %x
db.selection(insert_string)


# class DB:
    '''Klasse die Verbindungsaufbau und Kommunikation mit der Datenbank übernimmt'''
    def __init__(self):
        my_dsn = cx_Oracle.makedsn("host",1234,"sid")
        self.db = cx_Oracle.connect("user","pwd",my_dsn)
        print self.db
               
    def __del__(self):
        self.db.close()
   
    def selection(self,query):
        cursor = self.db.cursor()
        cursor.execute(query)
        try:
            sel = cursor.fetchall()
            cursor.close
            return sel
        except:
            cursor.close
            self.db.commit()


(die Einrückung kommt jetzt durchs Copy/Paste)

Ergebnis:
als encode - Parameter hab ich jetzt noch mal alles durchprobiert. Weder cp1252, iso und auch utf-8 bringt alles umgedrehte Fragezeichen.´, utf-8 zwei, die anderen je eins. Also hab ich es einfach noch mal probiert OHNE mir über codings Gedanken zumachen und einfach '\xe4' reingeschrieben --> gleiches Ergebnis: ein umgedrehtes Fragezeichen, sowohl im ArcGIS, als auch im SQL-Developer


Test 2:
aus einer in der gleichen Datenbank liegenden anderen Tabelle, wo es Zeilen mit Umlauten gibt, diese über select ausgelesen und mir ohne irgendwas zu machen die ganze Zeile ausgeben lassen mittels:

Code: Alles auswählen

print repr(row)


Ergebnis: statt ä ein a, ö ein o und u ein ü und ß ein ? in der Console von MyEclipse.
-------------

die csv-Datei nehm ich mir dann nach der MIttagspause mal vor, aber mir scheint, das Problem liegt dann eher auf Datenbankseite? Zumindest einen einfachen Test-String müsste ich doch irgendwie korrekt in die DB bekommen. :(

----
BlackJack

Beitragvon BlackJack » Dienstag 30. September 2008, 11:51

Das Ergebnis von Test 2 mag ich nicht glauben, denn `repr()` sollte reine ASCII-Zeichen erzeugen und alles ausserhalb von ASCII als '\x??' Sequenz darstellen, wobei die ? für Hexadezimalziffer stehen.
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Dienstag 30. September 2008, 12:15

.. das hätte ich eben auch erwartet ...

... hab gerade auch getestet, ein einfaches Script wo nur print repr('ö') drin steht, liefert erwartetes Ergebnis: '\xf6'

ich räum mal den code auf und teste noch mal ...

Dennoch wundert es mich, dass ich den einfachen Test-String bisher nicht "korrekt" in die DB bekommen hab :(
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Dienstag 30. September 2008, 12:25

Übergabe der Daten wie so oft falsch, siehe: [wiki]Parametrisierte SQL-Queries[/wiki]

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Hyperion
Moderator
Beiträge: 7471
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Dienstag 30. September 2008, 12:40

Code: Alles auswählen

# -*- coding: cp1252 -*-
db = DB()
test = u'\xe4'
x = test.encode("cp1252")
insert_string = "INSERT INTO ADRESSEN (PfBezNr) VALUES('%s')" %x
db.selection(insert_string)

Was passiert denn hier eigentlich beim Erstellen des insert_string? Wird da nicht der Unicode-String test wieder in einen Byte-String mit der cp1252 Codierung gewandelt? Ist also das explizite Encodieren in Zeile 4 nicht überflüssig? Irgend wie hab ich das Gefühl ich hab das auch alles noch nicht zu 100% begriffen ... :-(
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Dienstag 30. September 2008, 12:45

Das meinte ich ja mit [wiki]Parametrisierte SQL-Queries[/wiki];)

Ich würde es vielleicht so machen:

Code: Alles auswählen

class DB:
    ...
    def execute(self, query, data):
        cursor = self.db.cursor()
        cursor.execute(query, data)

db = DB()
db.execute(
    query = "INSERT INTO ADRESSEN (PfBezNr) VALUES('%s')",
    data = (u'\xe4',)
)


EDIT: @meneliel: Bei cursor.close fehlen die Klammern ;) Ohne die wird nix gemacht...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

Beitragvon meneliel » Dienstag 30. September 2008, 12:59

@ jens: das funktioniert aber nicht

Hab jetzt mal einfach mit ipython probiert:

Code: Alles auswählen

In [29]: select = "INSERT INTO ADRESSEN (PfBezNr) VALUES('%s')"
In [32]: test = 'ö'
In [35]: cursor = db.cursor()
In [36]: cursor.execute(select, test)
---------------------------------------------------------------------------
DatabaseError                             Traceback (most recent call last)

C:\...\Desktop\<ipython console>

DatabaseError: ORA-01036: illegal variable name/number

In [38]: cursor.execute("INSERT INTO ADRESSEN (PfBezNr) VALUES('%s')",test)
---------------------------------------------------------------------------
DatabaseError                             Traceback (most recent call last)
C:\...\Desktop\<ipython console>
DatabaseError: ORA-01036: illegal variable name/number

In [37]: cursor.execute(select %test )
# Eintrag aber wieder mit Sonderzeichen in der Datenbank


Hab dann auch das Script aufgeräumt um aus einer anderen Tabelle ein Umlaut auszulesen (das was BlackJack nicht glauben wollte):


Code: Alles auswählen

In [18]: select = '''SELECT OBJECTID, Strasse FROM GC_TEST_GK WHERE OBJECTID = 3'''
In [21]: cursor = db.cursor()
In [23]: cursor.execute(select)
Out[23]: [<cx_Oracle.NUMBER with value None>, <cx_Oracle.STRING with value None>]
In [24]: sel = cursor.fetchall()
In [26]: sel
Out[26]: [(3, 'Am Kappele')]

# müsste eigentlich heißten "Am Käppele"

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder