rfc822-like(5)

Date: $Date: 2000/03/18 06:54:10 $
Source: $Author: odakker $
Title: File Format
$Revision: 1.1.1.1 $

名前

rfc822-like - インターネットの電子メールヘッダに類するファイル形式

書式


file = fields [ NEWLINE text ]
fields = field ...
field = field-name ":" [ field-body ] NEWLINE
field-name = NAME-CHAR ...
field-body = field-body-contents [ CRLF LWSP field-body ]
field-body-contents = ANY-CHAR ...
text = [ ANY-CHAR | NEWLINE ] ...
NEWLINE = [ CR ] LF
LWSP = SPC | HT
ANY-CHAR = <CR, LF 以外のすべての文字>
NAME-CHAR = <数字 0-9、英大文字 A-Z、英小文字 a-z、
または ASCII HYPHEN-MINUS "-">
HT = <ASCII HT, タブ文字>
CR = <ASCII CR, 復帰文字>
LF = <ASCII LF, 改行文字>
SPC = <ASCII SPC, スペース>

説明

dcbib で用いる多くのファイルの形式はインターネットの電子メールのヘッダと 同じ構造をしています。 ここではその字句的構造を説明します。

ファイルは ISO-2022-JP、Shift_JIS または EUC-JP で 符号化されたプレーンテキストです。 内部的処理は EUC-JP に変換することで行われます。 ファイルは 復帰改行 または 改行 によって に区切られます。 ファイルの中の最初の空行以降を 本文 text と呼び、この内容は解析ルーチンからは無視されます。 本文は注釈や履歴の管理に用いることができます。 最初の空行までの行は ヘッダ の羅列を構成していなければなりません。 ヘッダは

From: TOYODA Eizi <toyoda@ms.u-tokyo.ac.jp>
というように フィールド名 とコロン、それから任意のテキストで成り立っています。 複数行にわたるヘッダの 2 行目以降は 行頭がスペースまたはタブ文字となっていなければなりません。

RFC 822 との相違

ここに示されている字句レベル文法は必ずしも RFC 822 と同一ではありません。 その相違は以下の通りです。

終端記号は「ASCII 文字」ではなく、「文字」であること。 いいかえればバイトストリームを文字列として解釈したあとで解析すべきこと。 これは ISO-2022-JP, Shift_JIS, EUC-JP などの 文字符号化方式によるファイルに課せられる条件を自然に記述するためです。 実装では、入力は EUC-JP に変換された後でフィールドの解析の対象となります。

フィールド名に英数字および負号以外のものを認めないこと。 これは日本の文字や正規表現のメタキャラクタをめぐる混乱を防ぐためです。

行の区切りに復帰改行だけでなく単一の改行を認めること。 これは UNIX のエディタで編集しやすくすることを想定しています。 作者は MacOS のテキストなんか知ったことではないと思っているので、 単独の CR はサポートされません (上記文法をよく見ると単独の CR は許容されないことがわかります)。

バグ

現在の処理系には以下のようなバグがあります。

内部処理を行う EUC-JP コードへの変換アルゴリズムは区点番号しか認識されて いないので、 文字集合 JIS X 0208 の 1978, 1983, 1990 年の各版の異同が区別されません。

参照

dcbib(1), dcbib-add(1), dcbib-card(5)
Crocker, D.H., 1982, RFC 822, Standard for ARPA Internet Text Messages.

作者

豊田英司 <toyoda@ms.u-tokyo.ac.jp>
HTML generated using htroff at 27 October 2000 23:7:51.