如：
<%
String ss = (String) session.getAttribute("username");
if (ss == null || ss == "") {
out.print("<script>alert('非法操作，你想幹嘛！');window.location.href='index.jsp';</script>");
return;
}
%>
如果把上面的代碼直接作爲一個.jsp文件的話，在導入的時候，會發現出現中文亂碼！即使文件的編碼保存格式爲utf-8也會亂碼的，我猜tomcat會以ISO-8859-1的編碼把這個.jsp編入要使用這個文件的另一個jsp文件中，但直接在另一個jsp頁面使用如上代碼就沒問題。
解決方法：
頭部加上<%@ page pageEncoding="utf-8"%>
所以說，<%@ include%>指令也不是完全等同於在jsp頁面裏直接使用代碼，<%@ include%>的文件也要指明編碼才得的！
參考：
JSP要經過兩次的“編碼”，第一階段會用pageEncoding
，第二階段會用utf-8至utf-8，第三階段就是在客戶端瀏覽器裏看到的網頁， 用的是contentType。
第一階段是jsp編譯成.java，它會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8 JAVA源碼（即.java），如果pageEncoding設定錯了，或沒有設定，出來的就是中文亂碼。
第二階段是由JAVAC的JAVA源碼至java byteCode的編譯，不論JSP編寫時候用的是什麼編碼方案，經過這個階段的結果全部是UTF-8的encoding的java源碼。
JAVAC用UTF-8的encoding讀取java源碼，編譯成UTF-8 encoding的二進制碼（即.class），這是JVM對常數字串在二進制碼（java encoding）內表達的規範。
第三階段是Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼，輸出的結果，也就是在客戶端見到的，這時隱藏在階段一和階段二的參數contentType就發揮了功效
而include指令就是在第一階段之前執行的,注意這個是在第一階段之前,所以,如果包含文件和被包含文件的文件編碼不是utf-8,那麼,該指令就會工作不太正常,不能正確的把被包含的文件從原來編碼轉換爲包含文件的編碼,就會出現亂碼現象.