RFC1505 日本語訳

1505 Encoding Header Field for Internet Messages. A. Costanzo, D.Robinson, R. Ullmann. August 1993. (Format: TXT=63796 bytes) (Obsoletes RFC1154) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        A. Costanzo
Request for Comments: 1505                                AKC Consulting
Obsoletes: 1154                                              D. Robinson
                                              Computervision Corporation
                                                              R. Ullmann
                                                             August 1993

コメントを求めるワーキンググループA.コスタンゾ要求をネットワークでつないでください: 1505年のAKCコンサルティングは以下を時代遅れにします。 1154 D.ロビンソンComputervision社のR.ウルマン1993年8月

              Encoding Header Field for Internet Messages

インターネットメッセージのためのヘッダーフィールドをコード化します。

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

IESG Note

IESG注意

   Note that a standards-track technology already exists in this area
   [11].

標準化過程技術がこの領域[11]に既に存在することに注意してください。

Abstract

要約

   This document expands upon the elective experimental Encoding header
   field which permits the mailing of multi-part, multi-structured
   messages.  It replaces RFC 1154 [1].

このドキュメントは複合の、そして、マルチ構造化されたメッセージの郵送を可能にする選挙の実験Encodingヘッダーフィールドに広がります。 それはRFC1154[1]を取り替えます。

Table of Contents

目次

          1.      Introduction . . . . . . . . . . . . . . . . . . . . 3
          2.      The Encoding Field . . . . . . . . . . . . . . . . . 3
          2.1       Format of the Encoding Field . . . . . . . . . . . 3
          2.2       <count>  . . . . . . . . . . . . . . . . . . . . . 4
          2.3       <keyword>  . . . . . . . . . . . . . . . . . . . . 4
          2.3.1       Nested Keywords  . . . . . . . . . . . . . . . . 4
          2.4       Comments . . . . . . . . . . . . . . . . . . . . . 4
          3.      Encodings  . . . . . . . . . . . . . . . . . . . . . 5
          3.1       Text . . . . . . . . . . . . . . . . . . . . . . . 5
          3.2       Message  . . . . . . . . . . . . . . . . . . . . . 6
          3.3       Hex  . . . . . . . . . . . . . . . . . . . . . . . 6
          3.4       EVFU . . . . . . . . . . . . . . . . . . . . . . . 6
          3.5       EDI-X12 and EDIFACT  . . . . . . . . . . . . . . . 7
          3.6       FS   . . . . . . . . . . . . . . . . . . . . . . . 7
          3.7       LZJU90 . . . . . . . . . . . . . . . . . . . . . . 7
          3.8       LZW  . . . . . . . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . 3 2。 コード化分野. . . . . . . . . . . 3 2.2<カウント>. . . . . . . . . . . . . . . . . . . . . 4 2.3<>. . . . . . . . . . . . . . . . . . . . 4 2.3.1のキーワードの入れ子にされたキーワード. . . . . . . . . . . . . . . . 4 2.4コメント. . . . . . . . . . . . . . . . . . . . . 4 3のコード化分野. . . . . . . . . . . . . . . . . 3 2.1形式。 Encodings. . . . . . . . . . . . . . . . . . . . . 5 3.1テキスト. . . . . . . . . . . . . . . . . . . . . . . 5 3.2メッセージ. . . . . . . . . . . . . . . . . . . . . 6 3.3十六進法. . . . . . . . . . . . . . . . . . . . . . . 6 3.4EVFU. . . . . . . . . . . . . . . . . . . . . . . 6 3.5EDI-X12とEDIFACT. . . . . . . . . . . . . . . 7 3.6FS. . . . . . . . . . . . . . . . . . . . . . . 7 3.7LZJU90. . . . . . . . . . . . . . . . . . . . . . 7 3.8LZW. . . . . . . . . . . . . . . . . . . . . . . 7

Costanzo, Robinson & Ullmann                                    [Page 1]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[1ページ]RFC1505

          3.9       UUENCODE . . . . . . . . . . . . . . . . . . . . . 7
          3.10      PEM and PEM-Clear  . . . . . . . . . . . . . . . . 8
          3.11      PGP  . . . . . . . . . . . . . . . . . . . . . . . 8
          3.12      Signature  . . . . . . . . . . . . . . . . . . .  10
          3.13      TAR  . . . . . . . . . . . . . . . . . . . . . .  10
          3.14      PostScript . . . . . . . . . . . . . . . . . . .  10
          3.15      SHAR . . . . . . . . . . . . . . . . . . . . . .  10
          3.16      Uniform Resource Locator . . . . . . . . . . . .  10
          3.17      Registering New Keywords . . . . . . . . . . . .  11
          4.      FS (File System) Object Encoding . . . . . . . . .  11
          4.1       Sections . . . . . . . . . . . . . . . . . . . .  12
          4.1.1       Directory  . . . . . . . . . . . . . . . . . .  12
          4.1.2       Entry  . . . . . . . . . . . . . . . . . . . .  13
          4.1.3       File . . . . . . . . . . . . . . . . . . . . .  13
          4.1.4       Segment  . . . . . . . . . . . . . . . . . . .  13
          4.1.5       Data . . . . . . . . . . . . . . . . . . . . .  14
          4.2       Attributes . . . . . . . . . . . . . . . . . . .  14
          4.2.1       Display  . . . . . . . . . . . . . . . . . . .  14
          4.2.2       Comment  . . . . . . . . . . . . . . . . . . .  15
          4.2.3       Type . . . . . . . . . . . . . . . . . . . . .  15
          4.2.4       Created  . . . . . . . . . . . . . . . . . . .  15
          4.2.5       Modified . . . . . . . . . . . . . . . . . . .  15
          4.2.6       Accessed . . . . . . . . . . . . . . . . . . .  15
          4.2.7       Owner  . . . . . . . . . . . . . . . . . . . .  15
          4.2.8       Group  . . . . . . . . . . . . . . . . . . . .  16
          4.2.9       ACL  . . . . . . . . . . . . . . . . . . . . .  16
          4.2.10      Password . . . . . . . . . . . . . . . . . . .  16
          4.2.11      Block  . . . . . . . . . . . . . . . . . . . .  16
          4.2.12      Record . . . . . . . . . . . . . . . . . . . .  17
          4.2.13      Application  . . . . . . . . . . . . . . . . .  17
          4.3       Date Field . . . . . . . . . . . . . . . . . . .  17
          4.3.1       Syntax . . . . . . . . . . . . . . . . . . . .  17
          4.3.2       Semantics  . . . . . . . . . . . . . . . . . .  17
          5.      LZJU90: Compressed Encoding  . . . . . . . . . . .  18
          5.1       Overview . . . . . . . . . . . . . . . . . . . .  18
          5.2       Specification of the LZJU90 compression  . . . .  19
          5.3       The Decoder  . . . . . . . . . . . . . . . . . .  21
          5.3.1       An example of an Encoder . . . . . . . . . . .  27
          5.3.2       Example LZJU90 Compressed Object . . . . . . .  33
          6.      Alphabetical Listing of Defined Encodings  . . . .  34
          7.      Security Considerations  . . . . . . . . . . . . .  34
          8.      References . . . . . . . . . . . . . . . . . . . .  34
          9.      Acknowledgements . . . . . . . . . . . . . . . . .  35
          10.     Authors' Addresses . . . . . . . . . . . . . . . .  36

3.9 UUENCODE. . . . . . . . . . . . . . . . . . . . . 7 3.10PEMとPEM明確な.83.11PGP. . . . . . . . . . . . . . . . . . . . . . . 8 3.12署名. . . . . . . . . . . . . . . . . . . 10 3.13はタールを塗ります…; 新しいキーワード. . . . . . . . . . . . 11 4を登録する.10 3.14のポストスクリプト. . . . . . . . . . . . . . . . . . . 10 3.15のSHAR. . . . . . . . . . . . . . . . . . . . . . 10 3.16Uniform Resource Locator. . . . . . . . . . . . 10 3.17。 FS(ファイルシステム)物のコード化. . . . . . . . . 11 4.1セクション. . . . . . . . . . . . . . . . . . . . 12 4.1 .1 ディレクトリ. . . . . . . . . . . . . . . . . . 12 4.1.2エントリー. . . . . . . . . . . . . . . . . . . . 13 4.1.3はファイルされます…; . . . . . . . . 13 4.1.4 セグメント. . . . . . . . . . . . . . . . . . . 13 4.1.5のデータ. . . . . . . . . . . . . . . . . . . . . 14 4.2の属性. . . . . . . . . . . . . . . . . . . 14 4.2.1表示. . . . . . . . . . . . . . . . . . . 14 4.2.2はコメントします; . . . . . . . . . . . . . . . . . . 15 4.2.3 タイプ. . . . . . . . . . . . . . . . . . . . . 15 4.2.4は変更された.154.2のアクセスされた.154.2.7所有者.154.2.8グループ. . . . . . . . . . . . . . . . . . . . 16 4.2.9.5.154.2.6ACL. . . . . . . . . . . . . . . . . . . . . 16 4.2.10パスワード. . . . . . . . . . . . . . . . . . . 16 4.2.11ブロックを作成しました… . . . . . . . . . . . . . 16 4.2 .12 記録的な.174.2.13アプリケーション. . . . . . . . . . . . . . . . . 17 4.3は分野.174.3.1構文. . . . . . . . . . . . . . . . . . . . 17 4.3.2の意味論. . . . . . . . . . . . . . . . . . 17 5と日付を入れます。 LZJU90: LZJU90圧縮. . . . 19 5.3の圧縮されたEncoding. . . . . . . . . . . 18 5.1Overview.185.2Specification、Encoder. . . . . . . . . . . 27 5.3.2Example LZJU90 Compressed Object. . . . . . . 33 6に関するDecoder.215.3.1Anの例 定義されたEncodings. . . . 34 7に関するアルファベット順リスト。 セキュリティ問題. . . . . . . . . . . . . 34 8。 参照. . . . . . . . . . . . . . . . . . . . 34 9。 承認. . . . . . . . . . . . . . . . . 35 10。 作者のアドレス. . . . . . . . . . . . . . . . 36

Costanzo, Robinson & Ullmann                                    [Page 2]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[2ページ]RFC1505

1.  Introduction

1. 序論

   STD 11, RFC 822 [2] defines an electronic mail message to consist of
   two parts, the message header and the message body, separated by a
   blank line.

STD11、RFC822[2]は空白行によって切り離された2つの部品から成る電子メールメッセージ、メッセージヘッダー、およびメッセージ本体を定義します。

   The Encoding header field permits the message body itself to be
   further broken up into parts, each part also separated from the next
   by a blank line.  Thus, conceptually, a message has a header part,
   followed by one or more body parts, all separated by apparently blank
   lines.  Each body part has an encoding type.  The default (no
   Encoding field in the header) is a one part message body of type
   "Text".

Encodingヘッダーフィールドは、メッセージ本体自体がさらに部品(また、空白行によって次と切り離された各部分)に壊れるのを許容します。 このようにして、概念的に、メッセージには、1つ以上の身体の部分があとに続いたヘッダー部分があります、明らかに空白の線によって切り離されたすべて。 コード化が部分でタイプする各ボディー。 デフォルト(ヘッダーでEncoding分野がない)はタイプ「テキスト」の一部メッセージ本体です。

   The purpose of Encoding is to be descriptive of the content of a mail
   message without placing constraints on the content or requiring
   additional structure to appear in the body of the message that will
   interfere with other processing.

Encodingの目的は他の処理を妨げるメッセージ欄に現れる置く規制のない内容か追加構造を必要とすることに関するメール・メッセージの内容で描写的であることです。

   A similar message format is used in the network news facility, and
   posted articles are often transferred by gateways between news and
   mail.  The Encoding field is perhaps even more useful in news, where
   articles often are uuencoded or shar'd, and have a number of
   different nested encodings of graphics images and so forth.  In news
   in particular, the Encoding header keeps the structural information
   within the (usually concealed) article header, without affecting the
   visual presentation by simple news-reading software.

ネットニュース施設で同様のメッセージ・フォーマットを使用します、そして、ゲートウェイはしばしばニュースとメールの間に掲示された記事を移します。 Encoding分野は恐らくニュースでさらに役に立ちます、そして、グラフィックスイメージなどの多くの異なった入れ子にされたencodingsを持ってください。(そこでは、記事がしばしばuuencodedされるか、またはsharはuuencodedされるでしょう)。 特にニュースでは、Encodingヘッダーは(通常、隠します)の記事ヘッダーの中に構造的な情報を保ちます、簡単なニュースを閲読するソフトウェアでビジュアル・プレゼンテーションに影響しないで。

2.  The Encoding Field

2. コード化分野

   The Encoding field consists of one or more subfields, separated by
   commas.  Each subfield corresponds to a part of the message, in the
   order of that part's appearance.  A subfield consists of a line count
   and a keyword or a series of nested keywords defining the encoding.
   The line count is optional in the last subfield.

Encoding分野はコンマによって切り離された1つ以上の部分体から成ります。 各部分体はその部分の外観の注文におけるメッセージの一部に対応しています。 部分体はラインカウントとキーワードかコード化を定義する一連の入れ子にされたキーワードから成ります。 ラインカウントは最後の部分体で任意です。

2.1  Format of the Encoding Field

2.1 コード化分野の形式

   The format of the Encoding field is:

Encoding分野の形式は以下の通りです。

        [  <count> <keyword> [ <keyword> ]* ,  ]*
                [ <count> ] <keyword> [ <keyword> ]*

[<カウント><キーワード>[<キーワード>]*] *[<カウント>]<キーワード>[<キーワード>]*

        where:

