readme

harvest是一个下载html网页得机器人

    As its name suggests, it does the same as BinHex 5.0.
UMCP:
    Looks similar, but the file as stored by UMCP is not true MacBinary.
    Size fields are modified, the result is not padded to a multiple of 128,
    etc.  Macunpack deals with all that, but until now is not able to
    correctly restore the finder flags of the original file.  Also, UMCP
    created files have type "TEXT" and creator "ttxt", which can create a
    bit of confusion.  Macunpack will recognize these files only if the
    creator has been modified to "UMcp".

Compressors:
ShrinkToFit:
    This program uses a Huffman code to compress.  It has an option (default
    checked for some reason), COMP, for which I do not yet know the
    meaning.  Compressing more than a single file in a single run results
    in a failure for the second and subsequent files.
Compress It:
    Also uses a Huffman code to compress.
MacCompress:
    MacCompress has two modes of operation, the first mode is (confusingly)
    MacCompress, the second mode is (again confusingly) UnixCompress.  In
    MacCompress mode both forks are compressed using the LZC algorithm.
    In UnixCompress mode only the data fork is compressed, and some shuffling
    of resources is performed.  Upto now macunpack only deals with MacCompress
    mode.  The LZC variant MacCompress uses depends on memory availability.
    12 bit to 16 bit LZC can be used.

Archivers:
ArcMac:
    Nearly PC-Arc compatible.  Arc knows 8 compression methods, I have seen
    all of them used by ArcMac, except the LZW techniques.  Here they are:
    1:	No compression, shorter header
    2:	No compression
    3:	(packing) Run length encoding
    4:	(squeezing) RLE followed by Huffman encoding
    5:	(crunching) LZW
    6:	(crunching) RLE followed by LZW
    7:	(crunching) as the previous but with a different hash function
    8:	(crunching) RLE followed by 12-bit LZC
    9:	(squashing) 13-bit LZC
PackIt:
    When archiving a file PackIt either stores the file uncompressed or
    stores the file Huffman encoded.  In the latter case both forks are
    encoded using the same Huffman tree.
StuffIt and StuffIt Classic/Deluxe:
    These have the ability to use different methods for the two forks of a
    file.  The following standard methods I do know about (the last three
    are only used by the Classic/Deluxe version 2.0 of StuffIt):
    0:	No compression
    1:	Run length encoding
    2:	14-bit LZC compression
    3:	Huffman encoding
    5:	LZAH: like LZH, but the Huffman coding used is adaptive
    6:	A Huffman encoding using a fixed (built-in) Huffman tree
    8:	A MW encoding
Diamond:
    Uses a LZ77 like frontend plus a Fraenkel-Klein like backend (see
    Apostolico & Galil, Combinatorial Algorithms on Words, pages 169-183).
Compactor/Compact Pro:
    Like StuffIt, different encodings are possible for data and resource fork.
    Only two possible methods are used:
    0:	Run length encoding
    1:	RLE followed by some form of LZH
Zoom:
    Data and resource fork are compressed with the same method.  The standard
    uses either no compression or some form of LZH
MacLHa:
    Has two basic modes of operation, Mac mode and Normal mode.  In Mac mode
    the file is archived in MacBinary form.  In normal mode only the forks
    are archived.  Normal mode should not be used (and can not be unpacked
    by macunpack) as all information about data fork size/resource fork size,
    type, creator etc. is lost.  It knows quite a few methods, some are
    probably only used in older versions, the only methods I have seen used
    are -lh0-, -lh1- and -lh5-.  Methods known by MacLHa:
    -lz4-:  No compression
    -lz5-:  LZSS
    -lzs-:  LZSS, another variant
    -lh0-:  No compression
    -lh1-:  LZAH (see StuffIt)
    -lh2-:  Another form of LZAH
    -lh3-:  A form of LZH, different from the next two
    -lh4-:  LZH with a 4096 byte buffer (as far as I can see the coding in
	    MacLHa is wrong)
    -lh5-:  LZH with a 8192 byte buffer
DiskDoubler:
    The older version of DiskDoubler is compatible with MacCompress.  It does
    not create archives, it only compresses files.  The newer version (since
    3.0) does both archiving and compression.  The older version uses LZC as
    its compression algorithm, the newer version knows a number of different
    compression algorithms.  Many (all?) are algorithms used in other
    archivers.  Probably this is done to simplify conversion from other formats
    to DiskDoubler format archives.  I have seen actual DiskDoubler archives
    that used methods 0, 1 and 8:
    0:	No compression
    1:	LZC
    2:	unknown
    3:	RLE
    4:	Huffman (or no compression)
    5:	unknown
    6:	unknown
    7:	An improved form of LZSS
    8:	Compactor/Compact Pro compatible RLE/LZH or RLE only
    9:	unknown
    The DiskDoubler archive format contains many subtle twists that make it
    difficult to properly read the archive (or perhaps this is on purpose?).

Naming:
Some people have complained about the name conflict with the unpack utility
that is already available on Sys V boxes.  I had forgotten it, so there
really was a problem.  The best way to solve it was to trash pack/unpack/pcat
and replace it by compress/uncompress/zcat.  Sure, man uses it; but man uses
pcat, so you can retain pcat.  If that was not an option you were able to feel
free to rename the program.  But finally I relented.  It is now macunpack.

When you have problems unpacking an archive feel free to ask for information.
I am especially keen when the program detects an unknown method.  If you
encounter such an archive, please, mail a 'binhexed' copy of the archive
to me so that I can deal with it.  Password protected archives are (as
already stated) not implemented.  I do not have much inclination to do that.
Also I feel no inclination to do multi-segment archives.

