LZW-сжатие строк на javascript и распаковка средствами PHP / Comments / Habr

XAKEPEHOK Sep 28 2012 at 14:11

У многих возникнет резонный вопрос: А зачем нужно сжимать данные на стороне клиента? На мой взгляд ответ может быть только один (та самая ситуация, с которой я и столкнулся): нужно передавать длинные строки через GET. Разумеется, многие скажут что для этого есть POST и кросдоменные ajax-запросы, но в моем случае это все не подходило по ряду причин. Я писал небольшой счетчик, собирающий инфу о браузерах и размещал его на разных своих сайтах. Вставлять на сайты iframe и делать ajax post — не подходит, потому, что насколько я знаю safari плохо дружит с установкой cookie в iframe (а мне это нужно). Вставлять свой js, который будет слать через POST данные прямо на сайт, где стоит счетчик может быть чревато конфликтами с другими скриптами.

Еще я заметил, что многие думаю, что длина GET'a ограничена 255-ю символами. Это не так. Погуглив я нашел интересную запись, датированную еще 23.11.2011 года, где челвоек провел небольшое исследование насчет поддержки максимальной длины GET различными браузерами:

Firefox 3.6.24 и Firefox 8.0.1 открыли все ссылки, но после тестового значения 8388608 анкор в адресной строке браузера перестал отображаться.
Internet Explorer 8.0 повел себя совсем неадекватно. При открытии ссылок они принудительно усекались до длины 4121 символ и отображались в адресной строке браузера, соответственно, так же. Более короткие ссылки открылись без проблем.
Opera 11.52 открыла все ссылки без проблем, при отображении даже самых длинных анкоров также никаких замечаний нет.
Safari 5.1 открыл все ссылки до тестового значения 8388608, а на нем вылетел с фатальной ошибкой.
Chromium 15.0 и Google Chrome 15.0 с трудом отрисовали даже исходную страницу, периодически вываливая вместо нее свое «Опаньки...». Проблемы с отображением URL в адресной строке браузера начались с тестового значения 32768. Ссылки же удалось открыть лишь до 1048576, дальше появлялось неизменное «Опаньки...».

Думаю, что новые версии описанных браузеров поддерживают длину GET строки не меньше, чем эти. Поддержка старых браузеров в моей ситуации была не нужна. Для IE < 9 я просто ничего не передавал

XAKEPEHOK Sep 28 2012 at 14:13

В моем случае мне нужно было передавать строки длиной менее 4000 символов

UFO just landed and posted this here

XAKEPEHOK Sep 28 2012 at 15:21

Я его целенаправленно вынес в отдельный коммент, т.к. посчитал, что это несколько 2 разные темы. Сам способ сжатия данных на стороне клиента и распаковки на сервере описан в статье. А то, как я это применил — вопрос несколько другой, и кто-то может быть прочитав мою ситуацию ответит к комменту альтернативным способ решения ситуации.
Криво высказался, но как-то так…

imater Sep 28 2012 at 19:43

Прав ли я, думая, что в обычных случаях нет смысла сжимать данные передаваемые от клиента на сервер. Например длинный текст написанный пользователем. Или лучше запаковать при помощи javascript и расшифровать на сервере PHP?

XAKEPEHOK Sep 28 2012 at 21:25

Длинный текст, который вводит пользователь конечно же нет. А вот вставить пиксель, вида .../pixel.php?info=… где параметр info будет содержать закодированную в base64 строку параметры о браузере и разрешении экрана — очень удобно. Например, IE >= 9 по http в заголовках передает один параметр useragent, а через js navigator.userAgent строку примерно на 40% длиннее. Мне как раз и надо было собирать инфу о браузерах, и объект js navigator содержит довольно много информации, чтобы передавать ее не сжимая

docomo Sep 29 2012 at 03:46

Если передаете base64 в урлах, не забудьте еще вот это: code.google.com/p/stringencoders/wiki/WebSafeBase64

XAKEPEHOK Sep 29 2012 at 12:48

Хм, а разве JS encodeURIComponent() не решает данную проблему?

gidroponic Oct 23 2012 at 20:06

> Вставлять свой js, который будет слать через POST данные прямо на сайт, где стоит счетчик может быть чревато конфликтами с другими скриптами

какими конфликтами чревато?

LZW-сжатие строк на javascript и распаковка средствами PHP

Comments 9

Articles