どこ:

        <count>    := a decimal integer
        <keyword>  := a single alphanumeric token starting with an alpha

<はアルファから始まる10進>の>:=a単一の英数字の:=a整数<キーワード象徴を数えます。

Costanzo, Robinson & Ullmann                                    [Page 3]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[3ページ]RFC1505

2.2  <count>

2.2 <カウント>。

   The line count is a decimal number specifying the number of text
   lines in the part.  Parts are separated by a blank line, which is not
   included in the count of either the preceding or following part.
   Blank lines consist only of CR/LF.  Count may be zero, it must be
   non-negative.

ラインカウントは部分のテキスト線の数を指定する10進数です。 部品は空白行によって切り離されます。(それは、先行か部分に続くカウントに含まれていません)。 空白行はCR/LFだけから成ります。 カウントがゼロであるかもしれない、それは非否定的であるに違いありません。

   It is always possible to determine if the count is present because a
   count always begins with a digit and a keyword always begins with a
   letter.

カウントがいつもケタで始まって、キーワードが手紙でいつも始まるのでカウントが存在しているかどうか決定するのはいつも可能です。

   The count is not required on the last or only part.  A multi-part
   message that consists of only one part is thus identical to a
   single-part message.

カウントは最終か唯一の部分の上で必要ではありません。 その結果、一部だけから成る複合メッセージはただ一つの部分メッセージと同じです。

2.3  <keyword>

2.3 <キーワード>。

   Keyword defines the encoding type.  The keyword is a common single-
   word name for the encoding type and is not case-sensitive.

キーワードはコード化しているタイプを定義します。 キーワードは、一般的なコード化しているタイプに、ただ一つの単語名であり、大文字と小文字を区別していません。

             Encoding: 107 Text

コード化します: 107 テキスト

2.3.1  Nested Keywords

2.3.1 入れ子にされたキーワード

   Nested keywords are a series of keywords defining a multi-encoded
   message part.  The encoding keywords may either be an actual series
   of encoding steps the encoder used to generate the message part or
   may merely be used to more precisely identify the type of encoding
   (as in the use of the keyword "Signature").

入れ子にされたキーワードはマルチコード化されたメッセージ部分を定義する一連のキーワードです。 コード化キーワードは、実際のシリーズについてエンコーダがメッセージ部分を発生させるのに使用したステップをコード化するか、または、より正確にコード化のタイプを特定するのに単に使用されるかもしれません(「署名」というキーワードの使用のように)。

   Nested keywords are parsed and generated from left to right.  The
   order is significant.  A decoding application would process the list
   from left to right, whereas, an encoder would process the Internet
   message and generate the nested keywords in the reverse order of the
   actual encoding process.

入れ子にされたキーワードは、左から右まで分析されて、発生します。 オーダーは重要です。 解読アプリケーションが左から右までリストを処理するでしょうが、エンコーダは、実際のコード化の過程の逆順でインターネットメッセージを処理して、入れ子にされたキーワードを発生させるでしょう。

        Encoding: 458 uuencode LZW tar (Unix binary object)

コード化します: 458 uuencode LZWタール(unixの2進の物)

2.4  Comments

2.4 コメント

   Comments enclosed in parentheses may be inserted anywhere in the
   encoding field.  Mail reading systems may pass the comments to their
   clients.  Comments must not be used by mail reading systems for
   content interpretation.  Other parameters defining the type of
   encoding must be contained within the body portion of the Internet
   message or be implied by a keyword in the encoding field.

括弧に同封されたコメントはコード化分野でどこでも挿入されるかもしれません。 メール読書システムは彼らのクライアントにコメントを渡すかもしれません。 コメントは満足している解釈のシステムを読む郵便配達人に使用されてはいけません。 コード化のタイプを定義する他のパラメタを、インターネットメッセージのボディー部分の中に含まれなければならないか、またはコード化分野でキーワードで含意しなければなりません。

Costanzo, Robinson & Ullmann                                    [Page 4]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[4ページ]RFC1505

3.  Encodings

3. Encodings

   This section describes some of the defined encodings used.  An
   alphabetical listing is provided in Section 6.

このセクションはencodingsが使用した定義のいくつかについて説明します。 セクション6にアルファベット順のリストを提供します。

   As with the other keyword-defined parts of the header format
   standard, new keywords are expected and welcomed.  Several basic
   principles should be followed in adding encodings.  The keyword
   should be the most common single word name for the encoding,
   including acronyms if appropriate.  The intent is that different
   implementors will be likely to choose the same name for the same
   encoding.  Keywords should not be too general:  "binary" would have
   been a bad choice for the "hex" encoding.

ヘッダー形式規格の他のキーワードで定義された部品のように、新しいキーワードは、予想されて、歓迎されます。 encodingsを加える際にいくつかの基本原理に従うべきです。 キーワードは大部分がコード化のための頭文字語を含む一般的な一語名であるなら適切であるならそうするでしょうに。 意図は異なった作成者を同じコード化のための同じ名前を選びそうであるということです。 キーワードはそれほど一般的であるべきではありません: 「バイナリー」は「十六進法」コード化のための下手な選択だったでしょう。

   The encoding should be as free from unnecessary idiosyncracies as
   possible, except when conforming to an existing standard, in which
   case there is nothing that can be done.

コード化には、不要な特異性ができるだけあるべきではありません、既存の規格に従って、その場合、できないことがある時を除いて。

   The encoding should, if possible, use only the 7 bit ASCII printing
   characters if it is a complete transformation of a source document
   (e.g., "hex" or "uuencode").  If it is essentially a text format, the
   full range may be used.  If there is an external standard, the
   character set may already be defined.  Keywords beginning with "X-"
   are permanently reserved to implementation-specific use.  No standard
   registered encoding keyword will ever begin with "X-".

できれば、コード化はそれがソースドキュメント(例えば、「十六進法」か"uuencode")の完全な変化であるなら7ビットのASCII表示文字だけを使用するべきです。 それが本質的にはテキスト形式であるなら、最大限の範囲は使用されるかもしれません。 外部の規格があれば、文字の組は既に定義されるかもしれません。 「X」と共に始まるキーワードは永久に、実現特定的用法に予約されます。 キーワードをコード化しながら示されなかった規格は全く「X」と共に始まるでしょう。

   New encoding keywords which are not reserved for implementation-
   specific use must be registered with the Internet Assigned Numbers
   Authority (IANA).  Refer to section 3.17 for additional information.

実現特定的用法のために予約されない新しいコード化キーワードをインターネットAssigned民数記Authorityに登録しなければなりません(IANA)。 追加情報についてセクション3.17を参照してください。

3.1  Text

3.1 テキスト

   This indicates that the message is in no particular encoded format,
   but is to be presented to the user as-is.

これは、どんな特定のコード化された形式にもメッセージがないのを示しますが、そのままなユーザに提示されることになっています。

   The text is ISO-10646-UTF-1 [3].  As specified in STD 10, RFC 821
   [10], the message is expected to consist of lines of reasonable
   length (less than or equal to 1000 characters).

テキストはISO-10646-UTF-1[3]です。 STD10、RFC821[10]で指定されるように、メッセージが妥当な長さ(1000以下のキャラクタ)の線から成ると予想されます。

   On some older implementations of mail and news, only the 7 bit subset
   of ISO-10646-UTF-1 can be used.  This is identical to the ASCII 7 bit
   code.  On some mail transports that are not compliant with STD 10,
   RFC 821 [10], line length may be restricted by the service.

メールとニュースのいくつかの、より古い実現のときに、ISO-10646-UTF-1の7ビットの部分集合しか使用できません。 これはASCII7ビット・コードと同じです。 いくつかのSTD10、RFC821[10]で対応でないメール輸送のときに、行長はサービスで制限されるかもしれません。

   Text may be followed by a nested keyword to define the encoded part
   further, e.g., "signature":

さらにコード化された部分を定義する入れ子にされたキーワード、例えば、「署名」はテキストのあとに続くかもしれません:

        Encoding: 496 Text, 8 Text Signature

コード化します: 496 テキスト、8テキスト署名

Costanzo, Robinson & Ullmann                                    [Page 5]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[5ページ]RFC1505

   An automated file sending service may find this useful, for example,
   to differentiate between and ignore the signature area when parsing
   the body of a message for file requests.

自動化されたファイル送付サービスによって、例えば、これがファイル要求へのメッセージのボディーを分析するとき、署名領域を区別して、無視するために役に立つのがわかるかもしれません。

3.2  Message

3.2 メッセージ

   This encoding indicates that the body part is itself in the format of
   an Internet message, with its own header part and body part(s).  A
   "message" body part's message header may be a full Internet message
   header or it may consist only of an Encoding field.

このコード化は、インターネットメッセージの形式には身体の部分がそれ自体であるのを示します、それ自身のヘッダー部分と身体の部分で。 身体の部分のメッセージヘッダーが完全なインターネットメッセージヘッダーであるかもしれないという「メッセージ」かそれがEncoding分野だけから成るかもしれません。

   Using the message encoding on returned mail makes it practical for a
   mail reading system to implement a reliable automatic resending
   function, if the mailer generates it when returning contents.  It is
   also useful in a "copy append" MUA (mail user agent) operation.

返されたメールでメッセージコード化を使用するのにメール読書システムが信頼できる自動再送機能を実行するのが実用的になります、コンテンツを返すとき、郵送者がそれを発生させるなら。 また、それもaで役に立つ、「コピーは」 MUA(メールユーザエージェント)操作を追加します。

   MTAs (mail transfer agents) returning mail should generate an
   Encoding header.  Note that this does not require any parsing or
   transformation of the returned message; the message is simply
   appended un-modified; MTAs are prohibited from modifying the content
   of messages.

MTAs(メール転送エージェント)の戻っているメールはEncodingヘッダーを発生させるべきです。 これがどんな構文解析や変化にも返されたメッセージを要求しないことに注意してください。 単に変更されていなくメッセージを追加します。 MTAsはメッセージの内容を変更するのが禁止されています。

        Encoding: 7 Text (Return Reason), Message (Returned Mail)

コード化します: 7 テキスト(リターン理由)、メッセージ(返されたメール)

3.3  Hex

3.3 十六進法

   The encoding indicates that the body part contains binary data,
   encoded as 2 hexadecimal digits per byte, highest significant nibble
   first.

コード化は、身体の部分が最初に1バイトあたり2つの16進数字、最も高いかなりの少量としてコード化された2進のデータを含むのを示します。

   Lines consist of an even number of hexadecimal digits.  Blank lines
   are not permitted.  The decode process must accept lines with between
   2 and 1000 characters, inclusive.

線は16進数字の偶数から成ります。 空白行は受入れられません。 2〜1000がキャラクタ的であって、包括的に解読の過程は線を受け入れなければなりません。

   The Hex encoding is provided as a simple way of providing a method of
   encoding small binary objects.

小さい2進の物をコード化する方法を提供する簡単な方法としてHexコード化を提供します。

3.4  EVFU

3.4 EVFU

   EVFU (electronic vertical format unit) specifies that each line
   begins with a one-character "channel selector".  The original purpose
   was to select a channel on a paper tape loop controlling the printer.

EVFU(電子紙送り制御)は、各線が1キャラクタ「チャンネル・セレクタ」で始まると指定します。 初心はプリンタを制御しながら紙テープ輪の上でチャンネルを選ぶことでした。

   This encoding is sometimes called "FORTRAN" format.  It is the
   default output format of FORTRAN programs on a number of computer
   systems.

このコード化は時々「FORTRAN」形式と呼ばれます。 それは多くのコンピュータ・システムの上のFORTRANプログラムのデフォルト出力形式です。

Costanzo, Robinson & Ullmann                                    [Page 6]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[6ページ]RFC1505

   The legal characters are '0' to '9', '+', '-', and space.  These
   correspond to the 12 rows (and absence of a punch) on a printer
   control tape (used when the control unit was electromechanical).

法的なキャラクタは'9、''+''への'0'です--'スペース。 これらはプリンタコントロールテープ(制御装置が電気機械であったときに、使用される)の上の12の行(そして、パンチの不在)に対応しています。

   The channels that have generally agreed definitions are:

一般に、定義に同意したチャンネルは以下の通りです。

        1          advances to the first print line on the next page
        0          skip a line, i.e., double-space
        +          over-print the preceeding line
        -          skip 2 lines, i.e., triple-space
        (space)    print on the next line, single-space

すなわち、preceeding系列をダブルスペースにするか、または重ね打ちしてください--次の0ページの最初の印刷系列への1進歩は系列をスキップして、スキップ2は立ち並んでいて、すなわち、トリプル・スペース(スペース)は次の系列への印刷です、シングルスペース

3.5  EDI-X12 and EDIFACT

3.5 EDI-X12とEDIFACT

   The EDI-X12 and EDIFACT keywords indicate that the message or part is
   a EDI (Electronic Document Interchange) business document, formatted
   according to ANSI X12 or the EDIFACT standard.

EDI-X12とEDIFACTキーワードは、メッセージか部分がANSI X12によると、フォーマットされたEDI(電子Document Interchange)ビジネスドキュメントかEDIFACT規格であることを示します。

   A message containing a note and 2 X12 purchase orders might have an
   encoding of:

注意と2つのX12購買注文を含むメッセージは以下のコード化を持っているかもしれません。

        Encoding: 17 TEXT, 146 EDI-X12, 69 EDI-X12

コード化します: 17 テキスト、146エディ-X12、69エディ-X12

3.6  FS

3.6 FS

   The FS (File System) keyword specifies a section consisting of
   encoded file system objects.  This encoding method (defined in
   section 4) allows the moving of a structured set of files from one
   environment to another while preserving all common elements.

