一種基于J2EE的WEB系統的國際化方案設計

中國長江三峽集團公司 李 哲 羅惠恒 周 容

1 引言

軟件國際化（Inter nat ional ization, 又稱I18N），是指在軟件設計和文檔開發過程中，為了代碼設計與功能實現能處理多種語言和文化習俗，從而創建不同語言版本時，不需要重新設計原程序代碼的軟件工程方法。

軟件本地化（Local izat ion，又稱L10N），是指將一個軟件產品按特定國家/地區或語言市場的需要進行加工，使之滿足特定市場上的用戶對語言和文化的特殊要求的軟件生成活動。即針對某一地域所支持的編碼字符集、語言和地域習慣為軟件建立符合本地要求的信息的過程[1]。

主流的J2EE的表現層框架如Spr ing MVC、St r ut s等對國際化或多或少有相應的解決方案。但上述方案并不能適配所有場景，隨著RESTFUL風格的興起，越來越多的數據展示和格式化工作直接交給了前端模板或組件，這需要客戶端Javascr ipt(簡稱JS)腳本國際化的支持。本文介紹了一種針對基于J2EE三層架構[2]WEB項目的多語言解決方案，有效解決了國際化過程中的相關問題。

2 國際化的背景及過程

多語言的網站根據語言的組織方式可以分為有如下的兩種構成類型：

(1)單站點類型。不同語言的網站作為一個站點，然后采用各種手段實現頁面的多語言。利用如第三方插件翻譯、針對不同語言頁面分目錄、動態內容產生[3]等方式實現國際化。

(2)多站點類型。不同語言的網站作為多個站點，保存在不同的服務器。服務器之間不存在任何聯系，即一系列內容相關的網站集合。

采用單站點模式[4]可以有效減少不必要的服務器開銷、降低開發及維護成本適用于大多數企業的信息系統建設。由于界面的風格以及展示的功能相對固定，翻譯的精細化程度相對較高，采用動態內容產生作的手段可以在保證功能的前提下，有效減少開發前端代碼的工作量。

動態內容產生模式進行國際化主要包含兩個步驟：一是對語言的解析，二是根據所解析的語言進行本地化內容填充。下面以基于J2EE的三層架構的WEB系統為例對其流程進行說明：

服務器在接收到請求后首先進行語言解析，依據請求中包含的參數確定出響應頁面的語言種類。然后依據所解析的語言種類，在不同層次完成國際化的工作。

一部分UI頁面直接在表現層的對模板(JSP)進行編譯時完成；一部分UI頁面通過JS、CSS在客戶端瀏覽器渲染時完成。

3 國際化方案的設計

3.1 語言解析規則的設計

由于JS對于國際化的支持相對Java較弱，所以擬將語言解析放在服務器端完成。J2SE中用地區（l ocal e）的概念代表用戶選擇的顯示語言以及日期、時間、貨幣等方面的格式化約定，這里選擇將該值作為解析的結果。

通常基于MVC的表現層框架都提供了幾種默認的地區解析器。例如在Spr ing MVC中,通過攔截器的方式配置地區解析器，默認通過HTTP請求頭部解析區域acceptl anguage設置l ocal e。對語言解析的方式可以通過配置id為l ocal eResol ver的bean對象進行修改，實現方式包括：根據session解析、根據cookie解析、固定地區等，當有特殊要求時也可通過自定義方式實現。

圖1 語言參數解析流程圖

在根據session解析的方式中，標識語言的參數作為session的一個屬性保存。該參數會隨著會話的結束而丟失。在根據cookie解析的方式中，標識語言的參數會在cookie中長期保存更加符合現實中的應用場景。對于沒有采用MVC框架的表現層，可以借鑒框架的結構自定義過濾器（f il ter）來完成對語言的解析工作。

如圖1所示，解析完成后，表現層的控制器可以獲取該值，并將其關聯到對應線程的上下文中傳遞給業務邏輯層進而完成業務動態數據國際化。

為了實現主動切換語言的功能，需要提供一個服務直接修改地區判據。具體實現可以通過一個控制器修改cookie中的參數。

3.2 服務器端的國際化設計

服務器端的國際化包含兩個方面：消息等靜態數據的國際化和動態數據的國際化。

