[MySQL, Tk] Und nochmal: utf-8-kodierte Daten in Datenbank -> Tk::Text -> Datenbank (gelöst) (Datenbanken und Verzeichnisdienste)

[thread]17188[/thread]

[MySQL, Tk] Und nochmal: utf-8-kodierte Daten in Datenbank -> Tk::Text -> Datenbank [gelöst]

Tags: perl5 MySQL Tk utf-8 Kodierung Zeichensatz Ähnliche Threads

Leser: 15

Articles: hide open all | hide show old branches

+14 replies
pktm

2012-02-23 15:41

User since
2003-08-07
2921 Artikel
BenutzerIn

Hi!

Ich habe utf-8-kodierte Daten in einer MySQL-Datenbank. Die Tabelle ist mit dem zeichensatz utf-8 angelegt. Die Daten waren utf-8-kodiert, als sie importiert wurden und ich hatte das FileHandle auch entsprechend geöffnet.

Diese Daten zeige ich in einem Tk::Text. Dort kann man die ändern und speichern. Wenn ich die Daten aus der Datenbank hole und einfach so in das Tk::Text einfüge, werden die Sonderzeichen aber defekt angezeigt. Ich muss die vorher mittels decode() (aus Encode) in das Perl-interne Format umwandeln.

Wenn ich die Daten jetzt wieder in die Datenbank schreiben möchte, und zwar utf-8-kodiert, muss ich die dann nochmal mittels encode() umwandeln?

Grüße,
pktm

