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編碼的字符串

回答

相關問題