nighty

    在項目中剛好有一個地方需要在服務器端處理一個請求后，重定向到另一個Action，這樣瀏覽器的url才會變成另一個url，用戶重新刷新時，才不會彈出一個對話框問你是不是要重新提交form。于是就自然而然地用了redirectAction。大概如下：
   

1<result name="myInfoSuccess" type="redirectAction">
2    myapp_myInfo.action?msg=${msg}
3</result>

    因為重定義會丟失所有的請求參數(shù)和值棧，所以這里轉向時，加了一個請求參數(shù)msg，msg在要重定向的action中設置。
    問題來了，重定向到myapp_myInfo.action時，這個Action里面取出msg參數(shù)時變成亂碼！！！ 不論中文或是英語還是數(shù)字，全是亂碼，折騰了一翻，URLEncoder、URLDEncoder進行URL Base64編碼和解碼處理，包括new String(msg.getBtye("ISO-8859-1"), "UTF-8")這種處理方式仍無法奏效。google了一下并且抱起書本認真看了看struts2重定向問題后。大概有了個思路。
    所有的重定向操作都會丟失所有的請求參數(shù)、請求屬性等，當然包括Action的處理結果也會丟失。 
    首先搞清楚redirect、redirectAction的區(qū)別：
    1. redirect類型struts2是調用HttpServletResponse的sendRedirect(String)方法來重定向到指定的資源，可以是一個視圖結果，也可以是其它類型的Action；
    2. redirectAction同樣是重新生成一個全新的請求。但是struts2內部卻是使用ActionMapperFactory提供的ActionMapper來重定向，它只能跳轉到另外一個Action；
         由于redirectAction使用的是ActionMapper來重定向，也就同時使用ActionMapper的編碼方式重新進行編碼，這就導致了后面在取出參數(shù)時變成亂碼，沒有具體閱讀它的源代碼，但是多次不同的編碼再想重新還原出來就有點麻煩了。而redirect是使用HttpServletResponse來重定向，就不存在上面的問題。最后改為redirect來重定向，結果如下：
        注意：在myapp_myInfo.action對應的Action必須對msg參數(shù)做一次轉碼，因為前面的Action過來時就做了URL base64編碼，如果直接發(fā)給瀏覽器，就會在瀏覽器看到一串帶%的URL base64編碼字符，所以要加上
       把它設置回為中文，瀏覽器才能正常。

       還得提到另一個重定向類型chain，它是Action鏈，還能維持當前的值棧不變。不過用它重定向后，雖然跳到其它Action，但是在瀏覽器端的URL是不會變化的，這樣開頭提到的那個問題仍是無法解決的！

剛進場的時候戲就落幕