pako（zlibはjavascript）で圧縮され、zlib（python）は動作しません。

Question

javascriptで圧縮を行うコードは、pako（https://github.com/nodeca/pako）Pakoを使用しています。これは、文字列「T」で

var compressedString = pako.gzip('t', {level: 4, to: 'string'})); 
$.ajax('/decompress', {string: compressedString}) 

コード/エラー、次のスロー解凍を行う解凍

from cgi import parse_qs, escape 
import json 
import zlib 
def application(environ, start_response): 
    status = '200 OK' 
    try: 
     request_body_size = int(environ.get('CONTENT_LENGTH', 0)) 
    except (ValueError): 
     request_body_size = 0 
    request_body = environ['wsgi.input'].read(request_body_size) 
    d = parse_qs(request_body) 

    response_headers = [('Content-type', 'text/plain')] 
    start_response(status, response_headers) 
    inputString = d.get('string')[0] 
    # Use same wbits(=31) as used by pako 
    decompressed = zlib.decompress(inputString, 31); 
    return 'done' 

にし解凍を圧縮します。このエラーは、zlib.decompress行で発生します。

error: Error -3 while decompressing data: incorrect header check

Iはまた、（

inputString.encode('utf-8')

）inputStringからをコードする試みたが、それはまた、エラーをスローします。

Answer 1

to: 'string' 

このオプションは、同じ番号と文字に各バイトをマッピングすることによって、JSへ出力バイトシーケンス（ユニコード）Stringをsmuggles。 （これは、ISO-8859-1エンコーディングを使用して復号化することと等価である。）

$.ajax('/decompress', {string: compressedString}) 

のXMLHttpRequestは、ネットワークを介して（URLエンコード）を移動するためにバックバイト配列（Unicode）の文字列値を符号化する必要があります。それが使用するエンコーディングは、ISO-8859-1ではなくUTF-8です。したがって、ネットワーク上のバイトシーケンスは、GZipコンプレッサーから出てきたバイトシーケンスと同じではありません。

あなたはURLデコード工程の後に再エンコードによってPythonの終わりに、このプロセスを元に戻すことができます。

d = parse_qs(request_body).decode('utf-8').encode('iso-8859-1') 

を今、あなたはコンプレッサーから出てきた同じバイトシーケンスを持つ必要があります。

バイトをUTF-8エンコードされたコードポイントとして送信し、その中から非ASCIIバイトをURLエンコードすると、ネットワークトラフィックは、生のバイトの約4倍に膨らんでしまいます。圧縮の良い仕事。

Pythonスクリプトへのリクエスト本体としてデータストリングを単独で投稿すると、URLエンコーディングが失われ、生の圧縮データよりも約50％多くのリクエスト（！）が発生します。それ以上の処理を行うには、生のバイトを直接as a ByteArrayに送信するか、おそらくマルチパートform-dataを使用して調べる必要があります。いずれにせよ、ブラウザの互換性の問題があります。