gabriel rosenkoetter on Thu, 22 Aug 2002 18:30:10 +0200 |
On Thu, Aug 22, 2002 at 05:01:12PM +0200, Jeff Abrahamson wrote: > No problem: <http://www.purple.com/image.bin>. Ummm... that file extension screams MacBinary compression. Decompress it. This should match it: 122 beshort&0xFCFF 0x8081 Macintosh MacBinary data ... but I just downloaded it and it doesn't. Perhaps you've managed to flip the endianness of it somewhere along the line? Ah, this might explain it: # MacBinary format (Eric Fischer, enf@pobox.com) # # Unfortunately MacBinary doesn't really have a magic number prior # to the MacBinary III format. The checksum is really the way to # do it, but the magic file format isn't up to the challenge. # [Specifics of the file format, clipped for brevity] # # This attempts to use the version numbers as a magic number, requiring # that the first one be 0x80, 0x81, 0x82, or 0x83, and that the second # be 0x81. This works for the files I have, but maybe not for everyone's. 122 beshort&0xFCFF 0x8081 Macintosh MacBinary data # MacBinary I doesn't have the version number field at all, but MacBinary II # has been in use since 1987 so I hope there aren't many really old files # floating around that this will miss. The original spec calls for using # the nulls in 0, 74, and 82 as the magic number. # # Another possibility, that would also work for MacBinary I, is to use # the assumption that 65-72 will all be ASCII (0x20-0x7F), that 73 will # have bits 1 (changed), 2 (busy), 3 (bozo), and 6 (invisible) unset, # and that 74 will be 0. So something like # # 71 belong&0x80804EFF 0x00000000 Macintosh MacBinary data # # >73 byte&0x01 0x01 \b, inited # >73 byte&0x02 0x02 \b, changed # >73 byte&0x04 0x04 \b, busy # >73 byte&0x08 0x08 \b, bozo # >73 byte&0x10 0x10 \b, system # >73 byte&0x10 0x20 \b, bundle # >73 byte&0x10 0x40 \b, invisible # >73 byte&0x10 0x80 \b, locked Using that second matching method gets me: humbug:~% file -m tmp/magic image.bin file: Using regular magic file `tmp/magic' image.bin: Macintosh MacBinary data, type " ", creator " " Hah! Got anything handy that speaks Mac compression formats? Maybe macutil from ftp://ftp.cwi.nl/pub/dik/ would help? > Package xv has no installation candidate, says apt-get. So apt-get > install xview-clients, but that's not it. Oh, well. It probably > wouldn't have worked, anyway. ;-) Huh. It's its own package under NetBSD's pkgsrc. ::shrug:: > Well, it was ftp'd from my old Mac two years ago to my linux box. I > wouldn't expect much damage, though it's certainly possible. Did you transfer it using binary or ascii mode? (The latter will break that file, if it's really a MacBinary I file. That's what BinHex and UUEncode are for.) > It still doesn't look like anything real to me. I look forward to your > opinion(s). Here 'tis. > Mind you, this has become a matter of pride more than necessity, since > my brother says he can open it and convert it to a different format. I > like to think I can do most everything besides quicktime on my linux > box. He's opening it because jpegViewer is doing on-the-fly decompression of the MacBinary I format. I'd forgotten it could do that, but the more I think about it I think I even remember a preference setting for that. -- gabriel rosenkoetter gr@eclipsed.net Attachment:
pgpT4GSZro4C1.pgp
|
|