Question

问题：我有一个.NET HTTP Handler接受XML的HTTP POST，我相信它来自Java系统。一个元素包含base64字符串编码文档（当前测试文件是PDF）。当我从原始PDF获取并从.NET生成base64字符串时，它与提供的XML中的相应文本之间存在一些差异。

有很多地方出现以下三种情况之一：

XML文件放置一个.NET放置加号的空间
同样，XML文件插入了一对连续的空格，而不是.NET的<+ p>
PgplbmRv YmoKNSAw与PgplbmRv++YmoKNSAw
有时XML文件插入了一对连续的空格，而和在XML的版本附近添加了和附加空格

3kuPs 85QZWYaw BsMNals与3kuPs 85QZWYaw++BsMNals
源XML将有四个空格（下面显示为2个空格），而.NET有一对连续的加号

vGDmKEJ gnJeOK与vGDmKEJ++gnJeOK

此外，源（Java创建？）数据中没有加分。

问题：有人可以帮助确定导致这些差异的原因吗？最紧迫的是我如何解决它们，因为我无法看到可靠的模式来搜索和替换它？

编辑：当POST到达时，它会在反序列化为对象之前进行URL解码。

public void ProcessRequest(HttpContext context)
{
    try
    {
        StreamReader reader = new StreamReader(context.Request.InputStream);
        context.Response.ContentType = "text/plain";
        var decodedRequest = HttpUtility.UrlDecode(reader.ReadToEnd());
        ...

Answer 1

可能通过一些URLDecoding将加号转换为空格，其中空格由加号表示。实际的base64编码结果中不应该有任何空格;空格是一个无效的字符。也许简单的搜索和替换可以纠正这一点，但您可能想要确定您的结果是如何被URLDecoded。

Answer 2

有两个问题。

URL解码将现有的内容翻译成空格。
POSTing Java代码强制使用MIME标准76个字符的行长。

URL解码还将行尾的CRLF转换为双倍空格。 CRLF还导致文件长度膨胀，导致需要重新考虑填充等号。以下代码剥离填充（并稍后重新计算和追加），将空格返回到加号并删除那些作为CRLF占位符。

// convert spaces to pluses and trim base64 spacers
char[] charDoc = doc.CONTENT.Replace(' ', '+').TrimEnd(new char[] {'='}).ToCharArray();

StringBuilder docBuilder = new StringBuilder();
for (int index = 0; index < charDoc.Length; index++)
{
    if ((index % 78 == 76) && (index < charDoc.Length - 1) && charDoc[index]  == '+' && charDoc[index + 1] == '+' )
    {
        index++;
        continue;
    }
    docBuilder.Append(charDoc[index]);
}
// Add padding, if needed--replicates 0-2 equals
docBuilder.Append(new string('=', (4 - docBuilder.Length % 4)%4));

Java Base64编码的字符串与.NET Base64编码的字符串

2 个答案: