問題タブ [rfc]

RFC (Request for Comments) を知らない人がたくさんいると思います。私はそれらが論理的なレベルで何であるかを知っていますが、新しい開発者を適切に説明できる人はいますか? また、それらの使用方法と読み方に関するリソースを共有するとよいでしょう。

HTTP 標準にかなり単純な追加があります。野心的な目標であることはわかっていますが、少なくとも提案を提出して、アイデアに関するフィードバックを得たいと思っています。そうするための適切なフォーラム/方法は何ですか?

A4 フォーマットのプリンターで RFC 文書を印刷すると、RFC 文書の 1 ページと見なされるよりも多く印刷することに気付きました。これはおそらく、RFC が北米の紙のレター形式 (216 × 279 mm) で書かれており、ISO A4 形式 (210 × 297 mm) を使用したいためだと思います。用紙サイズに関する情報。したがって、私の質問は、少なくともすべてのレター形式のページを別の A4 形式のページに印刷できる方法またはプログラムがあるかどうかです。下部に未使用のスペースがあることはわかっていますが、少なくとも A4 用紙のページごとに 1 つのテキスト ページしかありません。プリンターの用紙サイズをA4からレターに変更してみましたが、だめでした。

RegEx を使用して Base64 データを検証またはサニタイズすることは可能ですか? それは単純な質問ですが、この質問を難しくしている要因があります。

RFC 仕様に従うために入力データに完全に依存できない Base64 デコーダーがあります。したがって、私が直面している問題は、おそらく 78 に分割されない可能性のある Base64 データのような問題です (78 だと思います。RFC を再確認する必要があるため、正確な数が間違っていても気にしないでください)。行、または行が CRLF で終わっていない可能性があります。つまり、CR または LF のみを含むか、どちらも含まない可能性があります。

だから、私はそのようにフォーマットされたBase64データを解析するのにかなりの時間を費やしました. このため、次のような例は確実にデコードできなくなります。簡潔にするために、部分的な MIME ヘッダーのみを表示します。

わかりました。解析は問題なく、まさに期待どおりの結果です。そして、99% のケースで、任意のコードを使用して、少なくともバッファー内の各文字が有効な base64 文字であることを確認すると、完全に機能します。しかし、次の例では問題が発生しています。

この Base64 エンコーディングのバージョンは、一部のメール リーダーを利用しようとする一部のウイルスやその他のもので見られたバージョンであり、厳密に書籍または RFC に従っているものとは対照的に、すべての犠牲を払って MIME を解析したいと考えています。もしよろしければ。

私の Base64 デコーダーは、2 番目の例を次のデータ ストリームにデコードします。ここで、元のストリームはすべて ASCII データであることを覚えておいてください。

一度に両方の問題を解決する良い方法はありますか? 異なるルールを適用してデータに2つの変換を行い、結果を比較する以外に、それが可能かどうかさえわかりません。しかし、そのアプローチを採用した場合、どのアウトプットを信頼しますか? ASCII ヒューリスティックが最善の解決策であるように見えますが、このコードが実際に関与しているウイルス スキャナーのような複雑なものに、コード、実行時間、および複雑さがどれだけ追加されるのでしょうか? Base64 で許容できるものとそうでないものを学習するには、ヒューリスティック エンジンをどのようにトレーニングしますか?

アップデート：

この質問が引き続き取得するビューの数に合わせて、数十万のトランザクションで C# アプリケーションで 3 年間使用してきた単純な RegEx を投稿することにしました。正直なところ、Gumboからの回答が一番気に入っているので、選択した回答として選択しました。しかし、C# を使用していて、文字列または byte[] に有効な Base64 データが含まれているかどうかを少なくとも検出する非常に簡単な方法を探している人にとっては、次の方法が非常にうまく機能することがわかりました。