FS(ファイルSystem)キーワードはコード化されたファイルシステム対象物から成るセクションを指定します。 このコード化メソッド(セクション4で、定義される)はすべての一般的な要素を保存している間、構造化されたセットのファイルの1つの環境から別の環境までの移行を許します。

3.7  LZJU90

3.7 LZJU90

   The LZJU90 keyword specifies a section consisting of an encoded
   binary or text object.  The encoding (defined in section 5) provides
   both compression and representation in a text format.

LZJU90キーワードはコード化されたバイナリーかテキストオブジェクトから成るセクションを指定します。 コード化(セクション5で、定義される)は圧縮と表現の両方をテキスト形式に提供します。

3.8  LZW

3.8 LZW

   The LZW keyword specifies a section consisting of the data produced
   by the Unix compress program.

LZWキーワードはUnix湿布プログラムで作り出されたデータから成るセクションを指定します。

3.9  UUENCODE

3.9 UUENCODE

   The uuencode keyword specifies a section consisting of the output of
   the uuencode program supplied as part of uucp.

uuencodeキーワードはuucpの一部として提供されたuuencodeプログラムの出力から成るセクションを指定します。

Costanzo, Robinson & Ullmann                                    [Page 7]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[7ページ]RFC1505

3.10  PEM and PEM-Clear

3.10 PEMとはっきりとPEM

   The PEM and PEM-Clear keywords indicate that the section is encrypted
   with the methods specified in RFCs 1421-1424 [4,5,6,7] or uses the
   MIC-Clear encapsulation specified therein.

PEMとPEM明確なキーワードは、セクションがメソッドがRFCs1421-1424[4、5、6、7]で指定されている状態で暗号化されるか、またはそこに指定されたMIC明確なカプセル化を使用するのを示します。

   A simple text object encrypted with PEM has the header:

PEMと共に暗号化された簡単なテキストオブジェクトには、ヘッダーがあります:

             Encoding: PEM Text

コード化します: PEMテキスト

   Note that while this indicates that the text resulting from the PEM
   decryption is ISO-10646-UTF-1 text, the present version of PEM
   further restricts this to only the 7 bit subset.  A future version of
   PEM may lift this restriction.

これが、PEM復号化から生じるテキストがISO-10646-UTF-1テキストであることを示しますが、PEMの現在のバージョンがさらにこれを7ビットの部分集合だけに制限することに注意してください。 PEMの将来のバージョンはこの制限について提案するかもしれません。

   If the object resulting from the decryption starts with Internet
   message header(s), the encoding is:

復号化から生じるオブジェクトがインターネットメッセージヘッダーから始めるなら、コード化は以下の通りです。

             Encoding: PEM Message

コード化します: PEMメッセージ

   This is useful to conceal both the encoding within and the headers
   not needed to deliver the message (such as Subject:).

これは両方のコード化を隠すために役に立ちます、そして、ヘッダーはメッセージ(Subject:などの)を提供する必要はありませんでした。

   PEM does not provide detached signatures, but rather provides the
   MIC-Clear mode to send messages with integrity checks that are not
   encrypted.  In this mode, the keyword PEM-Clear is used:

PEMは、離れている署名を提供しませんが、暗号化されなかった保全チェックと共にメッセージを送るためにむしろMIC明確なモードを提供します。 このモードで、はっきりとキーワードPEMは使用されています:

             Encoding: PEM-Clear EDIFACT

コード化します: PEM明確なEDIFACT

   The example being a non-encrypted EDIFACT transaction with a digital
   signature.  With the proper selection of PEM parameters and
   environment, this can also provide non-repudiation, but it does not
   provide confidentiality.

デジタル署名がある非暗号化されたEDIFACTトランザクションである例。 また、PEMパラメタと環境の適切な選択には、これは非拒否を提供できますが、それは秘密性を提供しません。

   Decoders that are capable of decrypting PEM treat the two keywords in
   the same way, using the contained PEM headers to distinguish the
   mode.  Decoders that do not understand PEM can use the PEM-Clear
   keyword as a hint that it may be useful to treat the section as text,
   or even continue the decode sequence after removing the PEM headers.

同様に、PEMを解読することができるデコーダが2つのキーワードを扱います、モードを区別するのに含まれたPEMヘッダーを使用して。 PEMを理解していないデコーダがテキストとしてセクションを扱うのが役に立つかもしれないというヒントとしてPEM明確なキーワードを使用するか、または続くことさえできる、PEMヘッダーを取り除いた後に、系列を解読してください。

   When Encoding is used for PEM, the RFC934 [9] encapsulation specified
   in RFC1421 is not used.

EncodingがPEMに使用されるとき、RFC1421で指定されたRFC934[9]カプセル化は使用されていません。

3.11  PGP

3.11 PGP

   The PGP keyword indicates that the section is encrypted using the
   Pretty Good Privacy specification, or is a public key block, keyring,
   or detached signature meaningful to the PGP program.  (These objects

PGPキーワードは、PGPプログラムに重要なセクションがプリティ・グッド・プライバシ仕様を使用することで暗号化されているのを示すか、公開鍵ブロック、keyring、または離れている署名です。 (これらのオブジェクト

Costanzo, Robinson & Ullmann                                    [Page 8]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[8ページ]RFC1505

   are distinguished by internal information.)

内部の情報によって区別されます。)

   The keyword actually implies 3 different transforms:  a compression
   step, the encryption, and an ASCII encoding.  These transforms are
   internal to the PGP encoder/decoder.  A simple text message encrypted
   with PGP is specified by:

キーワードは実際に3つの異なった変換を含意します: 圧縮ステップ、暗号化、およびASCIIコード化。 これらの変換はPGPエンコーダ/デコーダに内部です。 PGPと共に暗号化された簡単なテキストメッセージは以下によって指定されます。

        Encoding: PGP Text

コード化します: PGPテキスト

   An EDI transaction using ANSI X12 might be:

ANSI X12を使用するEDIトランザクションは以下の通りです。

        Encoding: 176 PGP EDI-X12

コード化します: 176 PGPエディ-X12

   Since an evesdropper can still "see" the nested type (Text or EDI in
   these examples), thus making information available to traffic
   analysis which is undesirable in some applications, the sender may
   prefer to use:

以来に、evesdropperはまだ、いくつかのアプリケーション、送付者で望ましくない分析が使用するのを好むかもしれないトラフィックに入れ子にされたタイプ(これらの例のテキストかEDI)を「見ることができ」て、その結果、情報を利用可能にします:

        Encoding: PGP Message

コード化します: PGPメッセージ

   As discussed in the description of the Message keyword, the enclosed
   object may have a complete header or consist only of an Encoding:
   header describing its content.

Messageキーワードの記述で議論するように、同封のオブジェクトは、完全なヘッダーがあるか、またはEncodingだけから成るかもしれません: 内容について説明するヘッダー。

   When PGP is used to transmit an encoded key or keyring, with no
   object significant to the mail user agent as a result of the decoding
   (e.g., text to display), the keyword is used by itself.

PGPがコード化されたキーを送るのに使用されるか、またはメールユーザエージェントにとって、解読の結果、重要なオブジェクトなしでkeyringしているとき(例えば表示するテキスト)、キーワードはそれ自体で使用されます。

   Another case of the PGP keyword occurs in "clear-signing" a message.
   That is, sending an un-encrypted message with a digital signature
   providing authentication and (in some environments) non-deniability.

PGPキーワードに関する別のケースは「明確な署名」aメッセージに現れます。 すなわち、デジタル署名が認証と(いくつかの環境における)非否認権を提供している不-暗号化メッセージを送ること。

        Encoding: 201 Text, 8 PGP Signature, 4 Text Signature

コード化します: 201 テキスト、8PGP署名、4テキスト署名

   This example indicates a 201 line message, followed by an 8 line (in
   its encoded form) PGP detached signature.  The processing of the PGP
   section is expected (in this example) to result in a text object that
   is to be treated by the receiver as a signature, possibly something
   like:

この例は201系列メッセージを示します、続いて、8系列(コード化されたフォームでの)PGP離れている署名を示します。 PGP部の処理が署名として受信機によって扱われることになっているテキストオブジェクトをもたらすと予想されます(この例で)、何かことによると以下のようなもの

        [PGP signed Ariel@Process.COM Robert L Ullmann  VALID/TRUSTED]

[ Ariel@Process.COM ロバートLウルマンVALID/TRUSTEDであると署名されるPGP]

   Note that the PGP signature algorithm is applied to the encoded form
   of the clear-text section, not the object(s) before encoding.  (Which
   would be quite difficult for encodings like tar or FS).  Continuing
   the example, the PGP signature is then followed by a 4 line
   "ordinary" signature section.

PGP署名アルゴリズムがコード化の前のオブジェクトではなく、クリアテキスト部のコード化されたフォームに適用されることに注意してください。 (encodingsには、タールやFSのようにかなり難しいでしょう。) 例を続けていて、そして、PGP署名は4系列「普通」署名部によって続かれています。

Costanzo, Robinson & Ullmann                                    [Page 9]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[9ページ]RFC1505

3.12  Signature

3.12 署名

   The signature keyword indicates that the section contains an Internet
   message signature.  An Internet message signature is an area of an
   Internet message (usually located at the end) which contains a single
   line or multiple lines of characters.  The signature may comprise the
   sender's name or a saying the sender is fond of.  It is normally
   inserted automatically in all outgoing message bodies.  The encoding
   keyword "Signature" must always be nested and follow another keyword.

署名キーワードは、セクションがインターネットメッセージ署名を含むのを示します。 インターネットメッセージ署名はキャラクタの単線か複数の系列を含むインターネットメッセージ(通常、終わりに見つけられている)の領域です。 署名は送付者が好きである送付者の名前かことわざを包括するかもしれません。 通常、それは自動的にすべての送信されるメッセージ本体に挿入されます。 「署名」というコード化キーワードは、いつも入れ子にされて、別のキーワードに従わなければなりません。

        Encoding: 14 Text, 3 Text Signature

コード化します: 14 テキスト、3テキスト署名

   A usenet news posting program should generate an encoding showing
   which is the text and which is the signature area of the posted
   message.

usenetニュース任命プログラムはテキストであり、掲示されたメッセージの署名領域であるコード化表示を生成するはずです。

3.13  TAR

3.13 タール

   The tar keyword specifies a section consisting of the output of the
   tar program supplied as part of Unix.

タールキーワードはUnixの一部として提供されたタールプログラムの出力から成るセクションを指定します。

3.14  PostScript

3.14 ポストスクリプト

   The PostScript keyword specifies a section formatted according to the
   PostScript [8] computer program language definition.  PostScript is a
   registered trademark of Adobe Systems Inc.

ポストスクリプトキーワードはポストスクリプト[8]コンピュータ・プログラム言語定義に従ってフォーマットされたセクションを指定します。 ポストスクリプトはアドビ・システムズ株式会社の登録商標です。

3.15  SHAR

3.15 SHAR

   The SHAR keyword specifies a section encoded in shell archive format.
   Use of shar, although supported, is not recommended.

SHARキーワードはシェルアーカイブ形式でコード化されたセクションを指定します。 サポートされますが、sharの使用は推薦されません。

   WARNING:  Because the shell archive may contain commands you may not
   want executed, the decoder should not automatically execute decoded
   shell archived statements.  This warning also applies to any future
   types that include commands to be executed by the receiver.

警告: シェルアーカイブがあなたが実行して欲しいことができないコマンドを含むかもしれないので、デコーダは自動的に解読されたシェル格納された声明を作成するはずがありません。 また、この警告は受信機によって実行されるべきコマンドを含んでいるどんな将来のタイプにも適用されます。

3.16  Uniform Resource Locator

3.16 Uniform Resource Locator

   The URL keyword indicates that the section consists of zero or more
   references to resources of some type.  URL provides a facility to
   include by reference arbitrary external resources from various
   sources in the Internet.  The specification of URL is a work in
   progress in the URI working group of the IETF.

URLキーワードは、セクションがタイプに関するリソースのゼロか、より多くの参照から成るのを示します。 URLはインターネットの様々なソースから参照の任意の外部のリソースで含んでいる施設を提供します。 URLの仕様はIETFのURIワーキンググループで進行中の仕事です。

Costanzo, Robinson & Ullmann                                   [Page 10]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[10ページ]RFC1505

3.17  Registering New Keywords

3.17 新しいキーワードを登録すること。

   New encoding keywords which are not reserved for implementation-
   specific use must be registered with the Internet Assigned Numbers
   Authority (IANA).  IANA acts as a central registry for these values.
   IANA may reject or modify the keyword registration request if it does
   not meet the criteria as specified in section 3.  Keywords beginning
   with "X-" are permanently reserved to implementation-specific use.
   IANA will not register an encoding keyword that begins with "X-".
   Registration requests should be sent via electronic mail to IANA as
   follows:

実装特定的用法のために予約されない新しいコード化キーワードをインターネットAssigned民数記Authorityに登録しなければなりません(IANA)。 これらのための中央の登録が評価するようにIANAは行動します。 セクション3の指定されるとしての評価基準を満たさないなら、IANAはキーワード登録要求を拒絶するか、または変更するかもしれません。 「X」と共に始まるキーワードは永久に、実装特定的用法に予約されます。 IANAは「X」と共に始まるコード化キーワードを登録しないでしょう。 以下のIANAへの電子メールを通して登録要求を送るべきです:

             To:  IANA@isi.edu
             Subject:  Registration of a new EHF-MAIL Keyword

To: IANA@isi.edu Subject: 新しいEHF-メールKeywordの登録

   The mail message must specify the keyword for the encoding and
   acronyms if appropriate.  Documentation defining the keyword and its
   proposed purpose must be included.  The documentation must either
   reference an external non-Internet standards document or an existing
   or soon to be RFC.  If applicable, the documentation should contain a
   draft version of the future RFC.  The draft must be submitted as a
   RFC according to the normal procedure within a reasonable amount of
   time after the keyword's registration has been approved.