基于MVC的表現層框架通常對J2EE中的消息機制進行了加強，已經實現在解析出l ocal e對象后自動加載對應語言名稱后綴的消息配置文件的功能。控制器根據請求參數調用不同的視圖（JSP）和模型組合并成返回的UI頁面。視圖中的消息預先定義在不同語言的消息配置文件中，依據l ocal e調用不同的消息配置文件，將其填充進UI頁面。

對于沒有采用MVC框架的項目，同樣可以利用JTSL的消息機制，但須自行完成不同種語言的標簽庫的加載工作。這里可以通過將這一部分工作直接放在語言解析過濾器中實現，通過代碼：Conf ig.set(r equest, Conf ig.FMT_LOCALE,l ocal e)修改JSTL的配置對象Conf ig即可。

動態數據的國際化較為復雜，依賴于業務邏輯層將語言作為參數進行處理。一般需要對數據訪問層以及數據庫層進行修改。常見的方案是根據語言參數在關系數據庫中按照單表或分表方式對不同語言的數據進行存儲，可以采用基于AOP的動態數據國際化方案[5]實現。

3.3 客戶端的國際化設計

在瀏覽器進行頁面渲染時，JS控件、前端模板(EJS)等對所展示數據進行內容填充、格式化時需要完成國際化操作。

通用的JS控件一般都包含獨立的本地化文件，采用多個文件分散管理標簽的方式雖然簡單，但是沒有達到與后臺標簽的統一管理的目的。因此，可以選擇采用在前端實現通用的標簽加載器的方式進行改進并達到上述目的，如圖2所示。

圖2 i18n標簽加載器的工作流程

由于語言的解析工作已在服務器端完成，頁面在加載時僅需根據l ocal e參數向服務器請求不同的JS、CSS文件。在開始渲染之前，利用一個通用的i18n標簽加載器發出Aj ax請求從服務器端獲取對應l ocal e的標簽文件(.pr oper t ies)，并按照各個UI控件的需求由i18n加載器轉換為特定的JS對象供UI組件使用。

此外對于貨幣、時間等信息的國際化，一部分利用JSTL標簽在服務器端處理，還有一部分必須在前端完成處理的利用For mat Js、Moment Js等通用格式化組件進行。

3.4 標簽維護方案的設計

由于本方案采用唯一的配置文件管理頁面上幾乎所有的靜態標簽（消息），配置文件的體積會隨著系統的增大而不斷擴大，不利于提高運行和維護的效率。為了解決上述問題，需要建立通用的標簽命名規則和標簽控制界面。

擬采用統一的命名方式: <應用名>_<標簽類型>_<標簽名稱>。企業內部根據系統名稱確定唯一的<應用名>，<標簽類型>分為m（message/消息）和l（l abel/標簽），<標簽名稱>盡量采用標簽顯示值得英文單詞駝峰形式（可根據情況選取縮寫）。

為了減少標簽的數量，規定m類型標簽區分大小寫，l類型不區分。對l類型的標簽的格式化通過設置CSS3的t ext-t r ansf or m或者JS函數進行。

建另外，需要立統一的標簽管理頁面，并采用如spr ing中提供的動態加載資源文件的模式（Rel oadabl eR esour ceBundl eMessageSour ce）加載消息配置文件。后期用戶如果對WEB界面上的任意標簽值不滿意，可以通過的標簽管理界面查詢標簽并修改，并且能夠實時地看到效果，避免用戶直接接觸到配置文件。

4 結語

本文通過對現有國際化方案的比較和分析，針對企業基于J2EE三層結構的信息系統設計了一整套國際化方案，并提出利用統一的資源文件管理前后端標簽，并創建標簽管理頁面進行后續維護。該方案已在公司內部的信息系統項目中得到驗證。

[1]董俊龍,王武魁.淺議基于JSF的Java國際化編程及其實現[J].微計算機信息,2009,25:170-171.

[2]陸榮幸,郁洲,阮永良,等.J2EE平臺上MVC設計模式的研究與實現[J].計算機應用研究,2003,20:144-146.

[3]周中雨,呂琳琳.J2EE平臺下WEB應用國際化的研究與實現[J].計算機系統應用,2006,09(9):69-71.

[4]張菲菲,薛賀,李建良.多語言Web網站的設計與實現[J].微電子學與計算機,2008,5:43-45.

[5]胡泊.基于JSF的國際化框架的設計與實現[D].北京郵電大學,2009.