magic.svn-base

来自「PHP 知识管理系统（基于树结构的知识管理系统）, 英文原版的PHP源码。」· SVN-BASE 代码 · 共 1,648 行 · 第 1/5 页

# Eric Fischer <[e-mail]>

# AppleWorks word processor:
#
# This matches the standard tab stops for an AppleWorks file, but if
# a file has a tab stop set in the first four columns this will fail.
#
# The "O" is really the magic number, but that's so common that it's
# necessary to check the tab stops that follow it to avoid false positives.

4       string          O====   AppleWorks word processor data
>85     byte&0x01       >0      \b, zoomed
>90     byte&0x01       >0      \b, paginated
>92     byte&0x01       >0      \b, with mail merge
#>91    byte            x       \b, left margin %d

# AppleWorks database:
#
# This isn't really a magic number, but it's the closest thing to one
# that I could find.  The 1 and 2 really mean "order in which you defined
# categories" and "left to right, top to bottom," respectively; the D and R
# mean that the cursor should move either down or right when you press Return.

#30	string		\x01D	AppleWorks database data
#30	string		\x02D	AppleWorks database data
#30	string		\x01R	AppleWorks database data
#30	string		\x02R	AppleWorks database data

# AppleWorks spreadsheet:
#
# Likewise, this isn't really meant as a magic number.  The R or C means
# row- or column-order recalculation; the A or M means automatic or manual
# recalculation.

#131	string		RA	AppleWorks spreadsheet data
#131	string		RM	AppleWorks spreadsheet data
#131	string		CA	AppleWorks spreadsheet data
#131	string		CM	AppleWorks spreadsheet data

# Applesoft BASIC:
#
# This is incredibly sloppy, but will be true if the program was
# written at its usual memory location of 2048 and its first line
# number is less than 256.  Yuck.

0       belong&0xff00ff 0x80000 Applesoft BASIC program data
#>2     leshort         x       \b, first line number %d

# ORCA/EZ assembler:
# 
# This will not identify ORCA/M source files, since those have
# some sort of date code instead of the two zero bytes at 6 and 7
# XXX Conflicts with ELF
#4       belong&0xff00ffff       0x01000000      ORCA/EZ assembler source data
#>5      byte                    x               \b, build number %d

# Broderbund Fantavision
#
# I don't know what these values really mean, but they seem to recur.
# Will they cause too many conflicts?

# Probably :-)
#2	belong&0xFF00FF		0x040008	Fantavision movie data

# Some attempts at images.
#
# These are actually just bit-for-bit dumps of the frame buffer, so
# there's really no reasonably way to distinguish them except for their
# address (if preserved) -- 8192 or 16384 -- and their length -- 8192
# or, occasionally, 8184.
#
# Nevertheless this will manage to catch a lot of images that happen
# to have a solid-colored line at the bottom of the screen.

8144	string	\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F	Apple II image with white background
8144	string	\x55\x2A\x55\x2A\x55\x2A\x55\x2A	Apple II image with purple background
8144	string	\x2A\x55\x2A\x55\x2A\x55\x2A\x55	Apple II image with green background
8144	string	\xD5\xAA\xD5\xAA\xD5\xAA\xD5\xAA	Apple II image with blue background
8144	string	\xAA\xD5\xAA\xD5\xAA\xD5\xAA\xD5	Apple II image with orange background

# Beagle Bros. Apple Mechanic fonts

0	belong&0xFF00FFFF	0x6400D000	Apple Mechanic font

# Apple Universal Disk Image Format (UDIF) - dmg files.
# From Johan Gade.
# These entries are disabled for now until we fix the following issues.
#
# Note there might be some problems with the "VAX COFF executable" 
# entry. Note this entry should be placed before the mac filesystem section, 
# particularly the "Apple Partition data" entry.
#
# The intended meaning of these tests is, that the file is only of the 
# specified type if both of the lines are correct - i.e. if the first
# line matches and the second doesn't then it is not of that type.
#
#0	long	0x7801730d
#>4	long	0x62626060	UDIF read-only zlib-compressed image (UDZO)
#
# Note that this entry is recognized correctly by the "Apple Partition 
# data" entry - however since this entry is more specific - this
# information seems to be more useful.
#0	long	0x45520200
#>0x410	string	disk\ image	UDIF read/write image (UDRW)

# From: Toby Peterson <[e-mail]>
0	string	bplist00	Apple binary property list

# Apple binary property list (bplist)
#  Assumes version bytes are hex.
#  Provides content hints for version 0 files. Assumes that the root
#  object is the first object (true for CoreFoundation implementation).
# From: David Remahl <[e-mail]>
0		string	bplist
>6		byte	x	\bCoreFoundation binary property list data, version 0x%c
>>7		byte	x	\b%c
>6		string		00		\b
>>8		byte&0xF0	0x00	\b
>>>8	byte&0x0F	0x00	\b, root type: null
>>>8	byte&0x0F	0x08	\b, root type: false boolean
>>>8	byte&0x0F	0x09	\b, root type: true boolean
>>8		byte&0xF0	0x10	\b, root type: integer
>>8		byte&0xF0	0x20	\b, root type: real
>>8		byte&0xF0	0x30	\b, root type: date
>>8		byte&0xF0	0x40    \b, root type: data
>>8		byte&0xF0	0x50	\b, root type: ascii string
>>8		byte&0xF0	0x60	\b, root type: unicode string
>>8		byte&0xF0	0x80	\b, root type: uid (CORRUPT)
>>8		byte&0xF0	0xa0	\b, root type: array
>>8		byte&0xF0	0xd0	\b, root type: dictionary

# Apple/NeXT typedstream data
#  Serialization format used by NeXT and Apple for various
#  purposes in YellowStep/Cocoa, including some nib files.
# From: David Remahl <[e-mail]>
2		string		typedstream	NeXT/Apple typedstream data, big endian
>0		byte		x		\b, version %hhd
>0		byte		<5		\b
>>13	byte		0x81	\b
>>>14	ubeshort	x		\b, system %hd
2		string		streamtyped NeXT/Apple typedstream data, little endian
>0		byte		x		\b, version %hhd
>0		byte		<5		\b
>>13	byte		0x81	\b
>>>14	uleshort	x		\b, system %hd

#------------------------------------------------------------------------------
# applix:  file(1) magic for Applixware
# From: Peter Soos <[e-mail]>
#
0	string		*BEGIN		Applixware
>7	string		WORDS			Words Document
>7	string		GRAPHICS		Graphic
>7	string		RASTER			Bitmap
>7	string		SPREADSHEETS		Spreadsheet
>7	string		MACRO			Macro
>7	string		BUILDER			Builder Object

#------------------------------------------------------------------------------
# archive:  file(1) magic for archive formats (see also "msdos" for self-
#           extracting compressed archives)
#
# cpio, ar, arc, arj, hpack, lha/lharc, rar, squish, uc2, zip, zoo, etc.
# pre-POSIX "tar" archives are handled in the C code.

# POSIX tar archives
257	string		ustar\0		POSIX tar archive
257	string		ustar\040\040\0	GNU tar archive

# cpio archives
#
# Yes, the top two "cpio archive" formats *are* supposed to just be "short".
# The idea is to indicate archives produced on machines with the same
# byte order as the machine running "file" with "cpio archive", and
# to indicate archives produced on machines with the opposite byte order
# from the machine running "file" with "byte-swapped cpio archive".
#
# The SVR4 "cpio(4)" hints that there are additional formats, but they
# are defined as "short"s; I think all the new formats are
# character-header formats and thus are strings, not numbers.
0	short		070707		cpio archive
0	short		0143561		byte-swapped cpio archive
0	string		070707		ASCII cpio archive (pre-SVR4 or odc)
0	string		070701		ASCII cpio archive (SVR4 with no CRC)
0	string		070702		ASCII cpio archive (SVR4 with CRC)

# Debian package (needs to go before regular portable archives)
#
0	string		=!<arch>\ndebian
>8	string		debian-split	part of multipart Debian package
>8	string		debian-binary	Debian binary package
>68	string		>\0		(format %s)
# These next two lines do not work, because a bzip2 Debian archive
# still uses gzip for the control.tar (first in the archive).  Only
# data.tar varies, and the location of its filename varies too.
# file/libmagic does not current have support for ascii-string based
# (offsets) as of 2005-09-15.
#>81	string		bz2		\b, uses bzip2 compression
#>84	string		gz		\b, uses gzip compression
#>136	ledate		x		created: %s

# other archives
0	long		0177555		very old archive
0	short		0177555		very old PDP-11 archive
0	long		0177545		old archive
0	short		0177545		old PDP-11 archive
0	long		0100554		apl workspace
0	string		=<ar>		archive

# MIPS archive (needs to go before regular portable archives)
#
0	string	=!<arch>\n__________E	MIPS archive
>20	string	U			with MIPS Ucode members
>21	string	L			with MIPSEL members
>21	string	B			with MIPSEB members
>19	string	L			and an EL hash table
>19	string	B			and an EB hash table
>22	string	X			-- out of date

0	string		-h-		Software Tools format archive text

