J2EE国际化与本地化：全面指南

### J2EE 国际化与本地化：全面指南 #### 1. JSP 页面本地化方法 在 J2EE 应用中，JSP 页面的本地化有两种主要方法，每种方法都有其优缺点。 ##### 1.1 使用资源束本地化 JSP 页面 使用资源束本地化 JSP 页面是一种常见的方法。通过使用支持区域设置的自定义标签来组装本地化文本块。每次请求页面时，自定义标签会从当前区域设置的资源束中选择文本。 这种方法的优点包括： - 易于维护：单个 JSP 页面是所有区域设置中特定屏幕的源文件。对 JSP 页面的修改会影响所有区域设置生成的动态内容。 - 页面结构一致：由于屏幕的源代码在所有区域设置之间共享，页面在所有区域设置中保持相同的结构，仅在数据值、消息文本和显示语言上有所变化。 - 易于扩展：只需为新的区域设置定义一个新的资源束，即可添加新的区域设置。 然而，这种方法也有缺点。虽然更改页面内容很容易，但根据不同区域设置自定义页面结构却比较困难，因为一个 JSP 页面要为所有区域设置生成内容。 此外，由于这种方法在所有区域设置中共享单个 JSP 页面，页面编码必须与所有应用程序字符集的编码兼容。建议使用 UTF - 8 编码，因为它被广泛支持。 推荐的实现方式是使用自定义标签访问资源束，而不是在脚本或表达式代码中使用资源束。这样可以提高 JSP 页面的可读性和可维护性，并减少重复代码。 ##### 1.2 特定区域设置的 JSP 页面 另一种本地化 JSP 页面的方法是为每个区域设置提供单独的 JSP 页面。在这种方法中，Servlet 或 Servlet 过滤器会根据请求客户端的区域设置将每个 JSP 页面请求转发到相应的文件。 可以使用目录或文件命名约定来区分不同区域设置的文件。例如，默认区域设置的文件名为 index.jsp，日本日语本地化的 JSP 文件名为 index_ja_JP.jsp 等。 这种方法的优点包括： - 更高的可定制性：每个区域设置使用一个 JSP 页面可以最大程度地定制该区域设置的内容，因为定制不受资源束内容的限制。 - 源文件清晰：特定区域设置的所有内容都出现在单个文件中，而不是分散在 JSP 页面文件和属性文件或资源束类中。 不过，这种方法也有缺点。使用单独的 JSP 页面在不同区域设置之间保持一致的外观和感觉比使用资源束更困难，并且需要为多个区域设置创建和维护单独的文件，这意味着更多的维护工作。 为了简化管理，建议将 JSP 页面、静态页面和其他资源（如图形文件）按区域设置分组到一个目录中。 无论选择哪种方法，正确设置 JSP 页面响应编码都至关重要。建议将所有页面编码标准化为 UTF - 8，并使用 Servlet 过滤器强制执行此编码。 以下是两种方法的对比表格： | 方法 | 优点 | 缺点 | | ---- | ---- | ---- | | 使用资源束 | 易于维护、页面结构一致、易于扩展 | 难以根据区域设置自定义页面结构 | | 特定区域设置的 JSP 页面 | 更高的可定制性、源文件清晰 | 难以保持一致的外观和感觉、维护工作多 | 其流程可以用下面的 mermaid 流程图表示： ```mermaid graph LR A[开始] --> B{选择本地化方法} B --> |资源束| C[使用自定义标签访问资源束] B --> |特定区域设置 JSP 页面| D[根据区域设置转发请求] C --> E[生成动态内容] D --> F[提供特定区域设置内容] E --> G[统一编码为 UTF - 8] F --> G G --> H[结束] ``` #### 2. EIS 层国际化 由于企业信息系统中的数据可能因区域设置而异，本地化问题可能会影响到 EIS 层。 ##### 2.1 持久化本地化数据 J2EE 应用不仅需要在组件源代码中支持国际化，还需要在持久化层中支持国际化。持久化层设计应始终考虑国际化问题。 容器管理的持久化和 Bean 管理的持久化都要求应用程序的 JDBC 驱动程序和后端数据存储支持所有用于表示持久化数据