错误的 ELF 类 - Python
我正在尝试安装此库以进行 LZJB 压缩。 PyLZJB LINK
该库是 C 库的绑定，文件位于此处 PyLZJB.so
不幸的是导入时复制到 site-packages 目录时出现“错误的 ELF 类”错误。
>>> import PyLZJB
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: ./PyLZJB.so: wrong ELF class: ELFCLASS32
帮助会很棒。:)
PS：我正在运行 Ubuntu 10.4 64 位
编辑：
如果有人可以建议我一种替代压缩算法，我会同样高兴。 :)
该算法用于HTML压缩，并且还需要客户端Javascript解压缩/压缩支持。
我真的希望有人能在这方面提供帮助。谢谢你们！
I'm trying to install this library for LZJB compression. PyLZJB LINK
The library is a binding for a C library, the file is located here PyLZJB.so
Unfortunately by copying to the site-packages directory when import I get the "Wrong ELF class" error.
>>> import PyLZJB
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: ./PyLZJB.so: wrong ELF class: ELFCLASS32
Help would be great. :)
PS: I'm running Ubuntu 10.4 64bit
Edit:
If someone could suggest me an alternative compression algorithm I would be equally happy. :)
The algorithm is for HTML compression, and it needs client side Javascript decompression/compression support too.
I really hope someone can help on this one. Thanks guys!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您正在运行 64 位 Python 解释器并尝试加载 32 位扩展，但这是不允许的。
您需要为相同的架构编译 Python 解释器和扩展。虽然您可以获得 32 位 Python 解释器，但获得 64 位扩展可能会更好。
您应该做的是获取 LZJB 的源代码并自己构建它以获得64 位共享对象。
You are running a 64 bit Python interpreter and trying to load a 32 bit extension and that is not allowed.
You need to have both your Python interpreter and your extension compiled for the same architectures. While you could get a 32 bit Python interpreter, it would probably be better to get a 64 bit extension.
What you should do is get the source for LZJB and build it yourself to get a 64 bit shared object.
总是有很好的旧 deflate，它是 LZ 压缩家族中更常见的成员。 JavaScript 实现。 如何使用 Python 的 zlib 模块处理原始 deflate 内容。
在相对较慢的客户端代码中压缩提交数据会产生大量开销，并且提交从中获得的原始字节也并非易事。
查询字符串中的 GET 表单提交本质上必须相当短，否则您将超出浏览器或服务器 URL 长度限制。压缩这么小的东西是没有意义的。如果您有大量数据，则需要采用 POST 形式。
即使在 POST 表单中，默认的
enctype也是application/x-www-form-urlencoded，这意味着大多数字节将被编码为% nn 序列。这将使您的表单提交膨胀，可能超出原始未压缩的大小。要提交原始字节，您必须使用enctype="multipart/form-data"表单。即使这样，你也会遇到编码问题。 JS 字符串是 Unicode 而不是字节，并且将使用包含表单的页面的编码进行编码。通常应该是 UTF-8，但是实际上您无法通过对其进行编码来生成用于上传的任意字节序列，因为许多字节序列在 UTF-8 中无效。您可以通过将每个字节编码为 UTF-8 的代码单元来获得 bytes-in-unicode，但这会使您的压缩字节膨胀 50%（因为一半的代码单元，即那些超过
0x80的代码单元）编码为两个 UTF-8 字节）。理论上，如果您不介意失去适当的国际化支持，您可以将页面作为 ISO-8859-1 提供服务，并使用
escape/encodeURIComponent习惯用法在 UTF-8 和 ISO-8859 之间进行转换 - 1 用于输出。但这行不通，因为浏览器会撒谎，实际上使用 Windows 代码页 1252 来编码/解码标记为 ISO-8859-1 的内容。您可以使用另一种编码将每个字节映射到一个字符，但这会增加手动编码开销，并且会进一步限制您可以在页面中使用的字符。您可以通过使用诸如 base64 之类的东西来避免编码问题，但话又说回来，您会获得更多的手动编码性能开销和 33% 的膨胀。
总而言之，所有的方法都是不好的；我认为你不会从中得到多少有用的东西。
There is always good old deflate, a much more common member of the LZ compression family. JavaScript implementation. How to handle raw deflate content with Python's zlib module.
This a lot of overhead in relatively slow client-side code to be compressing submission data, and it's not trivial to submit the raw bytes you will obtain from it.
GET form submissions in the query string must by nature be fairly short, or you will overrun browser or server URL length limits. There is no point compressing anything so small. If you have a lot of data, it needs to go in a POST form.
Even in a POST form, the default
enctypeisapplication/x-www-form-urlencoded, which means a majority of bytes are going to get encoded as%nnsequences. This will balloon your form submission, probably beyond the original uncompressed size. To submit raw bytes you would have to use aenctype="multipart/form-data"form.Even then, you're going to have encoding problems. JS strings are Unicode not bytes, and will get encoded using the encoding of the page containing the form. That should normally be UTF-8, but then you can't actually generate an arbitrary sequence of bytes for upload by encoding to it, since many byte sequences are not valid in UTF-8. You could have bytes-in-unicode by encoding each byte as a code unit to UTF-8, but that would bloat your compressed bytes by 50% (since half the code units, those over
0x80, would encode to two UTF-8 bytes).In theory, if you didn't mind losing proper internationalisation support, you could serve the page as ISO-8859-1 and use the
escape/encodeURIComponentidiom to convert between UTF-8 and ISO-8859-1 for output. But that won't work because browsers lie and actually use Windows code page 1252 for encoding/decoding content marked as ISO-8859-1. You could use another encoding that mapped every byte to a character, but that'd be more manual encoding overhead and would further limit characters you could use in the page.You could avoid encoding problems by using something like base64, but then, again, you've got more manual encoding performance overhead and a 33% bloat.
In summary, all approaches are bad; I don't think you're going to get much useful out of this.
您可以运行 32 位 Python 或编译自己的 PyLZJB，而不是使用预构建的二进制文件。或者从某处获取 64 位二进制 PyLZJB。
You can either run a 32-bit Python or compile your own PyLZJB rather than using the prebuilt binary. Or get a 64-bit binary PyLZJB from somewhere.