#
# XXX - why are there multiple <ar> thingies?  Note that 0x213c6172 is
# "!<ar", so, for new-style (4.xBSD/SVR2andup) archives, we have:
#
# 0	string		=!<arch>		current ar archive
# 0	long		0x213c6172	archive file
#
# and for SVR1 archives, we have:
#
# 0	string		\<ar>		System V Release 1 ar archive
# 0	string		=<ar>		archive
#
# XXX - did Aegis really store shared libraries, breakpointed modules,
# and absolute code program modules in the same format as new-style
# "ar" archives?
#
0	string		=!<arch>		current ar archive
>8	string		__.SYMDEF	random library
>0	belong		=65538		- pre SR9.5
>0	belong		=65539		- post SR9.5
>0	beshort		2		- object archive
>0	beshort		3		- shared library module
>0	beshort		4		- debug break-pointed module
>0	beshort		5		- absolute code program module
0	string		\<ar>		System V Release 1 ar archive
0	string		=<ar>		archive
#
# XXX - from "vax", which appears to collect a bunch of byte-swapped
# thingies, to help you recognize VAX files on big-endian machines;
# with "leshort", "lelong", and "string", that's no longer necessary....
#
0	belong		0x65ff0000	VAX 3.0 archive
0	belong		0x3c61723e	VAX 5.0 archive
#
0	long		0x213c6172	archive file
0	lelong		0177555		very old VAX archive
0	leshort		0177555		very old PDP-11 archive
#
# XXX - "pdp" claims that 0177545 can have an __.SYMDEF member and thus
# be a random library (it said 0xff65 rather than 0177545).
#
0	lelong		0177545		old VAX archive
>8	string		__.SYMDEF	random library
0	leshort		0177545		old PDP-11 archive
>8	string		__.SYMDEF	random library
#
# From "pdp" (but why a 4-byte quantity?)
#
0	lelong		0x39bed		PDP-11 old archive
0	lelong		0x39bee		PDP-11 4.0 archive

# ARC archiver, from Daniel Quinlan ([e-mail])
#
# The first byte is the magic (0x1a), byte 2 is the compression type for
# the first file (0x01 through 0x09), and bytes 3 to 15 are the MS-DOS
# filename of the first file (null terminated).  Since some types collide
# we only test some types on basis of frequency: 0x08 (83%), 0x09 (5%),
# 0x02 (5%), 0x03 (3%), 0x04 (2%), 0x06 (2%).  0x01 collides with terminfo.
0	lelong&0x8080ffff	0x0000081a	ARC archive data, dynamic LZW
0	lelong&0x8080ffff	0x0000091a	ARC archive data, squashed
0	lelong&0x8080ffff	0x0000021a	ARC archive data, uncompressed
0	lelong&0x8080ffff	0x0000031a	ARC archive data, packed
0	lelong&0x8080ffff	0x0000041a	ARC archive data, squeezed
0	lelong&0x8080ffff	0x0000061a	ARC archive data, crunched
# [JW] stuff taken from idarc, obviously ARC successors:
0	lelong&0x8080ffff	0x00000a1a	PAK archive data
0	lelong&0x8080ffff	0x0000141a	ARC+ archive data
0	lelong&0x8080ffff	0x0000481a	HYP archive data

# Acorn archive formats (Disaster prone simpleton, [e-mail])
# I can't create either SPARK or ArcFS archives so I have not tested this stuff
# [GRR:  the original entries collide with ARC, above; replaced with combined
#  version (not tested)]
#0	byte		0x1a		RISC OS archive (spark format)
0	string		\032archive	RISC OS archive (ArcFS format)
0       string          Archive\000     RISC OS archive (ArcFS format)

# All these were taken from idarc, many could not be verified. Unfortunately,
# there were many low-quality sigs, i.e. easy to trigger false positives.
# Please notify me of any real-world fishy/ambiguous signatures and I'll try
# to get my hands on the actual archiver and see if I find something better. [JW]
# probably many can be enhanced by finding some 0-byte or control char near the start

# idarc calls this Crush/Uncompressed... *shrug*
0	string	CRUSH Crush archive data
# Squeeze It (.sqz)
0	string	HLSQZ Squeeze It archive data
# SQWEZ
0	string	SQWEZ SQWEZ archive data
# HPack (.hpk)
0	string	HPAK HPack archive data
# HAP
0	string	\x91\x33HF HAP archive data
# MD/MDCD
0	string	MDmd MDCD archive data
# LIM
0	string	LIM\x1a LIM archive data
# SAR
3	string	LH5 SAR archive data
# BSArc/BS2
0	string	\212\3SB \0 BSArc/BS2 archive data
# MAR
2	string	=-ah MAR archive data
# ACB
0	belong&0x00f800ff	0x00800000 ACB archive data
# CPZ
# TODO, this is what idarc says: 0	string	\0\0\0 CPZ archive data
# JRC
0	string	JRchive JRC archive data