Помогите определить схему многобайтовой кодировки символов на странице ASP Classic - PullRequest
1 голос
/ 16 ноября 2010

Я работаю в сторонней системе обработки платежей (Commidea.com), и одним из параметров, отправляемых вместе с результатом обработки, является поле "подпись".Это используется для предоставления хэша SHA1 сообщения результата, обернутого в зашифрованный конверт RSA, чтобы обеспечить контроль целостности и подлинности.У меня есть API от Commidea, но он не дает подробностей кодирования и использует искусственно созданные подписи, полученные из строк Base64, для иллюстрации примеров.

Я пытаюсь выяснить, какая кодировка используется для этого параметраи надеялся, что кто-то может распознать довольно характерную модель.Сначала я думал, что это UTF8, но, посмотрев на отдельные символы, я не уверен.

Вот краткий пример содержимого, созданного с помощью следующего кода, где я перебираю каждый «байт» вstring:

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] значений, по-видимому, обрабатываются иначе, чем другие значения?

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

Спасибо.

1 Ответ

1 голос
/ 16 ноября 2010

Быстрое наблюдение говорит мне, что вы, вероятно, имеете дело с UTF-16Начните оттуда.

...