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

Всегда есть старый добрый дефлят, гораздо более распространенный член семейства компрессионных LZ. реализация JavaScript. Как обрабатывать необработанное содержимое deflate с помощью модуля 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% раздувания.

Таким образом, все подходы плохие; Не думаю, что вы извлечете из этого много пользы.

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

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

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

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