resin 小巧，快速，穩定，廣泛應用于工業強度的 web 應用。通常，大家認為是中文問題較少的一個 servlet container 。通常的解決辦法是這樣的，在 resin.conf 中加上：

<jsp PRecompile=´true´ static-encoding=´true´ recompile-on-error=´true´/>此外，在頁面上，要避免使用： <%@ page contentType="text/Html; charset=GBK"%> 指定字符集

應該說，這個配置能解決大部分的中文顯示問題(能解決問題，但并非真正解決了問題，細節容后再敘)。直到前不久，因為在項目中應用一個 mvc 框架，中文問題才再次不可調和的浮現出來。深入代碼，發現 resin 在處理中文時，其實是存在問題的。

我們來看一下“static-encoding=´true´”和“不作字符集指定”是如何讓中文正常顯示的。在 WEB-INF 的 work 目錄下，通常可以找到 resin 根據 jsp 生成的 java 代碼。JSP中的字符串："中文"，在生成 java 文件的時候，這個字符串的轉換會有這么幾種情況：

static-encoding=´false´ (缺省值)(設置字符集沒有影響)

_jsp_string1 = "/u00D6/u00D0/u00CE/u00C4".toCharArray();

static-encoding=´true´ (不設置字符集)

_jsp_string1 = "/u00D6/u00D0/u00CE/u00C4".getBytes();

static-encoding=´true´ (設置字符集GBK)

_jsp_string1 = "/u00D6/u00D0/u00CE/u00C4".getBytes("GBK");

我們知道，字符串"中文"在正確的轉換應該是"/u4e2d/u6587"長度為2(可以運行native2ascii 輸入"中文" 進行檢查)，在JSP處理的第一個環節，上面各種情況下生成的 Java 代碼，"中文"字符串都是被錯誤轉換的。也就是說，在 jsp 被轉換成為 java 文件的時候，出現了編碼錯誤。那么為什么，在“static-encoding=´true´ (不設置字符集)”的情況下，它能正常顯示呢？

在“static-encoding=´true´ (不設置字符集)”的情況下，采用默認的ISO-8859-1編碼方式，兩個雙字節編碼的GBK中文字符被當作四個字節處理，必須注重到，此時，一個中文字符被拆為兩個“字節字符”來處理，字符串的長度是錯誤的。在顯示的時候，按照默認的ISO-8859-1方式編碼返回給瀏覽器。此時，單字節流被瀏覽器自動識別，認出是GBK格式，從而可以正常顯示。也就是說，此時的正常顯示實際上是利用了ISO-8859-1和UNICODE相互轉換時按單字節處理的特點(不進行轉碼處理)，將錯就錯的實現了中文的正常顯示。

我們定位了問題，是在 jsp 被轉換成為 java 文件的時候出現了編碼錯誤。那么如何使JSP中的中文能正確的生成java文件？我跟蹤了 resin 的源代碼，找到了一個可行，但也許不是最好的解決辦法。

JspParser.java of resin-2.1.10

///// added by jackyz private static String sysEncoding = System.getProperty("file.encoding"); Page parse(Path path, String uri, String className, String uripwd, CaUChoRequest req, Cauchoapplication app) throws Exception { ReadStream stream = path.openRead(); ///// added by jackyz stream.setEncoding(sysEncoding); try { return parse(stream, uri, className, uriPwd, path.getParent(), req, app); } catch (FileNotFoundException e) { throw e; } catch (IOException e) { if (path.isDirectory()) throw new FileNotFoundException(path.toString()); else throw e; } finally { stream.close(); } }