📄 swffileformat.html
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>A Concise Guide to the SWF File Format</title>
<style type="text/css">
<!--
H1 {font-family: Arial, Helvetica, sans-serif;
font-size: 24pt;
font-weight: 900;
}
H2 {font-family: Arial, Helvetica, sans-serif;
font-size: 18pt;
font-weight: 700;
}
H3 {font-family: Arial, Helvetica, sans-serif;
font-size: 14pt;
font-weight: 700;
}
H4 {font-family: Arial, Helvetica, sans-serif;
font-size: 12pt;
font-weight: 700;
}
H5 {font-family: Arial, Helvetica, sans-serif;
font-size: 12pt;
font-weight: 500;
}
.runInHead {font-family: Arial, Helvetica, sans-serif;
font-size: 11pt;
font-weight: 700;
}
-->
</style>
</head>
<body bgcolor="#FFFFFF" link="#FF0000" vlink="#333399" text="#000000">
<a name="h1FileFormat"> </a>
<h1 align="center">SWF File Format Specification</h1>
<p> The SWF (pronounced 'swiff') file format was designed from the ground up to
deliver graphics and animation over the Internet. The SWF file format was designed
as a very efficient delivery format and not as a format for exchanging graphics
between graphics editors. It was designed to meet the following goals: </p>
<ul>
<li><span class="runInHead">On-screen Display—</span>The format is primarily
intended for on-screen display and so it supports anti-aliasing, fast rendering
to a bitmap of any color format, animation and interactive buttons.</li>
<li><span class="runInHead">Extensibility—</span>The format is a tagged format,
so the format can be evolved with new features while maintaining backwards compatibility
with older players.</li>
<li><span class="runInHead">Network Delivery—</span>The files can be delivered
over a network with limited and unpredictable bandwidth. The files are compressed
to be small and support incremental rendering through streaming.</li>
<li><span class="runInHead">Simplicity—</span>The format is simple so that
the player is small and easily ported. Also, the player depends upon only a very
limited set of operating system functionality.</li>
<li><span class="runInHead">File Independence—</span>Files can be displayed
without any dependence on external resources such as fonts.</li>
<li><span class="runInHead">Scalability—</span>Different computers have different
monitor resolutions and bit depths. Files work well on limited hardware, while
taking advantage of more expensive hardware when it is available.</li>
<li><span class="runInHead">Speed—</span>The files are designed to be rendered
at a high quality very quickly.</li>
</ul>
<p>
The following document describes the file format in detail.
</p>
<a name="h2BasicConcepts"> </a>
<h2>Basic Concepts</h2>
<a name="h3ContainerFormat"> </a>
<h3>Container Format</h3>
<p> SWF files are stored in files with the extension .swf and currently for historical
reasons the MIME type is application/x-shockwave-flash. SWF files are binary
files stored as 8-bit bytes. The container format consists of a header block
with the structure shown below. </p>
<table border cellspacing=2 bordercolor="#000000" cellpadding=7 width=100%>
<tr valign="top">
<td width="33%" bgcolor="#CCCCCC"><b>Field</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Type</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Comment</b></td>
</tr>
<tr valign="top">
<td width="33%">Signature</td>
<td width="33%">UI8</td>
<td width="33%">Signature byte 1 - always 'F'</td>
</tr>
<tr valign="top">
<td width="33%">Signature</td>
<td width="33%">UI8</td>
<td width="33%">Signature byte 2 - always 'W'</td>
</tr>
<tr valign="top">
<td width="33%">Signature</td>
<td width="33%">UI8</td>
<td width="33%">Signature byte 3 - always 'S'</td>
</tr>
<tr valign="top">
<td width="33%">Version </td>
<td width="33%">UI8</td>
<td width="33%">Single byte file version</td>
</tr>
<tr valign="top">
<td width="33%">File Length</td>
<td width="33%">UI32</td>
<td width="33%">Length of entire file in bytes</td>
</tr>
<tr valign="top">
<td width="33%">Frame Size</td>
<td width="33%">RECT</td>
<td width="33%">Frame size in TWIPS</td>
</tr>
<tr valign="top">
<td width="33%">Frame Rate</td>
<td width="33%">UI16</td>
<td width="33%">Frame delay in 8.8 fixed number of frames per second</td>
</tr>
<tr valign="top">
<td width="33%">Frame Count</td>
<td width="33%">UI16</td>
<td width="33%">Total number of frames in movie</td>
</tr>
</table>
<p>
Following the header are a series of tagged data blocks. Each data block has a tag type (stag) and a length. There is both a short and long tag format. Short tags are used for blocks with 62 bytes of data or less and large tags can be used for any size block. A short tag has 9 bits used for the block type and 6 bits used for a block length in number of bytes. If a block is 63 bytes or longer, it should be stored in a long tag which consists of a short tag whose length is 0x3f and is followed by a 32-bit length.
</p>
<p>
The following tables show the structure of both short and long tag record headers.
</p>
<h5>Short header - for records less than 63 bytes in length</h5>
<table border cellspacing=2 bordercolor="#000000" cellpadding=7 width=100%>
<tr valign="top">
<td width="33%" bgcolor="#CCCCCC"><b>Field</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Type</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Comment</b></td>
</tr>
<tr valign="top">
<td width="33%">Tag</td>
<td width="33%">UB[10]</td>
<td width="33%">Tag id</td>
</tr>
<tr valign="top">
<td width="33%">Length</td>
<td width="33%">UB[6]</td>
<td width="33%">Length of tag</td>
</tr>
</table>
<h5>Long header - for records 63 bytes in length or greater</h5>
<table border cellspacing=2 bordercolor="#000000" cellpadding=7 width=100%>
<tr valign="top">
<td width="33%" bgcolor="#CCCCCC"><b>Field</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Type</b></td>
<td width="33%" bgcolor="#CCCCCC"><b>Comment</b></td>
</tr>
<tr valign="top">
<td width="33%">Tag</td>
<td width="33%">UB[10]</td>
<td width="33%">Tag id</td>
</tr>
<tr valign="top">
<td width="33%">Long Header Flag</td>
<td width="33%">UB[6]</td>
<td width="33%">Always 0x3F </td>
</tr>
<tr valign="top">
<td width="33%">Length</td>
<td width="33%">UI32</td>
<td width="33%">Length of tag</td>
</tr>
</table>
<p> Any program parsing a SWF file can skip over blocks it does not understand.
Data blocks can point to offsets within the block, but they should never point
to an offset in another block. This enables tags to be removed, inserted, or
modified by tools that process a SWF file. With some network transports like
RealFlash, data blocks can be reordered and delivered with different priorities.
</p>
<p>
Currently, many useful block types are defined. Tag numbers 0-511 are reserved for future use. Tag numbers 512-1023 are reserved for use by third party applications. For more information on developing extension mechanisms, see the extension mechanism section.
</p>
<a name="h3TypesofTags"> </a>
<h3>Types of Tags</h3>
<p>
Definition tags are used to add character information to the dictionary. Definition tags define data that can be reused in a file like shapes, bitmaps, buttons, text, fonts and sounds. Control tags manipulate characters and provide administrative functions. For example, control tags are used to move objects on the screen, show frames, and start sounds. For information on specific tags, see the Tag Reference section.
</p>
<a name="h3TagOrderingandStreaming"> </a>
<h3>Tag Ordering and Streaming</h3>
<p>
Tags can occur in the file in any order. Definition tags must occur in the file before any control tags that refer to the character that is defined. The order of control tags defines the order of the animation.
</p>
<p> This ordering of tags is how the SWF file format supports streaming. The rule
is that a given tag should only depend on tags that come before it. A tag should
never depend on a tag that comes later in the file. </p>
<p>
The End tag should be used at the end of the file to indicate the file's end.
</p>
<a name="h3CharactersandtheDictionary"> </a>
<h3>Characters and the Dictionary</h3>
<p> In order to support streaming and references between tags, SWF uses the concept
of characters and a dictionary of characters that have been encountered so far
in a file. A character has a 16-bit numeric name. Every character in a file
must have a unique name. Typically, the first character is #1, the second character
is #2 and so on. Character #0 is special and considered a null character. </p>
<p>
Characters are entered into the dictionary when a define tag is encountered in the .swf file. Characters are looked up in the dictionary based on the character identification number.
</p>
<a name="h3DisplayList"> </a>
<h3>Display List</h3>
<p> Conceptually, the SWF file format can be considered as two interleaved streams
of data. The definition stream adds characters to the dictionary and the control
stream performs operations on the display list using the characters that have
been defined in the dictionary. </p>
<p> In SWF 1 and 2, the display list was a flat list of the objects that are present
on the screen at any given point in time. For SWF 3, this list has been extended
to a hierarchical list where an element on the display can have a list of child
elements. </p>
<p>
Objects on the display list are referred to by a depth number. The object at depth 0 is the bottom of the stacking order. Only one object can exist at any given depth.
</p>
<p>
There are three basic operations on the display list:
</p>
<ul>
<li><span class="runInHead">Place an object—</span>Place an character on
at a given depth level using a specified transform.</li>
<li><span class="runInHead">Move an object—</span>Modify the object at the
given depth level. Both the transform and the character can be modified.</li>
<li><span class="runInHead">Remove an object—</span>Remove the object at
a given depth number from the display.</li>
</ul>
<p> Note that for SWF 1 and 2, the only operations are Place and Remove. Move
was added to support sprites and as a size optimization for SWF 3. </p>
<a name="h3NumbersandCoordinates"> </a>
<h3>Numbers and Coordinates</h3>
<p> SWF uses integers and fixed point numbers for all of its coordinates and transformation
matrices. The coordinate space is defined by integer coordinates. This coordinate
space can be mapped to the display in any way that a player might want. By convention,
coordinates are specified where one unit equal 1/1440 inches. On a typical 72
dpi display this is equivalent to saying that a single pixel is divided into
20 units. This choice of units provides a good compromise between giving a high
resolution for zooming in and precise placement of objects. A higher resolution
would increased the file size because of the extra bits needed for precision.
</p>
<a name="h3Transforms"> </a>
<h3>Transforms</h3>
<p>
<span class="runInHead">Matrices—</span>Object positioning is specified by
a standard 2x3 transformation matrix using 16.16 fixed point numbers for the first
four elements and integers for the last two elements.
</p>
<p> <span class="runInHead">Color Transforms—</span>SWF uses color transforms
to perform effects like fading in or out from an object on the display. The
color transform consists of a simple linear equation that is applied to each
color element of an object. </p>
<p>
<span class="runInHead">Ratio—</span>For some objects like morphed shapes,
a 16-bit ratio is used to control what point in the morph should be displayed.
The ratio is also used to track the lifetime of sprite objects.
</p>
<p> <span class="runInHead">Clip depth—</span>An object on the SWF display
list can be used as a clipping path for range of objects. This is controlled
by the clip depth field for Place object. </p>
<a name="h3ProcessingaSWFFile"> </a>
<h3>Processing a SWF File</h3>
<p>
The model for processing a stream is that all tags are processed in a stream until a ShowFrame tag is encountered. At that point, the display list is copied to the screen and the player is idle until it is time to process the next frame.
</p>
<p> A SWF file is divided into numbered frames by ShowFrame tags. Frame 1 is defined
by performing all the control operations before the first ShowFrame tag. Frame
2 is defined by performing all the control operations before the second ShowFrame
tag and so on. </p>
<a name="h3FileCompressionStrategy"> </a>
<h3>File Compression Strategy</h3>
<p> Since SWF files are frequently delivered over a network connection, it is
important that they be as compact as possible. There are several techniques
that are used to accomplish this: </p>
<ul>
<li><span class="runInHead">Reuse—</span>The structure of the character dictionary
makes it very easy to reuse elements in a SWF file. For example, a shape,
button, sound, font, or bitmap can be stored in a file once and referenced
many times.</li> <li><span class="runInHead">Compression—</span>The contents of tags are compressed.
SWF supports a variety of compression techniques. Bitmaps can be compressed
with JPEG or a PNG-like zlib compression. Sound is compressed with various
levels of ADPCM compression. Shapes are compressed using a very efficient
delta encoding scheme.</li>
<li><span class="runInHead">Bit Packing—</span>Whenever possible, numbers
are packed into the smallest possible number of bits for a particular value. Coordinates
are commonly stored using variable-sized bit fields, where a few bits are used
to indicate how many bits are needed by subsequent values. See RECT for an example.</li>
<li><span class="runInHead">Default values—</span>Some structures like matrices
and color transforms have common fields that are used more often than others.
For example, for a matrix, the most common field is the translation field. Scaling
and rotation are less common. Therefore if the scaling field is not present, it
is assumed to be 100%. If the rotation field is not present, it is assumed that
there is no rotation. This use of default values helps to minimize file sizes.</li>
<li><span class="runInHead">Change Encoding—</span>As a rule, SWF files just
store the changes between states. This is reflected in shape data structures
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -