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ページ]
一覧
スポンサーリンク
