Альтернатива строке запроса и файлам cookie при отправке данных на сервер?

Существует несколько плагинов кодирования Base64 для jQuery, но это не так. Помогите, потому что Base64 обычно делает данные длиннее, а не короче.

В зависимости от данных я бы рассмотрел некоторые другие методы сжатия текста. Википедия перечисляет несколько:

• Метод взвешивания контекстного дерева (CTW)
• Преобразование Берроуза-Уилера (предварительная обработка блочной сортировки, которая делает сжатие более эффективным)
• LZ77 (используется DEFLATE)
• ЛЗВ

Вот реализация LZW для Javascript.

Кодировка Хаффмана основана на частоте букв, поэтому она может не подходить для ваших данных. Вам, вероятно, придется экранировать результат, чтобы сделать его безопасным для URL.

Помимо перехода на POST, ваши возможности будут ограничены. Base64 будет увеличивать размер данных, а не уменьшать его. Вы упомянули сжатие данных в один элемент строки запроса... может быть, вместо этого вы могли бы разделить данные на 2 отдельных запроса, используя Ajax? Я не уверен, что это возможно для вашей ситуации.

Я бы предложил использовать JSON в качестве формата передачи данных, если массив, подобный строке запроса, генерируется следующим образом:

params[]=sth&params[]=sth2&params[]=sth3

Это было бы

{params:['sth1', 'sth2', 'sth3']}

Вы можете назначить эту строку JSON однобуквенной переменной, как показано ниже.

p={params:['sth1', 'sth2', 'sth3']}

Еще лучше было бы сжать и закодировать в Base64 всю строку запроса. Поскольку вы генерируете строку запроса на стороне сервера (я предполагаю, что то же самое можно сделать в JS, используя те же алгоритмы компоновки/декомпрессии), вы можете использовать любой встроенный алгоритм сжатия с вашим языком программирования, например gzip. После того, как Base64 кодирует сжатые данные, да, они немного расширятся, но не так сильно, как кодирование URL-адресов.

Я бы не стал слишком полагаться на javascript. Сжатие строки запроса было бы первым естественным действием; но если вы намного опережаете эти пределы, вам следует попробовать поддерживать сеансы. Вы начинаете заново с информацией о состоянии по умолчанию, затем постепенно отражаете состояние на сервере в сеансе пользователя с предоставленными данными POST, поэтому вы разделяете все эти данные на множество обработчиков (страниц чтения).

Ответ из учебника - использовать POST. Почему это невозможно? Причина, по которой был изобретен POST, заключалась в том, чтобы обойти ограничения длины в GET.

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

Ограничение строки запроса на клиенте или сервере?

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

Это для хранения информации о состоянии между страницами? Если это так, можно использовать файл cookie со значением GUID как таковым:

_SESSIONID=3F2504E0-4F89-11D3-9A0C-0305E82C3301

И сохраните информацию о сеансе на стороне сервера. Сеанс однозначно идентифицируется с помощью GUID, поэтому можно легко получить большой объем информации непосредственно на сервере.

Затем все, что вам нужно для отправки/получения на стороне клиента, — это идентификатор сеанса, а также сгенерированная клиентом информация (поля GET/POST).