The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 11 of 83
One way to determine if a file is likely to be plain ASCII is if all the bytes in it are less than 128 in 
value. Generally, text encoded using other standards will include values equal to or above this 
number. 
By design of the Unicode creators, ASCII files are also completely valid UTF-8 files (a form of 
Unicode encoding – see section 2.4.1
). Note that the reverse is not necessarily true, as Unicode 
can encode far more characters than ASCII.   
ASCII files are very resilient, in that a change to a byte, or a loss or addition of a byte only 
affects that byte – the rest of the text is never affected by local corruption. 
2.3  EBCDIC 
EBCDIC
8
encoding is generally found on IBM mainframe computers or in systems which 
interact with them. It is similar to ASCII in that it can only represent very few characters, and so 
uses code pages to extend it to cover other languages. However, it is not compatible with 
ASCII, and has itself several versions which are not compatible with each other. It has been in 
use since the late 1950s, but it is not formally standardised, being a vendor-controlled encoding.  
Because this encoding has existed for a long time, it is possible to encounter EBCDIC encoded 
text files, although this is uncommon outside of an IBM environment. If possible in your business 
and technological environment, it is recommended to migrate files out of EBCDIC encodings, as 
they are not widely used. 
2.4  Unicode 
Unicode
9
is an international standard for text which allows the representation of most of the 
writing systems in the world, by allowing a much greater number of characters within it and 
explicit support for various specialised symbols. It does not need code pages to represent 
different characters, as the allowable range of numbers in it is large enough to accommodate 
national variations, special purpose symbols and any other character requirements. It was first 
developed in 1987, and has been through regular revisions since then, adding support for 
increasing numbers of characters and languages. 
8
See http://en.wikipedia.org/wiki/EBCDIC
9
See http://en.wikipedia.org/wiki/Unicode
Extract one page from pdf reader - copy, paste, cut PDF pages in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Easy to Use C# Code to Extract PDF Pages, Copy Pages from One PDF File and Paste into Others
export pages from pdf reader; pdf extract pages
Extract one page from pdf reader - VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Detailed VB.NET Guide for Extracting Pages from Microsoft PDF Doc
delete pages from pdf in reader; delete page from pdf
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 12 of 83
It is closely related to the ISO/IEC 10646
10
standard in that the characters defined in it are the 
same in both, but the Unicode standard imposes some additional constraints on how those 
characters must be processed. The characters of the ISO 8859-1 encoding represent the first 
256 characters of the Unicode standard, to make it easy to convert existing Western European 
text and ASCII, in which a large amount of text files were originally encoded.  
However, there are actually several different possible encodings of Unicode text. The Unicode 
standard itself defines the characters which can be encoded by it (called ‘code-points’), then 
there are several different ways of actually encoding those characters. A useful comparison of 
Unicode encodings can be found at: 
http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
2.4.1 
UTF-8 
The most common encoding is UTF-8
11
, which is directly compatible with ASCII (all ASCII text is 
automatically valid UTF-8, but not vice versa if characters outside the first 128 characters are 
used). ASCII compatibility is a useful property given the large volume of existing files using 
ASCII.   
UTF-8 is known as a multi-byte encoding, in that from 1 to 4 bytes are used to encode each 
character. For values under 128, a single byte is used to encode a character, for any other 
character, more than one byte is used, with at least one byte having a value over 128 to 
distinguish it from single-byte characters.  
File sizes of UTF-8 encoded files are often relatively small, as the standard only uses as many 
bytes as needed for each character, in contrast to other encodings which may use a fixed 
number of bytes regardless. 
UTF-8 also has the useful property of being self-synchronising, meaning that the loss, insertion 
or corruption of a byte in the text will not generally prevent software from determining where the 
other characters begin or end. This keeps any problems localised, and the rest of the text 
readable in the face of errors. 
10
See http://en.wikipedia.org/wiki/Universal_Character_Set
11
See http://en.wikipedia.org/wiki/UTF-8
VB.NET PDF Page Delete Library: remove PDF pages in vb.net, ASP.
If you are looking for a solution to conveniently delete one page from your PDF document, you can use this VB.NET PDF Library, which supports a variety of PDF
export pages from pdf online; cutting pdf pages
C# PDF File Merge Library: Merge, append PDF files in C#.net, ASP.
C# developers can easily merge and append one PDF document to document imaging toolkit, also offers other advanced PDF document page processing and
copy web pages to pdf; copy one page of pdf
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 13 of 83
2.4.2 
UTF-16  
UTF-16
12
uses groups of 2 bytes to encode what are called ‘code-units’. It usually uses one 
code-unit to encode a single character, but will sometimes use 2 code-units (4 bytes) to encode 
a character.   
UTF-16 encodings have two variants in terms of the order in which the group of two bytes are 
written, termed the ‘endianness’ of the encoding. These variants are termed ‘Big Endian’ and 
‘Little Endian’. Some files specify a Byte-Order-Mark (BOM), which is a 2-byte prefix at the start 
of the file which indicates the endianness of the file. However, this is not mandatory, and many 
files do not include a BOM. 
UTF-16 can handle corruptions to individual bytes, re-synchronising on the next valid Unicode 
code-point, but the loss of bytes or insertion of additional bytes can cause the succeeding text 
to become unintelligible. 
File sizes of UTF-16 encoded text are reasonably small, but are usually larger than the 
equivalent text encoded in UTF-8 (depending on which characters appear in the text). 
UTF-16 is frequently used internally in software and programming languages to represent 
Unicode text, and is not infrequently found in text-files, although it is not as common as the 
UTF-8 encoding for storage purposes. 
2.4.3 
UTF-32 
UTF-32
13
is known as a fixed-byte encoding, in that UTF-32 always uses 4 bytes to encode 
each character. However, since Unicode allows for adjacent characters to be combined in some 
circumstances, this does not lead to a direct relationship between the number of bytes and the 
number of displayed characters. The value of a UTF-32 character is the direct numeric value of 
its corresponding Unicode code-point. 
Using 4 bytes per character is much less space efficient than UTF-8 or UTF-16, resulting in 
much larger file or memory sizes when processing text in this encoding.   
UTF-32 can handle corruptions to individual bytes, re-synchronising on the next valid Unicode 
code-point, but the loss of bytes or insertion of additional bytes can cause the succeeding text 
to become unintelligible. 
12
See http://en.wikipedia.org/wiki/UTF-16/UCS-2
13
See http://en.wikipedia.org/wiki/UTF-32
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
Open a document. PDFDocument doc = new PDFDocument(inputFilePath); PDFPage page = (PDFPage)pdf.GetPage(0); // Extract all images on one pdf page.
delete pages of pdf reader; deleting pages from pdf
VB.NET PDF File Merge Library: Merge, append PDF files in vb.net
all. This guiding page will help you merge two or more PDF documents into a single one in a Visual Basic .NET imaging application.
delete pages from pdf acrobat; extract pages from pdf without acrobat
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 14 of 83
Hence, UTF-32 is less commonly found in text files, and is more commonly used as an internal 
representation of Unicode code-points in software. 
VB.NET PDF Annotate Library: Draw, edit PDF annotation, markups in
to display it. Thus, PDFPage, derived from REPage, is a programming abstraction for representing one PDF page. Annotating Process.
extract pdf pages for; copy pdf page to powerpoint
C# PDF Page Delete Library: remove PDF pages in C#.net, ASP.NET
Using RasterEdge Visual C# .NET PDF page deletion component, developers can easily select one or more PDF pages and delete it/them in both .NET web and Windows
delete page from pdf file; extract pages from pdf file online
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 15 of 83
3.  Mark-up languages 
3.1  Introduction 
Mark-up languages are file formats built on text, which use ‘tags’ inside the format to add 
additional structure and meaning to the plain text. For example, we could write: 
<Title>Format facts</Title> 
<Body>To help in evaluating file formats, ...</Body> 
Like the text they are based on, they are also fairly resilient to corruption, and can be opened in 
a common text editor, a specialised markup editor or processed programmatically using 
commonly available libraries of code. Markup languages themselves are not innately lossy and 
have no precision issues in principle (although a lossy format or one with precision issues could 
be created using markup). 
Almost all markup languages in use today inherit from a specification known as Standardised 
General Markup Language
14
(SGML), which itself is not in widespread use anymore. Markup 
languages in widespread use include: 
Hypertext Markup Language  
HTML   
see section 3.2
Extensible Markup Language  
XML   
see section 3.3
3.1.1 
Schemas 
Markup languages define a specific set of tags used to annotate the text. There may be 
constraints on the valid structures of tags – for example, which ones appear next to one another 
or how they can be nested within others. The definition of valid tags and their structure is called 
a schema. There are many ways to define schemas for markup languages, including Document 
Type Definitions
15
(DTD), XML Schemas
16
(XSD) and RELAX NG.
17
Schemas both provide a technical level of documentation on how a format defined using 
markup is constructed, and a way to automatically validate that a markup-format conforms to a 
specification. 
14
See http://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language
15
See http://en.wikipedia.org/wiki/Document_Type_Definition
16
See http://en.wikipedia.org/wiki/XML_Schema_(W3C)
17
See http://en.wikipedia.org/wiki/RELAX_NG
VB.NET PDF copy, paste image library: copy, paste, cut PDF images
how to copy an image from one page of PDF how to cut image from PDF file page by using doc As PDFDocument = New PDFDocument(inputFilePath) ' Extract all images
extract pages from pdf document; cut and paste pdf pages
C# PDF: C# Code to Process PDF Document Page Using C#.NET PDF
Able to separate one PDF file into two PDF documents using C#.NET programming code; Free to extract page(s) from source PDF file and combine extracted pages
copying a pdf page into word; cut pages from pdf online
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 16 of 83
3.1.2 
Continuity risks 
Formats based on markup languages can be quite complex. Since it is also quite easy to define 
file formats based on markup languages (in particular, XML-based formats are very common), 
then a large number of highly bespoke, and often poorly documented formats are in existence.  
Without knowledge of the schema used to define the format, data encoded in a markup 
language can be hard, if not impossible to interpret, even though it remains technically 
accessible. In cases where software that provides the necessary layer of processing needs 
maintenance, or where you otherwise need to programmatically access the data encoded in a 
markup language, you should ensure that you understand the schemas used by them. Without 
this understanding you will be at risk of losing continuity if the software changes or becomes 
unavailable. 
Understanding a schema implies more than simply knowing which schema was used. While 
schemas provide a base level of technical documentation for a markup-based format, they are 
generally not sufficient to interpret the meaning of the markup and the data contained within 
them. For example, if a tag is called ‘<Creator>’, does this refer to a person, or an organisation?  
Does it matter? Are there any other constraints on valid data which the schema does not 
capture? You should make sure that you have both schemas and documentation explaining the 
intended meaning and constraints of the markup. 
3.2  Hypertext Markup Language (.html, .htm) 
A well-known example of a mark-up file format is HyperText Markup Language
18
(HTML, HTM), 
used to create web pages. The first specification of HTML was made available by 1992. Various 
versions of HTML exist, including 2.0, 3.2, 4.0, 4.01, and version 5 is currently in development.  
Version 2 is now considered obsolete, as it contains elements which have been dropped in 
subsequent versions. From version 3.2 onwards, it is standardised through the W3C (World 
Wide Web Consortium). 
While HTML itself is standardised, many technologies interpret these standards slightly 
differently from one another. In addition, many real-world HTML files do not strictly conform to 
the standards. This can create situations where an HTML file will render correctly on one 
platform, but not on another. Increasingly, HTML processing technologies are becoming more 
consistent, but differences can still be expected. 
18
See http://en.wikipedia.org/wiki/HTML
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 17 of 83
In addition to the HTML standards, there is also a variant called XHTML
19
, which is a version of 
HTML which is fully compatible with XML (see section 3.3)
. XHTML is stricter than HTML in the 
structures it allows, ensuring that all the markup conforms to a precise standard. Theoretically, 
this would make it easier to write applications which work with HTML, which in practice is often 
quite loosely written. For example, in real HTML documents, markup tags are not always closed 
after they are opened. However, XHTML has not been widely adopted on the web, so in 
practice it is necessary to be able to deal with HTML as well. 
Note that HTML files are rarely found on their own; they make reference to external resources 
(via hyperlinks, or file includes).  These external resources may not be HTML themselves – they 
can be images, video, audio, programming languages (e.g. JavaScript), style sheets which 
affect how the HTML displays (e.g. css files). All of these external resources can affect how the 
HTML displays, or even which content is ultimately loaded into it. You should ensure that you 
understand which external resources are required to use your HTML files into the future, and 
whether they pose any continuity risks of their own. 
3.2.1 
Continuity properties of HTM and HTML 
Flexibility Interoperability  Very high. All platforms can process HTML data. 
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 18 of 83
creating file formats using markup. XML defines a set of syntax and rules which markup 
languages must obey to be considered valid XML, but the specific tags and structures used in 
the XML markup are left up to the format designer. XML files are written using Unicode text. 
Almost all recent document formats are created using XML as a base, as are increasing 
numbers of other formats. The advantages include human readability of the underlying files, 
ease of extending the information within them and programmatic processing. Almost all (if not 
all) programming languages can process XML using widely available libraries, and there are 
many different software applications available to author, edit and transform XML directly. 
However, due to the ease of creating  formats based on XML, there has been a huge increase 
in bespoke file formats. To assure their continuity requires detailed knowledge of the XML 
schema and other documentation on the meaning of the tags. 
Disadvantages of XML over binary file formats include larger file sizes, although this can be 
largely mitigated by compressing them (they typically compress very well), and difficulty 
including binary objects (e.g. an image) within an XML document, since XML is a textual format.  
Binary objects can be converted to a textual representation, but this takes up a lot of space (and 
they do not compress as well if such objects are included). 
3.3.1 
Continuity properties of XML 
Flexibility 
Interoperability 
Very high. All platforms can process XML data. 
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 19 of 83
4.  File containers 
4.1  Introduction 
File container formats are designed to contain other files. They are often used deliberately to 
archive files, compress them to save storage space or encrypt them. But it may be less well 
understood that they are used to support applications which require more than one file-resource 
to be available from within a single file (e.g. documents with embedded images). 
4.1.1 
Continuity risks 
There is a broad continuity risk arising from the use of container formats in the first place. By 
placing files in container formats, they become obscured from other information management 
tools. It is not enough to know you have a zip or a tar file – you need to know what is inside 
them to manage your digital continuity properly. However, note that this is not a continuity risk to 
file container formats themselves; it is a continuity risk created by using file container formats. 
In general, file containers tend to be very long-lived formats and widely supported in software. 
However, note that few container formats are formally standardised – they are typically de facto 
standards, with freely available specifications. 
File containers are not innately lossy (they must be able to accurately reconstitute the files 
contained within them), although most do not preserve all available file system metadata along 
with the files, and some have precision issues (e.g. around date-times). 
All of the file container formats described here are binary, which is more compact, as opposed 
to textual. Some email formats which are based on text encode file attachments textually (e.g. 
EML – see section 9.1
). However, in general, most file container formats are binary. Binary 
formats tend to be less recoverable than textual formats (as, aside from other considerations, 
they store information more densely, meaning errors have a correspondingly greater impact). 
Some container formats include error detection and correction features to aid recoverability, 
since their role is to hold other files safely. 
4.2  Zip (.zip) 
The ZIP file format (ZIP)
21
21
See 
is one of the most widely used file container formats in use today. It is 
a binary format, provides good compression of contained files, is fairly fast to compress and 
decompress, and supports several different compression algorithms (including using no 
compression). Zip files can be accessed by a wide variety of software and support is found in all 
programming environments. 
http://en.wikipedia.org/wiki/ZIP_(file_format)
The National Archives                                                                                   A Guide to Formats  Version: 1 
Page 20 of 83
It was first created in 1989, and its specification was released into the public domain. It has not 
been formally standardised, although the ISO organisation is currently investigating whether it 
should produce an ISO standard for the zip specification. However, note that the legal status of 
recent versions of ZIP (particularly 64-bit zip) is not clear, and software support is more limited. 
These versions give support for strong encryption and file sizes greater than four Gigabytes. 
File system metadata, such as original file names, folder structure and dates are usually 
included in zip files. However, note that the default timestamp in zip files is only accurate to two 
seconds, so dates and times will often be slightly different when compared to the original file 
system. Also note that no other file system metadata is preserved by default, including file 
system permissions. 
The zip file format is inherently extensible, and some extensions provide for more accurate date 
times, and some file system permissions to be preserved. Whether these extensions are used 
or not will depend on the zip software in use. If zip software cannot understand an extension 
written by different zip software, the standard behaviour is simply to ignore it (while still dealing 
with what can be understood). This can lead to metadata loss if different zip software is used to 
zip and unzip files. If recovery of file system metadata is important, you should ensure that both 
the software used to zip and unzip files can handle the same metadata in equivalent ways. 
The zip format provides a measure of integrity protection against corruption, using CRC
22
4.2.1 
Continuity properties of ZIP file formats 
checksums to detect errors, and it stores two copies of a file directory structure to provide some 
redundancy. Having a file listing inside the zip file allows access to each file in the zip 
independently of the others, without having to read the entire zip file to access them individually. 
Each file inside the zip file is compressed separately, meaning that corruption which affects one 
file contained in it may not affect others, assuming the files can still be properly located within 
the zip file itself. Tools to repair corrupted zip files are readily available, although repair cannot 
be guaranteed.  
Flexibility Interoperability  Very highAll platforms can process zip files, although note 
gh note 
that the 64-bit zip format is not so interoperable. 
Documents you may be interested
Documents you may be interested