RFC 2068によると:
コメント テキストを括弧で囲むことにより、一部の HTTP ヘッダー フィールドにコメントを含めることができます。コメントは、フィールド値定義の一部として「コメント」を含むフィールドでのみ許可されます。他のすべてのフィールドでは、括弧はフィールド値の一部と見なされます。
関連するルールは次のとおりです。
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
コメント内のコメント? これはばかげているようです。私の主張は次のとおりです。(1) コメント内にネストされたコメントは必要ありません。(2) その場合、コメント ルールは次のように表現した方がよいでしょう。
comment = "(" *( ctext ) ")"
私の主張は正しいですか?そうでない場合、ネストされたコメントが実際に使用されるのはいつですか? 他の図書館は気にしますか?これについてあなたが知っている歴史/解説はありますか? (「RFC 2068 ネストされたコメント」で Web 検索を試みてもあまり役に立ちません。)
(動機: RFC 2068 用に (Ragel を使用して) lexer を作成しているので気にします。コメントをネスト可能にする必要がある場合、それは再帰ルールを意味します。これは、私が理解しているように、Ragel のスイート スポットではありません。場合によっては、Ragel が再帰規則を処理できることを示すいくつかの兆候がありますが、それについてはよくわかりません. また、Unicorn Ragel コードも調べていますが、これは役に立ちます.)
PS 簡単にするために、別のルールの詳細については意図的に掘り下げませんquoted-string
。
更新 2012-08-20 : 以下の 1 つの回答は、RFC 2068 の新しいバージョンを参考に引用しています。これは、解析規則を明確にするという点で役立ちます。ただし、それは私の他の点に対処していません:
コメント内にコメントを含めるという仕様の説得力のある根拠は見当たりません。それは単に不必要に思えます。おそらくオーバーエンジニアリングされているか、見過ごされているのでしょう。これは、再帰的なルールによってフォーマットが非正規言語になるため、煩わしくも重要でもあります。これは、仕様の作成者が通常は警戒すべきことですよね?
私は (まだ?) コメント内でコメントを使用する実際の例を見たことがありません。もしそうなら、世界は暗黙のうちに「ネストされたコメントはあまり重要ではない」と言ったことになります。