Base64 は、1 文字あたり 6 ビット (2^6 = 64) のみを使用して、画像ファイルからテキスト データを作成します。これは非効率を引き起こします。
Base64 に関するウィキペディアのエントリによると、この非効率性は、電子メールなどの 8 ビットのダーティなものから保護することです。
Ajax Posting 8 ビットはクリーンですか? その場合、Base64 を使用する代わりの方法はありますか?
php.net (ウィキペディアと同様) は、base64_encode の効率が 33% 低いと主張しています。.
すこし。すべてのJavaScript文字列はUTF-16であり、バイト文字列ではありません。を使用してデータを送信する場合は、送信send前にUTF-8にエンコードされます。そのため、バイトをUnicodeコードポイントに変換して、UTF-8にエンコードすることができます。サーバーに到達したら、UTF-8をデコードしてから、コードポイントをバイトに変換し直す必要があります。
7ビットデータの場合、これによってデータのサイズがまったく拡張されることはありません。最上位ビットが常に設定されている8ビットデータの場合、データのサイズは2倍になります。最上位ビットが半分の時間で設定されている8ビットデータの場合、データのサイズが50％増加します。これは、Base64の33.3％の増加よりも悪い結果です。
一方、XMLHttpRequestレベル2sendを使用するArrayBufferと、、、、Blobまたはを渡すことでバイナリデータを送信できますFormData。ただし、XMLHttpRequestレベル2は新しいブラウザでのみサポートされます。
その点では、AJAX 投稿は一般的な POST 要求と同じだと思います。そのため、たとえば、ファイルのコンテンツを送信するために「multipart/form-data」が必要です。通常、データは URL エンコードされますが、Base64 の方が (一般的に) 効率的であるため、おそらくより良い方法です。
更新：これを別の方法で見ると役立つ場合があります。) 7 ビットのフィルタリングを安全に通過するには、8 ビットすべてを使用する可能性のある値のストリームが必要です。完璧な解決策は、「7-to-8」エンコーディングを使用することです。これにより、7 バイトごとに 8 つの「安全な」文字になります。ただし、これらの 7 ビット文字の一部は、ストリームに関する追加の (メタ) 情報を指定するために実際に使用されるため、これは当てはまりません...
ここで、次の整数 (6 ビット - つまり base64) を使用するか、「非整数」除算器を使用してスキームを発明しようとするジレンマがあります。そのようなスキームは存在しますが (たとえば、 Ascii85を確認してください)、めったに使用されません。