Десериализация из CRC сумм

Если у тебя есть только CRC, то расшифровать ты обратно не можешь, потому что CRC это контрольная сумма, а не какое-либо шифрование.
Т.е. допустим можно с гигабайта данных получить CRC32 и она будет занимать 32 бита.

Кроме CRC других данных не приходит?

Сейчас пример приведу из тамошнего мана.

В принципе известны еще число параметров, их типы то есть размер и смещения относительно начала посылки.

бинарно сериализовываться путем вычисления соответствующих им CRC

А почему не сразу «путем симпилляции диструбных гентронов»? Смысла примерно столько же.

А я тут при чем? Мопед же не мой.

http://dev.stel.com/mtproto/serialize

Я о том, что «сериализация путем вычисления ЦРЦ» это какая-то кривая формулировка. Или так в самом деле принято?
Вопрос «как перевести в человеческий вид значения этих параметров?» остается непонятным. Значения же тупо передаются «как есть», зачем их куда либо «переводить»? Ну то есть не совсем «как есть», но описание передачи значений базовых типов есть по твоей ссылке.

Типа я получу строку 0xC001 0xDE16 0x1113 0x1010, а означать она должна first_name: «Pupkin» last_name: «Vasya»

Вспомнилось, как на некой планете получили цифру 42, а означала она ответ на вопрос жизни, вселенной и всего такого.

Типа я получу строку 0xC001 0xDE16 0x1113 0x1010, а означать она должна first_name: «Pupkin» last_name: «Vasya»

При преобразовании строки в хэш информация теряется. Её неоткуда восстановить. Задача в общем виде нерешаема. Есть частное решение в виде перебора всех возможных значений исходной строки и сравнения полученного хэша с принятым.

http://dev.stel.com/mtproto/TL

Пример RPC-запроса

Предположим, мы хотим запросить getUsers([2,3,4]). Этот запрос будет сериализован следующим образом:

0x2d84d5f5 0x1cb5c415 0x3 0x2 0x3 0x4

Ответ на него может выглядеть примерно так:

0x1cb5c415 0x3 0xd23c81a3 0x2 0x76615005 0x6c65 0x72754405 0x766f 0xc67599d1 0x3 0xd23c81a3 0x4 0x6b694e07 0x79616c6f 0x72754405 0x766f

Это примерно соответствует

[{«id»:2,«first_name»:«Peter», «last_name»:«Parker»},{},{«id»:4,«first_name»:«John»,«last_name»:«Doe»}]

Обратите внимание, что в обоих случаях используется один и тот же универсальный конструктор vector#1cb5c415, в запросе для сериализации значения типа Vector int, в ответе — типа Vector User. Путаницы не происходит, так как в обоих случаях тип (де)сериализуемого значения известен до начала его десериализации. Например, сервер, получив запрос, видит, что первая его компонента — это 0x2d84d5f5, что соответствует комбинатору getUsers#2d84d5f5 (Vector int) = Vector User, поэтому понятно, что дальше будет следовать значение именно типа Vector int. Клиент же, получив ответ на этот запрос, знает, что ему должны вернуть значение типа Vector User, и десериализует его соответственно.

ключевая фраза:

Путаницы не происходит, так как в обоих случаях тип (де)сериализуемого значения известен до начала его десериализации.