Byte raw format in String umwandeln (Glib::IO::File->get_contents) (solved) (Allgemeines zu Perl)

[thread]20088[/thread]

Byte raw format in String umwandeln (Glib::IO::File->get_contents) [solved]

Tags: perl5 Gtk3 Similar Threads

Readers: 15

Articles: hide open all | hide show old branches

+19 replies
Max_Perlbeginner

2016-05-31 10:53

User since
2016-04-04
107 articles
BenutzerIn

Liebe Perl-Spezialisten,

Ich versuche gerade die Funktion Glib::IO::File::get_contents() zum Laufen zu kriegen. Das Problem ist, dass nach dieser Quelle Glib::IO Dateien im "raw byte format" liest und speichert, d.h. ohne jegliche Kodierung (keine Ahnung, was das heißt ;-) ).

Um es konkret zu machen:
1)Ich habe eine einfache Textdatei mit dem Inhalt: "Hallo Welt"

2) Wenn ich deren Inhalt mit my ($success, $content, $etags) = Glib::IO::File::load_contents($file) lese [wobei $file eben eine zuvor erzeugte GFile ist] erhalte ich neben anderen Variablen eine Arrayreferenz auf den content in der Variablen $content.

3) Diese Arrayreferenz dereferenziere ich mit my @contents = @$content;

4) Doch, wenn ich diese dann ausgebe (print "@contents \n";), erhalte ich Folgendes:

Quote
72 97 108 108 111 32 87 101 108 116

Ihr könnt Euch vorstellen, dass sich bei mir alles dreht ;-). Ich hab schon gesehen, dass scheinbar pack oder unpack der richtige Weg sein muss. Aber da werde ich einfach nicht schlau.
Die API Referenz gibt übrigens für content als element-type guint8 an, was folgendermaßen definiert wird (ist vlt. auch relevant):

Quote
An unsigned integer guaranteed to be 8 bits on all platforms. Values of this type can range from 0 to G_MAXUINT8 (= 255).

Letztlich ist es ein akademisches Problem, weil ich die Dateien ja auch mit perl Befehlen öffnen und schreiben kann, aber meine Neugier ist natürlich geweckt und vlt. kann mir jemand helfen diesen Content-Array in eine leserliche Perl Variable umzuwandeln.

Im Voraus Danke!
- Raubtier
  
  2016-05-31 11:48
  User since
  2012-05-04
  1083 articles
  BenutzerIn
  Da steht "Hallo Welt", wie du dich leicht mit
  
  Code (perl): (dl )
  
  print chr for qw(72 97 108 108 111 32 87 101 108 116);
  
  überzeugen kannst.
- GwenDragon
  
  2016-05-31 12:04
  User since
  2005-01-17
  14911 articles
  Admin1
  Dumper von Data::Dumper kann dir anzeigen, welche Daten vorliegen.
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12
  
  use strict; use warnings; use 5.010; use Data::Dumper; my $buffer_ref = [72,97,108,108,111,32,87,101,108,116]; # Puffer mit Bytes ähnlich deines $content say Dumper $buffer_ref; my $string = pack "C*",@{$buffer_ref}; # in eine Zeichenkette umwandeln say Dumper $string;
  
  Last edited: 2016-05-31 12:07:07 +0200 (CEST)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
