简体   繁体   English

在python中从ActionScript读取base64 / zlib编码的字符串

[英]Reading base64/zlib encoded string from actionscript in python

I have a string saved to a database that is encoded by Actionscript by base64ing it and then zlib compressing it. 我将一个字符串保存到由Actionscript编码的数据库中,方法是将它进行base64编码,然后zlib对其进行压缩。

An example string is this: "eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI=" 示例字符串是这样的:“ eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI =”

If I unzip and un base64 this via Actionscript, I get what I expect: 如果我通过Actionscript解压缩和unbase64,我会得到我期望的结果:

{"xp": 656398, "rank": 34} {“ xp”:656398,“等级”:34}

But, I need to be able to also read this server-side. 但是,我还需要能够阅读此服务器端。 For now I'm using Python but I'd be open to a working PHP solution or similar. 现在,我正在使用Python,但是我愿意接受可用的PHP解决方案或类似解决方案。

So far in Python I have tried this: 到目前为止,我已经在Python中尝试过此操作:

import base64
import zlib

s = 'eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI='

print s.decode("base64").decode("zlib")

It looks like Actionscript adds some extra bits into the header, but my Python is not strong enough to defeat this :) Any help would be much appreciated! 看来Actionscript在标头中添加了一些额外的位,但是我的Python不足以击败它:)任何帮助将不胜感激!

EDIT: Actionscript first takes an AS Object and converts it to a ByteArray, before zlib compressing it and base64ing it. 编辑:Actionscript首先使用AS对象并将其转换为ByteArray,然后zlib对其进行压缩并对其进行base64化。 It looks like this is what is generating the extra header/mangled data info. 看起来这就是生成额外的标头/损坏的数据信息的原因。

If the string is first base64-ed and then zipped, decoding it should be the other way around! 如果字符串首先是base64版本的,然后压缩了,那么应该反过来解码它!

Your example and output strings don't match; 您的示例和输出字符串不匹配;

In [1]: t = '{"xp": 656398, "rank": 34}'

In [2]: t.encode('base64')
Out[2]: 'eyJ4cCI6IDY1NjM5OCwgInJhbmsiOiAzNH0=\n'

In [3]: t.encode('zlib').encode('base64')
Out[3]: 'eJyrVqooULJSMDM1M7a00FFQKkrMywbyjU1qAVupBsE=\n'

In [4]: t.encode('base64').encode('zlib')
Out[4]: 'x\x9cK\xad\xf42Iv\xf64\xf3t\x894\xf4\xcb\xf25\xf5w.O\xf7\xcc\xf3\xcaH\xca-\xce\xf4\xcft\xac\xf2\xf30\xb0\xe5\x02\x00\xe3E\x0b\xd7'

The given input string '{"xp": 656398, "rank": 34}' does not produce the example output (see Out[3] and Out[4]). 给定的输入字符串'{“ xp”:656398,“ rank”:34}'不会产生示例输出(请参见Out [3]和Out [4])。

You should also note that in this case the base64 encoded string is longer than the original, and the additional zlib encoding is longest. 您还应该注意,在这种情况下, base64编码的字符串比原始字符串 ,并且其他zlib编码最长。 Compressing strings this short is usually not worth the overhead. 压缩字符串这么短通常是不值得的。

If we take your example output and process it, this is what we get; 如果我们以您的示例输出并对其进行处理,这就是我们得到的;

In [5]: s = 'eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI='

In [6]: s.decode('base64')
Out[6]: 'x\xda\xe3\xe2fd\xad(`Y\xd1\xc1\xc7Y\x94\x98\x97\xcd\xa2\xc4\x08\x00%!\x04"'

In [7]: s.decode('base64').decode('zlib')
Out[7]: '\n\x0b\x01\x05xp\x04\xa8\x88\x0e\trank\x04"\x01'

You can clearly see the texts 'xp' and 'rank' in the output. 您可以在输出中清楚地看到文本“ xp”和“ rank”。 And the '"' near the end could be interpreted as the integer 34. 并且末尾的“”可以解释为整数34。

It seems that your actionscript does some mangling of the data before encoding and compressing it. 您的动作脚本似乎在对数据进行编码和压缩之前会进行一些处理。

To me it looks like your Python script is decoding in the wrong order. 在我看来,您的Python脚本解码顺序错误。 If what you say about the encoding order is correct, first base64, then zlib, you must decode in the opposite order: 如果您说的编码顺序正确,首先是base64,然后是zlib,则必须以相反的顺序解码:

print s.decode("zlib").decode("base64")

Tosh, you say that you first base64-encode data and then zip it before storing it to the database. Tosh,您说您先对数据进行base64编码,然后将其压缩,然后再将其存储到数据库中。 This is fine so far. 到目前为止还好。 After zipping the data, it is binary data. 压缩数据后,它就是二进制数据。 Hence, I assume that you have stored this data in binary format in the database. 因此,我假设您已将该数据以二进制格式存储在数据库中。 Now you show us a string: 现在,我们向我们显示一个字符串:

An example string is this: "eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI=" 示例字符串是这样的:“ eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI =”

This, according to you, represents the zipped data. 根据您的说法,这表示压缩的数据。 Now, there is a contradiction. 现在,有一个矛盾。 On the one hand zipped data is binary data, on the other hand you clearly show us a string here that resulted from base64-encoding (as you can infer from the '=' in the end). 一方面,压缩数据是二进制数据,另一方面,您在此处清楚地向我们显示了一个字符串,该字符串是由base64编码产生的(可以从最后的'='推断出)。

You confuse something. 你搞混了。

Flash could be mangling this, but you should share an example from Actionscript that creates and checks this data. Flash可能会解决这个问题,但是您应该从Actionscript中分享一个创建和检查此数据的示例。

If you're using a 3rd party library, it might be using an alternate characterset than Python is expecting. 如果您使用的是第三方库,则它可能使用了Python期望的替代字符集。

if you're using the official library, it seems that Actionscript implements UTF8 and ascii differently. 如果您使用的是官方库,则Actionscript似乎以不同的方式实现UTF8和ascii。 ( there are different methods here - http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/utils/Base64Encoder.html ) (此处有不同的方法-http: //help.adobe.com/zh_CN/FlashPlatform/reference/actionscript/3/mx/utils/Base64Encoder.html

it's much easier to just see the actionscript and note if there's an issue with the library or your code, than try to reverse engineer this. 与尝试进行反向工程相比,仅查看动作脚本并注意库或代码是否存在问题要容易得多。

I think it also might be worth trying to bugfix this in reverse... 我认为也可以尝试反向修正错误...

import base64
import zlib

flash =  "eNrj4mZkrShgWdHBx1mUmJfNosQIACUhBCI="

original = '{"xp": 656398, "rank": 34}'
encoded = original.encode('zlib').encode('base64')
decoded = encoded.decode('base64').decode('zlib')
print original
print encoded
print decoded

Can I also ask why you're even doing this ? 我还能问你为什么要这么做吗?

1- unless your packets are much bigger, you're not going to be saving much bandwidth. 1-除非您的数据包更大,否则您将不会节省太多带宽。 in fact, compression on small payloads can actually increase the size. 实际上,对小型有效负载的压缩实际上会增加大小。

2- assuming this is web based, you should be able to have the server do this on the fly. 2-假设这是基于Web的,那么您应该能够让服务器即时执行此操作。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM