Я работаю со сторонней системой обработки платежей (Commidea.com), и одним из параметров, отправляемых вместе с результатом обработки, является поле «подпись». Это используется для предоставления хэша SHA1 результирующего сообщения, завернутого в зашифрованный конверт RSA, чтобы обеспечить как целостность, так и контроль подлинности. У меня есть API от Commidea, но он не дает сведений о кодировании и использует искусственно созданные подписи, полученные из строк Base64, для иллюстрации примеров.
Я изо всех сил пытаюсь понять, какая кодировка используется для этого параметра, и надеялся, что кто-нибудь сможет распознать довольно характерный шаблон. Сначала я подумал, что это UTF8, но, посмотрев на отдельные символы, я менее уверен.
Вот краткий пример содержимого, созданного с помощью следующего кода, в котором я перебираю каждый «байт» в строке:
sig = Request.Form("signature")
For x = 1 To LenB(sig)
s = s & AscB(MidB(sig,x,1)) & ","
Next
' Print s to a debug log file
Когда я смотрю в журнал, я получаю что-то вроде этого:
129,0,144,0,187,0,67,0,234,0,71,0,197,0,208,0,191,0,9,0,43,0,230,0,19,32,195,0,248,0,102,0,183,0,73,0,192,0,73,0,175,0,34,0,163,0,174,0,218,0,230,0,157,0,229,0,234,0,182,0,26,32,42,0,123,0,217,0,143,0,65,0,42,0,239,0,90,0,92,0,57,0,111,0,218,0,31,0,216,0,57,32,117,0,160,0,244,0,29,0,58,32,56,0,36,0,48,0,160,0,233,0,173,0,2,0,34,32,204,0,221,0,246,0,68,0,238,0,28,0,4,0,92,0,29,32,5,0,102,0,98,0,33,0,5,0,53,0,192,0,64,0,212,0,111,0,31,0,219,0,48,32,29,32,89,0,187,0,48,0,28,0,57,32,213,0,206,0,45,0,46,0,88,0,96,0,34,0,235,0,184,0,16,0,187,0,122,0,33,32,50,0,69,0,160,0,11,0,39,0,172,0,176,0,113,0,39,0,218,0,13,0,239,0,30,32,96,0,41,0,233,0,214,0,34,0,191,0,173,0,235,0,126,0,62,0,249,0,87,0,24,0,119,0,82,0
Обратите внимание, что любое другое значение равно нулю, за исключением случаев, когда оно равно 32 (0x20). Я знаком с UTF8, где он представляет символы выше 127, используя два байта, но если бы это была кодировка UTF8, я бы ожидал, что значение «32» будет больше похоже на 194 (0xC2) или (0xC3), а другое значение будет больше чем 0x80.
В конечном итоге я пытаюсь преобразовать этот параметр подписи в строку в шестнадцатеричном коде (например, «12ab0528...»), которая затем используется функцией RSA/SHA1 для проверки целостности сообщения. Эта часть уже работает, но я не могу понять, как расшифровать параметр подписи.
По историческим причинам нам приходится использовать классический ASP, а функции SHA1/RSA основаны на javascript.
Любая помощь приветствуется. С уважением, Крейг.
Обновление: пытался найти кодировку UTF-16 в Википедии и на других сайтах. Не могу найти ничего, чтобы объяснить, почему я вижу только 0x20 или 0x00 в (предполагаемых) позициях байтов старшего порядка. Я не думаю, что это больше актуально, так как в приведенном ниже примере показаны другие значения в этой позиции высокого порядка.
Попытался добавить некоторый код для регистрации значений с использованием Asc вместо AscB (Len, Mid вместо LenB, MidB тоже). Получил несколько удивительных результатов. Вот новый поток байтовых символов, за которым следует эквивалентный поток словесных (если вы понимаете, о чем я) символов.
21,0,83,1,214,0,201,0,88,0,172,0,98,0,182,0,43,0,103,0,88,0,103,0,34,33,88,0,254,0,173,0,188,0,44,0,66,0,120,1,246,0,64,0,47,0,110,0,160,0,84,0,4,0,201,0,176,0,251,0,166,0,211,0,67,0,115,0,209,0,53,0,12,0,243,0,6,0,78,0,106,0,250,0,19,0,204,0,235,0,28,0,243,0,165,0,94,0,60,0,82,0,82,0,172,32,248,0,220,2,176,0,141,0,239,0,34,33,47,0,61,0,72,0,248,0,230,0,191,0,219,0,61,0,105,0,246,0,3,0,57,32,54,0,34,33,127,0,224,0,17,0,224,0,76,0,51,0,91,0,210,0,35,0,89,0,178,0,235,0,161,0,114,0,195,0,119,0,69,0,32,32,188,0,82,0,237,0,183,0,220,0,83,1,10,0,94,0,239,0,187,0,178,0,19,0,168,0,211,0,110,0,101,0,233,0,83,0,75,0,218,0,4,0,241,0,58,0,170,0,168,0,82,0,61,0,35,0,184,0,240,0,117,0,76,0,32,0,247,0,74,0,64,0,163,0
А теперь пословный поток данных:
21,156,214,201,88,172,98,182,43,103,88,103,153,88,254,173,188,44,66,159,246,64,47,110,160,84,4,201,176,251,166,211,67,115,209,53,12,243,6,78,106,250,19,204,235,28,243,165,94,60,82,82,128,248,152,176,141,239,153,47,61,72,248,230,191,219,61,105,246,3,139,54,153,127,224,17,224,76,51,91,210,35,89,178,235,161,114,195,119,69,134,188,82,237,183,220,156,10,94,239,187,178,19,168,211,110,101,233,83,75,218,4,241,58,170,168,82,61,35,184,240,117,76,32,247,74,64,163
Обратите внимание, что вторая пара байтовых символов (83,1), по-видимому, интерпретируется как 156 в пословном потоке. Мы также видим (34,33) как 153 и (120,1) как 159 и (220,2) как 152. Дает ли это какие-то подсказки в качестве кодировки? Почему эти 15[2369] значений явно трактуются не так, как другие значения?
Я пытаюсь выяснить, следует ли мне использовать побайтовые данные и выполнять некоторую постобработку, чтобы вернуться к предполагаемым значениям, или мне следует доверять пословным данным с любым неявным декодированием, которое оно, по-видимому, выполняет. . На данный момент ни один из них не дает мне совпадения между содержанием данных и подписью, поэтому мне нужно что-то изменить.
Спасибо.
