То же самое и здесь: csharp, проверяющий входящий XML-файл со знаком SAML, полученный как XML-строка в кодировке base64, но созданный из него XML-документ будет выводить еще несколько байтов.Оказалось, что это были не только дополнительные пробелы для самозакрывающихся элементов, вставленных в вывод .net, но и использование «\ r \ n» для перевода строки, где исходная входная строка содержала только «\ n».
Итак, теперь я проверяю строку ввода для этих функций (самозакрывающийся элемент без предшествующего пробела? Только "\ n" для перевода строки?), А затем на протяжении всего процесса проверки подписанного xml (значение дайджеста, подпись) я проверяючто любой промежуточный XML-документ будет создан из строки, подготовленной таким же образом с помощью [xmlString] .Replace ("/>", "/>") и / или [xmlString] .Replace ("\ r \ n""\ n").Это действительно имеет значение, так что, очевидно, документ .net xml внутренне придерживается исходной строки ввода, с которой он был создан.
Однако есть одно исключение: есть также случай, когда я получаю строку xmlбез лишних пробелов для самозакрывающихся элементов, но с полной последовательностью перевода строки "\ r \ n".Однако, следуя упомянутой выше процедуре - [xmlString] .Replace ("/>", "/>") - я не могу скопировать SignatureValue и DigestValue в xml;однако, если в этой ситуации я также заменяю последовательность перевода строки - [xmlString] .Replace ("\ r \ n", "\ n") - я получаю правильные значения.Очевидно, что в этой ситуации SignatureValue и DigestValue сначала вычисляются только с "\ n" в качестве перевода строки, а затем - когда документ XML был закодирован в Base64 - использовалась строка, содержащая "\ r \ n".
ДляВ целях проверки, в конце концов, кажется, имеет значение только разница в последовательностях перевода строки, потому что дополнительные пробелы для самозакрывающихся элементов исчезнут после канонизации (когда введены явные закрывающие теги), которая обычно предшествует вычислению DigestValue и SignatureValue.