-------------------------------------------------------------------------------
Hexbin will de-hexify files created in BinHex 4.0 compatible format (hqx)
but also the older format (dl, hex and hcx).  Moreover it will uudecode
files uuencoded by UUTool (the only program I know that does UU hexification
of all Mac file information).

There are currently many programs that are able to create files in BinHex 4.0
compatible format.  There are however some slight differences, and most
de-hexifiers are not able to deal with all the variations.  This program is
very simple minded.  First it will intuit (based on the input) whether the
file is in dl, hex, hcx or hqx format.  Next it will de-hexify the file.
When the format is hqx, it will check whether more files follow, and continue
processing.  So you can catenate multiple (hqx) hexified files together and
feed them as a single file to hexbin.  Also hexbin does not mind whether lines
are separated by CR's, LF's or combinations of the two.  Moreover, it will
strip all leading, trailing and intermediate garbage introduced by mailers
etc.  Next, it does not mind if a file is not terminated by a CR or an LF
(as StuffIt 1.5.1 and earlier did), but in that case a second file is not
allowed to follow it.  Last, while most hexifiers output lines of equal length,
some do not.  Hexbin will deal with that, but there are some caveats; see the
-c option in the man page.

Background:

dl format:
    This was the first hexified format used.  Programs to deal with it came
    from SUMacC.  This format only coded resource forks, 4 bits in a byte.
hex format:
    I think this is the first format from Yves Lempereur.  Like dl format,
    it codes 4 bits in a byte, but is able to code both resource and
    data fork.  Is it BinHex 2.0?
hcx format:
    A compressing variant of hex format.  Codes 6 bits in a byte.
    Is it BinHex 3.0?
hqx format:
    Like hcx, but using a different coding (possibly to allow for ASCII->EBCDIC
    and EBCDIC->ASCII translation, which not always results in an identical
    file).  Moreover this format also encodes the original Mac filename.
mu format:
    The conversion can be done by the UUTool program from Octavian Micro
    Development.  It encodes both forks and also some finder info.  You will
    in general not use this with uudecode on non Mac systems, with uudecode
    only the data fork will be uudecoded.  UU hexification is well known (and
    fairly old) in Unix environments.  Moreover it has been ported to lots of
    other systems.
-------------------------------------------------------------------------------
Macsave reads a MacBinary stream from standard input and writes the
files according to the options.
-------------------------------------------------------------------------------
Macstream reads files from the Unix host and will output a MacBinary stream
containing all those files together with information about the directory
structure.
-------------------------------------------------------------------------------
Binhex will read a MacBinary stream, or will read files/directories as
indicated on the command line, and will output all files in binhexed (.hqx)
format.  Information about the directory structure is lost.
-------------------------------------------------------------------------------
Tomac will transmit a MacBinary stream, or named files to the Mac using
the XMODEM protocol.
-------------------------------------------------------------------------------
Frommac will receive one or more files from the Mac using the XMODEM protocol.
-------------------------------------------------------------------------------
This is an ongoing project, more stuff will appear.

All comments are still welcome.  Thanks for the comments I already received.

dik t. winter, amsterdam, nederland
email: [e-mail]

--
Note:
In these programs all algorithms are implemented based on publicly available
software to prevent any claim that would prevent redistribution due to
Copyright.  Although parts of the code would indeed fall under the Copyright
by the original author, use and redistribution of all such code is explicitly
allowed.  For some parts of it the GNU software license does apply.
--
Appendix.

BinHex 4.0 compatible file creators:

Type	Creator		Created by

"TEXT"	"BthX"		BinHqx
"TEXT"	"BNHQ"		BinHex
"TEXT"	"BnHq"		StuffIt and StuffIt Classic
"TEXT"	"ttxt"		Compactor

Files recognized by macunpack:

Type	Creator		Recognized as

"APPL"	"DSEA"		"DiskDoubler"		Self extracting
"APPL"	"EXTR"		"Compactor"		Self extracting
"APPL"	"Mooz"		"Zoom"			Self extracting
"APPL"	"Pack"		"Diamond"		Self extracting
"APPL"	"arc@"		"ArcMac"		Self extracting (not yet)
"APPL"	"aust"		"StuffIt"		Self extracting
"ArCv"	"TrAS"		"AutoSqueeze"				(not yet)
"COMP"	"STF "		"ShrinkToFit"
"DD01"	"DDAP"		"DiskDoubler"
"DDAR"	"DDAP"		"DiskDoubler"
"DDF."	"DDAP"		"DiskDoubler" (any fourth character)
"DDf."	"DDAP"		"DiskDoubler" (any fourth character)
"LARC"	"LARC"		"MacLHa (LHARC)"
"LHA "	"LARC"		"MacLHa (LHA)"
"PACT"	"CPCT"		"Compactor"
"PIT "	"PIT "		"PackIt"
"Pack"	"Pack"		"Diamond"
"SIT!"	"SIT!"		"StuffIt"
"SITD"	"SIT!"		"StuffIt Deluxe"
"Smal"	"Jdw "		"Compress It"
"TEXT"	"BnHq"		"BinHex 5.0"
"TEXT"	"GJBU"		"MacBinary 1.0"
"TEXT"	"UMcp"		"UMCP"
"ZIVM"	"LZIV"		"MacCompress(M)"
"ZIVU"	"LZIV"		"MacCompress(U)"			(not yet)
"mArc"	"arc*"		"ArcMac"				(not yet)
"zooM"	"zooM"		"Zoom"