RFC3261: SIP:7.3.1报头字段格式

7.3.1 Header Field Format
7.3.1报头字段格式

   Header fields follow the same generic header format as that given in [3].  Each header field consists of a field name followed by a colon (":") and the field value.
​
报头字段遵循与[3]中给出的相同的通用报头格式。每个报头字段都包含一个字段名，后跟冒号（“：”）和字段值。
​

      field-name: field-value
        字段名称：字段值

   The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value.

​第25节中指定的消息头的形式语法允许冒号两侧任意数量的空白；但是，实现应该避免在字段名和冒号之间使用空格，并在冒号和字段值之间使用单个空格（SP）。

      Subject:            lunch
      Subject      :      lunch
      Subject            :lunch
      Subject: lunch

   Thus, the above are all valid and equivalent, but the last is the preferred form.

因此，以上都是有效和等效的，但最后一种是首选形式。

   Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT).  The line break and the whitespace at the beginning of the next line are treated as a single SP character.  Thus, the following are equivalent:

通过在每一行前面至少加一个SP或水平制表符（HT），可以在多行上扩展报头字段。换行符和下一行开头的空白被视为单个SP字符。因此，以下内容是等效的：

      Subject: I know you're there, pick up the phone and talk to me!
      Subject: I know you're there,
               pick up the phone
               and talk to me!

   The relative order of header fields with different field names is not significant.  However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing.  The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3).  It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.  The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields.  Multiple header field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row.

​具有不同字段名称的报头字段的相对顺序并不重要。但是，建议代理处理所需的报头字段（例如，Via、Route、Record Route、proxy Require、Max Forwards和proxy Authorization）显示在消息的顶部，以便于快速解析。具有相同字段名称的报头字段行的相对顺序很重要。如果且仅当该报头字段的整个字段值被定义为逗号分隔列表（即，如果遵循第7.3节中定义的语法），则消息中可能存在多个具有相同字段名称的报头字段行。必须能够将多个报头字段行组合成一个“字段名称：字段值”对，而不改变消息的语义，通过将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。此规则的例外情况是WWW-Authenticate、Authorization、Proxy Authenticate和Proxy Authorization报头字段。一条消息中可能存在多个具有这些名称的报头字段行，但由于它们的语法不遵循第7.3节中列出的一般形式，因此不得将它们组合成一个报头字段行。

   Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms.

实现必须能够以每行单个值或逗号分隔的值形式的任何组合处理具有相同名称的多个报头字段行。

   The following groups of header field rows are valid and equivalent:

以下报头字段行组有效且等效：

      Route: <sip:alice@atlanta.com>
      Subject: Lunch
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>
      Subject: Lunch

      Subject: Lunch
      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
             <sip:carol@chicago.com>

   Each of the following blocks is valid but not equivalent to the others:

以下每个块都是有效的，但不等同于其他块：

      Route: <sip:alice@atlanta.com>
      Route: <sip:bob@biloxi.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:bob@biloxi.com>
      Route: <sip:alice@atlanta.com>
      Route: <sip:carol@chicago.com>

      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
             <sip:bob@biloxi.com>

   The format of a header field-value is defined per header-name.  It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs:

报头字段值的格式是按报头名称定义的。它将始终是TEXT-UTF8八位字节的不透明序列，或者是空白、标记、分隔符和带引号的字符串的组合。许多现有的头字段将遵循值的一般形式，后面是参数名称、参数值对的分号分隔序列：

         field-name: field-value *(;parameter-name=parameter-value)

   Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once.

即使报头字段值可以附加任意数量的参数对，任何给定的参数名称也不得出现多次。

   When comparing header fields, field names are always case-insensitive.  Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive.  Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive.  For example,

在比较报头字段时，字段名称始终不区分大小写。除非在特定报头字段的定义中另有说明，否则字段值、参数名称和参数值不区分大小写。令牌总是不区分大小写。除非另有规定，否则用带引号的字符串表示的值区分大小写。例如

      Contact: <sip:alice@atlanta.com>;expires=3600

   is equivalent to
等效于

      CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

   and
和

      Content-Disposition: session;handling=optional

   is equivalent to
等效于

      content-disposition: Session;HANDLING=OPTIONAL

   The following two header fields are not equivalent:
以下两个报头字段不等效：

      Warning: 370 devnull "Choose a bigger pipe"
      Warning: 370 devnull "CHOOSE A BIGGER PIPE"