unzip und Sonderzeichen in gepackten Datei-/Verzeichnisnamen (Allgemeines zu Perl)

[thread]13451[/thread]

unzip und Sonderzeichen in gepackten Datei-/Verzeichnisnamen

Leser: 16

Articles: hide open all | hide show old branches

+15 replies
frankes

2009-04-29 17:51
User since
2005-04-02
140 Artikel
BenutzerIn
Nicht wirklich ein Perl Problem, aber vielleicht kann mir hier einer weiter helfen.

Mittels eines Formular-Uploads werden gezippte Verzeichnisse auf einen (in diesem Fall) Solaris Web-Server geladen, die dort über ein Perl Script entpackt werden.
Mangels eines passenden Modul auf dem Server greife ich mit system auf unzip zurück um die ZIP Archive zu entpacken:
Code: (dl )

system ('/usr/bin/unzip','ziparchiv','-d','/Zielverzeichnis');
Probleme gab es nun, als ZIP Archive Dateien mit Sonderzeichen (konkret ä,ö,ü) im Datei-/ Verzeichnisnamen beinhalteten.
Die ZIP-Archive werden hier unter Linux mit utf-8 als Systemzeichensatz erstellt. Nach dem entpacken auf dem Server werden Sonderzeichen in Dateinamen falsch codiert (sieht nach verwendeten Systemzeichensatz iso-8859-1 auf dem Server aus).

Wäre ja nicht weiter tragisch, aber leider verschluckt sich der Solaris Server dermaßen an diesen Datei- und Verzeichnisnamen, dass er behauptet, diese würden nicht existieren. Sprich, die Verzeichnisse/Dateien werden mittels FTP-Client angezeigt können aber nicht bearbeitet werden. (Nach langem herumprobieren mit FTP-Client und Perl Scripten lies der Server sich wenigsten dazu überreden, diese 'nicht vorhandenen' Einträge zu löschen.)

Frage:
Suche nach einem Lösungsansatz (oder Lösung :-) ) wie ich erreichen kann, dass die entpackten Datei-/ und Verzeichnisnamen mittels 'unzip' im richtigen Zeichensatz des entpackenden Systems entpackt werden,
oder Sonderzeichen in Verzeichnis-/Dateinamen vor dem Entpacken entschärft/ausgetauscht werden können.
(... um ehrlich zu sein: Einfach eine Lösung, dass der Sch... funktioniert. )

Danke
Last edited: 2009-04-29 17:52:30 +0200 (CEST)
- +2 replies
- GwenDragon
  
  2009-04-29 19:50
  
  User since
  2005-01-17
  14761 Artikel
  Admin1
  
  Frage doch erst mal zu Sicherheit ab, welches locale der Server verwendet.
  Das sollte in der Shell in LC_ALL oder LANG stehen.
  
  Es sollte also in $ENV{'LANG'} oder $ENV{'LC_ALL'} stehen.
  
  Ich kann mir nicht vorstellen, dass Solaris ISO-8859-1 eingestellt hat, das ist unüblich.
  
  Last edited: 2009-04-29 19:51:55 +0200 (CEST)
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - frankes
    
    2009-04-29 21:08
    User since
    2005-04-02
    140 Artikel
    BenutzerIn
    
    Hallo GwenDragon
    
    Danke für die schnelle Antwort.
    
    Leider sind genau diese Umgebungsvariablen in %ENV nicht belegt.
    
    Über eine Shell Abfrage mittels 'locale' erhalte ich für LANG und LC_ALL gleichfalls keine Auskunft:
    
    Quote
    LANG=
    LC_CTYPE="C"
    LC_NUMERIC="C"
    LC_TIME="C"
    LC_COLLATE="C"
    LC_MONETARY="C"
    LC_MESSAGES="C"
    LC_ALL=
    
    Gleichfalls "C" (meines Wissens nach für Standard) mittels POSIX unter Perl
    
    Code: (dl )
    
    print setlocale(LC_CTYPE); # Ergebnis "C"
    
    Ein
    
    Code: (dl )
    
    1 2
    
    use locale; print +(sort grep /\w/, map { chr } 0..255), "\n";
    
    ergibt Ausgabe:
    
    Quote
    0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
    
    Weißt wohl eher darauf hin, dass ein Standard ASCii verwendet wird, oder?
    
    Hoffnung macht mir, dass ich wenigstens mittels einem locale -a (shell)
    auch "de_DE.UTF-8", "de_DE.UTF-8@euro" angezeigt bekomme.
    
    Die Server wurden vor ungefähr 3 Jahren aufgesetzt. - Weiss nicht, ob Solaris Server zu dem Zeitpunkt bereits auf Unicode setzten.
    
    Allerdings verstehe ich auch nicht, warum unzip Dateinamen nicht anpassen kann :-)
    Last edited: 2009-04-29 21:09:07 +0200 (CEST)