適切であるなら、メール・メッセージはコード化と頭文字語のためのキーワードを指定しなければなりません。 キーワードとその提案された目的を定義するドキュメンテーションを含まなければなりません。 ドキュメンテーションは、すぐ、RFCになるように外部の非インターネット標準ドキュメントか存在に参照をつけなければなりません。 適切であるなら、ドキュメンテーションは将来のRFCの草案バージョンを含むべきです。 キーワードの登録の後の妥当な時間以内の正常な手順に従ったRFCを承認したとき、草稿を提出しなければなりません。

4.  FS (File System) Object Encoding

4. FS(ファイルシステム)オブジェクトコード化

   The file system encoding provides a standard, transportable encoding
   of file system objects from many different operating systems.  The
   intent is to allow the moving of a structured set of files from one
   environment to another while preserving common elements.  At the same
   time, files can be moved within a single environment while preserving
   all attributes.

ファイルシステムコード化は多くの異なったオペレーティングシステムから規格、ファイルシステム対象物の輸送可能なコード化を提供します。意図は一般的な要素を保存している間、構造化されたセットのファイルの1つの環境から別の環境までの移行を許すことです。 同時に、すべての属性を保存している間、ただ一つの環境の中でファイルを動かすことができます。

   The representations consist of a series of nested sections, with
   attributes defined at the appropriate levels.  Each section begins
   with an open bracket "[" followed by a directive keyword and ends
   with a close bracket "]".  Attributes are lines, beginning with a
   keyword.  Lines which begin with a LWSP (linear white space)
   character are continuation lines.

