More than a set of
Zip and Unzip Components!

ZipTV is a suite of over 37
compression related components!

   
Home
  What's New
Product Info
  Archive Filter
Downloads
Ordering Info
Problem Report
Upgrades
Contact Us
Home- | -What's New- | -Product Info- -Archive Filter- | -Downloads- | -Ordering Info- | -Upgrade- | -Contact

 


Enhanced Power, Speed, and Operability
Under Most Web-Servers.

ZipTV's AES encryption and PPMD compression requires no external dll's!

 

Conditional Defines (requires VCL source version)

External dll files (installed in windows\system32 directory)

REMINDER:
Installer Password: The password for the registered version of the installer is the order invoice number obtained from the invoice received at the time of registration.

NOTE: 7-zip support is included in the ZipTV versions for Delphi 2009+.

v2012

v2011.11.01 

v2010.10.11  We make every attempt to retain compatibility with prior versions; however, this version may require some minor revisions to your project’s code.

v2010.08.16

v2010.08.15

v2010.08.10

v2010.04.08

v2010.04.06

v2010.04.03

v2010.03.29


v2010.03.22


v2010.01.12


v2009.12.21


v2009.11.24


v2009.7.28


v2009.6.16
 

v2009.6.15  (7-zip support is available in ZipTV for Delphi 2009+)

v2009.6.11

v2009.5.4

v2009.4.14

v2009.1.1

v2009.0.0

v2008.12.13

  1. Included support for the proper reading and extraction of unicode filenames stored in zip files that use extended headers as a method of providing support for unicode filenames. Utility applications that use this method, first write the ansi-string form of the filename to the header, UTF8 encode it, and then write the UTF8 encoded string value to an extended header. This method results in the writing of one filename to a zip file four times.

    There are many problems with this method. The first is the writing of a filename four times as previously mentioned. With that in mind, if it is determined that UTF8 encoding is required and an extended header created, full reconstruction of the stored ansi-string value is generally not possible anyway, so what is the purpose of writing it to the archive? Another is that most utility applications compressing files using this method, bypass the ansi-string stored value and instead, read the UTF8 encoded string from the extended header, providing no access to the stored ansi-string value - again, what's the purpose of writing the filename four times? The zip format is the only archive format that supports extended headers; therefore, uniformity of unicode filename support across all supported archive formats cannot be achieved.

    The zip format contains three header types. The local header, central header, and ending header. Filenames have always been written to a zip archive, two times. Once in the local header and once in the central header. With the use of an extended header to support unicode, one filename is written to the archive four times. Twice in the local header and twice in the central header. Consider an archive containing a thousand compressed files, a single filename has the capacity to hold up to 256 single byte characters, and each filename stored four times. 

    There are three points here. Consideration for unicode in archives exists only in the archive's compressed filenames. Compression algorithms remain heavily byte oriented, so the compressed data will always be reconstructed back to it's exact original decompressed state. Storing the ansi-string version of the filename is wasted space because when the archive signals the filename is UTF8 encoded, the stored ansi-string version of the filename is bypassed, and the UTF8 encoded string value is used.. Therefore, if our default UTF8 encoding method fails, so will the method of using extended headers. Second, the use of UTF8 encoding of filenames as the default in ZipTV, is universal in all archive formats supported. Only zip headers support extended headers; therefore, the method of supporting unicode with the use of extended headers is possible only in zip files. Third, the practice of bloating headers with junk data is reversing the small gains that's been achieved over the years in compression ratios.

    Not to imply it is not possible, but we have yet to test an archive containing UTF8 encoded filenames that fails decoding and proper reconstruction, even in double byte character set languages such as the Arabic. Unless we are provided with an instance where UTF8 encoded filenames in an archive fails decoding, we favor UTF8 encoding as the default method for writing filenames to all archive formats. ZipTV can properly read and extract unicode filenames from a zip file compressed using extended headers; however, we currently have no plans to pattern this method in compressing new files to a zip file. Other utility applications wishing to support default UTF8 encoded filenames, can simply test the stored filename to see if it is UTF8 encoded.

    Barriers in international communications are rapidly narrowing, and issues regarding character translations between languages are lessening. Even though great progress has been made over the past few years, it is not a perfected science yet. We do not in any way, purport to be experts on the subject of unicode, nor do we mean to imply that others are wrong in their use of extended headers for unicode support.  Only that we will not unquestionably pattern our development to follow the lead of others who have not proven a comparable level of understanding and uniformity in their development regarding unicode issues, as the Delphi folks have in their recent release of Delphi 2009.  

    We have listed our finding and reasoning for not agreeing with the use of extended headers to support unicode filenames in zip files. Opposing arguments are always welcome..

  2. TUnGZip: this issue involved a gzip compressed tarball (.tar.gz). 

    Archive:  distributor tar.gz
    Properties:
    UseStoredDirs property := true;
    ExtractDir := ‘c:\test’;

a. distributor tar.gz contains one compressed file:

  • data01\eserverdata\contentitems\19\61\test.tar

b. data01\eserverdata\contentitems\19\61\test.tar has two files:

  • NRC\ NRC Handelsblad - Maandag 8 december.pdf
  • System\Inbox\test.001.desktop

