OFF-SOFT.net » Archived

Sorry, this post is written by only Japanese language.

master — Sat, 02 Oct 2010 17:52:15 +0000

Sorry, this post is written by only Japanese language.

Japanease Only.

master — Wed, 11 Nov 2009 05:24:53 +0000

Japanease Only.

bz2 format

master — Fri, 10 Apr 2009 02:17:58 +0000

---------------------------------------------------------------------------------
BZ2 Header format
---------------------------------------------------------------------------------

.magic:16                       = 'BZ' signature/magic number
.version:8                      = 'h' for Bzip2 ('H'uffman coding), '0' for Bzip1 (deprecated)
.hundred_k_blocksize:8          = '1'..'9' block-size 100 kB-900 kB

.compressed_magic:48            = 0x314159265359 (BCD (pi))
.crc:32                         = checksum for this block
.randomised:1                   = 0=>normal, 1=>randomised (deprecated)
.origPtr:24                     = starting pointer into BWT for after untransform
.huffman_used_map:16            = bitmap, of ranges of 16 bytes, present/not present
.huffman_used_bitmaps:0..256    = bitmap, of symbols used, present/not present (multiples of 16)
.huffman_groups:3               = 2..6 number of different Huffman tables in use
.selectors_used:15              = number of times that the Huffman tables are swapped (each 50 bytes)
*.selector_list:1..6            = zero-terminated bit runs (0..62) of MTF'ed Huffman table (*selectors_used)
.start_huffman_length:5         = 0..20 starting bit length for Huffman deltas
*.delta_bit_length:1..40        = 0=>next symbol; 1=>alter length
                                                { 1=>decrement length;  0=>increment length } (*(symbols+2)*groups)
.contents:2..∞                  = Huffman encoded data stream until end of block

.eos_magic:48                   = 0x177245385090 (BCD sqrt(pi))
.crc:32                         = checksum for whole stream
.padding:0..7                   = align to whole byte

---------------------------------------------------------------------------------

Tar format

master — Fri, 10 Apr 2009 01:51:29 +0000

The content is not necessarily correct. Therefore, please refer.

-------------------------------------------------- -------------------------------
TAR format
-------------------------------------------------- -------------------------------

Offset Length Contents
   0 100 bytes File name ( '\ 0' terminated, 99 maxmum length)
100 8 bytes File mode (in octal ascii)
108 8 bytes User ID (in octal ascii)
116 8 bytes Group ID (in octal ascii)
124 12 bytes File size (s) (in octal ascii)
136 12 bytes Modify time (in octal ascii)
148 8 bytes Header checksum (in octal ascii)
156 1 bytes Link flag
157 100 bytes Linkname ( '\ 0' terminated, 99 maxmum length)
257 8 bytes Magic ( "ustar \ 0")
265 32 bytes User name ( '\ 0' terminated, 31 maxmum length)
297 32 bytes Group name ( '\ 0' terminated, 31 maxmum length)
329 8 bytes Major device ID (in octal ascii)
337 8 bytes Minor device ID (in octal ascii)
345 167 bytes Padding
512 (s + p) bytes File contents (s + p): = (((s) + 511) & ~ 511), round up to 512 bytes


Checksum:
int i, sum;
char * header = tar_header_pointer;
sum = 0;
for (i = 0; i <512; i + +)
     sum + = 0xFF & header [i];


/ * The linkflag defines the type of file * /
# define LF_OLDNORMAL '\ 0' / * Normal disk file, Unix compatible * /
# define LF_NORMAL'0 '/ * Normal disk file * /
# define LF_LINK'1 '/ * Link to previously dumped file * /
# define LF_SYMLINK'2 '/ * Symbolic link * /
# define LF_CHR'3 '/ * Character special file * /
# define LF_BLK'4 '/ * Block special file * /
# define LF_DIR'5 '/ * Directory * /
# define LF_FIFO'6 '/ * FIFO special file * /
# define LF_CONTIG'7 '/ * Contiguous file * /

+---------------------------------+
| header (header portion) 512bytes fixed |
+---------------------------------+
| data (data portion) 512bytes multiples of |
+---------------------------------+
|: |
| Header + data repeatedly in |
|: |
+---------------------------------+
| end of mark 1024bytes |
+---------------------------------+
  End of 1024 * 00 bytes of fill

(Note)
Header information is basically set in ASCII text.
Number is set as a string of decimal

-------------------------------------------------- --
Japanese names
-------------------------------------------------- --
File Name: 100
Attributes: 8
User ID: 8
Group ID: 8
File Size: 12
Updated: 12
Checksum: 8
Type: 1
Destination file name: 100
Magic number code version: 8
Guest Users: 32
Group name: 32
Device Major: 8
Minor device name: 8
Padding: 167

