PureBoard

Verfasst: **18.05.2007 20:34**

Ich weiß ja nicht, obs speziell um ZIP geht, oder ums packen von Dateien,
sonst könnteste zum Beispiel hier mal gucken:
http://www.purebasic.fr/german/viewtopi ... highlight=
Eigenes Packformat kreieren wäre auch ein feine Sache, guck mal hier:
http://www.purebasic.fr/german/viewtopi ... hlight=bcl

Verfasst: **18.05.2007 21:21**

Das wird ja immer besser.
Es ging eigentlich nur um das ZIP Format. (free)

Aber von deinen hier erwähnten links
kann ich bestimmt auch noch einiges gebrauchen.
Danke.

Wo ich hier schon mal das Thema angerissen habe.
Wollte ich auch noch mal erwähnen,
dass die PureZIP sich keine Attribute merken kann.
(Schreibschutz / Versteckt)
Wenn die Informationen in der ZIP vorhanden sind geht das auslesen ja mit
„PureZIP_GetFileInfo \ external_fa“
Aber beim Packen wird das nicht berücksichtigt.
Und kann somit auch nicht ausgelesen werden.

Verfasst: **18.05.2007 23:40**

String hat geschrieben:Wo ich hier schon mal das Thema angerissen habe.
Wollte ich auch noch mal erwähnen,
dass die PureZIP sich keine Attribute merken kann.
(Schreibschutz / Versteckt)
Wenn die Informationen in der ZIP vorhanden sind geht das auslesen ja mit
„PureZIP_GetFileInfo \ external_fa“
Aber beim Packen wird das nicht berücksichtigt.
Und kann somit auch nicht ausgelesen werden.

Bestätigt. Eigentlich wollte ich dieses manko mit dem release von P.F.M v2 beheben.
Aber es scheint tatsächlich keine möglichkeit zu geben die Attribute zu übernehmen.
Zuerst dachte ich wenn man sie vor dem packen ausliest und dann in internal_fa.l schreibt.
Leider Fehlanzeige. Das mitgelieferte DOC ist zwar recht gut, schweigt sich
IMHO aber zu sehr aus. Ein paar einfache Anhaltspunkte z.b. in klammern hinter
den Variablen oder so, könnte einem oftmals schon weiterhelfen, ohne nachfragen zu müssen.

Verfasst: **19.05.2007 01:45**

Könnte er die Dateinamen nicht mit UTF8 kodieren? Oder zur Not mit Base64?

Verfasst: **19.05.2007 11:34**

Bei der UTF-8-Kodierung kommen auch Bytes mit Werten > 127 vor, so dass das Problem dadurch nicht behoben wird.
Base64 verwendet zur Codierung nur die Zeichen A–Z, a–z, 0–9, + und / sowie = am Ende. Das / darf in normalen Dateinamen nicht enthalten sein -- inwieweit ZLIB damit klarkommt weiß ich nicht. / könnte notfalls durch _ o.Ä. ersetzt werden. UTF-8 kann auch verwendet werden, wenn dies dann noch Base64 codiert wird (so wird es auch in E-Mail-Headern gemacht).
Und dann? Wenn ich ZIP-Archive weitergebe, die Dateien mit derart kodierten Namen enthalten, was soll dann der Empfänger damit machen? Die Dateinamen könnten ja mit normalen EntZIPpungs-Programmen nicht wieder decodiert werden.

Ich stimme voll und ganz dem zu was hier bereits gesagt wurde:
Wer viel mit Computern arbeitet macht früher oder später die Erfahrung, dass Sonderzeichen in Dateinamen Probleme verursachen, und es daher besser ist diese in Dateinamen zu vermeiden.

In der Praxis kann es allerdings leicht 'mal passieren, dass ich es vergesse z.B. den Dateinamen einer gespeicherten Webseite entspr. umzubenennen. Und was meine lieben Kollegen im Büro mit ihren Computern so alles machen ist noch 'mal wieder 'ne andere Sache ...
D.h. ich halte es durchaus für wünschenswert, dass ein Programm möglichst robust ist. Dazu gehört entsprechend des "Prinzips der geringsten Überraschung" heutzutage im 21. Jahrhundert m.E. auch, dass ein ZIP-Programm Dateinamen mit Sonderzeichen ohne Gedöns verarbeiten kann. Dass PureZIP das nicht kann, sollte wenigstens deutlich dokumentiert sein.

Umso mehr danke ich Thomas für den 7-zip wrapper. Dies ist offenbar eine zeitgemäße Lösung.

Gruß, Little John

Verfasst: **17.06.2007 15:47**

Hab mal ne Deutsche Version von „PureZIP_AsciiDosLatinUS_To_AsciiWinLatin1“ erstellt.

Wenn noch jemand Fehler entdeckt bitte melden.
Gegebenenfalls den ASCII Wert Posten, eventuell auch den ersatzwert wenn erforderlich.

Code: Alles auswählen


Procedure AsciiDosUS_To_AsciiWinWestern(StringPointer.l)
 ; Transforms a string from ASCII DOS Latin US to "Westeuropa" oder "Western") ISO 8859-1 
  ! LEA Ebx, [TableConversion]
  MOV Ecx, StringPointer       ;    --> INLINE ASM !
  ! Boucle :
  ! MOV al, byte [Ecx]
  ! TEST al, al
  ! JZ FinChaine
  ! CMP  al, $80
  ! JNA  CarSuivant
  ! ADD  al, -$80
  ! XLATB
  ! MOV  byte[Ecx], al
  ! CarSuivant:
  ! INC Ecx
  ! JMP Boucle
  ! TableConversion:
  ! DB    $80, $FC, $82, $83, $E4, $85, $86, $87, $88, $89, $8A, $8B, $8C, $8D, $C4, $8F
  ! DB    $90, $91, $92, $93, $F6, $95, $96, $97, $98, $D6, $DC, $9B, $9C, $9D, $9E, $9F
  ! DB    $A0, $A1, $A2, $A3, $A4, $A5, $A6, $A7, $A8, $A9, $AA, $AB, $AC, $AD, $AE, $AF
  ! DB    $B0, $B1, $B2, $B3, $B4, $B5, $B6, $B7, $B8, $B9, $BA, $BB, $BC, $BD, $BE, $BF
  ! DB    $C0, $C1, $C2, $C3, $8E, $C5, $C6, $C7, $C8, $C9, $CA, $CB, $CC, $CD, $CE, $CF
  ! DB    $D0, $D1, $D2, $D3, $D4, $D5, $99, $D7, $D8, $D9, $DA, $DB, $9A, $DD, $DE, $E1
  ! DB    $E0, $DF, $E2, $E3, $84, $E5, $E6, $E7, $E8, $E9, $EA, $EB, $EC, $ED, $EE, $EF
  ! DB    $F0, $F1, $F2, $F3, $F4, $F5, $94, $F7, $F8, $F9, $FA, $FB, $81, $FD, $FE, $FF
  ! FinChaine:
EndProcedure 


  gASCII.s = " Ä_ä_Ö_ö_Ü_ü_ß_ "  

  Debug "" 
  Debug gASCII + "      <-  Original"
  Debug ""
  AsciiDosUS_To_AsciiWinWestern(@gASCII)
  Debug gASCII + "       <-  konvertiert"
  Debug ""
  AsciiDosUS_To_AsciiWinWestern(@gASCII)
  Debug gASCII + "     <-  und zurück" 
  Debug ""
  Debug ""

Änderung vorgenommen 17.06.2007 18.54 Uhr

PureBoard

PureZIP und äöü