Неправильный класс ELF - Python

Question

Я пытаюсь установить эту библиотеку для 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 64bit

---

Edit:

Если бы кто-то мог предложить мне альтернативный алгоритм сжатия, я был бы одинаково счастлив. :)

Алгоритм для сжатия HTML , и для него требуется клиентская сторона Поддержка распаковки и сжатия Javascript .

Я действительно надеюсь, что кто-то может помочь в этом. Спасибо, ребята!

Answer 1

Вы используете 64-битный интерпретатор Python и пытаетесь загрузить 32-битное расширение, но это не разрешено.

Вам нужно, чтобы ваш интерпретатор Python и ваше расширение были скомпилированы для одних и тех же архитектур. Хотя вы можете получить 32-битный интерпретатор Python, было бы лучше получить 64-битное расширение.

Что вам нужно сделать, это получить исходный код LZJB и собрать его самостоятельно, чтобы получить 64-битный общий объект.

Answer 2

Если бы кто-то мог предложить мне альтернативный алгоритм сжатия, я был бы одинаково счастлив.

Всегда есть старый добрый дефлят, гораздо более распространенный член семейства сжатия LZ. Реализация JavaScript . Как обрабатывать необработанный контент с использованием модуля zlib Python .

Это большое количество накладных расходов в относительно медленном клиентском коде, сжимающем данные отправки, и нетривиально передать необработанные байты, которые вы получите от него.

они Gzip GET параметры в запросе?

Получение формы GET в строке запроса по своей природе должно быть достаточно коротким, иначе вы превысите ограничения длины URL-адреса браузера или сервера. Нет смысла сжимать что-либо столь маленькое. Если у вас много данных, их нужно отправить в форме POST.

Даже в форме POST значение по умолчанию enctype равно application/x-www-form-urlencoded, что означает, что большинство байтов будет закодировано в виде %nn последовательностей. Это приведет к отправке формы, вероятно, за пределы исходного несжатого размера. Чтобы отправить необработанные байты, вы должны использовать форму enctype="multipart/form-data".

Даже тогда у вас будут проблемы с кодированием. Строки JS - это Unicode, а не байты, и они будут закодированы с использованием кодировки страницы, содержащей форму. Обычно это должен быть UTF-8, но тогда вы не сможете создать произвольную последовательность байтов для загрузки путем кодирования в нее, поскольку многие последовательности байтов недопустимы в UTF-8. Вы можете получить байты в юникоде, кодируя каждый байт как кодовую единицу в UTF-8, но это приведет к увеличению количества сжатых байтов на 50% (поскольку половина кодовых единиц, превышающих 0x80, будет кодироваться до двух UTF-). 8 байт).

Теоретически, если вы не возражаете против потери надлежащей поддержки интернационализации, вы можете использовать страницу как ISO-8859-1 и использовать идиому escape/encodeURIComponent для преобразования между UTF-8 и ISO-8859-1 для вывода. Но это не сработает, потому что браузеры лгут и фактически используют кодовую страницу Windows 1252 для кодирования / декодирования содержимого, помеченного как ISO-8859-1. Вы могли бы использовать другую кодировку, которая сопоставляла бы каждый байт с символом, но это было бы более затратным ручным кодированием и дополнительно ограничивало бы количество символов, которые вы могли бы использовать на странице.

Вы могли бы избежать проблем с кодированием, используя что-то вроде base64, но, опять же, у вас больше накладных расходов на производительность кодирования вручную и увеличение на 33%.

В итоге все подходы плохие; Я не думаю, что вы получите от этого много пользы.

Answer 3

Вы можете либо запустить 32-битный Python, либо скомпилировать свой собственный PyLZJB, а не использовать готовый двоичный файл. Или получите 64-битный двоичный PyLZJB откуда-то.