Network Working Group J. Strombergson
Request for Comments: 4194 InformAsic AB
Category: Standards Track L. Walleij
Lunds Tekniska Hogskola
P. Faltstrom
Cisco Systems Inc
October 2005
Network Working Group J. Strombergson
Request for Comments: 4194 InformAsic AB
Category: Standards Track L. Walleij
Lunds Tekniska Hogskola
P. Faltstrom
Cisco Systems Inc
October 2005
The S Hexdump Format
hexsdump格式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format.
本文档指定了S Hexdump格式（SHF），这是一种新的、基于XML的开放格式，用于以十六进制表示法描述二进制数据。SHF能够以开放、现代、传输和供应商中立的格式描述小型和大型、简单和复杂的十六进制数据转储。
In the computing, network, and embedded systems communities, several different types of data formats for hexadecimal data are being used. One of the more common formats is known as "S-records" (and several derivatives), which reportedly originated at the Motorola company. The S Hexdump Format is named in its honour.
在计算、网络和嵌入式系统社区中，使用了几种不同类型的十六进制数据格式。其中一种更为常见的格式是“S-records”（以及一些衍生产品），据报道它起源于摩托罗拉公司。S hextump格式是为纪念它而命名的。
Typical uses of these dump formats include executable object code for embedded systems (i.e., "firmware"), on-chip flash memories and filesystems, FPGA configuration bitstreams, graphics and other application resources, routing tables, etc. Unfortunately, none of the formats used are truly open, vendor-neutral, and/or well-defined.
这些转储格式的典型用途包括嵌入式系统的可执行目标代码（即“固件”）、片上闪存和文件系统、FPGA配置比特流、图形和其他应用程序资源、路由表等。不幸的是，所使用的格式都不是真正开放的、供应商中立的和/或定义良好的。
Even more problematic is the fact that none of these formats are able to represent the large data sizes that are getting more and more common. Data dumps comprised of multiple sub-blocks with different
更成问题的是，这些格式都不能表示越来越常见的大数据量。数据转储由多个子块组成，具有不同的
Word sizes, and data sizes spanning anywhere from a few Bytes of data to much larger than 2^32 bits are not handled. Also, the checksums included in these formats are too simplistic and for larger data sizes, they provide insufficient ability to accurately detect errors. Alternatively, the overhead needed for proper error detection is very large.
不处理字大小和数据大小（从几个字节的数据到远大于2^32位的数据）。此外，这些格式中包含的校验和过于简单，对于较大的数据量，它们提供的准确检测错误的能力不足。或者，正确的错误检测所需的开销非常大。
Therefore, the S Hexdump format is an effort to provide a modern, XML-based format that is not too complex for simple tools and computing environments to implement, generate, parse, and use. Yet the format is able to handle large data sizes and complex data structures, and can provide high quality error detection by leveraging standardized cryptographic hash functions.
因此，S Hexdump格式旨在提供一种现代的、基于XML的格式，对于简单的工具和计算环境来说，这种格式不太复杂，无法实现、生成、解析和使用。然而，该格式能够处理大数据量和复杂的数据结构，并且可以通过利用标准化的加密哈希函数提供高质量的错误检测。
One of the simplifications introduced in the format is to disallow other number systems such as octal or decimal notation, and to allow for Word sizes of even bytes (8-bit groups) only. This is intentional and was done to simplify implementations aimed for practical present-day applications. Formats aimed for esoteric number systems or odd Word sizes may be implemented elsewhere.
该格式中引入的简化之一是不允许使用其他数字系统，如八进制或十进制表示法，并且只允许偶数字节（8位组）的字大小。这是有意的，目的是为了简化针对当前实际应用程序的实现。针对深奥数字系统或奇数字大小的格式可以在其他地方实现。
At present, the usage of the SHF format may be mainly for Internet transport and file storage on development machinery. A parser for the XML format is presently not easily deployed in hardware devices, but the parsing and checksumming of the SHF data may be done by a workstation computer, which in turn converts the SHF tokens to an ordinary bitstream before the last step (e.g., of a firmware upgrade) commences.
目前，SHF格式的使用可能主要用于开发机器上的Internet传输和文件存储。XML格式的解析器目前不容易部署在硬件设备中，但是SHF数据的解析和校验和可由工作站计算机完成，其反过来在最后一步（例如固件升级）开始之前将SHF令牌转换为普通比特流。
SHF is a dump format only and shall not be confused with similar applications, such as binary configuration formats or patches, which are intended to, for example, alter contents of a core memory. Such applications require the possibility of modifying individual bits or groups of bits in the memory of a machine, and is not the intended usage of the mechanism described in the present document.
SHF仅为转储格式，不得与类似应用混淆，如二进制配置格式或补丁，其目的是改变核心内存的内容。此类应用需要修改机器存储器中的单个位或位组的可能性，并且不是本文档中描述的机制的预期用途。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The key word "Byte" is to be interpreted as a group of 8 bits. The key word "Octet" is another name for Byte.
关键字“Byte”被解释为一组8位。关键字“Octet”是字节的另一个名称。
The key word "Word" is to be interpreted as a group containing an integral number of Bytes.
关键字“word”被解释为包含整数字节数的组。
The key word "Block" is to be interpreted as an ordered sequence of Words, beginning at a certain address, running from lower to higher addresses. A Block typically represents a sequence of Words at a certain address range in the memory of a computer.
关键词“Block”被解释为从某个地址开始，从较低地址到较高地址的有序单词序列。块通常表示计算机内存中特定地址范围内的一系列字。
The key word "Dump" is to be interpreted as a sequence of Blocks, which may or may not be in a particular order. A Dump typically represents some non-continuous, interesting parts of the memory of a computer, such that the Dump as a whole has a certain meaning, for example (but not limited to) a complete firmware for an embedded system.
关键字“Dump”将被解释为块序列，其可以是也可以不是以特定顺序。转储通常表示计算机内存的一些非连续、有趣的部分，因此转储作为一个整体具有一定的含义，例如（但不限于）嵌入式系统的完整固件。
The expression "2^n" is to be interpreted as the value two (2) raised to the n:th power. For example, 2^8 equals the value 256.
表达式“2^n”应解释为第n次方的值2（2）。例如，2^8等于值256。
The SHF-format has the following features:
SHF格式具有以下功能：
o Support for arbitrarily wide data Words
o 支持任意宽的数据字
o Support for very large data Blocks
o 支持非常大的数据块
o Support for an arbitrary number of independent data Blocks
o 支持任意数量的独立数据块
o Data integrity detection against errors provided by the RFC3174 specified (see [2]) SHA-1 cryptographic signature
o 针对指定的RFC3174（参见[2]）SHA-1加密签名提供的错误进行数据完整性检测
o An XML-based format
o 一种基于XML的格式
In the embedded systems domain, 8- and 16-bit processors are still used in large numbers and will continue to be used for any foreseeable future. Simultaneously, more and more systems are using 64-bit and even larger Word sizes.
在嵌入式系统领域，8位和16位处理器仍然大量使用，并将在任何可预见的未来继续使用。同时，越来越多的系统使用64位甚至更大的字大小。
SHF supports all of these systems by allowing the Word size to be specified. The Word size MUST be an integer number of Bytes and at least one (1) Byte.
SHF通过允许指定字长来支持所有这些系统。字长必须为整数字节数，且至少为一（1）个字节。
SHF is able to represent both large and small data Blocks. The data Block MUST contain at least one (1) Word. Additionally, the data Block MUST NOT be larger than (2^64)-1 bits.
SHF能够表示大数据块和小数据块。数据块必须至少包含一（1）个字。此外，数据块不得大于（2^64）-1位。
The SHF Dump MUST contain at least one (1) data Block. The maximum number of Blocks supported is 2^64. Each data Block in the Dump MAY have different Word sizes and start at different addresses.
SHF转储必须至少包含一（1）个数据块。支持的最大块数为2^64。转储中的每个数据块可能具有不同的字大小，并且从不同的地址开始。
The checksum (or message digest) used to verify the correctness or data integrity of each Block is 20 Bytes (160 bits) long. The digest MUST be calculated on the data actually represented by the SHF data Block, NOT the representation, i.e., NOT the ASCII-code. SHA-1 is only able to calculate a digest for a data Block no larger than (2^64)-1 bits and this limits the size of each data Block in SHF to (2^64)-1 bits.
用于验证每个块的正确性或数据完整性的校验和（或消息摘要）长度为20字节（160位）。摘要必须根据SHF数据块实际表示的数据计算，而不是表示，即不是ASCII码。SHA-1只能为不大于（2^64）-1位的数据块计算摘要，这将SHF中每个数据块的大小限制为（2^64）-1位。
The SHF format consists of an XML data structure representing a Dump. The Dump consists of a Dump header section and one (1) or more Block sections containing data. Each Block of data is independent of any other Block.
SHF格式由表示转储的XML数据结构组成。转储由转储头部分和一（1）个或多个包含数据的块部分组成。每个数据块独立于任何其他数据块。
A short, symbolic example of an SHF Dump is illustrated by the following structure:
SHF转储的简短符号示例如下所示：
<dump name="(Human readable string)" blocks="(64-bit value)">
<block name="(Human readable string)" start_address="(64-bit
value)" word_size="(64-bit value)" length="(64-bit value)"
checksum="(20-Byte digest)">
(Data)
</block>
</dump>
<dump name="(Human readable string)" blocks="(64-bit value)">
<block name="(Human readable string)" start_address="(64-bit
value)" word_size="(64-bit value)" length="(64-bit value)"
checksum="(20-Byte digest)">
(Data)
</block>
</dump>
The header section comprises the Dump tag, which includes the following attributes:
标题部分包含转储标记，其中包括以下属性：
o name: A compulsory string of arbitrary length used by any interested party to identify the specific SHF Dump.
o 名称：任何相关方用于标识特定SHF转储的任意长度的强制字符串。
o blocks: An optional 64-bit hexadecimal value representing the number of Blocks in the specific SHF Dump. Whenever available, this value should be supplied. However, there are potential scenarios where the number of Blocks cannot be given beforehand. If the value is present, it should be verified by implementers; if the value is untrue, the behaviour is implementation-defined.
o blocks：可选的64位十六进制值，表示特定SHF转储中的块数。只要可用，应提供该值。然而，在某些潜在情况下，无法事先给出块的数量。如果该值存在，则应由实施者进行验证；如果该值不真实，则行为由实现定义。
After the opening Dump tag, one or more subsections of Blocks must follow. Finally, the complete SHF Dump ends with a closing Dump tag.
打开转储标记后，必须跟随一个或多个子块。最后，完整的SHF转储以结束转储标记结束。
The Block subsection contains a Block tag and a number of data words. The Block tag includes the following attributes:
块子部分包含一个块标记和多个数据字。块标记包括以下属性：
o name: A compulsory string of arbitrary length used by any interested party to identify the specific Block.
o 名称：任何相关方用于标识特定块的任意长度的强制字符串。
o start_address: A compulsory, 64-bit hexadecimal value representing the start address in Bytes for the data in the Block.
o 起始地址：一个强制的64位十六进制值，表示块中数据的起始地址（字节）。
o word_size: A compulsory 64-bit hexadecimal value representing the number of Bytes (the width) of one Word of the data.
o word_size：一个强制的64位十六进制值，表示一个数据字的字节数（宽度）。
o length: A compulsory hexadecimal representation of an unsigned 64-bit integer indicating the number of Words following inside the Block element. If this value turns out to be untrue, the Block MUST be discarded.
o 长度：无符号64位整数的强制十六进制表示形式，表示块元素中紧跟其后的字数。如果该值不真实，则必须丢弃该块。
o checksum: A compulsory hexadecimal representation of the 20 Byte SHA-1 digest of the data in the Block.
o 校验和：块中数据的20字节SHA-1摘要的强制十六进制表示。
The total size of the data in the Block (in bits) is given by the expression (8 * word_size * length). The expression MUST NOT be larger than (2^64)-1.
块中数据的总大小（以位为单位）由表达式（8*字大小*长度）给出。表达式不能大于（2^64）-1。
After the opening Block tag, a hexadecimal representation of the actual data in the Block follows. Finally, the Block section ends with a closing Block tag.
在开始块标记之后，块中实际数据的十六进制表示如下。最后，块段以结束块标记结束。
There are several rules and limits in SHF:
SHF中有几个规则和限制：
o All attribute values representing an actual value and the data MUST be in hexadecimal notation. The only attribute excluded from this rule is the name attribute in the Dump and Block tags. This restriction has been imposed for ease of reading the dump: a reader shall not be uncertain about whether a figure is in hex notation or not, and can always assume it is hexadecimal.
o 表示实际值和数据的所有属性值必须采用十六进制表示法。此规则中排除的唯一属性是Dump和Block标记中的name属性。为了便于读取转储文件，施加了此限制：读者不应不确定某个数字是否使用十六进制表示法，并且可以始终假定它是十六进制的。
o All attribute values, with the exception of the checksum, MAY omit leading zeros. Conversely, the checksum MUST NOT omit leading zeros.
o 除校验和外，所有属性值都可以省略前导零。相反，校验和不能忽略前导零。
o The data represented in a Block MUST NOT be larger than (2^64)-1 bits.
o 块中表示的数据不得大于（2^64）-1位。
o The size of a Word MUST NOT be larger than (2^64)-1 bits. This implies that a Block with a Word defined to the maximum width cannot contain more than one Word. An SHF consumer shall assure that it can handle a certain Word length before beginning to parse blocks of an SHF Dump. Failure to do so may cause buffer overflows and endanger the stability and security of the system running the consuming application.
o 字的大小不能大于（2^64）-1位。这意味着具有定义为最大宽度的单词的块不能包含多个单词。SHF使用者应确保在开始解析SHF转储块之前能够处理一定的字长。否则可能导致缓冲区溢出，并危及运行消费应用程序的系统的稳定性和安全性。
o The attribute values representing an actual value MUST be in big-endian format. This means that the most significant hexadecimal digits are to be put to the left in a hexadecimal Word, address, or similar field. For example, the address value 1234 represents the address 1234 and not 3412. While some computing architectures may be using little-endian Words as their native format, it is the responsibility of any SHF producer running on such an architecture to swap the attribute values to a big-endian format. The reverse holds for a consumer receiving the big-endian SHF attributes: if the consumer is little-endian, the values have to be swapped around.
o 表示实际值的属性值必须采用big-endian格式。这意味着最重要的十六进制数字将放在十六进制字、地址或类似字段的左侧。例如，地址值1234表示地址1234而不是3412。虽然一些计算架构可能使用小端字作为其本机格式，但在这种架构上运行的任何SHF生成器都有责任将属性值交换为大端字格式。对于接收big-endian SHF属性的使用者，则相反：如果使用者是little-endian，则必须交换值。
o Likewise, the words inside a Dump MUST be stored in a big-endian format if the word size is larger than one Byte. Here, the same need for swapping Bytes around may arise, as mentioned in the previous paragraph.
o 同样，如果字大小大于一个字节，则转储中的字必须以big-endian格式存储。在这里，可能会出现交换字节的相同需求，如前一段所述。
The contents of the element named "block" and the attributes "blocks", "address", "word_size" and "checksum" should only contain the characters that are valid hexbyte sequences. These are:
名为“block”的元素的内容以及属性“blocks”、“address”、“word_size”和“checksum”应仅包含有效的六字节序列的字符。这些是：
whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)
hexdigit ::= [0-9A-Fa-f]
hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)*
whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)
hexdigit ::= [0-9A-Fa-f]
hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)*
A parser reading in an SHF file should silently ignore any other characters that (by mistake) appear in any of these elements or attributes. These alien characters should be treated as if they did not exist. Also note that "whitespace" has no semantic meaning; it is only valid for the reason of improving the human readability of the Dump. Whitespace may be altogether removed and the hexbyte sequences concatenated if desired. Notice that the fact that word size is to be given in a number of bytes implies that the number of hexadecimal digits inside a block need to be even. Malformed blocks should be ignored by implementations.
在SHF文件中读取的解析器应该默默地忽略（错误地）出现在这些元素或属性中的任何其他字符。这些外来字符应视为不存在。还请注意，“空白”没有语义含义；它只有在提高转储的可读性的情况下才有效。如果需要，可以完全删除空白，并连接六字节序列。请注意，单词大小以字节数表示这一事实意味着块中的十六进制数字数需要是偶数。实现应忽略格式错误的块。
<!-- DTD for the S Hexdump Format, as of 2003-10-10 Linus Walleij, Joachim Strombergson, Patrik Faltstrom 2003
<!-- S Hexdump格式的DTD，自2003年10月10日起，Linus Walleij，Joachim Strombergson，Patrik Faltstrom 2003
Refer to this DTD as:
将此DTD称为：
<!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
"http://ietf.org/dtd/shf.dtd">
%SHF;
-->
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
"http://ietf.org/dtd/shf.dtd">
%SHF;
-->
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT dump (block)+>
<!ATTLIST dump
name CDATA #REQUIRED
blocks CDATA #IMPLIED>
<!ELEMENT dump (block)+>
<!ATTLIST dump
name CDATA #REQUIRED
blocks CDATA #IMPLIED>
<!ELEMENT block (#PCDATA)>
<!ATTLIST block
name CDATA #REQUIRED
address CDATA #REQUIRED
word_size CDATA #REQUIRED
length CDATA #REQUIRED
checksum CDATA #REQUIRED>
<!ELEMENT block (#PCDATA)>
<!ATTLIST block
name CDATA #REQUIRED
address CDATA #REQUIRED
word_size CDATA #REQUIRED
length CDATA #REQUIRED
checksum CDATA #REQUIRED>
This section contains three different SHF examples, illustrating the usage of SHF and the attributes in SHF.
本节包含三个不同的SHF示例，说明SHF的用法和SHF中的属性。
The first example is a simple SHF Dump with a single Block of data:
第一个示例是具有单个数据块的简单SHF转储：
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Simple SHF example" blocks="01">
<block name="Important message in hex format" address="0400"
word_size="01" length="1f"
checksum="5601b6acad7da5c7b92036786250b053f05852c3">
41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72
65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a
</block>
</dump>
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Simple SHF example" blocks="01">
<block name="Important message in hex format" address="0400"
word_size="01" length="1f"
checksum="5601b6acad7da5c7b92036786250b053f05852c3">
41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72
65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a
</block>
</dump>
The second example is a program in 6502 machine code residing at memory address 0x1000, which calculates the 13 first Fibonacci numbers and stores them at 0x1101-0x110d:
第二个示例是驻留在内存地址0x1000的6502机器码中的程序，该程序计算13个Fibonacci第一个数，并将其存储在0x1101-0x110d：
<?xml version="1.0" encoding="UTF-8"?>
<dump name="6502 Fibonacci" blocks="02">
<block name="Code" address="1000" word_size="01" length="2a"
checksum="5cab5bf8ee299af1ad17e8093d941914eb5930c7">
a9 01 85 20 85 21 20 1e 10 20 1e 10 18 a5 21 aa
65 20 86 20 85 21 20 1e 10 c9 c8 90 ef 60 ae 00
11 a5 21 9d 00 11 ee 00 11 60
</block>
<block name="Mem" address="1100" word_size="01" length="e"
checksum="c8c2001c42b0226a5d9f7c2f24bd47393166487a">
01 00 00 00 00 00 00 00 00 00 00 00 00 00
</block>
</dump>
<?xml version="1.0" encoding="UTF-8"?>
<dump name="6502 Fibonacci" blocks="02">
<block name="Code" address="1000" word_size="01" length="2a"
checksum="5cab5bf8ee299af1ad17e8093d941914eb5930c7">
a9 01 85 20 85 21 20 1e 10 20 1e 10 18 a5 21 aa
65 20 86 20 85 21 20 1e 10 c9 c8 90 ef 60 ae 00
11 a5 21 9d 00 11 ee 00 11 60
</block>
<block name="Mem" address="1100" word_size="01" length="e"
checksum="c8c2001c42b0226a5d9f7c2f24bd47393166487a">
01 00 00 00 00 00 00 00 00 00 00 00 00 00
</block>
</dump>
The final example contains a Block of 40-bit wide data:
最后一个示例包含一个40位宽的数据块：
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Example of an SHF dump with wide data words" blocks="00001">
<block name="SMIL memory dump" address="000" word_size="5"
length="1A" checksum="ff2033489aff0e4e4f0cd7901afc985f7a213c97">
00100 00200 00000 00090 00000 00036 00300 00400
00852 00250 00230 00858 00500 00600 014DC 00058
002A8 000B8 00700 00800 000B0 00192 00100 00000
00900 00A00 00000 0000A 40000 00000 00B00 00C00
00000 00000 00000 00001 00D00 00E00 00000 00100
0CCCC CCCCD 00F00 01000 00000 00010 80000 00000
00100 00790 00000 00234
</block>
</dump>
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Example of an SHF dump with wide data words" blocks="00001">
<block name="SMIL memory dump" address="000" word_size="5"
length="1A" checksum="ff2033489aff0e4e4f0cd7901afc985f7a213c97">
00100 00200 00000 00090 00000 00036 00300 00400
00852 00250 00230 00858 00500 00600 014DC 00058
002A8 000B8 00700 00800 000B0 00192 00100 00000
00900 00A00 00000 0000A 40000 00000 00B00 00C00
00000 00000 00000 00001 00D00 00E00 00000 00100
0CCCC CCCCD 00F00 01000 00000 00010 80000 00000
00100 00790 00000 00234
</block>
</dump>
The SHF format is a format for representing hexadecimal data that one wants to transfer, manage, or transform. The format itself does not guarantee that the represented data is not falsely represented, malicious, or otherwise dangerous.
SHF格式是一种表示要传输、管理或转换的十六进制数据的格式。格式本身并不保证所表示的数据没有错误、恶意或其他危险。
The data integrity of the SHF file as a whole is to be provided, if needed, by means external to the SHF file, such as the generic signing mechanism described by RFC 3275 [3].
如果需要，将通过SHF文件外部的方式（如RFC 3275[3]所述的通用签名机制）提供SHF文件作为一个整体的数据完整性。
This section contains the registration information for the MIME type to SHF. The media type has been chosen to comply with the guidelines in [4].
本节包含MIME类型到SHF的注册信息。选择的媒体类型符合[4]中的指南。
o Registration: application/shf+xml o MIME media type name: application o MIME subtype name: shf+xml o Required parameters: charset
o 注册：应用程序/shf+xml o MIME媒体类型名称：应用程序o MIME子类型名称：shf+xml o所需参数：字符集
Required parameters: charset
所需参数：字符集
This parameter must exist and must be set to "UTF-8". No other character sets are allowed for transporting SHF data. The character set designator MUST be uppercase.
此参数必须存在并且必须设置为“UTF-8”。不允许使用其他字符集传输SHF数据。字符集指示符必须为大写。
Encoding considerations:
编码注意事项：
This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied.
此媒体类型可能包含二进制内容；因此，当在不允许二进制传输的传输上使用时，必须应用适当的编码。
Security considerations:
安全考虑：
A hex Dump in itself has no other security considerations than what applies for any other XML file. However, the included binary data may in decoded form contain any executable code for a target platform. If additional security is desired, additional transport security solutions may be applied. For target code contained in a hex Dump, developers may want to include certificates, checksums, and the like in hexdump form for the target platform. Such uses are outside the scope of this document and a matter of implementation.
十六进制转储本身除了适用于任何其他XML文件之外，没有其他安全考虑。然而，所包括的二进制数据可以解码形式包含用于目标平台的任何可执行代码。如果需要额外的安全性，可采用额外的运输安全解决方案。对于十六进制转储中包含的目标代码，开发人员可能希望在目标平台的十六进制转储形式中包含证书、校验和等。此类用途不在本文件范围内，属于实施事项。
Interoperability considerations:
互操作性注意事项：
n/a
不适用
Published specification:
已发布的规范：
This media type is a proper subset of the XML 1.0 specification [5]. One restriction is made: no entity references other than the five predefined general entities references ("&", "<", ">", "'", and """) and numeric entity references may be present. Neither the "XML" declaration (e.g., <?xml version="1.0" ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) need be present. (XML fragments are allowed.) All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed.
这种媒体类型是XML 1.0规范的一个适当子集[5]。有一个限制：除了五个预定义的通用实体引用（“&；”、“<；”、“>；”、“&apos；”和“"；”）和数字实体引用之外，不能存在任何实体引用。“XML”声明（例如<？XML version=“1.0”？>）和“DOCTYPE”声明（例如<！DOCTYPE…>）都不需要存在。（允许使用XML片段。）允许使用所有其他XML 1.0指令（例如CDATA块、处理指令等）。
Applications that use this media type: any program or individual wishing to make use of this XML 1.0 subset for hexdump exchange.
使用此媒体类型的应用程序：希望将此XML 1.0子集用于hexdump exchange的任何程序或个人。
Additional information:
其他信息：
o Magic number: There is no single initial Byte sequence that is always present for SHF files o File extension: shf o Macintosh File Type code: none
o 幻数：SHF文件没有始终存在的单个初始字节序列o文件扩展名：SHF o Macintosh文件类型代码：无
Intended usage: COMMON.
预期用途：普通。
Author/Change controller: this MIME transport type is controlled by the IETF.
作者/更改控制器：此MIME传输类型由IETF控制。
The attributes of elements in the SHF XML format may be extended when need arises. For example, certain applications will want to represent executable code as an SHF Dump, and may then need an execution start address to be associated with certain Dump Blocks, so that the address can be configured as a starting point for the CPU part of any processor code present in the Block, as opposed to the raw data, which is already given a start address by way of the "address" attribute. This can be done by extending the Block tag with a "start_address" attribute.
当需要时，可以扩展SHF XML格式中元素的属性。例如，某些应用程序希望将可执行代码表示为SHF转储，然后可能需要与某些转储块关联的执行开始地址，以便该地址可以配置为块中存在的任何处理器代码的CPU部分的起点，而不是原始数据，它已经通过“address”属性提供了一个起始地址。这可以通过使用“start_address”属性扩展块标记来实现。
Another possible scenario is when a dump is applied to a computer system with several independent address spaces, such as a system with two CPUs, each with independent memories. In this case, a user may want to add an "address_space" attribute.
另一种可能的情况是，转储应用于具有多个独立地址空间的计算机系统，例如具有两个CPU的系统，每个CPU具有独立的内存。在这种情况下，用户可能希望添加“地址空间”属性。
As long as such new attributes are added, with no attributes being removed or redefined, the resulting Dump shall be considered a valid SHF Dump and transported using the application/xml+shf transport type. Parsers unaware of the modified namespace shall silently ignore any such extended attributes, or simply duplicate them from input to output when processing an SHF file as a filter. The management of such extended attributes is a matter of convention between different classes of users and not a matter of the IETF.
只要添加了此类新属性，且未删除或重新定义任何属性，则生成的转储应视为有效的SHF转储，并使用application/xml+SHF传输类型进行传输。不知道修改后的名称空间的解析器将默默地忽略任何此类扩展属性，或者在将SHF文件作为过滤器处理时，将它们从输入复制到输出。这种扩展属性的管理是不同类别用户之间的约定问题，而不是IETF的问题。
Contact for further information: c.f., the "Authors' Addresses" section of this memo.
更多信息请联系：c.f.，本备忘录的“作者地址”部分。
Acknowledgements: The SMIL memory Dump was kindly provided by Sten Henriksson at Lund University. Proofreading and good feedback on the SHF document was generously provided by Peter Lindgren, Tony Hansen, Larry Masinter, and Clive D.W. Feather. We also want to thank the Applications area workgroup for their help during development.
感谢：SMIL内存转储由隆德大学的Sten Henriksson提供。Peter Lindgren、Tony Hansen、Larry Masinter和Clive D.W.Feather慷慨提供了SHF文件的校对和良好反馈。我们还要感谢应用领域工作组在开发过程中提供的帮助。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", BCP 14, RFC 3174, September 2001.
[2] Eastlake，3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，BCP 14，RFC 3174，2001年9月。
[3] Eastlake, 3rd, D., Joseph, J., and D. David, "(Extensible Markup Language) XML-Signature Syntax and Processing", BCP 14, RFC 3275, March 2002.
[3] Eastlake，3rd，D.，Joseph，J.，和D.David，“（可扩展标记语言）XML签名语法和处理”，BCP14，RFC3275，2002年3月。
[4] Makoto, M., Simon, S., and D. Dan, "(Extensible Markup Language) XML Media Types", RFC 3023, January 2001.
[4] Makoto，M.，Simon，S.，和D.Dan，“（可扩展标记语言）XML媒体类型”，RFC 3023，2001年1月。
[5] Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M. and Maler, Eve, Yergeau, Francois, "Extensible Markup Language (XML) 1.0 (Third Edition)", http://www.w3.org/TR/REC-xml.
[5] Bray，Tim，Paoli，Jean，Sperberg McQueen，C.M.和Maler，Eve，Yergeau，Francois，“可扩展标记语言（XML）1.0（第三版）”，http://www.w3.org/TR/REC-xml.
Authors' Addresses
作者地址
Joachim Strombergson InformAsic AB Hugo Grauers gata 5a Gothenburg 411 33 SE
Joachim Strombergson InformAsic AB Hugo Grauers gata 5a哥德堡411 33东南
Phone: +46 31 68 54 90
EMail: Joachim.Strombergson@InformAsic.com
URI: http://www.InformAsic.com/
Phone: +46 31 68 54 90
EMail: Joachim.Strombergson@InformAsic.com
URI: http://www.InformAsic.com/
Linus Walleij Lunds Tekniska Hogskola Master Olofs Vag 24 Lund 224 66 SE
Linus Walleij Lunds Tekniska Hogskola大师Olofs Vag 24 Lund 224 66东南
Phone: +46 703 193678
EMail: triad@df.lth.se
Phone: +46 703 193678
EMail: triad@df.lth.se
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
Patrik Faltstrom思科系统有限公司Ledasa 273 71瑞典洛夫斯塔德
EMail: paf@cisco.com
URI: http://www.cisco.com
EMail: paf@cisco.com
URI: http://www.cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。