8

エンコードする必要があるバイナリ データがある場合、どのエンコード スキームを使用しますか?

私は知っています：

  • 16 進エンコーディング。非常に単純ですが、非常に冗長で、1 バイトを 2 に拡張します。
  • ベース64。最も一般的ですが、それほど冗長ではありませんが、3 バイトを 4 に拡張します。
  • ベース85。一般的ではなく、冗長ではありませんが、4 バイトを 5 に拡張します。

一般的に使用されている他のエンコード方式はありますか? もしそうなら、どのような利点と欠点がありますか?

編集: これは、たとえば、任意のデータを Cookie に保存しようとする場合に役立ちます。Cookie はテキストのみを保存でき、任意のデータは保存できないため、何らかの方法で、できれば元に戻す方法で変換する必要があります。さらに、ステートレス サーバーを使用しているため、状態をサーバーに保存できず、識別子を Cookie に入れるだけであるとします。もちろん、これを行う場合、ユーザーがあなたに返しているものが、たとえば署名など、ユーザーに渡したものであることを確認する何らかの方法も必要になります。

また、現在のコンセンサスは base64 が広く使用されているため使用する必要があるということなので、これが私が使用しているものであることも指摘します... 誰かが他のものを使用したかどうか、もしそうならその理由.

編集:誰かがこれに出くわした場合に備えて、Base64 を使用してデータを Cookie に保存する場合は、変更された Base64 実装を使用する必要があります。理由については、この回答を参照してください。

4

4 に答える 4

15

Cookieの値をエンコードする場合は、注意が必要です。この古い答えを参照してください：

バージョン0のCookieでは、値に空白、角かっこ、括弧、等号、コンマ、二重引用符、スラッシュ、疑問符、記号、コロン、およびセミコロンを含めないでください。空の値は、すべてのブラウザで同じように動作するとは限りません。

Base64エンコーディングは=特定の入力に対してシンボルを生成できますが、これは技術的にはCookieでは許可されていません（とにかく、最も広くサポートされているバージョン0のCookie）。=実際には、実際にはうまくいくと思いますが、そうではないかもしれません。

エンコードされたバイナリがCookieと互換性があることを絶対に確認するには、基本的な16進エンコードが最も安全であることをお勧めします（Javaなど）。

編集： @Paulが参考に指摘したように、「URLセーフ」（そして、私は「Cookieセーフ」だと思います）であるBase64の修正バージョンがあります。標準アルゴリズムの修正バージョンを使用すると、その魅力がかなり薄れてしまいます。

編集=：@shooshは、がbase64文字列の終わりを示すためにのみ使用されることを指摘しました。そのため、をトリミングし=、Cookieを設定して、=デコードする必要があるときに再度アタッチすることができます。

于 2010-01-18T23:53:03.780 に答える
4

Base64 は非常に一般的であるため、独自のエンコーダー/デコーダーの展開について心配する必要はありません。エンコードされたバイナリ データで帯域幅やファイル容量を節約することを心配しているアプリケーションに遭遇したことはありません。

于 2010-01-19T00:04:30.287 に答える
2

むかしむかし、UTF-7 がありました。公式には非推奨ですが、ACE (ASCII 互換エンコーディング) として引き続き機能します。今はIDNがあります。

于 2010-01-18T23:47:49.423 に答える
1

Base64は事実上の標準です。他のものを使用することは問題を引き起こします。

于 2010-01-18T23:48:31.920 に答える