- +3 replies
- guest janus
  
  2016-05-31 12:43
  
  Umständlicher gehts ja nun wirklich nicht. Es wäre besser Du guckst Dir mal an, wie mit native Perl Dateien gelesen und geschrieben werden.
  
  Ansonsten: Die Speichereinheit in Dateien ist das Byte, 1 Byte sind 8 Bit aber das ist ja nun auch nichts Neues.
  Last edited: 2016-05-31 12:50:48 +0200 (CEST)
  - +2 replies
  - GwenDragon
    
    2016-05-31 13:18
    
    User since
    2005-01-17
    14911 articles
    Admin1
    
    Guest janus
    Umständlicher gehts ja nun wirklich nicht. Es wäre besser Du guckst Dir mal an, wie mit native Perl Dateien gelesen und geschrieben werden.
    Wieso umständlich?
    Wenn man Bibliotheken wie GNOMEs GLib benutzt, solche die ein Fenstersystem zur Verfügung stellt, ist das Zeit sparend.
    
    Wie soll das mit native Perl gelöst werden? Erkläre es bitte dem Fragenden.
    Last edited: 2016-05-31 13:19:06 +0200 (CEST)
    die Drachin Gwen
    
    Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
    - guest janus
      
      2016-06-02 07:42
      
      Der Sinn eines Data Access Layers besteht darin, bei einer Persistierung Low-Level-Operationen (IO) vom wahlfreien Zugriff (Random Access) zu trennen. Letzeres geschieht über einen abstrakten Datentyp, bspw. einen Hash-of-Hashes nach dem Muster Entity/Attribute/Value.
      
      Zum Beispiel:
      
      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
      
      # Layer laden # Lade den Data Access Layer $self->{DAL} = FastEAV->new( file => $self->{FILEDIR}."/".$self->eav('file'), lock => $self->eav('edit') ? 1 : 0, auto => 0 ) or die $@; # einen Hash einchecken my %hunt = ( title => $self->trim($self->param('title')), descr => $descr, body => $self->trim($self->param('body')), ); # Neue Nummer oder vorhandene Nummer my $number = $self->param('lfdnr') ? $self->param('lfdnr') : $self->{DAL}->lfdnr; $self->{STASH}{lfdnr} = $number; $self->{DAL}->checkin($number, %hunt) or die $@; $self->{DAL}->write or die $@;
      
      Entity ist eine fortlaufende Nummer, vom DAL selbst verwaltet. Attribute => Value ein gewöhnlicher Hash.
      
      Anwendungsbeispiel: http://perl.rolfrost.de/notes.html
      Last edited: 2016-06-02 07:53:47 +0200 (CEST)