PS: hier habe ich das mit dem decode() her: http://www.perlmonks.org/?node_id=797292
http://www.intergastro-service.de (mein erstes CMS :) )
- +13 replies
- rosti
  
  2012-02-23 15:53
  
  User since
  2011-03-19
  3247 Artikel
  BenutzerIn
  
  Quote
  Wenn ich die Daten jetzt wieder in die Datenbank schreiben möchte, und zwar utf-8-kodiert, muss ich die dann nochmal mittels encode() umwandeln?
  
  Ja, wenn Du Wert auf eine vollständig zeichenorientierte Kommunikation zwischen Perl und DB Wert legst, sollten die einzufügenden Werte keine Bytesequenzen sein sondern utf-8-kodierte Strings.
  
  im DBH { mysql_enable_utf8 => 1 } damit gehts in beiden Richtungen, der DBD Layer muss das jedoch unterstützen.
  - +12 replies
  - pktm
    
    2012-02-23 15:56
    
    User since
    2003-08-07
    2921 Artikel
    BenutzerIn
    
    Ah ok, danke. Dann mache ich das so.
    mysql_enable_utf8 => 1 habe ich an, allerdings muss ich trotzdem noch decode() verwenden, damit es in Tk richtig angezeigt wird. Auf der Konsole kommt es auch ohne richtig an.
    http://www.intergastro-service.de (mein erstes CMS :) )
    - +11 replies
    - rosti
      
      2012-02-23 16:17
      
      User since
      2011-03-19
      3247 Artikel
      BenutzerIn
      
      Konsole: Heißt STDOUT. Es gilt:
      
      Alles was auf STDOUT geht oder in FileHandler, das müssen Bytesequenzen sein. Es gibt mehrere Möglichkeiten, zwischen byte-semantic und char-semantic zu wechseln, Encode ist eine davon, dann gibt es noch das Pragma use bytes und seit 5.8. kann auch der IO-Layer vermitteln.
      
      Viele Grüße,
      Rosti
      - +10 replies
      - pktm
        
        2012-02-23 19:04
        
        User since
        2003-08-07
        2921 Artikel
        BenutzerIn
        
        Hm, das hat mich jetzt wieder ins Grübeln gebracht.
        
        Hier mal ein kleines Testskript mit Ausgabe:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
        
        #!perl use strict; use warnings; use utf8; use DBI; use Devel::Peek; use Encode; my $dbh = DBI->connect('DBI:mysql:database:server;mysql_enable_utf8=1', 'username', 'password'); die DBI::errstr() unless $dbh; my $stmt = qq~SELECT raw FROM files WHERE file_id = ?~; my $sth = $dbh->prepare($stmt); $sth->execute(1); my $row = $sth->fetchrow_hashref(); my $raw = $row->{raw}; Dump $raw; $raw = decode('utf8', $raw); Dump $raw; $raw = encode('utf8', $raw); Dump $raw; exit(0); __END__ SV = PV(0x35b7900) at 0x328d0f0 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0x306df38 "\303\244\303\266\303\274\303\237kekse!\303\252"\0 CUR = 16 LEN = 24 SV = PVMG(0x3539908) at 0x328d0f0 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) IV = 0 NV = 0 PV = 0x306bbb8 "\303\244\303\266\303\274\303\237kekse!\303\252"\0 [UTF8 "\x{e4}\x{f6}\x{fc}\x{df}kekse!\x{ea}"] CUR = 16 LEN = 24 SV = PVMG(0x3539908) at 0x328d0f0 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) IV = 0 NV = 0 PV = 0x306bb78 "\303\244\303\266\303\274\303\237kekse!\303\252"\0 CUR = 16 LEN = 24
        
        Die in der Datenbank enthaltene Zeichenkette ist äöüßkekse!ê.
        Stehen die Daten nun utf-8-kodiert in der Datenbank oder nicht? Woran erkenne ich das?
        http://www.intergastro-service.de (mein erstes CMS :) )
        
        +9 replies
        
        pq
        
        2012-02-23 19:08
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        ich glaube, du musst mysql_enable_utf8 als attribut übergeben, nicht im DSN.
        vielleicht geht das auch im DSN, aber das habe ich noch nie ausporobiert. schau mal, ob das einen unterschied macht.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +2 replies
        
        rosti
        
        2012-02-23 19:44
        
        User since
        2011-03-19
        3247 Artikel
        BenutzerIn
        
        2012-02-23T18:08:19 pq
        ich glaube, du musst mysql_enable_utf8 als attribut übergeben, nicht im DSN.
        vielleicht geht das auch im DSN, aber das habe ich noch nie ausporobiert. schau mal, ob das einen unterschied macht.
        
        Es kommt in die Hashref der Attribute, neben RaiseError, PrintError, AutoCommit...
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        { RaiseError => 1, mysql_enable_utf8 => 1, # ab DBD Version ?? musst gucken, sorry ;) PrintError => 0, }
        
        und ermöglicht die vollständig zeichenorientierte Kommunikation über den DBI-Layer. Die Tabelle in MySQL muss da auch das Flag haben,
        
        Code: (dl )
        
        create ..()default charset utf8
        
        dann geht auch sowas Select UPPER(name) mit UTF-8-kodierten Zeichen. Weitere Tests sind die Ausgabe der Länge mit Stringfunktionen in MySQL.
        
        Dein Dump (pktm) zeigt, so wie ich sehen kann, die Oktetten, die jedoch zusammen utf-8-kodierte Umlaute (äöü) ergeben.
        
        Wenn mysql_enable_utf8 nicht gesetzt ist, kriegst Du über DBI die Oktetten geliefert. Für eine Ausgabe auf STDOUT sind Oktetten ok. Mit Encode.pm kannst Du Oktetten zu UTF-8-kodierten Strings machen.
        
        Sorry, ich hab mir das nicht ausgedacht, das ist in der Tat etwas verwirrend, was hilft:
        
        So wie Perl-intern zwischen Oktetten und Zeichenketten unterscheidet, so muss der Programmierer auch seinen Code sehen, also immer wissen, sind das jetzt Oktetten oder UTF-8-kodierte Zeichenketten.
        
        Viel Erfolg!
        Rosti
        
        pq
        
        2012-02-23 19:47
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2012-02-23T18:44:21 rosti
        Es kommt in die Hashref der Attribute, neben RaiseError, PrintError, AutoCommit...
        
        sag ich ja.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +6 replies
        
        pktm
        
        2012-02-23 20:22
        
        User since
        2003-08-07
        2921 Artikel
        BenutzerIn
        
        Ja, es scheint einen Unterschied zu machen:
        
        more (5.8kb)
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
        
        SV = PV(0x35f7d20) at 0x32cd0a8 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) PV = 0x30ade38 "\303\244\303\266\303\274\303\237kekse!\303\252"\0 [UTF8 "\x{e4}\x{f6}\x{fc}\x{df}kekse!\x{ea}"] CUR = 16 LEN = 24 SV = PVMG(0x357a958) at 0x32cd0a8 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) IV = 0 NV = 0 PV = 0x30a86f8 "\357\277\275\357\277\275\357\277\275\357\277\275kekse!\357\277\275"\0 [UTF8 "\x{fffd}\x{fffd}\x{fffd}\x{fffd}kekse!\x{fffd}"] CUR = 21 LEN = 24 SV = PVMG(0x357a958) at 0x32cd0a8 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) IV = 0 NV = 0 PV = 0x30ab9f8 "\357\277\275\357\277\275\357\277\275\357\277\275kekse!\357\277\275"\0 CUR = 21 LEN = 24
        
        Da ich die Daten mit der falschen Notation auch eingefügt habe, dürfte ich das dann wohl nochmal machen :-(
        
        Immerhin erstellt wurden die Tabellen mit utf-8 als Zeichensatz - sagen mir die MySQL-Tools.
        http://www.intergastro-service.de (mein erstes CMS :) )
        
        +5 replies
        
        pq
        
        2012-02-23 20:24
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        hm, wieso, der erste Dump sieht doch gut aus?
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +4 replies
        
        pktm
        
        2012-02-23 20:35
        
        User since
        2003-08-07
        2921 Artikel
        BenutzerIn
        
        Aber ich hatte die Daten ohne das mysql_enable_utf8 => 1 in den Attributen in die Datenbank importiert. Müssten die Daten dann nicht Murks sein?
        http://www.intergastro-service.de (mein erstes CMS :) )
        
        +3 replies
        
        pq
        
        2012-02-23 20:40
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        nein, wenn sie dekodiert waren, nicht.
        wie dein import genau aussieht, weiss ich natürlich nicht. aber der dump sieht ja wie gesagt gut aus.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +2 replies
        
        pktm
        
        2012-02-23 20:50
        
        User since
        2003-08-07
        2921 Artikel
        BenutzerIn
        
        Ok. Wenn ich das jetzt richtig verstehe, waren die Daten beim Import dekodiert, weil ich die Angabe beim Filehandle gemacht habe.
        Hier ein Codeschnipsel aus dem import-Skript:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
        
        #!perl use strict; use warnings; use utf8; use FindBin qw/$Bin/; use Data::Dumper qw/Dumper/; use Text::CSV; use DBI; use SQL::Abstract; my $dbh = DBI->connect('DBI:mysql:ling:127.0.0.1;mysql_enable_utf8=1', 'test', 'test'); die DBI::errstr() unless $dbh; my $file = 'source.csv'; my $csv = Text::CSV->new ({ sep_char => ';', empty_is_undef => 1, binary => 1, }) or die "Cannot use CSV: ".Text::CSV->error_diag (); open my $fh, "<:encoding(utf8)", $file or die "$file: $!"; while ( my $row = $csv->getline( $fh ) ) { # Absetzen des Import-Statements für 1 Zeile hier } $csv->eof or $csv->error_diag(); close $fh; exit(0);
        
        http://www.intergastro-service.de (mein erstes CMS :) )
        
        rosti
        
        2012-02-23 21:01
        
        User since
        2011-03-19
        3247 Artikel
        BenutzerIn
        
        Entscheidend ist das hier:
        
        Code (perl): (dl )
        
        open my $fh, "<:encoding(utf8)", $file or die "$file: $!";
        
        Wenn utf8-oktetten in der Datei sind, kriegst Du beim Lesen aus $fh utf8-kodierte Zeichenketten. Der Layer ':encoding(utf8)' vermittelt das.
        
        Wenn solche tagged Strings (SvUTF8) über DBI nach MySQL gehen, funktioniert das zeichenorientiert entweder mit
        
        Code (perl): (dl )
        
        $DBH->do("SET NAMES UTF8");
        
        oder "SET CHARACTER SET utf8"
        
        oder {mysql_enable_utf8 => 1}
        
        Ansonsten werden die nackten Oktetten in die Tabelle geschrieben und kommen auch so zurück.
        
        Sofern einer der o.g. 3 Varianten angewandt wird, kannst Du jedoch auch anstelle eines SvUTF8 (Scalar-Value UTF8) die Oktetten über DBI schicken, weil für die Verbindung mithin utf-8-kodierung ausgehandelt wurde.
        
        set names u.a. http://dev.mysql.com/doc/refman/5.1/de/charset-con...
        Last edited: 2012-02-23 21:02:51 +0100 (CET)

View all threads created 2012-02-23 15:41.