Я немного из зоны комфорта здесь, поэтому я даже не уверен, что я правильно подхожу к проблеме. Во всяком случае, здесь идет:Urlencode/decode, другое представление той же строки
Так что у меня есть проблема, когда я буду размещать некоторую информацию с sha1, которая будет работать как идентификатор этой информации.
Когда клиент хочет сообщить, какая текущая информация используется, он отправляет строку sha1, закодированную в процентах.
Так один пример, мой сервер хэши некоторую информацию и получает шестнадцатиричное представление, как так:
44 c1 b1 0d 6a de ce 01 09 fd 27 bc 81 7f 0e 90 e3 b7 93 08
и клиент посылает мне
D%c1%b1%0dj%de%ce%01%09%fd%27%bc%81%7f%0e%90%e3%b7%93%08
Удаление% мы получаем
D c1 b1 0dj de ce 01 09 fd 27 bc 81 7f 0e 90 e3 b7 93 08
, который соответствует моему хешу, за исключением начала D и j после 0d, но заменяя их их ascii hex no, у нас одинаковый хеш.
Итак, поскольку я прочитал и понял urlencoding, стандарт позволит клиенту отправить D как D или% 44? Таким образом, разные клиенты могли бы отправлять разные представления из одного и того же хэша, и я не смогу просто сравнить их для равенства?
Я бы предпочел иметь возможность сравнивать строки с urlencoded, как они есть, когда они отправлены, но один способ сделать это - это их декодировать, удалив все «%» и получив шестнадцатеричное значение ascii для любого несоответствия I получить, как D и j в моем примере выше.
Это, кажется, очень раздражающий способ сделать что-то, я что-то упустил, пожалуйста, скажите мне, что я? :)
Я делаю это в node.js, но я полагаю, что решение было бы агностиком языка/платформы.
Почему клиент отправляет хэш SHA1, как то, что вместо буквального «44c1b10d6adece0109fd27bc817f0e90e3b79308»? Вы контролируете, что клиент отправляет? – mscdex
Не контролирует клиента, и есть несколько клиентов, которые, насколько мне известно, могут отправлять разные представления одного и того же хеша. Клиенты, о которых идет речь, являются торрент-клиентами, если это имеет значение. – Pengtuzi