任意のバイト値（00-FF）にすることができる約1000文字の文字列をエンコードする必要があります。Hexは密度が十分でないため、使用したくありません。私が理解しているbase64の問題は、アプリケーションで許容できない文字である+/と=が含まれていることです。
助言がありますか？
21219 次
7 に答える
15
Base58Checkはオプションです。それは暗号通貨アドレスの事実上の標準のようなものになり始めています。
Base64に対する基本的な改善：
- 英数字のみ
[0-9a-zA-Z] - そっくりさんなし：
0OIl/ 0OIl - ドキュメントや電子メールでワードラップや改行をトリガーする句読点はありません
- 句読点がないため、1回のダブルクリックで値全体を選択することもできます。
ビットコインアドレスユーティリティは実装例です。ビットコインを対象としています。
注：新しい事実上の標準は、ニーズに適していない場合があります。Base58Checkエンコーディングメソッドが現在のプロトコル全体で形式化されるかどうかは不明です。
于 2013-09-22T23:49:45.737 に答える
12
代替品を選んでください。他のいくつかのバリアントを検討してください：ウィキペディアのbase64バリアントテーブル。
base64エンコーダー/デコーダーは簡単ですが、置換の置換は、既存のbase64エンコード/デコード機能（ラッパー内）の単純な前処理/後処理ステップで実行できます。ホイールを（完全に）再発明する必要はありません。または、さらに良いことに、Skeet氏が指摘しているように、十分な柔軟性を備えた既存のライブラリを見つけてください。
選択できる代替の適切な「面白い」文字がない場合（おそらく、他のすべての文字は無効で、62文字の英数字のみを選択できます）、いつでもエスケープ文字をごくわずかに使用できます（〜3/64？）サイズの増加。たとえば、0（A）は「AA」としてエンコードされ、62（+）は「AB」としてエンコードされ、63（/）は「AC」としてエンコードされます。これも、独自のエンコーダー/デコーダーをゼロから作成したくない場合は、事前/事後の手順として実行できます。このアプローチの欠点は、入力バイトに対する出力文字の比率が固定されていないことです。
于 2010-12-09T07:30:44.300 に答える
6
気になるのが特定の文字だけで、代わりに使用する他の文字を見つけることができる場合は、独自のカスタムbase64モジュールを実装してみてはどうでしょうか。それほど難しいことではありません。
于 2010-12-09T07:07:52.467 に答える
2
代わりにBase32を使用できます。Base64よりも密度は低くなりますが、不要な文字を完全に排除します。
于 2010-12-09T07:40:43.820 に答える
1
もちろん。独自のBase64エンコーダー/デコーダーを作成して、アルゴリズムでそれらの文字を置き換えてみませんか。もちろん、通常のデコーダーではデコードできませんが、それが問題にならないのであれば、心配する必要はありません。ただし、 +/と=の...を表すためにアプリで使用できる他の文字を少なくとも3つ用意することをお勧めします。
于 2010-12-09T07:09:04.150 に答える
1
Ciaranが言うように、base64の実装はそれほど難しくありませんが、使用する文字のカスタムセットを指定できる既存のライブラリを探すことをお勧めします。そこにはたくさんあると確信していますが、これが必要なプラットフォームを指定していません。
基本的に、必要なのは65個のASCII文字だけです。これは、できれば改行に加えて、受け入れ可能です。
于 2010-12-09T07:10:56.893 に答える
0
base62は基本的にbase64ですが、英数字のみです。
于 2021-03-22T20:37:14.880 に答える