表現は属性が適正水準で定義されている一連の入れ子にされたセクションから成ります。 各セクションは「[「指示のキーワードで続いて、近いブラケットで終わる」]」という開きの角括弧で始まります。 キーワードで始まって、属性は系列です。 LWSP(直線的な余白)キャラクタと共に始まる線は継続行です。

   Any string-type directive or attribute may be a simple string not
   starting with a quotation mark ( " ) and not containing special
   characters (e.g.  newline) or LWSP (space and tab).  The string name
   begins with the first non-LWSP character on the line following the
   attribute or directive keyword and ends with the last non-LWSP
   character.

どんなストリングタイプ指示や属性も引用符から始まらない簡単なストリングであるかもしれない、(「)、特殊文字(例えば、ニューライン)かLWSP(スペースとタブ)を含まない、」 ストリング名は、系列の最初の非LWSPキャラクタが属性か指示のキーワードに従っていて始まって、最後の非LWSPキャラクタと共に終わります。

Costanzo, Robinson & Ullmann                                   [Page 11]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[11ページ]RFC1505

   Otherwise, the character string name is enclosed in quotes.  The
   string itself contains characters in ISO-10646-UTF-1 but is quoted
   and escaped at octet level (as elsewhere in RFC822 [2]).  The strings
   begin and end with a quotation mark ( " ).  Octets equal to quote in
   the string are escaped, as are octets equal to the escape characters
   (\" and \\).  The escaped octets may be part of a UTF multi-octet
   character.  Octets that are not printable are escaped with \nnn octal
   representation.  When an escape (\) occurs at the end of a line, the
   escape, the end of the line, and the first character of the next
   line, which must be one of the LWSP characters, are removed
   (ignored).

さもなければ、文字列名は引用文に同封されます。 ストリング自体八重奏レベルでISO-10646-UTF-1にキャラクタを含んでいますが、引用されて、逃げられる、(RFC822[2])のほかの場所。 ストリングは、引用符で始まって、終わります。(「)。」 「ストリングで引用するために等しい八重奏拡張文字と等しい八重奏のように逃げられる、(\、」 \\、) 逃げられた八重奏はUTFマルチ八重奏キャラクタの一部であるかもしれません。 印刷可能でない八重奏\nnn8進表現で逃げられます。 エスケープ(\)が線の端に起こるとき、エスケープ、行の終わり、および次の系列の最初のキャラクタ(LWSPキャラクタのひとりであるに違いない)は取り外されます(無視されます)。

    [ file Simple-File.Name

[Simple-File.Nameをファイルしてください。

    [ file "   Long file name starting with spaces and having a couple\
      [sic] of nasties in it like this newline%%BODY%%12near the end."

[「空間とこのニューライン%%BODY%%12nearのようなそれの2、3\[原文のまま]の嫌なものを持っているのに終わりを始動する長いファイル名」をファイルしてください。

   Note that in the above example, there is one space (not two) between
   "couple" and "[sic]".  The encoder may choose to use the nnn sequence
   for any character that might cause trouble.  Refer to section 5.1 for
   line length recommendations.

「カップル」と「[原文のまま]」の間には、上記の例に、1つのスペース(2でない)があることに注意してください。 エンコーダは、問題を起こすかもしれないどんなキャラクタにもnnn系列を使用するのを選ぶかもしれません。 行長推薦についてセクション5.1を参照してください。

4.1  Sections

4.1 セクション

   A section starts with an open bracket, followed by a keyword that
   defines the type of section.

セクションは開きの角括弧から始まります、続いて、セクションのタイプを定義するキーワードから始まります。

   The section keywords are:

セクションキーワードは以下の通りです。

             directory
             entry
             file
             segment
             data

ディレクトリエントリファイルセグメントデータ

   The encoding may start with either a file, directory or entry.  A
   directory section may contain zero or more file, entry, and directory
   sections.  A file section contains a data section or zero or more
   segment sections.  A segment section contains a data section or zero
   or more segment sections.

コード化はファイル、ディレクトリまたはエントリーから始まるかもしれません。 ディレクトリ部分はゼロか、より多くのファイル、エントリー、およびディレクトリ部分を含むかもしれません。 ファイル節は資料課、ゼロまたは、より多くのセグメント部を含みます。 セグメント部は資料課、ゼロまたは、より多くのセグメント部を含みます。

4.1.1  Directory

4.1.1 ディレクトリ

   This indicates the start of a directory.  There is one parameter, the
   entry name of the directory:

これはディレクトリの始まりを示します。 1つのパラメタ、ディレクトリの入口名があります:

Costanzo, Robinson & Ullmann                                   [Page 12]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[12ページ]RFC1505

             [ directory foo
             ...
             ]

[ディレクトリfoo]

4.1.2  Entry

4.1.2 エントリー

   The entry keyword represents an entry in a directory that is not a
   file or a sub-directory.  Examples of entries are soft links in Unix,
   or access categories in Primos.  A Primos access category might look
   like this:

エントリーキーワードはファイルでなくて、またサブディレクトリでもないディレクトリにおけるエントリーを表します。 エントリーに関する例は、Unixの柔らかいリンク、またはPrimosのアクセスカテゴリです。 Primosアクセスカテゴリはこれに似るかもしれません:

             [ entry SYS.ACAT
             type ACAT
             created 27 Jan 1987 15:31:04.00
             acl SYADMIN:* ARIEL:DALURWX $REST:
             ]

[エントリーSYS.ACATタイプACATは1987年1月27日の15:31:04.00acl SYADMINを作成しました: *アリエル: DALURWX$REST:]

4.1.3  File

4.1.3 ファイル

   The file keyword is followed by the entry name of the file.  The
   section then continues with attributes, possibly segments, and then
   data.

ファイルの入口名はファイルキーワードのあとに続いています。 そして、セクションは属性、ことによるとセグメント、および次に、データで続きます。

             [ file MY.FILE
             created 27 Feb 1987 12:10:20.07
             modified 27 Mar 1987 16:17:03.02
             type DAM
             [ data LZJU90
             * LZJU90
             ...
             ]]

[ファイルMY.FILEは1987年2月27日の12:10:20.07の変更された1987年3月27日の16:17:03.02タイプDAM[データLZJU90*LZJU90…]を作成しました]

4.1.4  Segment

4.1.4 セグメント

   This is used to define segments of a file.  It should only be used
   when encoding files that are actually segmented.  The optional
   parameter is the number or name of the segment.

これは、ファイルのセグメントを定義するのに使用されます。 実際に区分されるファイルをコード化するときだけ、それは使用されるべきです。 任意のパラメタは、セグメントの数か名前です。

   When encoding Macintosh files, the two forks of the file are treated
   as segments:

マッキントッシュファイルをコード化するとき、ファイルの2つのフォーク状の物がセグメントとして扱われます:

Costanzo, Robinson & Ullmann                                   [Page 13]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[13ページ]RFC1505

             [ file A.MAC.FILE
             display "A Mac File"
             type MAC
             comment "I created this myself"
             ...
             [ segment resource
             [ data ...
             ...
             ]]
             [ segment data
             [ data ...
             ...
             ]]]

[「私は自分でこれを作成した」というファイルA. MAC.FILEディスプレイ「Macはファイルする」タイプMACコメント… [セグメントリソース[データ]] [セグメントデータ[データ]]]

4.1.5  Data

4.1.5 データ

   The data section contains the encoded data of the file.  The encoding
   method is defined in section 5.  The data section must be last within
   the containing section.

資料課はファイルのコード化されたデータを含みます。 コード化メソッドはセクション5で定義されます。 含んでいるセクションの中に資料課が最後にあるに違いありません。

4.2  Attributes

4.2 属性

   Attributes may occur within file, entry, directory, and segment
   sections.  Attributes must occur before sub-sections.

属性はファイル、エントリー、ディレクトリ、およびセグメント部の中に起こるかもしれません。 属性は小区分の前に起こらなければなりません。

   The attribute directives are:

属性指示は以下の通りです。

             display
             type
             created
             modified
             accessed
             owner
             group
             acl
             password
             block
             record
             application

変更されていた状態で創造されたディスプレイタイプは所有者グループaclパスワードブロック・レコードアプリケーションにアクセスしました。

4.2.1  Display

4.2.1 ディスプレイ

   This indicates the display name of the object.  Some systems, such as
   the Macintosh, use a different form of the name for matching or
   uniqueness.

これはオブジェクトのディスプレイ名を示します。 マッキントッシュなどのいくつかのシステムがマッチングかユニークさに名前の異なったフォームを使用します。

Costanzo, Robinson & Ullmann                                   [Page 14]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[14ページ]RFC1505

4.2.2  Comment

4.2.2 コメント

   This contains an arbitrary comment on the object.  The Macintosh
   stores this attribute with the file.

これはオブジェクトの任意のコメントを含んでいます。 マッキントッシュはファイルでこの属性を保存します。

4.2.3  Type

4.2.3 タイプ

   The type of an object is usually of interest only to the operating
   system that the object was created on.

通常、オブジェクトのタイプはオブジェクトが作成されたオペレーティングシステムだけに興味があります。

   Types are:

タイプは以下の通りです。

          ACAT       access category (Primos)
          CAM        contiguous access method (Primos)
          DAM        direct access method (Primos)
          FIXED      fixed length records (VMS)
          FLAT       `flat file', sequence of bytes (Unix, DOS, default)
          ISAM       indexed-sequential access method (VMS)
          LINK       soft link (Unix)
          MAC        Macintosh file
          SAM        sequential access method (Primos)
          SEGSAM     segmented direct access method (Primos)
          SEGDAM     segmented sequential access method (Primos)
          TEXT       lines of ISO-10646-UTF-1 text ending with CR/LF
          VAR        variable length records (VMS)

FLAT'平坦なファイル'というACATアクセスカテゴリ(Primos)のCAMの隣接のアクセス法(Primos)DAM直接アクセス法(Primos)FIXED固定長レコード(VMS)、バイト(unix、DOSはデフォルトとする)ISAM索引順アクセス法(VMS)のLINKの柔らかいリンク(unix)MACマッキントッシュファイルSAM順アクセス法(Primos)SEGSAMの系列はCR/LF VAR可変長レコードで終わるISO-10646-UTF-1テキストの直接アクセス法(Primos)SEGDAM区分された順アクセス法(Primos)TEXT系列を区分しました。(VMS)

4.2.4  Created

4.2.4 作成されています。

   Indicates the creation date of the file.  Dates are in the format
   defined in section 4.3.

ファイルの作成日付を示します。 セクション4.3で定義された書式には日付があります。

4.2.5  Modified

4.2.5 変更されています。

   Indicates the date and time the file was last modified or closed
   after being open for write.

開いたファイルが最後に変更されていたか、または閉じられた後日時が書くのを示します。

4.2.6  Accessed

4.2.6 アクセスされています。

   Indicates the date and time the file was last accessed on the
   original file system.

ファイルが最後に元のファイルシステムでアクセスされた日時を示します。

4.2.7  Owner

4.2.7 所有者

   The owner directive gives the name or numerical ID of the owner or
   creator of the file.

所有者指示はファイルの所有者かクリエイターを名前か数字のIDに与えます。

Costanzo, Robinson & Ullmann                                   [Page 15]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[15ページ]RFC1505

4.2.8  Group

4.2.8 グループ

   The group directive gives the name(s) or numerical IDs of the group
   or groups to which the file belongs.

グループ指示はファイルが属するグループかグループの名前か数字のIDを与えます。

4.2.9  ACL

4.2.9 ACL

   This directive specifies the access control list attribute of an
   object (the ACL attribute may occur more than once within an object).
   The list consist of a series of pairs of IDs and access codes in the
   format:

この指示はオブジェクトのアクセスコントロールリスト属性を指定します(ACL属性はオブジェクトの中の一度より起こるかもしれません)。 リストは形式で一連の組のIDとアクセスコードから成ります:

                user-ID:access-list

ユーザID: アクセスリスト

   There are four reserved IDs:

4つの予約されたIDがあります:

                $OWNER  the owner or creator
                $GROUP  a member of the group or groups
                $SYSTEM a system administrator
                $REST   everyone else

$OWNERより自己かグループのクリエイター$GROUP aメンバーかグループの$SYSTEM aシステム管理者$REST、他の人皆

   The access list is zero or more single letters:

アクセスリストは、ゼロか、よりただ一つの手紙です:

                A    add (create file)
                D    delete
                L    list (read directory)
                P    change protection
                R    read
                U    use
                W    write
                X    execute
                *    all possible access

Aは、Dが使用Wが*すべて可能なアクセスを実行するとXに書くUが読まれたLリスト(ディレクトリを読む)P変化保護Rを削除すると言い足します(ファイルを作成します)。

4.2.10  Password

4.2.10 パスワード

   The password attribute gives the access password for this object.
   Since the content of the object follows (being the raison d'etre of
   the encoding), the appearance of the password in plain text is not
   considered a security problem.  If the password is actually set by
   the decoder on a created object, the security (or lack) is the
   responsibility of the application domain controlling the decoder as
   is true of ACL and other protections.

パスワード属性はこのオブジェクトのためのアクセスパスワードを与えます。 オブジェクトの内容が従うので(コード化の存在理由であり)、プレーンテキストにおける、パスワードの外観は警備上の問題であると考えられません。 パスワードが実際に作成されたオブジェクトの上のデコーダによって設定されるなら、セキュリティ(または、不足)はACLと他の保護本当にそのままでデコーダを制御するアプリケーションドメインの責任です。

4.2.11  Block

4.2.11 ブロック

   The block attribute gives the block size of the file as a decimal
   number of bytes.

ブロック属性はバイトの10進数としてファイルのブロック・サイズを与えます。

Costanzo, Robinson & Ullmann                                   [Page 16]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[16ページ]RFC1505

4.2.12  Record

4.2.12 記録

   The record attribute gives the record size of the file as a decimal
   number of bytes.

記録的な属性はバイトの10進数としてファイルのレコード・サイズを与えます。

4.2.13  Application

4.2.13 アプリケーション

   This specifies the application that the file was created with or
   belongs to.  This is of particular interest for Macintosh files.

これはファイルが作成されたか、または属するアプリケーションを指定します。 これはマッキントッシュファイルに関して特別におもしろいです。

4.3  Date Field

4.3 年月日欄

   Various attributes have a date and time subsequent to and associated
   with them.

様々な属性はその後の、そして、それらに関連している日時を過します。

4.3.1  Syntax

4.3.1 構文

   The syntax of the date field is a combination of date, time, and
   timezone:

年月日欄の構文は日付、時間、およびタイムゾーンの組み合わせです:

       DD Mon YYYY HH:MM:SS.FFFFFF [+-]HHMMSS

DD月曜日のYYYY HH:mm:SS.FFFFFF[+]HHMMSS

       Date :=  DD Mon YYYY      1 or 2 Digits " " 3 Alpha " " 4 Digits
       DD   :=  Day              e.g. "08", " 8", "8"
       Mon  :=  Month            "Jan" | "Feb" | "Mar" | "Apr" |
                                 "May" | "Jun" | "Jul" | "Aug" |
                                 "Sep" | "Oct" | "Nov" | "Dec"
       YYYY :=  Year
       Time :=  HH:MM:SS.FFFFFF  2 Digits ":" 2 Digits [ ":" 2 Digits
                                 ["." 1 to 6 Digits ] ]
                                 e.g. 00:00:00, 23:59:59.999999
       HH   :=  Hours            00 to 23
       MM   :=  Minutes          00 to 59
       SS   :=  Seconds          00 to 60 (60 only during a leap second)
       FFFFF:=  Fraction
       Zone :=  [+-]HHMMSS       "+" | "-" 2 Digits [ 2 Digits
                                 [ 2 Digits ] ]
       HH   :=  Local Hour Offset
       MM   :=  Local Minutes Offset
       SS   :=  Local Seconds Offset

:=DD月曜日のYYYY日付1か2Digits、「「3アルファー、」、「4Digits DD:=日、例えば、「8インチ」、8インチ、「8インチ:=月の月曜日の「1月」」| 「2月」| 「3月」| 「4月」| 「5月」| 「6月」| 「7月」| 「8月」| 「9月」| 「10月」| 「11月」| 「「12月」YYYY:=時間:=HH年(mm: SS.FFFFFF2ケタ)」:、」 2ケタ、[「:」 2ケタ、[「. 」 1〜6ケタ] 例えば、00:00:00、23:59:59.999999HH:=:=00〜23mm分00〜59時間、SS:=は00〜60(閏秒だけの間の60)FFFFFを後援します: 断片ゾーン:=[+]HHMMSS「+」と等しいです。| 地方のオフセット2「--」ケタ[2ケタ[2ケタ]]HH:=時間mm、:=地方の分は地方の秒が相殺するSS:=を相殺します。

4.3.2  Semantics

4.3.2 意味論

   The date information is that which the file system has stored in
   regard to the file system object.  Date information is stored
   differently and with varying degrees of precision by different
   computer file systems.  An encoder must include as much date
   information as it has available concerning the file system object.  A

日付の情報はファイルシステムがファイルシステム対象物に関して保存したそれです。 日付の情報は異なるのと異なったコンピュータファイルシステムによる種々の精度で保存されます。エンコーダはファイルシステム対象物に関して利用可能な持っているのと同じくらい多くの日付の情報を含まなければなりません。 A

Costanzo, Robinson & Ullmann                                   [Page 17]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[17ページ]RFC1505

   decoder which receives an object encoded with a date field containing
   greater precision than its own must disregard the excessive
   information.  Zone is Co-ordinated Universal Time "UTC" (formerly
   called "Greenwich Mean Time").  The field specifies the time zone of
   the file system object as an offset from Universal Time.  It is
   expressed as a signed [+-] two, four or six digit number.

年月日欄が自分自身のが無視しなければならないより大きい精度を含んでいて、オブジェクトを受けるデコーダが過度の情報をコード化しました。 ゾーンはCo-ordinated世界標準時の"UTC"(以前呼ばれた「グリニッジ標準時」)です。 分野はオフセットとして世界標準時からファイルシステム対象物の時間帯を指定します。 それは署名している[+]2、4または6桁数として言い表されます。

   A file that was created April 15, 1993 at 8:05 p.m.  in Roselle Park,
   New Jersey, U.S.A.  might have a date field which looks like:

1993年4月15日午後8時5分にローゼル・パークで作成されたファイル、ニュージャージー(米国)には、似ている年月日欄があるかもしれません:

   15 Apr 1993 20:05:22.12 -0500

1993年4月15日20:05:22.12 -0500

5.  LZJU90:  Compressed Encoding

5. LZJU90: 圧縮されたコード化

   LZJU90 is an encoding for a binary or text object to be sent in an
   Internet mail message.  The encoding provides both compression and
   representation in a text format that will successfully survive
   transmission through the many different mailers and gateways that
   comprise the Internet and connected mail networks.

LZJU90はバイナリーかテキストオブジェクトがインターネットメール・メッセージで送られるコード化です。 コード化は首尾よく多くの異なった郵送者、インターネットを包括するゲートウェイ、および接続メールネットワークを通したトランスミッションを乗り切るテキスト形式に圧縮と表現の両方を提供します。

5.1  Overview

5.1 概要

   The encoding first compresses the binary object, using a modified
   LZ77 algorithm, called LZJU90.  It then encodes each 6 bits of the
   output of the compression as a text character, using a character set
   chosen to survive any translations between codes, such as ASCII to
   EBCDIC.  The 64 six-bit strings 000000 through 111111 are represented
   by the characters "+", "-", "0" to "9", "A" to "Z", and "a" to "z".
   The output text begins with a line identifying the encoding.  This is
   for visual reference only, the "Encoding:" field in the header
   identifies the section to the user program.  It also names the object
   that was encoded, usually by a file name.

LZJU90は、変更されたLZ77アルゴリズムを使用して、コード化が最初に2進のオブジェクトを圧縮すると呼びました。 次に、それはテキストキャラクタとして圧縮の出力の各6ビットをコード化します、コードの間のどんな翻訳も乗り切るために選ばれて、文字集合を使用して、EBCDICへのASCIIなどのように。 64 6ビット列の000000〜111111がキャラクタ「+」、「-」によって表される、「「9インチ、「Z」、および「z」への“a"への「A」」への0インチ 系列がコード化を特定している状態で、出力テキストは始まります。 これは展示が「以下をコード化します」だけ、に参照をつけるからです ヘッダーの分野はユーザ・プログラムへのセクションを特定します。 また、それは通常ファイル名によってコード化されたオブジェクトを命名します。

   The format of this line is:

この系列の形式は以下の通りです。

                * LZJU90 <name>

* LZJU90<名前>。

   where <name> is optional.  For example:

<名前>が任意であるところ。 例えば:

                * LZJU90 vmunix

* LZJU90 vmunix

   This is followed by the compressed and encoded data, broken into
   lines where convenient.  It is recommended that lines be broken every
   78 characters to survive mailers than incorrectly restrict line
   length.  The decoder must accept lines with 1 to 1000 characters on
   each line.  After this, there is one final line that gives the number
   of bytes in the original data and a CRC of the original data.  This

圧縮されてコード化された系列が便利であるところに細かく分けられたデータはこれのあとに続いています。 系列が郵送者より長生きする78の失意のキャラクタ毎であることが不当に行長を制限するよりお勧めです。 デコーダは各系列の1〜1000のキャラクタと共に系列を受け入れなければなりません。 この後、オリジナルのデータとオリジナルのデータのCRCでバイト数を与える1つの最終的な系列があります。 これ

Costanzo, Robinson & Ullmann                                   [Page 18]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[18ページ]RFC1505

   should match the byte count and CRC found during decompression.

バイト・カウントと減圧の間に見つけられたCRCを合わせるべきです。

   This line has the format:

この系列には、形式があります:

                * <count> <CRC>

* <カウント><CRC>。

   where <count> is a decimal number, and CRC is 8 hexadecimal digits.
   For example:

<カウント>が10進数であり、CRCが8つの16進数字であるところ。 例えば:

                * 4128076 5AC2D50E

* 4128076 5AC2D50E

   The count used in the Encoding:  field in the message header is the
   total number of lines, including the start and end lines that begin
   with *.  A complete example is given in section 5.3.2.

Encodingで使用されるカウント: メッセージヘッダーの分野は系列の総数です、*で始まる始めとEND行を含んでいて。完全な例はセクション5.3.2で出されます。

5.2  Specification of the LZJU90 compression

5.2 LZJU90圧縮の仕様

   The Lempel-Ziv-Storer-Szymanski model of mixing pointers and literal
   characters is used in the compression algorithm.  Repeat occurrences
   of strings of octets are replaced by pointers to the earlier
   occurrence.

指針と文字通りのキャラクタを混合するLempel-Ziv-Storer-Szymanskiモデルは圧縮アルゴリズムで使用されます。 八重奏のストリングの反復発生を以前の発生への指針に取り替えます。

   The data compression is defined by the decoding algorithm.  Any
   encoder that emits symbols which cause the decoder to produce the
   original input is defined to be valid.

データ圧縮は解読アルゴリズムで定義されます。 デコーダがオリジナルの入力を作り出すシンボルを放つどんなエンコーダも、有効になるように定義されます。

   There are many possible strategies for the maximal-string matching
   that the encoder does, section 5.3.1 gives the code for one such
   algorithm.  Regardless of which algorithm is used, and what tradeoffs
   are made between compression ratio and execution speed or space, the
   result can always be decoded by the simple decoder.

エンコーダがする最大限度のストリングマッチングのための多くの可能な戦略があって、セクション5.3.1はそのようなアルゴリズムの1つのためにコードを与えます。 どのアルゴリズムが使用されているか、そして、どんな見返りが圧縮比と実行速度かスペースの間で作られているかにかかわらず、簡単なデコーダはいつも結果を解読できます。

   The compressed data consists of a mixture of unencoded literal
   characters and copy pointers which point to an earlier occurrence of
   the string to be encoded.

圧縮されたデータはコード化されるためにストリングの以前の発生を示す暗号化されていない文字通りのキャラクタとコピー指針の混合物から成ります。

   Compressed data contains two types of codewords:

圧縮されたデータは2つのタイプの符号語を含んでいます:

   LITERAL pass the literal directly to the uncompressed output.

LITERALは直接解凍された出力するのにリテラルを通過します。

   COPY    length, offset
           go back offset characters in the output and copy length
           characters forward to the current position.

キャラクタが相殺し返しにCOPYの長さ、オフセットは出力とコピー長さのキャラクタに前方に現在の位置まで行きます。

   To distinguish between codewords, the copy length is used.  A copy
   length of zero indicates that the following codeword is a literal
   codeword.  A copy length greater than zero indicates that the

符号語を見分けるために、コピーの長さは使用されています。 ゼロのコピーの長さは、以下の符号語が文字通りの符号語であることを示します。 ゼロ以上のコピーの長さはそれを示します。

Costanzo, Robinson & Ullmann                                   [Page 19]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[19ページ]RFC1505

   following codeword is a copy codeword.

次の符号語はコピー符号語です。

   To improve copy length encoding, a threshold value of 2 has been
   subtracted from the original copy length for copy codewords, because
   the minimum copy length is 3 in this compression scheme.

コピー長さのコード化を改良するために、2の閾値はコピー符号語のために原本の長さから引き算されました、最小のコピーの長さがこの圧縮技術で3であるので。

   The maximum offset value is set at 32255.  Larger offsets offer
   extremely low improvements in compression (less than 1 percent,
   typically).

最大のオフセット値は32255に設定されます。 より大きいオフセットは圧縮(通常、1パーセント未満)における非常に低い改良を提供します。

   No special encoding is done on the LITERAL characters.  However,
   unary encoding is used for the copy length and copy offset values to
   improve compression.  A start-step-stop unary code is used.

LITERALキャラクタで特別なコード化をしません。 しかしながら、単項コード化はコピーの長さに使用されました、そして、コピーは圧縮を改良するために値を相殺しました。 スタートステップ停止単項コードは使用されています。

   A (start, step, stop) unary code of the integers is defined as
   follows:  The Nth codeword has N ones followed by a zero followed by
   a field of size START + (N * STEP).  If the field width is equal to
   STOP then the preceding zero can be omitted.  The integers are laid
   out sequentially through these codewords.  For example, (0, 1, 4)
   would look like:

整数の(始めてください、そして、踏んでください、そして、止まってください)単項コードは以下の通り定義されます: Nth符号語には、サイズSTART+(N*STEP)の分野があとに続いたNのがあります、続いて、ゼロを持っています。 欄の幅がSTOPと等しいなら、前のゼロを省略できます。 整数はこれらの符号語を通して連続して広げられます。 例えば、(0、1、4)に似ているでしょう:

             Codeword      Range

符号語範囲

             0             0
             10x           1-2
             110xx         3-6
             1110xxx       7-14
             1111xxxx      15-30

0 0 10x1-2 110xx3-6 1110xxx7-14 1111xxxx15-30

   Following are the actual values used for copy length and copy offset:

コピーの長さに使用される実価が以下にあって、コピーは相殺されました:

   The copy length is encoded with a (0, 1, 7) code leading to a maximum
   copy length of 256 by including the THRESHOLD value of 2.

(0、1、7)コードが2のTHRESHOLD値を含んでいることによって256の最大のコピーの長さにつながっていて、コピーの長さはコード化されます。

             Codeword       Range

符号語範囲

             0              0
             10x            3-4
             110xx          5-8
             1110xxx        9-16
             11110xxxx      17-32
             111110xxxxx    33-64
             1111110xxxxxx  65-128
             1111111xxxxxxx 129-256

0 0 10x3-4 110xx5-8 1110xxx9-16 11110xxxx17-32 111110xxxxx33-64 1111110xxxxxx65-128 1111111xxxxxxx129-256

   The copy offset is encoded with a (9, 1, 14) code leading to a
   maximum copy offset of 32255.  Offset 0 is reserved as an end of
   compressed data flag.

(9、1、14)コードが32255の最大のコピーオフセットにつながっていて、コピーオフセットはコード化されます。 オフセット0は圧縮されたデータ旗の端として控えられます。

Costanzo, Robinson & Ullmann                                   [Page 20]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[20ページ]RFC1505

             Codeword       Range

符号語範囲

             0xxxxxxxxx                0-511
             10xxxxxxxxxx            512-1535
             110xxxxxxxxxxx         1536-3583
             1110xxxxxxxxxxxx       3485-7679
             11110xxxxxxxxxxxxx     7680-15871
             11111xxxxxxxxxxxxxx   15872-32255

0xxxxxxxxx0-511 10xxxxxxxxxx512-1535 110xxxxxxxxxxx1536-3583 1110xxxxxxxxxxxx3485-7679 11110xxxxxxxxxxxxx7680-15871 11111xxxxxxxxxxxxxx15872-32255

   The 0 has been chosen to signal the start of the field for ease of
   encoding.  (The bit generator can simply encode one more bit than is
   significant in the binary representation of the excess.)

0は、コード化の容易さのために分野の始まりに合図するために選ばれました。 (噛み付いているジェネレータは過剰の2進法表示で重要であるというよりも単にもうひとつのビットをコード化できます。)

   The stop values are useful in the encoding to prevent out of range
   values for the lengths and offsets, as well as shortening some codes
   by one bit.

停止値は1ビットに従って長さのための範囲値といくつかのコードを短くすることと同様にオフセットから防ぐコード化で役に立ちます。

   The worst case compression using this scheme is a 1/8 increase in
   size of the encoded data.  (One zero bit followed by 8 character
   bits).  After the character encoding, the worst case ratio is 3/2 to
   the original data.

この体系を使用する最悪の場合圧縮はコード化されたデータのサイズの1/8増加です。 (8キャラクタビットが支えた1ゼロ・ビット。) 文字符号化の後に、最悪の場合比はオリジナルのデータへの3/2です。

   The minimum copy length of 3 has been chosen because the worst case
   copy length and offset is 3 bits (3) and 19 bits (32255) for a total
   of 22 bits to encode a 3 character string (24 bits).

最悪の場合コピーの長さとオフセットが合計22ビットが3文字列(24ビット)をコード化する3ビット(3)と19ビット(32255)であるので、3つの最小のコピーの長さが選ばれました。

5.3  The Decoder

5.3 デコーダ

   As mentioned previously, the compression is defined by the decoder.
   Any encoder that produced output that is correctly decoded is by
   definition correct.

既述のとおり、圧縮はデコーダによって定義されます。 正しく解読される出力を起こしたどんなエンコーダも定義上正しいです。

   The following is an implementation of the decoder, written more for
   clarity and as much portability as possible, rather than for maximum
   speed.

↓これは最高回転数のためにというよりむしろ明快とできるだけ多くの移植性のためにもう少し書かれたデコーダの実装です。

   When optimized for a specific environment, it will run significantly
   faster.

特定の環境のために最適化されると、それはかなり快走するでしょう。

    /* LZJU 90 Decoding program */

/*LZJU90Decodingプログラム*/

    /* Written By Robert Jung and Robert Ullmann, 1990 and 1991. */

ロバート・ユング、ロバート・ウルマン、1990、および1991年までに書かれた/*。 */

    /* This code is NOT COPYRIGHT, not protected. It is in the true
       Public Domain. */

これがコード化する/*は保護されるのではなく、NOT COPYRIGHTです。 それは本当のPublic Domainにあります。 */

    #include <stdio.h>
    #include <string.h>

#<stdio.h>#インクルード<string.h>を含めてください。

Costanzo, Robinson & Ullmann                                   [Page 21]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[21ページ]RFC1505

    typedef unsigned char uchar;
    typedef unsigned int  uint;

typedefの未署名の炭のuchar。 typedefの未署名のint uint。

    #define N          32255
    #define THRESHOLD      3

#定義、N32255#、はTHRESHOLD3を定義します。

    #define STRTP          9
    #define STEPP          1
    #define STOPP         14
    #define STRTL          0
    #define STEPL          1
    #define STOPL          7

#定義、STRTP9#、が定義する、シュテップ1#、がSTOPP14#、を定義する、定義、STRTL0#、がSTEPL1#、を定義する、STOPL7を定義してください。

    static FILE *in;
    static FILE *out;

*中の静的なFILE。 静的なFILE*アウト。

    static int   getbuf;
    static int   getlen;
    static long  in_count;
    static long  out_count;
    static long  crc;
    static long  crctable[256];
    static uchar xxcodes[] =
    "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ\
    abcdefghijklmnopqrstuvwxyz";
    static uchar ddcodes[256];

static int getbuf; static int getlen; static long in_count; static long out_count; static long crc; static long crctable[256]; static uchar xxcodes[] = "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ\ abcdefghijklmnopqrstuvwxyz"; static uchar ddcodes[256];

    static uchar text[N];

static uchar text[N];

    #define CRCPOLY         0xEDB88320
    #define CRC_MASK        0xFFFFFFFF
    #define UPDATE_CRC(crc, c)  \
            crc = crctable[((uchar)(crc) ^ (uchar)(c)) & 0xFF] \
                  ^ (crc >> 8)
    #define START_RECD      "* LZJU90"

#define CRCPOLY 0xEDB88320 #define CRC_MASK 0xFFFFFFFF #define UPDATE_CRC(crc, c) \ crc = crctable[((uchar)(crc) ^ (uchar)(c)) & 0xFF] \ ^ (crc >> 8) #define START_RECD "* LZJU90"

    void MakeCrctable()     /* Initialize CRC-32 table */
    {
    uint i, j;
    long r;
        for (i = 0; i <= 255; i++) {
            r = i;
            for (j = 8; j > 0; j--) {
                if (r & 1)
                    r = (r >> 1) ^ CRCPOLY;
                else

void MakeCrctable() /* Initialize CRC-32 table */ { uint i, j; long r; for (i = 0; i <= 255; i++) { r = i; for (j = 8; j > 0; j--) { if (r & 1) r = (r >> 1) ^ CRCPOLY; else

Costanzo, Robinson & Ullmann                                   [Page 22]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 22] RFC 1505 Encoding Header Field August 1993

                    r >>= 1;
                }
            crctable[i] = r;
            }
    }

r >>= 1; } crctable[i] = r; } }

    int GetXX()             /* Get xxcode and translate */
    {
    int c;
        do {
            if ((c = fgetc(in)) == EOF)
                c = 0;
            } while (c == '\n');
        in_count++;
        return ddcodes[c];
    }

int GetXX() /* Get xxcode and translate */ { int c; do { if ((c = fgetc(in)) == EOF) c = 0; } while (c == '\n'); in_count++; return ddcodes[c]; }

    int GetBit()            /* Get one bit from input buffer */
    {
    int c;
        while (getlen <= 0) {
            c = GetXX();
            getbuf |= c << (10-getlen);
            getlen += 6;
            }
        c = (getbuf & 0x8000) != 0;
        getbuf <<= 1;
        getbuf &= 0xFFFF;
        getlen--;
        return(c);
    }

int GetBit() /* Get one bit from input buffer */ { int c; while (getlen <= 0) { c = GetXX(); getbuf |= c << (10-getlen); getlen += 6; } c = (getbuf & 0x8000) != 0; getbuf <<= 1; getbuf &= 0xFFFF; getlen--; return(c); }

    int GetBits(int len)        /* Get len bits */
    {
    int c;
        while (getlen <= 10) {
            c = GetXX();
            getbuf |= c << (10-getlen);
            getlen += 6;
            }
        if (getlen < len) {
            c = (uint)getbuf >> (16-len);

int GetBits(int len) /* Get len bits */ { int c; while (getlen <= 10) { c = GetXX(); getbuf |= c << (10-getlen); getlen += 6; } if (getlen < len) { c = (uint)getbuf >> (16-len);

Costanzo, Robinson & Ullmann                                   [Page 23]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 23] RFC 1505 Encoding Header Field August 1993

            getbuf = GetXX();
            c |= getbuf >> (6+getlen-len);
            getbuf <<= (10+len-getlen);
            getbuf &= 0xFFFF;
            getlen -= len - 6;
            }
        else {
            c = (uint)getbuf >> (16-len);
            getbuf <<= len;
            getbuf &= 0xFFFF;
            getlen -= len;
            }
        return(c);
    }

getbuf = GetXX(); c |= getbuf >> (6+getlen-len); getbuf <<= (10+len-getlen); getbuf &= 0xFFFF; getlen -= len - 6; } else { c = (uint)getbuf >> (16-len); getbuf <<= len; getbuf &= 0xFFFF; getlen -= len; } return(c); }

    int DecodePosition()    /* Decode offset position pointer */
    {
    int c;
    int width;
    int plus;
    int pwr;
        plus = 0;
        pwr = 1 << STRTP;
        for (width = STRTP; width < STOPP; width += STEPP) {
            c = GetBit();
            if (c == 0)
                break;
            plus += pwr;
            pwr <<= 1;
            }
        if (width != 0)
            c = GetBits(width);
        c += plus;
        return(c);
    }

int DecodePosition() /* Decode offset position pointer */ { int c; int width; int plus; int pwr; plus = 0; pwr = 1 << STRTP; for (width = STRTP; width < STOPP; width += STEPP) { c = GetBit(); if (c == 0) break; plus += pwr; pwr <<= 1; } if (width != 0) c = GetBits(width); c += plus; return(c); }

    int DecodeLength()      /* Decode code length */
    {
    int c;
    int width;
    int plus;
    int pwr;
        plus = 0;
        pwr = 1 << STRTL;

int DecodeLength() /* Decode code length */ { int c; int width; int plus; int pwr; plus = 0; pwr = 1 << STRTL;

Costanzo, Robinson & Ullmann                                   [Page 24]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 24] RFC 1505 Encoding Header Field August 1993

        for (width = STRTL; width < STOPL; width += STEPL) {
            c = GetBit();
            if (c == 0)
                break;
            plus += pwr;
            pwr <<= 1;
            }
        if (width != 0)
            c = GetBits(width);
        c += plus;
    return(c);
    }

for (width = STRTL; width < STOPL; width += STEPL) { c = GetBit(); if (c == 0) break; plus += pwr; pwr <<= 1; } if (width != 0) c = GetBits(width); c += plus; return(c); }

    void InitCodes()        /* Initialize decode table */
    {
    int i;
        for (i = 0; i < 256; i++) ddcodes[i] = 0;
        for (i = 0; i < 64; i++) ddcodes[xxcodes[i]] = i;
    return;
    }

void InitCodes() /* Initialize decode table */ { int i; for (i = 0; i < 256; i++) ddcodes[i] = 0; for (i = 0; i < 64; i++) ddcodes[xxcodes[i]] = i; return; }

    main(int ac, char **av)            /* main program */
    {
    int r;
    int j, k;
    int c;
    int pos;
    char buf[80];
    char name[3];
    long num, bytes;

main(int ac, char **av) /* main program */ { int r; int j, k; int c; int pos; char buf[80]; char name[3]; long num, bytes;

        if (ac < 3) {
            fprintf(stderr, "usage: judecode in out\n");
            return(1);
            }

if (ac < 3) { fprintf(stderr, "usage: judecode in out\n"); return(1); }

        in = fopen(av[1], "r");
        if (!in){
            fprintf(stderr, "Can't open %s\n", av[1]);
            return(1);
            }

in = fopen(av[1], "r"); if (!in){ fprintf(stderr, "Can't open %s\n", av[1]); return(1); }

        out = fopen(av[2], "wb");
        if (!out) {
            fprintf(stderr, "Can't open %s\n", av[2]);
            fclose(in);

out = fopen(av[2], "wb"); if (!out) { fprintf(stderr, "Can't open %s\n", av[2]); fclose(in);

Costanzo, Robinson & Ullmann                                   [Page 25]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 25] RFC 1505 Encoding Header Field August 1993

        return(1);
            }

return(1); }

        while (1) {
            if (fgets(buf, sizeof(buf), in) == NULL) {
                fprintf(stderr, "Unexpected EOF\n");
            return(1);
                }
            if (strncmp(buf, START_RECD, strlen(START_RECD)) == 0)
                break;
            }

while (1) { if (fgets(buf, sizeof(buf), in) == NULL) { fprintf(stderr, "Unexpected EOF\n"); return(1); } if (strncmp(buf, START_RECD, strlen(START_RECD)) == 0) break; }

        in_count = 0;
        out_count = 0;
        getbuf = 0;
        getlen = 0;

in_count = 0; out_count = 0; getbuf = 0; getlen = 0;

        InitCodes();
        MakeCrctable();

InitCodes(); MakeCrctable();

        crc = CRC_MASK;
        r = 0;

crc = CRC_MASK; r = 0;

        while (feof(in) == 0) {
            c = DecodeLength();
            if (c == 0) {
                c = GetBits(8);
                UPDATE_CRC(crc, c);
                out_count++;
                text[r] = c;
                fputc(c, out);
                if (++r >= N)
                    r = 0;
                }

while (feof(in) == 0) { c = DecodeLength(); if (c == 0) { c = GetBits(8); UPDATE_CRC(crc, c); out_count++; text[r] = c; fputc(c, out); if (++r >= N) r = 0; }

            else {
                pos = DecodePosition();
                if (pos == 0)
                    break;
                pos--;
                j = c + THRESHOLD - 1;
                pos = r - pos - 1;
                if (pos < 0)
                    pos += N;
                for (k = 0; k < j; k++) {
                    c = text[pos];
                    text[r] = c;
                    UPDATE_CRC(crc, c);

else { pos = DecodePosition(); if (pos == 0) break; pos--; j = c + THRESHOLD - 1; pos = r - pos - 1; if (pos < 0) pos += N; for (k = 0; k < j; k++) { c = text[pos]; text[r] = c; UPDATE_CRC(crc, c);

Costanzo, Robinson & Ullmann                                   [Page 26]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 26] RFC 1505 Encoding Header Field August 1993

                    out_count++;
                    fputc(c, out);
                    if (++r >= N)
                        r = 0;
                    if (++pos >= N)
                        pos = 0;
                    }
                }
            }

out_count++; fputc(c, out); if (++r >= N) r = 0; if (++pos >= N) pos = 0; } } }

        fgetc(in); /* skip newline */

fgetc(in); /* skip newline */

        if (fscanf(in, "* %ld %lX", &bytes, &num) != 2) {
            fprintf(stderr, "CRC record not found\n");
            return(1);
            }

if (fscanf(in, "* %ld %lX", &bytes, &num) != 2) { fprintf(stderr, "CRC record not found\n"); return(1); }

        else if (crc != num) {
            fprintf(stderr,
                 "CRC error, expected %lX, found %lX\n",
                 crc, num);
            return(1);
            }

else if (crc != num) { fprintf(stderr, "CRC error, expected %lX, found %lX\n", crc, num); return(1); }

        else if (bytes != out_count) {
            fprintf(stderr,
                 "File size error, expected %lu, found %lu\n",
                 bytes, out_count);
        return(1);
            }

else if (bytes != out_count) { fprintf(stderr, "File size error, expected %lu, found %lu\n", bytes, out_count); return(1); }

        else
            fprintf(stderr,
                 "File decoded to %lu bytes correctly\n",
                 out_count);

else fprintf(stderr, "File decoded to %lu bytes correctly\n", out_count);

        fclose(in);
        fclose(out);
    return(0);
    }

fclose(in); fclose(out); return(0); }

5.3.1  An example of an Encoder

5.3.1 An example of an Encoder

   Many algorithms are possible for the encoder, with different
   tradeoffs between speed, size, and complexity.  The following is a
   simple example program which is fairly efficient; more sophisticated
   implementations will run much faster, and in some cases produce

Many algorithms are possible for the encoder, with different tradeoffs between speed, size, and complexity. The following is a simple example program which is fairly efficient; more sophisticated implementations will run much faster, and in some cases produce

Costanzo, Robinson & Ullmann                                   [Page 27]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 27] RFC 1505 Encoding Header Field August 1993

   somewhat better compression.

somewhat better compression.

   This example also shows that the encoder need not use the entire
   window available.  Not using the full window costs a small amount of
   compression, but can greatly increase the speed of some algorithms.

This example also shows that the encoder need not use the entire window available. Not using the full window costs a small amount of compression, but can greatly increase the speed of some algorithms.

    /* LZJU 90 Encoding program */

/* LZJU 90 Encoding program */

    /* Written By Robert Jung and Robert Ullmann, 1990 and 1991. */

/* Written By Robert Jung and Robert Ullmann, 1990 and 1991. */

    /* This code is NOT COPYRIGHT, not protected. It is in the true
       Public Domain. */

/* This code is NOT COPYRIGHT, not protected. It is in the true Public Domain. */

    #include <stdio.h>

#include <stdio.h>

    typedef unsigned char uchar;
    typedef unsigned int  uint;

typedef unsigned char uchar; typedef unsigned int uint;

    #define N          24000    /* Size of window buffer */
    #define F            256   /* Size of look-ahead buffer */
    #define THRESHOLD      3
    #define K          16384    /* Size of hash table */

#define N 24000 /* Size of window buffer */ #define F 256 /* Size of look-ahead buffer */ #define THRESHOLD 3 #define K 16384 /* Size of hash table */

    #define STRTP          9
    #define STEPP          1
    #define STOPP         14

#define STRTP 9 #define STEPP 1 #define STOPP 14

    #define STRTL          0
    #define STEPL          1
    #define STOPL          7

#define STRTL 0 #define STEPL 1 #define STOPL 7

    #define CHARSLINE     78

#define CHARSLINE 78

    static FILE *in;
    static FILE *out;

static FILE *in; static FILE *out;

    static int   putlen;
    static int   putbuf;
    static int   char_ct;
    static long  in_count;
    static long  out_count;
    static long  crc;
    static long  crctable[256];
    static uchar xxcodes[] =
    "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ\
    abcdefghijklmnopqrstuvwxyz";
    uchar window_text[N + F + 1];

static int putlen; static int putbuf; static int char_ct; static long in_count; static long out_count; static long crc; static long crctable[256]; static uchar xxcodes[] = "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ\ abcdefghijklmnopqrstuvwxyz"; uchar window_text[N + F + 1];

Costanzo, Robinson & Ullmann                                   [Page 28]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 28] RFC 1505 Encoding Header Field August 1993

    /* text contains window, plus 1st F of window again
       (for comparisons) */

/* text contains window, plus 1st F of window again (for comparisons) */

    uint hash_table[K];
    /* table of pointers into the text */

uint hash_table[K]; /* table of pointers into the text */

    #define CRCPOLY         0xEDB88320
    #define CRC_MASK        0xFFFFFFFF
    #define UPDATE_CRC(crc, c)  \
      crc = crctable[((uchar)(crc) ^ (uchar)(c)) & 0xFF] \
      ^ (crc >> 8)

#define CRCPOLY 0xEDB88320 #define CRC_MASK 0xFFFFFFFF #define UPDATE_CRC(crc, c) \ crc = crctable[((uchar)(crc) ^ (uchar)(c)) & 0xFF] \ ^ (crc >> 8)

    void MakeCrctable()     /* Initialize CRC-32 table */
    {
    uint i, j;
    long r;
        for (i = 0; i <= 255; i++) {
            r = i;
            for (j = 8; j > 0; j--) {
                if (r & 1)
                    r = (r >> 1) ^ CRCPOLY;
                else
                    r >>= 1;
            }
            crctable[i] = r;
        }
    }

void MakeCrctable() /* Initialize CRC-32 table */ { uint i, j; long r; for (i = 0; i <= 255; i++) { r = i; for (j = 8; j > 0; j--) { if (r & 1) r = (r >> 1) ^ CRCPOLY; else r >>= 1; } crctable[i] = r; } }

    void PutXX(int c)           /* Translate and put xxcode */
    {
        c = xxcodes[c & 0x3F];
        if (++char_ct > CHARSLINE) {
            char_ct = 1;
            fputc('\n', out);
        }
        fputc(c, out);
        out_count++;
    }

void PutXX(int c) /* Translate and put xxcode */ { c = xxcodes[c & 0x3F]; if (++char_ct > CHARSLINE) { char_ct = 1; fputc('\n', out); } fputc(c, out); out_count++; }

    void PutBits(int c, int len)  /* Put rightmost "len" bits of "c" */
    {
        c <<= 16 - len;
        c &= 0xFFFF;
        putbuf |= (uint) c >> putlen;

void PutBits(int c, int len) /* Put rightmost "len" bits of "c" */ { c <<= 16 - len; c &= 0xFFFF; putbuf |= (uint) c >> putlen;

Costanzo, Robinson & Ullmann                                   [Page 29]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 29] RFC 1505 Encoding Header Field August 1993

        c <<= 16 - putlen;
        c &= 0xFFFF;
        putlen += len;
        while (putlen >= 6) {
            PutXX(putbuf >> 10);
            putlen -= 6;
            putbuf <<= 6;
            putbuf &= 0xFFFF;
            putbuf |= (uint) c >> 10;
            c = 0;
            }
    }

c <<= 16 - putlen; c &= 0xFFFF; putlen += len; while (putlen >= 6) { PutXX(putbuf >> 10); putlen -= 6; putbuf <<= 6; putbuf &= 0xFFFF; putbuf |= (uint) c >> 10; c = 0; } }

    void EncodePosition(int ch) /* Encode offset position pointer */
    {
    int width;
    int prefix;
    int pwr;
        pwr = 1 << STRTP;
        for (width = STRTP; ch >= pwr; width += STEPP, pwr <<= 1)
            ch -= pwr;
        if ((prefix = width - STRTP) != 0)
            PutBits(0xffff, prefix);
        if (width < STOPP)
            width++;
        /* else if (width > STOPP)
        abort(); do nothing */
        PutBits(ch, width);
    }

void EncodePosition(int ch) /* Encode offset position pointer */ { int width; int prefix; int pwr; pwr = 1 << STRTP; for (width = STRTP; ch >= pwr; width += STEPP, pwr <<= 1) ch -= pwr; if ((prefix = width - STRTP) != 0) PutBits(0xffff, prefix); if (width < STOPP) width++; /* else if (width > STOPP) abort(); do nothing */ PutBits(ch, width); }

    void EncodeLength(int ch)   /* Encode code length */
    {
    int width;
    int prefix;
    int pwr;
        pwr = 1 << STRTL;
        for (width = STRTL; ch >= pwr; width += STEPL, pwr <<= 1)
            ch -= pwr;
        if ((prefix = width - STRTL) != 0)
            PutBits(0xffff, prefix);
        if (width < STOPL)
            width++;
        /* else if (width > STOPL)
        abort(); do nothing */
        PutBits(ch, width);
    }

void EncodeLength(int ch) /* Encode code length */ { int width; int prefix; int pwr; pwr = 1 << STRTL; for (width = STRTL; ch >= pwr; width += STEPL, pwr <<= 1) ch -= pwr; if ((prefix = width - STRTL) != 0) PutBits(0xffff, prefix); if (width < STOPL) width++; /* else if (width > STOPL) abort(); do nothing */ PutBits(ch, width); }

Costanzo, Robinson & Ullmann                                   [Page 30]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 30] RFC 1505 Encoding Header Field August 1993

    main(int ac, char **av)            /* main program */
    {
    uint r, s, i, c;
    uchar *p, *rp;
    int match_position;
    int match_length;
    int len;
    uint hash, h;

main(int ac, char **av) /* main program */ { uint r, s, i, c; uchar *p, *rp; int match_position; int match_length; int len; uint hash, h;

        if (ac < 3) {
            fprintf(stderr, "usage: juencode in out\n");
        return(1);
            }

if (ac < 3) { fprintf(stderr, "usage: juencode in out\n"); return(1); }

        in = fopen(av[1], "rb");
        if (!in) {
            fprintf(stderr, "Can't open %s\n", av[1]);
        return(1);
            }

in = fopen(av[1], "rb"); if (!in) { fprintf(stderr, "Can't open %s\n", av[1]); return(1); }

        out = fopen(av[2], "w");
        if (!out) {
            fprintf(stderr, "Can't open %s\n", av[2]);
            fclose(in);
        return(1);
            }

out = fopen(av[2], "w"); if (!out) { fprintf(stderr, "Can't open %s\n", av[2]); fclose(in); return(1); }

        char_ct = 0;
        in_count = 0;
        out_count = 0;
        putbuf = 0;
        putlen = 0;
        hash = 0;

char_ct = 0; in_count = 0; out_count = 0; putbuf = 0; putlen = 0; hash = 0;

        MakeCrctable();
        crc = CRC_MASK;

MakeCrctable(); crc = CRC_MASK;

        fprintf(out, "* LZJU90 %s\n", av[1]);

fprintf(out, "* LZJU90 %s\n", av[1]);

        /* The hash table inititialization is somewhat arbitrary */
        for (i = 0; i < K; i++) hash_table[i] = i % N;

/* The hash table inititialization is somewhat arbitrary */ for (i = 0; i < K; i++) hash_table[i] = i % N;

        r = 0;
        s = 0;

r = 0; s = 0;

        /* Fill lookahead buffer */

/* Fill lookahead buffer */

        for (len = 0; len < F && (c = fgetc(in)) != EOF; len++) {

for (len = 0; len < F && (c = fgetc(in)) != EOF; len++) {

Costanzo, Robinson & Ullmann                                   [Page 31]

RFC 1505                 Encoding Header Field               August 1993

Costanzo, Robinson & Ullmann [Page 31] RFC 1505 Encoding Header Field August 1993

            UPDATE_CRC(crc, c);
        in_count++;
        window_text[s++] = c;
        }

UPDATE_CRC(crc, c); in_count++; window_text[s++] = c; }

        while (len > 0) {
        /* look for match in window at hash position */
        h = ((((window_text[r] << 5) ^ window_text[r+1])
                << 5) ^ window_text[r+2]);
        p = window_text + hash_table[h % K];
        rp = window_text + r;
        for (i = 0, match_length = 0; i < F; i++) {
                if (*p++ != *rp++) break;
                match_length++;
                }
        match_position = r - hash_table[h % K];
        if (match_position <= 0) match_position += N;

while (len > 0) { /* look for match in window at hash position */ h = ((((window_text[r] << 5) ^ window_text[r+1]) << 5) ^ window_text[r+2]); p = window_text + hash_table[h % K]; rp = window_text + r; for (i = 0, match_length = 0; i < F; i++) { if (*p++ != *rp++) break; match_length++; } match_position = r - hash_table[h % K]; if (match_position <= 0) match_position += N;

        if (match_position > N - F - 2) match_length = 0;
        if (match_position > in_count - len - 2)
            match_length = 0; /* ! :-) */

if (match_position > N - F - 2) match_length = 0; if (match_position > in_count - len - 2) match_length = 0; /* ! :-) */

        if (match_length > len)
            match_length = len;
        if (match_length < THRESHOLD) {
            EncodeLength(0);
            PutBits(window_text[r], 8);
            match_length = 1;
            }
        else {
            EncodeLength(match_length - THRESHOLD + 1);
            EncodePosition(match_position);
            }

if (match_length > len) match_length = len; if (match_length < THRESHOLD) { EncodeLength(0); PutBits(window_text[r], 8); match_length = 1; } else { EncodeLength(match_length - THRESHOLD + 1); EncodePosition(match_position); }

        for (i = 0; i < match_length &&
                        (c = fgetc(in)) != EOF; i++) {
                UPDATE_CRC(crc, c);
                in_count++;
            window_text[s] = c;
                if (s < F - 1)
                window_text
                [s + N] = c;
            if (++s > N - 1) s = 0;
            hash = ((hash << 5) ^ window_text[r]);
            if (r > 1) hash_table[hash % K] = r - 2;
            if (++r > N - 1) r = 0;
            }

for (i = 0; i < match_length && (c = fgetc(in)) != EOF; i++) { UPDATE_CRC(crc, c); in_count++; window_text[s] = c; if (s < F - 1) window_text [s + N] = c; if (++s > N - 1) s = 0; hash = ((hash << 5) ^ window_text[r]); if (r > 1) hash_table[hash % K] = r - 2; if (++r > N - 1) r = 0; }

Costanzo, Robinson & Ullmann                                   [Page 32]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[32ページ]RFC1505

        while (i++ < match_length) {
            if (++s > N - 1) s = 0;
            hash = ((hash << 5) ^ window_text[r]);
            if (r > 1) hash_table[hash % K] = r - 2;
            if (++r > N - 1 ) r = 0;
            len--;
                }
        }

(i++<のマッチ_長さ)である間の[細切れ肉料理%K]はrと等しいです--2(+ + r>N--1)r=0である(len)なら}(r>1)が_テーブルを論じ尽くすなら(+ + s>N--1)sは0と等しいです; 細切れ肉料理=(細切れ肉料理<<5)^窓_テキスト[r])なら

        /* end compression indicator */
        EncodeLength(1);
        EncodePosition(0);
        PutBits(0, 7);

/*エンド圧縮インディケータ*/EncodeLength(1)。 EncodePosition(0)。 PutBits(0、7)。

        fprintf(out, "\n* %lu %08lX\n", in_count, crc);
        fprintf(stderr, "Encoded %lu bytes to %lu symbols\n",
                in_count, out_count);

「fprintf、(外」、_カウントにおける\n*%Lu%08lx\n」crc)、。 fprintf、(stderr、「%をコード化する、%LuへのLuバイトが_カウントから_カウントで\n」を象徴する、)、。

        fclose(in);
        fclose(out);

fclose(in)。 fclose(out)。

    return(0);
    }

リターン(0)。 }

5.3.2  Example LZJU90 Compressed Object

5.3.2 例のLZJU90は物を圧縮しました。

   The following is an example of an LZJU90 compressed object.  Using
   this as source for the program in section 5.3 will reveal what it is.

以下によるLZJU90に関する例が物を圧縮したということです。 プログラムにソースとしてセクション5.3でこれを使用するのは、それが何であるかを明らかにするでしょう。

      Encoding: 7 LZJU90 Text

コード化します: 7 LZJU90テキスト

      * LZJU90 example
      8-mBtWA7WBVZ3dEBtnCNdU2WkE4owW+l4kkaApW+o4Ir0k33Ao4IE4kk
      bYtk1XY618NnCQl+OHQ61d+J8FZBVVCVdClZ2-LUI0v+I4EraItasHbG
      VVg7c8tdk2lCBtr3U86FZANVCdnAcUCNcAcbCMUCdicx0+u4wEETHcRM
      7tZ2-6Btr268-Eh3cUAlmBth2-IUo3As42laIE2Ao4Yq4G-cHHT-wCEU
      6tjBtnAci-I++
      * 190 081E2601

* LZJU90例の8-mBtWA7WBVZ3dEBtnCNdU2WkE4owW+l4kkaApW+o4Ir0k33Ao4IE4kk bYtk1XY618NnCQl+OHQ61d+J8FZBVVCVdClZ2-LUI0v+I4EraItasHbG VVg7c8tdk2lCBtr3U86FZANVCdnAcUCNcAcbCMUCdicx0+u4wEETHcRM7tZ2-6Btr268-Eh3cUAlmBth2-IUo3As42laIE2Ao4Yq4G-cHHT-wCEU 6tjBtnAci-I++*190 081E2601

Costanzo, Robinson & Ullmann                                   [Page 33]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[33ページ]RFC1505

6.  Alphabetical Listing of Defined Encodings

6. 定義されたEncodingsに関するアルファベット順リスト

        Keyword         Description             Section  Reference(s)
        _______         ___________             _______  ____________

キーワード記述セクション参照_______ ___________ _______ ____________

        EDIFACT         EDIFACT format          3.5
        EDI-X12         EDI X12 format          3.5      ANSI X12
        EVFU            FORTRAN format          3.4
        FS              File System format      3.6, 4
        Hex             Hex binary format       3.3
        LZJU90          LZJU90 format           3.7, 5
        LZW             LZW format              3.8
        Message         Encapsulated Message    3.2      STD 11, RFC 822
        PEM, PEM-Clear  Privacy Enhanced Mail   3.10     RFC 1421-1424
        PGP             Pretty Good Privacy     3.11
        Postscript      Postscript format       3.14     [8]
        Shar            Shell Archive format    3.15
        Signature       Signature               3.12
        Tar             Tar format              3.13
        Text            Text                    3.1      IS 10646
        uuencode        uuencode format         3.9
        URL             external URL-reference  3.16

EDIFACT EDIFACT形式3.5EDI-X12 EDI X12形式3.5ANSI X12 EVFU FORTRAN形式3.4FS File Systemは3.6、4Hex Hexバイナリフォーマット3.3LZJU90 LZJU90形式3.7、5LZW LZW形式3.8Message Encapsulated Message3.2STD11をフォーマットします、RFC822PEM、PEM明確なPrivacy Enhancedメール3; 10 RFC1421-1424PGPプリティ・グッド・プライバシ3.11Postscript Postscript形式3.14 8Sharシェルアーカイブ形式3.15Signature Signature3.12Tar Tar形式3.13Text Text3.1は外部のURL参照3.16に10646uuencode uuencode形式3.9URLです。

7.  Security Considerations

7. セキュリティ問題

   Security of content and the receiving (decoding) system is discussed
   in sections 3.10, 3.11, 3.15, and 4.2.10.  The considerations
   mentioned also apply to other encodings and attributes with similar
   functions.

セクション3.10、3.11、3.15、および4.2.10で内容と受信(解読)システムのセキュリティについて議論します。 問題は、また、他のencodingsと属性に同様の機能で適用するように言及しました。

8.  References

8. 参照

   [1] Robinson, D. and R. Ullmann, "Encoding Header Field for Internet
       Messages", RFC 1154, Prime Computer, Inc., April 1990.

[1] ロビンソンとD.とR.ウルマン、「インターネットメッセージのためのヘッダーフィールドをコード化します」、RFC1154、プライムコンピュータInc.、1990年4月。

   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, University of Delaware, August 1982.

[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。

   [3] International Organization for Standardization, Information
       Technology -- Universal Coded Character Set (UCS).  ISO/IEC
       10646-1:1993, June 1993.

[3]国際標準化機構、情報技術--普遍的なコード化文字集合(UCS)。 1993年6月のISO/IEC10646-1:1993。

   [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       I: Message Encryption and Authentication Procedures" RFC 1421,
       IAB IRTF PSRG, IETF PEM WG, February 1993.

[4] リン、J.、「インターネット電子メールのためのプライバシー増進:」 部分I: 「メッセージ暗号化と認証手順」RFC1421、IAB IRTF PSRG、IETF PEM WG、1993年2月。

Costanzo, Robinson & Ullmann                                   [Page 34]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[34ページ]RFC1505

   [5] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
       II: Certificate-Based Key Management", RFC 1422, IAB IRTF PSRG,
       IETF PEM, BBN, February 1993.

[5] ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、IAB IRTF PSRG、IETF PEM、BBN、1993年2月。

   [6] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
       Part III: Algorithms, Modes, and Identifiers", RFC 1423, IAB IRTF
       PSRG, IETF PEM WG, TIS, February 1993.

[6]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、IAB IRTF PSRG、IETF PEM WG、TIS、2月1993日

   [7] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
       Part IV: Key Certification and Related Services", RFC 1424, RSR
       Laboratories, February 1993.

[7]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 パートIV: 「主要な証明の、そして、関連のサービス」、RFC1424、RSR研究所、1993年2月。

   [8] Adobe Systems Inc., PostScript Language Reference Manual.  2nd
       Edition, 2nd Printing, January 1991.

[8]アドビ・システムズ株式会社、ポストスクリプト言語リファレンスマニュアル。 第2版、第2印刷、1991年1月。

   [9] Rose, M. and E. Steffererud, "Proposed Standard for Message
       Encapsulation", RFC 934, Delaware and NMA, January 1985.

[9] ローズとM.とE.Steffererudと「メッセージカプセル化の提案された標準」とRFC934、デラウェアとNMA、1985年1月。

  [10] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

[10] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。

  [11] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions): Mechanisms for Specifying and Describing the Format
       of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June
       1992.

[11] Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。

  [12] Borenstein, N., and M. Linimon, "Extension of MIME Content-Types
       to a New Medium", RFC 1437, 1 April 1993.

[12]Borenstein、N.、およびM.Linimon、「新しい媒体へのMIMEコンテントタイプの拡大」、RFC1437、1993年4月1日。

9.  Acknowledgements

9. 承認

   The authors would like to thank Robert Jung for his contributions to
   this work, in particular the public domain sample code for LZJU90.

作者はこの仕事への彼の貢献、LZJU90のための特に公共の場サンプルコードについてロバート・ユングに感謝したがっています。

Costanzo, Robinson & Ullmann                                   [Page 35]

RFC 1505                 Encoding Header Field               August 1993

コスタンゾ、ロビンソン、および1993年8月にヘッダーフィールドをコード化するウルマン[35ページ]RFC1505

10.  Authors' Addresses

10. 作者のアドレス

   Albert K. Costanzo
   AKC Consulting Inc.
   P.O. Box 4031
   Roselle Park, NJ  07204-0531

アルバートK.コスタンゾAKCコンサルティング株式会社私書箱4031ローゼル・パーク、ニュージャージー07204-0531

   Phone: +1 908 298 9000
   Email: AL@AKC.COM

以下に電話をしてください。 +1 9000年の908 298メール: AL@AKC.COM

   David Robinson
   Computervision Corporation
   100 Crosby Drive
   Bedford, MA  01730

デイビッド・ロビンソンComputervision社100のクロズビー・Driveベッドフォード、MA 01730

   Phone: +1 617 275 1800 x2774
   Email: DRB@Relay.CV.COM

以下に電話をしてください。 +1 1800年の617 275x2774メール: DRB@Relay.CV.COM

   Robert Ullmann

ロバート・ウルマン

   Phone: +1 617 247 7959
   Email: ariel@world.std.com

以下に電話をしてください。 +1 7959年の617 247メール: ariel@world.std.com

Costanzo, Robinson & Ullmann                                   [Page 36]

コスタンゾ、ロビンソン、およびウルマン[36ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

行の高さを正しく算出しない

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る