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

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

有一些地方的三件事情之一发生：

XML文件的地方，.NET放置一个加
同样一个空间，XML文件具有对连续空间插入与.NET的组件加起来

PgplbmRv YmoKNSAw与PgplbmRv++YmoKNSAw
有时XML文件中有对连续空间的我nserted与.NET的组件加起来和额外的空间附近中添加了XML的版本

3kuPs 85QZWYaw BsMNals与3kuPs 85QZWYaw++BsMNals
源XML将有四个空格（下面显示的样子2位）与.NET的有一对连续的加分的

vGDmKEJ gnJeOKvGDmKEJ++gnJeOK与

而且，存在于T号加分他来源（Java创建的？）数据。

问题：有人可以帮助确定会导致这些差异可能是什么？最迫切的是我如何解决这些问题，因为我看不到一个可靠的模式来寻找和替代？

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

来源

2013-05-13 John Spiegel

这些数据是否以URL参数传输？ – Oded 2013-05-13 17:05:59

我不这么认为，但在这一点上没有确切的答案。这些通常是相当大的文档，会超过我认为查询字符串强加的字符限制（我认为首先使用POST的部分原因）。 – 2013-05-13 18:53:22

URL解码是混淆的一部分。它看起来像双加号也是由76个字符的行限制和CRLF被转换为加号引入。 – 2013-05-14 14:35:35

有两个问题。

URL解码翻译现有的加号到空格。
POSTing Java代码强制MIME标准76字符行长度。

URL解码还将行尾的CRLF翻译为双倍空格。 CRLFs也导致文档长度膨胀，导致需要重新考虑填充等号。以下代码条填充（并在稍后重新计算和追加），将空格返回给加号并删除那些为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));

来源

2013-05-14 16:08:54

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

来源

2013-05-13 17:11:08 klugerama

感谢您的回复。 S＆R将无法工作，因为它不可预测。有一些空间不符合加号。我会看看我在为URL解码部分做些什么。 – 2013-05-13 18:50:39

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

回答

相关问题