誰かが私に別の圧縮アルゴリズムを提案してくれるなら、私も同じように幸せです。
LZ圧縮ファミリーのはるかに一般的なメンバーである古き良きデフレートが常にあります。JavaScriptの実装。Pythonのzlibモジュールを使用して生のdeflateコンテンツを処理する方法。
これは、送信データを圧縮するための比較的遅いクライアント側コードでの多くのオーバーヘッドであり、そこから取得する生のバイトを送信することは簡単ではありません。
リクエスト内でGETパラメータをGzip圧縮しますか?
クエリ文字列でのGETフォームの送信は、本質的にかなり短くする必要があります。そうしないと、ブラウザまたはサーバーのURLの長さの制限を超えてしまいます。こんなに小さいものを圧縮しても意味がありません。大量のデータがある場合は、POSTフォームに入力する必要があります。
POST形式でも、デフォルトenctype
はです。これは、バイトの大部分がシーケンスapplication/x-www-form-urlencoded
としてエンコードされることを意味します。%nn
これにより、おそらく元の非圧縮サイズを超えて、フォーム送信が膨らみます。生のバイトを送信するには、enctype="multipart/form-data"
フォームを使用する必要があります。
それでも、エンコーディングの問題が発生します。JS文字列はバイトではなくUnicodeであり、フォームを含むページのエンコーディングを使用してエンコードされます。通常はUTF-8である必要がありますが、UTF-8では多くのバイトシーケンスが無効であるため、実際にアップロードするバイトシーケンスを任意に生成してエンコードすることはできません。各バイトをコードユニットとしてUTF-8にエンコードすることで、Unicode内のバイトを作成できますが、圧縮されたバイトが50%肥大化します(コードユニットの半分以上0x80
が2つのUTF-8バイトにエンコードされるため) 。
理論的には、適切な国際化サポートを失ってもかまわない場合は、ページをISO-8859-1として提供し、このescape/encodeURIComponent
イディオムを使用してUTF-8とISO-8859-1の間で出力を変換できます。しかし、ブラウザが嘘をついていて、ISO-8859-1としてマークされたコンテンツのエンコード/デコードに実際にWindowsコードページ1252を使用しているため、これは機能しません。すべてのバイトを文字にマップする別のエンコーディングを使用することもできますが、それはより手動のエンコーディングオーバーヘッドであり、ページで使用できる文字をさらに制限します。
base64のようなものを使用することでエンコードの問題を回避できますが、繰り返しになりますが、手動によるエンコードのパフォーマンスのオーバーヘッドが増え、33%の肥大化が発生します。
要約すると、すべてのアプローチは悪いです。私はあなたがこれからあまり役に立たないだろうと思います。