- +11 replies
- frankes
  
  2009-04-29 23:12
  
  User since
  2005-04-02
  140 Artikel
  BenutzerIn
  
  So, ein Stück weiter beim durchwühlen des Internets und Herumtesten mit zip Dateien.
  
  Das Problem scheint zu sein, dass ZIP Archive (zumindest unter unzip) nicht den charset der Dateinamen mit speichert (kommt wohl in Version 6).
  
  Lösungen suche ich nach wie vor.
  - +10 replies
  - murphy
    
    2009-04-30 00:03
    
    User since
    2004-07-19
    1776 Artikel
    HausmeisterIn
    
    2009-04-29T21:12:32 frankes
    [...]
    Das Problem scheint zu sein, dass ZIP Archive (zumindest unter unzip) nicht den charset der Dateinamen mit speichert (kommt wohl in Version 6).
    [...]
    
    Zumindest unter *NIX haben Dateinamen auch keinen definierten Zeichensatz. Ein Dateiname ist für das Betriebssystem eine ziemlich beliebige Sequenz von Bytes, in der nur drei Zeichen eine besondere Bedeutung haben: '/' trennt die Komponenten eines Pfades, '.' und '..' bezeichnen besondere Verzeichnisse und das Nullbyte zeigt das Ende der Zeichenkette an.
    
    Was auch immer bei Dir Probleme macht, eine tiefe Schicht des Betriebssystemes ist es wohl eher nicht. Mehr kann man nach Deiner Problembeschreibung ohne Glaskugel aber auch nicht aussagen.
    
    Wenn Du die Dateinamen beim Entpacken ändern willst, dann benutze eben ein Perlmodul zum Verarbeiten des ZIP-Archives, mit dem das geht. Oder benenne die Dateien nach dem Extrahieren einfach um.
    When C++ is your hammer, every problem looks like your thumb.
    - +9 replies
    - frankes
      
      2009-04-30 00:32
      
      User since
      2005-04-02
      140 Artikel
      BenutzerIn
      
      Hallo murphy
      
      Danke für die Antwort.
      Die Glaskugel hätte ich auch gerne, denn mein Problem ist wirklich nicht, dass Sonderzeichen erscheinen, sondern dass das Solaris System mit diesen dermaßen durcheinander kommt, dass auch ein Umbenennen nicht mehr funktioniert.
      Klar kann ich mir hier jetzt einen Zettel auf den Tisch legen, keine Sonderzeichen in den Datei- und Verzeichnisnamen, nur werde ich halt mit diesem System nicht alleine arbeiten. Gut eine Stunde um solch ein entpacktes Verzeichnis wieder vom Server zu entfernen, da es angeblich nicht existiert aber doch im Dateiverzeichnis eingetragen ist und man sucht nach einer anderen Lösung.
      
      Am experimentieren mit Perl Modulen bin ich bereits dran. - Nur kann ich halt mit meinen Rechten nicht jedes x-beliebige Modul auf diesem Server installieren.
      - +8 replies
      - murphy
        
        2009-04-30 01:20
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        Es wäre zur näheren Problemanalyse hilfreich zu wissen, welche Programme behaupten, dass es die Dateien nicht gibt und welche sie doch finden. Zeigt ls zum Beispiel die Dateien an? Kannst Du sie mit Perls readdir oder glob auflisten? Kannst Du sie mit einem simplen C-Programm mit readdir auflisten? ...
        When C++ is your hammer, every problem looks like your thumb.
        
        +7 replies
        
        frankes
        
        2009-04-30 14:46
        
        User since
        2005-04-02
        140 Artikel
        BenutzerIn
        
        Hallo murphy
        
        Angezeigt bekomme ich die betroffenen Verzeichnissen und Dateien mit dem FTP-Client als auch mit den Perl Verzeichnis und Datei Operationen. Auch über Perl gestartete Shell Aufrufe liefern mir diese Dateien.
        
        Mit dem FTP Client komme ich in der Verzeichnistiefe bis zum ersten Datei oder Verzeichnis Eintrag mit Sonderzeichen, wobei die Sonderzeichen im Namen durch andere Sonderzeichen ersetzt sind. Ab da wird behauptet, dass das angezeigte Verzeichnis/Datei nicht existiert.
        
        Das File::Find Modul liefert mir witziger Weise auch Einträge in Verzeichnissen mit Sonderzeichen, ein Zugriff ist dennoch nicht möglich.
        
        Nochmals, dies gilt nur mit unzip entpackte Verzeichnisstrukturen und die Dateien/Verzeichnisse mit Sonderzeichen im Namen. Zugriffe werden dann mit dem Hinweis, dass diese Datei nicht existiert verweigert. - Gleiches gilt für rekursives Löschen, da die Einträge mit Sonderzeichen nicht gelöscht werden können.
        
        Warum Solaris 10 solche Probleme mit diesen Sonderzeichen in Verzeichnis- und Dateinamen hat kann ich nicht nachvollziehen. Entsprechende ZIP Files (dazu unten mehr) liefern auf einem Linux System mit UTF8 die gleichen Kodierungsfehler, ein Zugriff auf die Dateien und Operationen sind aber problemlos möglich. Meine aber mich noch an Linux Systeme zu erinnern, die ohne UTF8 Standardzeichensatz ähnliche Probleme zeigten. - Daher auch mein Tipp Richtung Charset Probleme.
        
        Mehr Informationen kann ich zum Solaris Server leider nicht geben, da mir entsprechende Rechte wie direkten Zugriff auf die Shell (ausgenommen perl system Aufrufe) fehlen.
        
        Weiter gekommen bin ich dagegen mit "unzip" und den entsprechenden Archiven.
        
        Diese ersetzten Sonderzeichen bekomme ich über die Archive. Laut zipinfo handelt es sich dabei um für FAT gepackte Archive. Da in FAT Archiven kein UTF8 Zeichensatz verwendet wird, werden die Sonderzeichen entsprechend umgewandelt. Zipinfo zeigt die problematischen Zeichen in der Informationsausgabe zu den ZIP Files bereits an.
        
        Bei neueren unzip Versionen kann man angeben, welcher Zeichensatz im Archiv verwendet wurde. Leider ist das verwendete unzip auf dem Server um einen Versionspunkt zu alt.
        Die Probleme sind bei den zip/unzip Entwicklern bekannt und werden wohl vollens behoben.
        
        In den kommenden Tagen werde ich versuchen, das Cpan Modul Archive::zip Archive::zip auf dem Server zum Laufen zu bringen. Auf dem ersten Blick könnte das funktionieren, da die Module, auf die Archive::zip zurückgreift vorhanden sind und das kopieren des Perl-Modul-Codes reichen könnte. Vielleicht komme ich dann mit dem Tipp von Jean Benoit ( http://tracker.moodle.org/browse/MDL-6733 ) weiter.
        
        Über Tipps und Vorschläge freue ich mich nach wie vor.
        Auch suche sich nach weiteren Informationen zu ZIP Archiven allgemein. ZB. die Bedeutung und Auswirkungen von den angezeigten Packetinformationen wie fat/unix (kann man sich noch zusammenreimen) oder auch Zahlen die über zipinfo mit ausgegeben werden.
        Zu den ausgegebenen Archiv-Informationen mit problematischen ZIP Archiven werde ich von zuhause aus mal Beispiele einstellen. - Vielleicht kennt sich ja jemand mit den angegebenen Informationen aus.
        
        Danke.
        
        +6 replies
        
        murphy
        
        2009-04-30 18:07
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        Was Du schreibst klingt eigentlich danach, dass das Problem überhaupt nicht auf dem Server sondern vielmehr in Deinem FTP-Client liegt. Da könntest Du ja mal ein paar verschiedene Programme ausprobieren...
        
        Außerdem spricht doch, wenn readdir und File::Find kein Problem mit den Dateinamen haben, auch nichts dagegen, Dein Skript, welches die Archive entpackt, einfach um eine Routine zu ergänzen, die alle Dateien in einem frisch entpackten Verzeichnis so umbenennt, dass keine Sonderzeichen mehr in ihren Namen auftauchen.
        When C++ is your hammer, every problem looks like your thumb.
        
        +5 replies
        
        frankes
        
        2009-04-30 21:22
        
        User since
        2005-04-02
        140 Artikel
        BenutzerIn
        
        Hallo murphy
        
        Leider dreht sich unser Gespräch im Kreis.
        
        Wie oben beschrieben bekomme ich die Files angezeigt, im FTP-Client als auch im also auch mit den Perl Verzeichnis und Dateioperationen, also auch über Shell Aufrufe (in meinem Fall mittels Perl system() )
        
        Datei Operationen mittels FTP Client, Perl und Shell wie umbenennen, löschen etc. führen beim FTP Client, Perl als auch der Shell zur Fehlermeldung, dass das File nicht existieren würde.
        
        Dabei wurden von mir bereits viele verschiedene Möglichkeiten durchprobiert:
        Direkte ansprechen der Files mittes unlink, rmdir, rename, mittels shell mit rm, rm -r ...
        File::Find Schleifen, File::Path mit Funktionen zum löschen bzw. umbenennen.
        
        Es bleib dabei, die Files wurden angezeigt, konnten aber nicht gelöscht, unbenannt oder sonstige Operationen ausgeführt werden.
        
        --------
        
        Es ist schwer vorstellbar, dass dies möglich ist, aber wie oben beschrieben befand ich mich vor Jahren auch bei einem Linux System in diesem Dilemma. - Meist führt dann Sturrheit zum Ziel, diese Einträge zu löschen.
        Erklären kann ich mir das nur so, dass die Filenamen im Verzeichnis der Festplatte eingetragen, die Daten aber wegen eines Fehlers nie geschrieben wurden. Wahrscheinlich sind die Einträge im Verzeichnis der Festplatte gleichfalls Fehlerhaft.
        
        Aber um darauf eine Antwort zu erhalten wird man sich mit jemanden unterhalten müssen, der sich mit Dateisystem wirklich auskennt.
        
        +2 replies
        
        nepos
        
        2009-04-30 21:58
        
        User since
        2005-08-17
        1420 Artikel
        BenutzerIn
        
        Letzteres würde aber ein Lauf von fsck aufdecken. Wenn die Namen da wären, die Daten aber nicht, ist für mich das Dateisystem inkonsistent.
        
        frankes
        
        2009-05-01 07:40
        
        User since
        2005-04-02
        140 Artikel
        BenutzerIn
        
        Hallo nepos
        Danke für die Antwort.
        Habe mir erlaubt eine gemeinsame Antwort zu schreiben die sich hier findet:
        msg #121068
        
        mod-edit pq: link zur message portabel gemacht
        Last edited: 2009-05-01 13:16:49 +0200 (CEST)
        
        +2 replies
        
        murphy
        
        2009-04-30 22:18
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        2009-04-30T19:22:02 frankes
        [...]
        Wie oben beschrieben bekomme ich die Files angezeigt, im FTP-Client als auch im also auch mit den Perl Verzeichnis und Dateioperationen, also auch über Shell Aufrufe (in meinem Fall mittels Perl system() )
        
        Datei Operationen mittels FTP Client, Perl und Shell wie umbenennen, löschen etc. führen beim FTP Client, Perl als auch der Shell zur Fehlermeldung, dass das File nicht existieren würde.
        [...]
        
        Das ist allerdings doof. ich hatte Deine Ausführungen auch erst anders verstanden -- aufgrund der Informationen, die ich hatte, vermutete ich, dass die Möglichkeiten des Zugriffes vom verwendeten Programm abhingen.
        
        Quote
        [...]
        Erklären kann ich mir das nur so, dass die Filenamen im Verzeichnis der Festplatte eingetragen, die Daten aber wegen eines Fehlers nie geschrieben wurden. Wahrscheinlich sind die Einträge im Verzeichnis der Festplatte gleichfalls Fehlerhaft.
        [...]
        
        Für wahrscheinlicher halte ich einen Fehler in der API des Betriebssystemes oder des Dateisystemtreibers: Da die Dateien korrekt gelistet werden, sind die Verzeichniseinträge vermutlich in Ordnung und ich sehe keinen Grund anzunehmen, dass die Daten nicht geschrieben wurden, aber beim Nachschlagen eines Namens wird wohl die Eingabe anders interpretiert als beim Anlegen desselben.
        
        Eventuell hast Du Glück und Dein Betriebssystem hat auch noch eine API um Dateien nicht über ihren Namen sondern über ihre Inodenummer anzusprechen. Dann könntest Du aus dem Listing des Verzeichnisses die Inodes zu den kaputten Namen herausfinden und über diese Schnittstelle die Dateien umbenennen...
        When C++ is your hammer, every problem looks like your thumb.
        
        frankes
        
        2009-05-01 07:36
        
        User since
        2005-04-02
        140 Artikel
        BenutzerIn
        
        Erlaube mir hier auf nepos und murphy Post zu antworten, da beides im Endeffekt ähnlich ist.
        
        @murphy: Macht ja nichts, wahrscheinlicher ist ja, dass ich mich oben ungeschickt ausgedrückt hatte.
        
        Leider ist es ja nicht mein Server, sonst wären schon lange alle Perl Module die ich benötige installiert und ich müsste nicht solche Klimmzüge mit Systemaufrufen machen.
        
        Womit ich auch schon bei der Kernfrage angekommen bin.
        Klar könnte ich jetzt anfangen den Server nach Fehlern im Dateisystem zu durchsuchen. Nur sehe ich das nicht als meine Aufgabe an, dafür sind andere Leute zuständig. Die Aufgabe habe ich zwar im Rahmen meines Brötchengebers übernommen, verdiene aber meine Brötchen mit anderen Aufgaben, so dass dies hier in meiner Freizeit läuft.
        Zudem habe ich bei Anfragen an den Anbieter des Servers nicht die besten Erfahrungen gemacht.
        Daher werde ich jetzt nicht Anfangen Fehlerreports zu erstellen.
        
        Murphys Vorschlag mit den Inodes kann ich gegebenenfalls nochmals aufgreifen. Nachteil dieser Lösung ist halt, dass ich gegebenenfalls das Script wieder anpassen muss, wenn ich es mal auf einem anderen System laufen lassen will. Auch das mein Entwicklungssystem und das Produktivsystem verschieden sind, lassen mich von diesem Ansatz zunächst Abstand nehmen.
        
        Zudem weißen Recherchen im Internet darauf hin, dass das Charset Problem in den Filenamen von ZIP Archiven bekannt ist. An Lösungen wird gearbeitet.
        
        Daher werde ich zunächst nach Alternativen beim Entpacken von ZIP Archiven suchen. So dass ich hoffentlich Einfluss auf die verwendeten Filenames bekomme.
        
        Was sich daraus ergibt, werde ich gerne hier im Forum zusammenfassen.
        
        Schönen Feiertag
- frankes
  
  2009-05-01 23:03
  User since
  2005-04-02
  140 Artikel
  BenutzerIn
  So mal einen ersten Lösungsansatz.
  
  Nach Recherchen im Internet weiß ich jetzt, dass das Problem im Zip-Archiv Dateiformat liegt. Während Windows Systeme anscheinend ziemlich sicher cp850 als Zeichensatz für die Dateinamen im Zip-Archiv verwendet, variiert dieser unter *nixe und anderen Systemen.
  Das Zip-Archiv speichert bisher nicht den verwendeten Zeichensatz für Dateinamen im Archiv.
  Das Problem ist bekannt und in zukünftigen zip Versionen (6.0?) soll dann der verwendete Zeichensatz mit gespeichert werden.
  Bis die Tage und sich das bei allen Zip Packern durchgesetzt hat, muss man halt herumspielen.
  
  Zu meiner Freude ist das Archive::Zip Modul pure Perl, so dass man es einfach durch kopieren auch auf Servern verwenden kann, wo es nicht installiert ist.
  Man sollte lediglich überprüfen, ob die von Archive::Zip benötigten Module installiert sind (vgl. dazu die Dokumentation von Archive::Zip).
  
  Archive::Zip bietet neben dem Packen und Entpacken eine bequeme Möglichkeit Kopfdaten zum Zip-Archiv auszulesen, als auch einzelne Files aus dem Archiv unter einem anderen Namen zu entpacken.
  
  Mittels "fileAttributeFormat()" kann man auch grob das vom Packer verwendete Dateiformat/System herausfinden.
  
  zB.
  MSDOS, FAT = 0; UNIX = 3; CMS = 4; OS2_HPFS = 6; MACINTOSH = 7; WINDOWS_NTFS = 11; VFAT = 14;
  (Eine vollständige Liste findet sich im Quellcode von Archive::Zip)
  
  Zum 1. Versuch
  
  Es würde sich nun anbieten, archivierte File-Namen die unter einem Windows/MS System gepackt wurden sofort mittels cp850 zu decodieren. Leider musste ich die Erfahrung machen, dass der KDE4 Packer Ark gleichfalls
  
  Quote
  fileAttributeFormat() = MSDOS/FAT
  
  angibt, aber die File-Namen im Archiv unter dem Systemzeichensatz (hier war es UTF8) abspeichert.
  
  Bleiben weitere Möglichkeiten:
  1. Vor dem entpacken nicht konforme Zeichen umwandeln.
  2. Versuchen, den Zeichensatz der File-Namen herauszufinden.
  3. ... (vielleicht fällt euch was ein)
  
  Trotz der Problematik einen verwendeten Zeichensatz herauszufinden probiere ich es hier zunächst über die zweite Möglichkeit.
  
  Das Script entpack ein gegebenes Zip Archiv ins gleiche Verzeichnis.
  Beim Aufruf des Script einfach den entsprechenden Verzeichnisnamen anhängen.
  
  Quote
  zip.pl Archiv.zip
  
  Das Script versucht mittels Encode::Guess festzustellen, ob ein ascii oder cp850 Zeichensatz verwendet wurde. UTF8 wird leider nicht sicher erkannt.
  
  Getestet wurde das Script bisher unter Linux (UTF8) mit Archiven von
  XP, Vista (eigene Systempacker, 7zip, WinAce) und dem oben genannten Linux (UTF8).
  
  Wie sich das script mit einem anderen Systemzeichensatz wie UTF8 klar kommt, wird sich noch herausstellen müssen.
  
  Mich würde es nun natürlich interessieren, wie diese script mit Archiven mit anderen Zeichensätzen/ System klar kommt.
  Und natürlich bin ich an Verbesserungsvorschlägen interessiert.
  
  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 53 54 55 56
  
  #!/usr/bin/perl -w ########### zip.pl ################ # Testing for modul Active::zip # Unpack given ZIP files in the same directory use lib './'; use strict; use Carp; use Encode; use Encode::Guess; use Archive::Zip qw( :ERROR_CODES :CONSTANTS ); use utf8; use open ':utf8'; binmode STDOUT,':utf8'; my $zip = Archive::Zip->new(); my @encodings = qw(ascii cp850); my $m = ''; my $n = ''; my $charset = ''; die 'read error: ',$ARGV[0] unless $zip->read( $ARGV[0] ) == AZ_OK; foreach $m ($zip->members()) { print "member filename: ",$m->fileName(),"\n"; print "fileAttributeFormat: ", $m->fileAttributeFormat(),"\n"; $n = $m->fileName(); print "Try to guess encoding\n"; $charset = guess_encoding($n, @encodings); #no charset found unless (ref $charset) { print "No charset found: $charset\n"; print "Using member filename like it is: $n\n"; $zip->extractMember($m); next; } #charset found $charset = $charset->name; print "Guessed charset: ",$charset,"\n"; print "Archive given member filename is $n.\n"; $n = decode($charset,$n); $m->extractToFileNamed($n) ; print "Decoded to $n\n"; print "----------------\n"; } print 'done.';

View all threads created 2009-04-29 17:51.