從Javascript到C＃編碼和解碼字符串 - 不工作

我遇到了一些字符串編碼問題，也許它是一個iis問題，或者我忽略了一些問題。基本上，隨機地，當用戶提交更改時，文本將與％20一起存儲，就好像它完全忽略了我的解碼。它從來沒有發生在我本地主機，現場或任何瀏覽器上;它永遠不會一致，甚至不知道如何測試發生了什麼問題。從Javascript到C＃編碼和解碼字符串 - 不工作

只是要粘貼基本部分：

文本控制接受用戶輸入

<asp:TextBox TextMode="MultiLine" runat="server" txtActionUpdate"></asp:TextBox>

然後

的Javascript 「逃逸」，並通過對AJAX方法被髮送到代碼隱藏

var tAction = escape(document.getElementById("txtActionUpdate").value);

然後

在的webmethod我解碼與執行以下操作：

Test = Microsoft.JScript.GlobalObject.unescape(tAction);

（以前是：測試= HttpUtility.UrlDecode（tAction）;）

但無一不是這兩個解碼選項上面的工作完美（對我？）。但隨機地，當用戶正在處理它時，它會逐字地「跳過」解碼步驟，並將其以編碼格式（即：this％20is％20a％20Test％20string）寫入數據庫，就好像我從來沒有代碼。

我們有多個客戶（單獨的URL），但有一個代碼庫。在發佈期間，我先刪除然後發佈，清除應用程序池，讓用戶清除瀏覽器緩存（實際上討厭後者），但這似乎從未保持一致。我有一種感覺，這是更多的「緩存」或「服務器設置」的問題，而不是代碼問題......讓我看起來不好！ ;）大聲笑。任何人都有一些預感？

來源

2012-04-19 Marthinus Elliott

沒有看到更多的代碼，它可能不可能提供幫助。 – Pointy 2012-04-19 13:05:48

我不會使用escape這個（或其他）。我會使用encodeURIComponent，然後用HttpUtility.UrlDecode解碼（我認爲，顯然，MSDN現在正在運行）。

來源

2012-04-19 13:09:02

我唯一改變的部分是解碼方法背後的代碼。因爲我認爲它很好，所以總是離開'逃生'。看到不少論壇提及避免「逃避」，因爲接收服務器可能無法「理解」某些字符。我會嘗試你的建議;我以前見過它，只是總是認爲它更適合URL，因爲它只是純文本（包括/ \ * +等）。好極了！ ;） – 2012-04-19 13:18:01

我的猜測是，在客戶端的某個地方數據編碼了兩次，然後導致你看到的效果。

來源

2012-04-19 13:13:22 Lucero

這是一個非常好的想法。 – 2012-04-19 14:11:36

從Javascript到C＃編碼和解碼字符串 - 不工作

回答

相關問題