-------------------------------------------------- --
Description of Japanese
-------------------------------------------------- --
File name: ASCII SJIS or 100 bytes (including path name)
User ID / Group ID: "0" will represent the root
Last Modified: ustat () the value of the Last updated obtained that showed a string of eight binary
Checksum: Checksum header of 512 bytes
Magic code / version number: "ustar \ 0" + version number "00"
User / Group name: null terminated ASCII string of
Device Number Major / minor device number
    - The type [3] or [4] use only

Attributes: (UNIX and attributes) / 16 to be registered as an 8-bit binary string
Bit Position
0,1,2: Run the other attributes, write attributes, the attribute reading
3,4,5: run attributes of the group, write attributes, the attribute reading
6,7,8: run attributes of the owner, write attributes, the attribute reading
   9: Sticky bit
  10: Set GID
  11: Set UID
  12: pipe
  13: Special-character file
  14: directory
  15: regular file

Type:
  Character
   0: normal file
   1: Links
   2: symlink
   3: character device
   4: Block device
   5: directory
   6: FIFO Special Files
   7: KONTIGIASU? (Contiguous) file
A-Z: Book



-------------------------------------------------- --
Description of the tar format
-------------------------------------------------- --
tar files in multiple formats such as: mainly.

     * V7 (Version 7 Unix)
     * Town gnu
     * New gnu
     * POSIX.1-1988 (ustar)
     * POSIX.1-2001 (posix)

Of these, the most basic and V7, V7 or other extension header format,
Structure is completely different.

WinZIP normal and when you unpack the tar file
Can handle the file type, file and directory only in most normal
And symbolic links (more than normal files and directories) are largely ignored.
Also, hard links and special files, and also ignores the volume label.

Zip Format

master — Fri, 10 Apr 2009 01:47:20 +0000

Original Document http://www.pkware.com/company/standards/appnote/appnote.txt
Please download from its site if you want to know detail information.

File:    APPNOTE.TXT - .ZIP File Format Specification
Version: 6.3.1 
Revised: April 11, 2007
Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved.

The use of certain technological aspects disclosed in the current
APPNOTE is available pursuant to the below section entitled
"Incorporating PKWARE Proprietary Technology into Your Product".

I. Purpose
----------

This specification is intended to define a cross-platform,
interoperable file storage and transfer format.  Since its 
first publication in 1989, PKWARE has remained committed to 
ensuring the interoperability of the .ZIP file format through 
publication and maintenance of this specification.  We trust that 
all .ZIP compatible vendors and application developers that have 
adopted and benefited from this format will share and support 
this commitment to interoperability.

II. Contacting PKWARE
---------------------

     PKWARE, Inc.
     648 N. Plankinton Avenue, Suite 220
     Milwaukee, WI 53203
     +1-414-289-9788
     +1-414-289-9789 FAX
     zipformat@pkware.com

III. Disclaimer
---------------

Although PKWARE will attempt to supply current and accurate
information relating to its file formats, algorithms, and the
subject programs, the possibility of error or omission cannot 
be eliminated. PKWARE therefore expressly disclaims any warranty 
that the information contained in the associated materials relating 
to the subject programs and/or the format of the files created or
accessed by the subject programs and/or the algorithms used by
the subject programs, or any other matter, is current, correct or
accurate as delivered.  Any risk of damage due to any possible
inaccurate information is assumed by the user of the information.
Furthermore, the information relating to the subject programs
and/or the file formats created or accessed by the subject
programs and/or the algorithms used by the subject programs is
subject to change without notice.

If the version of this file is marked as a NOTIFICATION OF CHANGE,
the content defines an Early Feature Specification (EFS) change 
to the .ZIP file format that may be subject to modification prior 
to publication of the Final Feature Specification (FFS).  This
document may also contain information on Planned Feature 
Specifications (PFS) defining recognized future extensions.

IV. Change Log
--------------

Version       Change Description                        Date
-------       ------------------                       ----------
5.2           -Single Password Symmetric Encryption    06/02/2003
               storage

6.1.0         -Smartcard compatibility                 01/20/2004
              -Documentation on certificate storage

6.2.0         -Introduction of Central Directory       04/26/2004
               Encryption for encrypting metadata
              -Added OS/X to Version Made By values

6.2.1         -Added Extra Field placeholder for       04/01/2005
               POSZIP using ID 0x4690

              -Clarified size field on 
               "zip64 end of central directory record"

6.2.2         -Documented Final Feature Specification  01/06/2006
               for Strong Encryption

              -Clarifications and typographical 
               corrections

6.3.0         -Added tape positioning storage          09/29/2006
               parameters

              -Expanded list of supported hash algorithms

              -Expanded list of supported compression
               algorithms

              -Expanded list of supported encryption
               algorithms

              -Added option for Unicode filename 
               storage

              -Clarifications for consistent use
               of Data Descriptor records

              -Added additional "Extra Field" 
               definitions

6.3.1         -Corrected standard hash values for      04/11/2007
               SHA-256/384/512