はい、これはBase64 データのSTRINGのためのものであり、適切にフォーマットされたRFC1341メッセージではありません。したがって、このタイプのデータを扱う場合は、上記の正規表現を使用する前にそのことを考慮してください。他の目的 (URL、ファイル名、XML エンコーディングなど) で Base16、Base32、Radix、さらには Base64 を扱っている場合は、Gumboが回答で言及したRFC4648を読むことを強くお勧めします。この質問/回答セットの提案を使用する前に、実装で使用される文字セットとターミネータを認識してください。

http://www.faqs.org/rfcs/rfc2822.htmlから:

CR と LF は、CRLF として一緒にのみ発生する必要があります。それらは体内で独立して出現してはなりません。

確認メールを送信する Web サービスがありますが、ユーザーの 1 人が、これが rfc2822 標準に準拠していないと指摘しました。私の質問は、メール メッセージで CR と LF が一緒に表示されることがなぜ重要なのですか?

私は、一方の側からパケットを送信し、もう一方の側でそれを受信するイーサネットアプリケーションを構築しています。RFC 3393のように、受信側でパケットの遅延を計算したいので、送信側でパケットにタイムスタンプを入れ、パケットを受信したらすぐに受信側でタイムスタンプを取得する必要があります。値iを減算すると、タイムスタンプの差が取得され、この値を後続の差で減算すると、一方向ipdv遅延が取得されます。両方のクロックが同期されていません。 ですから、どんな助けでも大歓迎です。ありがとうございました。

データベース内のデータの更新に対する即時の反応をプログラムするための最良の方法は何ですか？

私がオフハンドで考えることができる最も簡単な方法は、データベースに特定のデータの変更がないかチェックし、事前定義された時間の間、データベースを再度チェックするのを継続的に待機するスレッドです。この解決策は私には無駄で最適ではないように思われるので、もっと良い方法があるかどうか疑問に思いました。

結局のところ、GmailのようなWebアプリケーションは、新しい電子メールが送信された直後に受信トレイを更新できるようです。確かに、私のクライアントは常に更新をチェックしているわけではありません。彼らがこれを行う方法はAJAXを使用する方法だと思いますが、AJAXがリモート関数呼び出しのようにどのように動作するかはわかりません。Gmailがこれをどのように行うのか知りたいのですが、私が最も知りたいのは、データベースを使用した一般的なケースでこれを行う方法です。

編集：トリガーがこれを実行できないことがわかっている限り、データベース自体ではなく、クライアントコードの更新にすぐに反応したいことに注意してください。基本的に、データベースに変更が加えられたら、ユーザーに通知を受け取るか、画面を更新してもらいたいと思います。

@ rfc 2231と2183を見てきました。マルチパート/関連 MIME ペイロードの処理。

以下が構文的に正しいかどうか、具体的には最初の Content-Type の「開始」属性かどうかを解読しようとしていますが、正しい RFC を見つけることができませんでした。

好奇心旺盛な人のための背景情報。application/vnd.oma.drm.* ファイル タイプは、ペイロード アイテム (mp3、jpg など) の単なるラッパーであり、セルラー デバイスに、ラップされたファイルが保護されたペイロードと見なされ、転送または転送を許可しないように指示します。とにかく電話。契約上の義務がなければ、ラッパーをはぎ取り、ペイロードを送信して満足するだけですが、それは簡単すぎて、おそらく違法です。

ID の統合を行っている最中なので、インターネット上のさまざまな場所で URL を提供しています。私は IRC で非常に活発に活動しているので、当然ながら、私の IRC プレゼンスへのリンクを提供する方法があったのではないかと思いました。

これにより、 http://www.w3.org/Addressing/draft-mirashi-url-irc-01.txtが見つかりました。これは、URL を IRC に関連付けるための RFC のドラフトのようです。

irc://irc.freenode.net/DRMacIver,isnick

これは少し不自由なようです。さらに、この RFC ドラフトは完全に失効しました (1997 年 2 月 28 日)。一方、少なくともchatzillaに実装されているようです：

http://www.mozilla.org/projects/rt-messaging/chatzilla/irc-urls.html

それで、これに取って代わるRFCおよび/または他の事実上の標準があるかどうか、誰かが知っていますか?