PNG (Portable Network Graphics) Specification, Version 0.91
Revision date: 8 November, 1995
Previous page
On systems where file names customarily include an extension
signifying file type, the extension ".png" is recommended for PNG
files. Lower case ".png" is preferred if file names are
case-sensitive.
In the Apple Macintosh system, the following conventions are
recommended:
- The four-byte type code for PNG files is PNGf.
(This code has been registered with Apple for PNG files.)
The creator code will vary depending on the creating application.
- The contents of the data fork shall be a PNG file exactly
as described in the rest of this specification.
- The contents of the resource fork are unspecified. It may
be empty or may contain application-dependent resources.
- When transferring a Macintosh PNG file to a non-Macintosh
system, only the data fork should be transferred.
PNG itself is strictly a single-image format. However, it may be
necessary to store multiple images within one file; for example, this
is needed to convert some GIF files. In the future, a multiple-image
format based on PNG may be defined. Such a format will be considered
a separate file format and will have a different signature.
PNG-supporting applications may or may not choose to support the
multiple-image format.
See Rationale:
Why not these features?.
A PNG file or datastream is composed of a collection of explicitly typed
"chunks". Chunks whose contents are defined by the specification
could actually contain anything, including malicious code. There is
no known risk that such malicious code could be caused to be brought
into execution on the recipient's computer, however.
The possible security risks associated with future chunk types cannot
be specified at this time. Security issues will be considered when
evaluating chunks proposed for registration as public chunks. There
is no additional security risk associated with unknown or
unimplemented chunk types, because such chunks will either be ignored
or simply be copied into another PNG file.
The tEXt and zTXt chunks contain data that is meant
to be displayed as plain text. It is possible that if the decoder
displays such text without filtering out control characters,
especially the ESC (escape) character, certain systems or terminals
could behave in undesirable and insecure ways. We recommend that
decoders filter out control characters to avoid this risk; see
Recommendations for Decoders:
Text chunk processing.
Because every chunk's length is available at its beginning, and because
every chunk has a CRC trailer, there is a very robust defense against
corrupted data and against fraudulent chunks that attempt to overflow
the viewer's buffers. Also, the PNG signature bytes provide early
detection of common file transmission errors.
A decoder that fails to check CRCs may be subject to data corruption.
The only likely consequence of such corruption is incorrectly displayed
pixels within the image. Worse things might happen if the CRC of the
IHDR chunk is not checked and the width or height fields are
corrupted.
A poorly written decoder might be subject to buffer overflow, because
chunks can be extremely large, up to (2^31)-1 bytes long. But
properly written decoders will handle large chunks without difficulty.
Back to PNG table of contents
Next page