бинарный формат

[antson]

https://ru.wikipedia.org/wiki/Алгоритм_Лемпеля_—_Зива_—_Велча

LZW основа всех архиваторов.
пусть в тексте 50% - A , 25% -Б , 25% -В тогда А - 0, Б -10, В - 11.
ААААБАААВ - 00001000011 сжали до 2х байт

В прайсе у нас обычно
наименование
цена
единица измерения
валюта
кол-во

цена обычно децимал 10.2 т.е. нет выигрыша от перевода ее из текстового вида.
валюту и единицы измерения можно закодировать через справочник. по 2 байта .

 

[antson]

один байт можно выиграть на цене , если передавать ее в копейках

 

[antson]

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

 

[grigori]

@antson, спасибо. то есть надо будет алгоритм разархивирования реализовать на javascript и померять. на webworker-ах, соответственно, чтобы не подвисало окно приложения.
нетривиальная такая задачка

 

[MiksIr]

Ага, если хочется свой gzip изобрести.

 

[grigori]

да, не успею такое реализовать - подготовлю данные для сжатия gzip-ом, уберу лишнее, а распаковку доверю браузеру

 

[antson]

@grigori, для надежности я бы добавил еще один небольшой оверхед.
фиксацию конца строки например еще один chr(0)
chr(0).chr(0) - можно будет использовать для разделения по строкам.

 

[fixxxer]

Не убирает накладные на имена полей

Решается укладыванием в обычные массивы с числовыми ключами и тасканием id-шника структуры (если их бывает несколько). Правда, так получается почти protobuf

 

[fixxxer]

https://ru.wikipedia.org/wiki/Алгоритм_Лемпеля_—_Зива_—_Велча

Для текстов эффективнее может оказаться BWT+Huffman (используется, например, в bzip2).

 

[fixxxer]

Но вообще для текстовых данных мне эта затея кажется бессмысленной. Json+gzip даст примерно то же, по идее.

Я msgpack (с обычными массивами и номером структуры) использовал для компактного обмена кучей int-ов, прямо через url в base64. Можно было бы и protobuf, конечно, но NIH же.

 

[antson]

@grigori, жалко нельзя вместо utf-8 использовать cp-1251 ;( сразу бы в 3 раза выиграли . Ну или хотя бы в 2 .

 

[AnrDaemon]

UTF-8 на самом деле неплохо жмётся, если большинство символов в строке из одного языка.

 

[grigori]

@antson, тоже о таком же думал -- /0 разделитель, /0/0 - конец записи

 

[grigori]

@AnrDaemon, да, все на одном языке

 

[fixxxer]

@grigori, у тебя зиг хайль неправильный! \0\0

 

[AnrDaemon]

@antson, тоже о таком же думал -- /0 разделитель, /0/0 - конец записи

Привет REG_MULTI_SZ \o/

 

[antson]

в общем, если сформированный файл прогоняется через gzip оптимизировать что-то еще нет смысла, все остальные повторы, он сам лучше пожмет, чем если мы будем извращаться.
Да про конец файла или число записей в нем забыли. В шапку на первую строку кол-во или в конце 6 нулей.

 

[grigori]

В http-заголовке ответа Content-size, конечно, передается.
Обеспечивают ли gzip и ssl-туннель консистентность данных в передаваемом файле?
То есть, можно ли потерять данные, чтобы браузер этого не заметил, не перезапросил, и не вернул ошибку соединения в XHR?

Если потеряется tcp-пакет по сети - tls-протокол заметит и повторит.
Если nginx отдаст не весь файл - теоретически, должена быть ошибка распаковки в браузере, к тому же, браузер должен заметить несовпадение Content-size, но я не проверял.
Остается риск, что gzip некорректно сожмет или распакует - тут можно только sha-256 считать. У меня не critical data, попробую забить.

Браузер отдает в JS данные ответа XHR целиком, после успешной распаковки gzip, или нет?

 

[fixxxer]

Браузер отдает в JS данные ответа XHR целиком, после успешной распаковки gzip, или нет?

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/readyState

С новомодными fetch() не проверял.

 

[AnrDaemon]

SSL тоннель обеспечивает целостность неявно. При повреждении соединение разрушается.
gzip так же обеспечивает проверку целостности неявно, но в зависимости от реализации клиента, можно получить обрезанный контент.
Если клиент поддерживает message checksumming https://tools.ietf.org/html/rfc3230 , можно обеспечивать явную проверку целостности.