When the UseStoredDirs property was true, the two files in test.tar were incorrectly being extracted as:

  • c:\test\data01\eserverdata\contentitems\19\61\ NRC\ NRC Handelsblad - Maandag 8 december.pdf
  • c:\test\data01\eserverdata\contentitems\19\61\ System\Inbox\test.001.desktop

Note the above extracted directory’s combination of the values of the ExtractDir property (c:\test), pathname stored in the gzip archive (data01\eserverdata\contentitems\19\61\), and the pathname stored in the tar files (NRC\ and System\Inbox\).
 
Considering the property settings shown above correct files should be extracted to:

  • c:\test\NRC\ NRC Handelsblad - Maandag 8 december.pdf
  • c:\test\System\Inbox\test.001.desktop


v2008.11.30

v2008.9.29

v2008.8.04

v2008.4.21

v2008.4.20

v2008.2.16

v2008.1.21

v2007.9.24

v2007.7.29

v2007.6.26

v2007.5.29

v2007.5.7

v2007.3.12

v2007.3.8

v2007.2.26

v2007.1.31

v2006.11.1

v2006.10.26

v2006.10.1

Note: unicode / dbcs support is available in the components, only in registered source code versions. Due to a requirement to compile the sources locally, dcu versions are not supported. Non-unicode versions like in every other way.

The most comprehensive revision of the ZipTV Components to date!

v2006.2.16


v2006.1.16

v2006.1.16

v2006.1.0

v2005.6.4

v2005.6.3

New component demos: 1) demos\streamingdemos\ziptvstream\ziptvstream.dpr

v2005.6.1

v2005.5

v2005.4

v2005.3

v2005.2.1

v2005.2.0

v2005.1.0

v2005.0.2

v7.4

Added support for a WinXP limited user account. When attempting to extract to a directory the user does not have permissions for, a new OnLimitedUser event is activated. This event passes both the name of the protected directory and the users directory. Users directories are located off "documents and settings" and are generally the only directory that holds write protections for these user accounts.

v7.3 (beta due to ZipV2 encryption SeedKeys)
Beta additions subject to change without prior notice.

WinZip "v9 final" bug:  in multiple disk spanned archives, the PackedSize variable field
is not assigned a value in the LocalHeader of each compressed file that spans two or more diskettes.  We've included a workaround for this bug, but will not include workarounds for bugs found in their application in the future.

v7.2

  1. ZipV2 (zip version 2+) encryption now supports the revision of the three previously constant seed-keys.  These three keys have been hard coded in every application supporting zip password encryption for decades, leaving encrypted files vulnerable to the brute force hack attack.  Revising the value of these keys make the original zip encryption the absolute most secure method of protecting compressed archives with a password (even the AES algorithm is vulnerable to the brute force attack).
  2. Decompressors -> " OnGetPassword" event change: 

    In the demos\maindemo\MainDemo.dpr application, we assign the new seed keys (both header and data keys) within this event.

    Old:
    TOnGetPassword = Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString; Var TryAgain: Boolean) Of Object;

    New:   
    TOnGetPassword = Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString; Var HeaderKeys, DataKeys: TSeedKeyValues; Var TryAgain: Boolean) Of Object;

    See the following demonstration app for usage of the new HeaderKeys & DataKeys parameters:
       Demo:  demos\MainDemo.dpr
       Unit:  main.pas
       Procedure: TfrmMain.UnZIP1GetPassword
  3. New Properties:
    * SeedHeaderKeys (TZip, TJar, TBlakHole, TZipSplitter, TZipTV, TUnZip, TUnJar,   TUnBh TZipSearch TZipCheck, TZipRun components)  
    * SeedDataKeys (TZip, TJar, TBlakHole, TUnZip, TUnJar, TUnBh, TZipSearch, TZipCheck, TZipRun) Both properties are of type TSeedKeys (defined in ztvCrypt. pas - requires source version to see). 

    Type
       TSeedKeyType = (skDataKeys, skHeaderKeys);
        TSeedKeys = Class(TPersistent)
        Private
          SeedKeyType: TSeedKeyType;
          Function GetKeyValue(x: Integer): Cardinal;
          Function GetDefaultKeyValue(x: Integer): Cardinal;
           Procedure SetKeyValue(x: Integer; Value: Cardinal);
       Protected
        Public
          Constructor Create(sk: TSeedKeyType); Virtual;
          Procedure SetKeys(k0, k1, k2: String); Overload;
          Procedure SetKeys(k0, k1, k2: Cardinal); Overload;
          Procedure SetDefaultKeys;
          Property GetDefaultKey[x: Integer]: Cardinal Read GetDefaultKeyValue;
          Property Key[x: Integer]: Cardinal Read GetKeyValue Write SetKeyValue;
        Published
          Property Key0: Cardinal Index 0 Read GetKeyValue Write SetKeyValue;
           Property Key1: Cardinal Index 1 Read GetKeyValue Write SetKeyValue;
          Property Key2: Cardinal Index 2 Read GetKeyValue Write SetKeyValue;
        End;