- +13 replies
- Max_Perlbeginner
  
  2016-05-31 13:55
  User since
  2016-04-04
  107 articles
  BenutzerIn
  Liebe GwenDragon,
  lieber Raubtier,
  
  Herzlichen Dank für Eure Antworten. Das geht ja doch recht einfach... Gibt es denn eine zu bevorzugende Lösung? Ich würde im Moment pack nehmen, weil da auch die umgekehrte Richtung problemlos klappt. Mit ord als Pendant zu chr wäre das wohl etwas umständlicher...
  
  @Gast janus
  In der Tat geht es letztlich darum, ein Gtk3 FileChooser widget zu bauen und dafür die Libraries von Gio::GFile optimal zu nutzen. Es gibt ein noch unfertiges Modul von Gio hier. Da ich gerade an einem Tutorial für Gtk3 schreibe und mir dabei aufgefallen ist, dass das Gio Modul gerade an dieser Stelle noch eine Anpassung bräuchte, würde ich gerne (auch wenn es etwas vermessen klingt) in diesem Modul einen Override schreiben und als Verbesserungsvorschlag auf der perl-gtk3 Liste diskutieren...
  
  Das Problem stellt sich wie angedeutet auch im umgekehrten Fall mit der Funktion Glib::IO::File::replace_readwrite. Das Modul Glib::Object::Introspection erwartet hier ein array ref, das auch im raw byte Format vorlag.
  
  Meine Lösung wäre nun einfach den umgekehrten Befehl zu verwenden:
  
  Code: (dl )
  
  my @content = unpack "C*", $current_contents;
  
  wobei $current_content eben den String "Hallo Welt" oder etwas anderes enthielte.
  
  Wäre das vertretbar? Oder gibt es dafür eine bessere Lösung? Es klappt bei mir so eigtl. ganz gut (insbes. auch die Umlaute). Ich frage mich nur, wie die Funktion pack/unpack weiß, welche Kodierung (utf8 oder ascii) es nehmen muss? Je nachdem würden den Zeichen ja unterschiedliche Zahlen zugeordnet, oder?
  - +12 replies
  - guest janus
    
    2016-05-31 14:15
    Das Verhalten von unpack hängt davon ab ob es zeichenorientiert oder byteorientiert gefüttert wird.
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8
    
    use strict; use warnings; use utf8; # Zeichenorientiert print "@{[unpack 'C*', 'ä€']}\n"; # 228 8364 Das sind die Codepoints no utf8; # byteorientiert print "@{[unpack 'C*', 'ä€']}\n"; # 195 164 226 130 172 Das sind die Byte-Wertigkeiten
    
    Last edited: 2016-05-31 14:32:04 +0200 (CEST)
    - +11 replies
    - Max_Perlbeginner
      
      2016-05-31 16:51
      
      User since
      2016-04-04
      107 articles
      BenutzerIn
      
      Lieber guest janus,
      Danke für Deine Antwort. Leider habe ich nun in der Tat ein Problem mit den Umlauten. Aus mir völlig unverständliche Gründen werden diese, wenn sie mit bspw. gedit in UTF 8 gespeichert werden (was auch die Einstellung meines Systems ist) falsch dargestellt..
      
      use utf8; hab ich aktiviert. Ich hab auch schon $content = pack( 'U*', @{$content} ); versucht, aber leider ohne Erfolg...
      
      Die relevanten Zeilen meines Codes sehen bislang folgendermaßen aus:
      
      Code: (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
      
      #!/usr/bin/perl package MyWin use utf8; use Encode; [...] sub open_response_cb { # $file is the file that we get from the FileChooserDialog $file = $open_dialog->get_file(); # an empty string (provisionally) #my $content = ''; # load the content of the file into memory: # success is a boolean depending on the success of the operation # content is self-explanatory # etags is an entity tag (can be used to quickly determine if the # file has been modified from the version on the file system) my ($success, $content, $etags) = Glib::IO::File::load_contents($file) or print "Error:"; #my $content_raw = Dumper $content; #print "DUMPER: $content_raw \n"; # Ich hab auch pack('C*' ...) probiert $content = pack( 'U*', @{$content} ); my $length = length(Encode::encode_utf8($content)); $buffer->set_text($content,$length);
      - guest janus
        
        2016-05-31 17:05
        
        Wie ich bereits schrieb: In Dateien sind Bytes gespeichert. D.h., alles was in eine Datei rein- oder rausgeht (IO) sind Bytes. Bytes kennen gar keine Zeichenkodierung, Bytes wissen nicht einmal ob sie Zeichen sind oder nicht.
        
        Erst der Anwender legt fest, welche Kodierung eine bestimmte Bytefolge ist oder sein soll. So nimmst Du Bytes aus einer Datei und sagtst Perl "das sind jetzt keine Bytes sondern utf-8-kodierte Zeichen" wenn Du zeichenorientiert arbeiten willst.
        
        Oder Du nimmst die Bytes so wie sie sind und arbeitest damit byteorientiert. Beim Zurückschreiben in die Datei musst Du auf JEDEN FALL wieder byteorientiert arbeiten, siehe oben warum.
        
        Und zum Wechsel von byte- auf zeichenorientierung gibt es mehrere Möglichkeiten. Das Pragma use utf8; macht nur dann Sinn, wenn die Bytes in der Sciptdatei zeichenorientiert verarbeitet werden sollen. Eine andere Möglichkeit zur Wiederherstellung der Byteorientierung ist use bytes;, darüber hinaus kannst Du auch direkt am IO-Layer umschalten und dann gibt es noch use Encode:
        Last edited: 2016-05-31 17:11:22 +0200 (CEST)
      - Raubtier
        
        2016-05-31 17:29
        
        User since
        2012-05-04
        1083 articles
        BenutzerIn
        
        Eigentlich steht zu Zeichensätzen in Perl alles hier drin (lies dir das mal komplett durch):
        https://perlgeek.de/de/artikel/charsets-unicode
      - +8 replies
      - Max_Perlbeginner
        
        2016-05-31 18:36
        
        User since
        2016-04-04
        107 articles
        BenutzerIn
        
        Lieber Janus,
        lieber Raubtier,
        
        Herzlichen Dank für Eure Hilfe und v.a. für Eure schier unendliche Geduld!!!! Vor allem, lieber Raubtier, Danke für den Artikel, der endlich (hoffe ich) das Brett vor meinem Kopf weggenommen hat. Ich dachte immer, der Bytestring, das seien die Zahlen und nicht ein Textstring, der eben noch nicht dekodiert wurde. Das war der Denkfehler ;-)
        
        Ich konnte es nun mit diesen zwei Schritten lösen:
        Für das Öffnen der Datei:
        
        Code: (dl )
        
        1 2 3 4
        
        # Zunächst wandeln wir die Bytes in einen Bytestring um my $content = pack "C*", @{$raw_content}; # Diesen Bytestring dekodieren wir in das utf8 Format my $content_utf8 = decode('utf-8', $content);
        
        Für das Speichern der Dateien
        
        Code: (dl )
        
        1 2 3 4
        
        # Den Textstring im UTF8 Format in einen Bytestring umwandeln my $content_utf8 = encode('utf-8', $content); # Den Bytestring wieder in Bytes umwandeln my @contents = unpack "C*", $content_utf8;
        
        Noch einmal allen Helfern tausend Dank!!!
        Falls jemand noch mit mir Geduld hat, zwei Fragen hätte ich (auch wenn ich den Thread jetzt als gelöst markiere):
        
        1) Was macht denn das Pragma use utf8;, wenn ich trotzdem vor dem Speichern den Bytestring mit encode('utf-8', $content) extra ins utf8 Format umwandeln muss?
        
        2) Was ist nun der Unterschied zwischen dem Template 'C*' und 'U*' bei der pack Funktion? Es klappt beides bei mir. Doch welches wäre hier das Richtige?
        
        +6 replies
        
        guest janus
        
        2016-05-31 19:48
        
        1) gar nichts
        2) die C- und U-Schablone verhalten sich ab v5.10 gleich
        Last edited: 2016-05-31 19:59:43 +0200 (CEST)
        
        +4 replies
        
        Raubtier
        
        2016-05-31 21:08
        
        User since
        2012-05-04
        1083 articles
        BenutzerIn
        
        Guest janus
        1) gar nichts
        
        ?!!!
        
        Natürlich macht "use utf8" etwas. Es bezieht sich allerdings nicht auf das, was das Script einliest oder ausgibt, sondern in welcher Kodierung das Script selbst geschrieben ist.
        
        Also
        
        Code (perl): (dl )
        
        1 2
        
        use utf8; $string = "Hallöle";
        
        String-Werte, die direkt im Script stehen, werden mit "use utf8" automatisch dekodiert. Siehe auch utf8, insbesondere das Zitat:
        
        perldoc utf8
        Do not use this pragma for anything else than telling Perl that your script is written in UTF-8.
        
        und
        
        Quote
        Enabling the utf8 pragma has the following effect:
        Bytes in the source text that are not in the ASCII character set will be treated as being part of a literal UTF-8 sequence. This includes most literals such as identifier names, string constants, and constant regular expression patterns.
        
        pq
        
        2016-06-01 11:16
        
        User since
        2003-08-04
        12209 articles
        Admin1
        
        die diskussion mit janus über use utf8 lohnt nicht, ich erinnere mich da an einen thread vor, hm, ein paar jahren...
        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
        
        guest janus
        
        2016-06-01 11:34
        
        Du kannst nicht lesen. Meine Antwort bezog sich auf die Frage und dass pragma utf8 nur auf die Literale in der Scriptdatei wirkt, hab ich weiter oben bereits geschrieben. Also bitte richtig lesen bevor Du hier lospolterst.
        Last edited: 2016-06-01 13:05:52 +0200 (CEST)
        
        GwenDragon
        
        2016-06-01 13:13
        
        User since
        2005-01-17
        14911 articles
        Admin1
        
        Max fragte:
        2016-05-31T16:36:19 Max_Perlbeginner
        1) Was macht denn das Pragma use utf8;, wenn ich trotzdem vor dem Speichern den Bytestring mit encode('utf-8', $content) extra ins utf8 Format umwandeln muss?
        
        Du antwortetest:
        Guest janus
        1) gar nichts
        
        Wenn du auf 1) geantwortet hättest: "Das Pragma beeinflusst nicht das encode oder den Inhalt von $content", dann wäre das stimmiger gewesen.
        Jedenfalls wäre es für Anfänger wie Max_Perlbeginner vielleicht sinnvoller, dass du das genauer benennst.
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        Max_Perlbeginner
        
        2016-06-02 14:26
        
        User since
        2016-04-04
        107 articles
        BenutzerIn
        
        Ihr Lieben, ich danke Euch allen herzlich für Eure Antworten. Jetzt verstehe ich auch, warum use utf8; bei Strings, die im Skript selbst erstellt wurden (und nicht nur aus anderen Datein geladen!), funktionierte!
        Danke!
        
        Muffi
        
        2016-06-01 09:31
        
        User since
        2012-07-18
        1465 articles
        BenutzerIn
        
        Quote
        Was macht denn das Pragma use utf8;
        
        Das sagt (vereinfacht) nichts anderes als: Mein Perlskript (irgendwas.pl) ist in utf8 abgespeichert.
        D.h. es betrifft NUR den Sourcecode und z.B. strings die du in den Sourcecode schreibst.
        Last edited: 2016-06-01 09:33:20 +0200 (CEST)
        1 + 1 = 10

View all threads created 2016-05-31 10:53.