Mercurial > hg > Blog
comparison content/GNUstep/new-zipper-release.md @ 0:4cd9b65e10e4
initial import of the pelican based blog
| author | Dirk Olmes <dirk@xanthippe.ping.de> |
|---|---|
| date | Fri, 28 Jun 2013 08:48:58 +0200 |
| parents | |
| children | 1d9382b0329b |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:4cd9b65e10e4 |
|---|---|
| 1 Title: New Zipper release | |
| 2 Date: 2007-05-22 | |
| 3 Lang: en | |
| 4 | |
| 5 I had to debug Mule's build for the upcoming 1.4.1 release a bit, especially the packaging of the JCA distribution. I usually use Zipper to open archives, that's why I wrote it in the first place. It turns out that some file extensions are ambiguous, e.g. a file ending in .rar could either be a rar archive or a Java Resource ARchive which is effectively a zip file. Since the rar packager cannot handle zip files I picked up an idea I had in mind for a long time now: file types should not be determined by their extensions but the way the unix file command does it: by looking for certain patterns inside of a file. I implemented the most simple cases in Zipper now: Zip files begin with | |
| 6 | |
| 7 { 'P', 'K', 0x003, 0x004 } | |
| 8 | |
| 9 and rar files begin with | |
| 10 | |
| 11 { 'R', 'a', 'r', '!'} | |
| 12 | |
| 13 straight from the beginning of the file. When opening a file Zipper asks all registered Archive subclasses for their magic bytes and compares them to the first four bytes of the file. I think I will extend this mechanism a bit in the future so in the end all supported archives will be determined by a file's content and not by its file extension any more. |