关于java中的fmt标签的用法？？

答案：关于jstl中的fmt标签2007-07-12  11:57今天看spring的messeagesource时查到了关于国际化的问题
spring中applicationContext虽然继承messeagesource，但它只是在配置文件中查找messagesource的实现bean，并以它为消息源，调用其指向的消息处理方法getmessage等
关于fmt的一些情况找了网页介绍的可以的如下
quto：
如果从 web 应用程序本身的用户界面中选择了地区设置，然后使用 <fmt: setLocale>进行设置，那么就可以假设该应用程序确实支持此地区设置。 另一方面，如果没有使用 <fmt: setLocale> 并且 JSTL必须从 Accept-Language 报头中的地区设置列表中找到一个支持的地区设置，那么情况会变得更复杂。

要决定哪个地区设置是被支持的，JSTL 将参考该应用程序所使用的资源束。 有两种操作可用于访问资源束： 和 。 它们的基本功能是相同的：它们查询一个资源束并创建一个“本地化环境”，在这个“本地化环境”中包含了对该资源束和用于请求该资源束的地区设置的引用。

<fmt:bundle> 和 <fmt: setBundle>操作所使用的资源束查询允许多次请求地区设置（这样它就可以处理由 Accept-Language 报头提供的列表），并使用由 web应用程序定义的备用（fallback）地区设置。 如果使用 <fmt:setLocale> 操作设置地区，那么  <fmt:bundle> 和 <fmt:setBundle>操作将请求用于该地区设置的束，或者，如果不成功的话，将请求用于备用地区设置的束。 如果没有使用<fmt:setLocale>，随后的操作将请求用于由 Accept-Language报头提供的地区设置和备用地区设置，直到请求成功。在每种情况下，基本查询（查询束的基本名称和一个请求地区设置）将为请求地区设置本身搜索一个资源束，随后搜索更简单的地区设置（首先从请求地区设置中舍弃变量，然后舍弃国家组件）。 如果全部的请求地区设置以及备用地区设置的查询都失败，那么将使用基础束。

以下是一些例子。 让我们假设某个应用程序拥有用于 en、zh_CN、zh_TW、ja 和 ko 的束。 备用地区设置被设置为   en。 没有使用  标记。 下表显示最终本地化环境的束和地区设置（用于一些请求地区设置列表）： 

被请求的地区设置 
 结果束 
 结果地区设置
 
zh_SG、zh_CN
 zh_CN
 zh_CN
 
zh、ja
 ja
 ja
 
es_MX
 en
 en
 
en_US
 en
 en_US
 
ja、zh_CN
 ja
 ja
 

ResourceBundle   类的行家会注意到，JSTL 操作所使用的查询策略与 ResourceBundle 所使用的查询策略是不同的。ResourceBundle 使用的策略只接受一个请求地区设置，这不足以处理由 Accept-Language报头所提供的地区设置列表，并且它会恢复 Java 运行环境的默认地区设置，此默认地区设置与 web应用程序和其用户并不相关，使用它将导致不可移植性。

那么，为什么查询资源束时存在两种不同的操作呢？ 它们的区别在于它们使用的方法：<fmt:bundle>标记提供了一个用于嵌套标记的环境，而 <fmt: setBundle>操作将最终本地化环境存储在一个变量中，此变量可以在相同页面中被后继操作访问，并且可以被其他页面中的操作所访问（这取决于该变量的范围）。

<fmt:message> 操作是一种利用本地化环境的 JSTL 标记。 它最简单的形式是，它从一个本地化环境的资源束中为一个指定的键获取一条信息并将该信息插入生成的页面中。 下面例子显示了它的不同用法：

<fmt:setBundle basename="Errors" var="errorBundle" />
<fmt:bundle basename="Messages">
   <%-- Localization context established by <fmt:bundle> tag --%>
   <fmt:message key="greeting" />
   <p>
   <%-- Localization context established by <fmt:setBundle> tag --%>
   <fmt:message key="emptyField" bundle="＄{errorBundle}" />
</fmt:bundle>
其次，为什么有一个请求地区设置与本地化环境相关联？ 这个地区设置是 JSTL将格式化标记限制到应用程序所支持的语言范围内的方法，这样展现在读者面前的页面语言将完全统一。 嵌套于 <fmt:bundle>标记中的格式化操作使用该标记的本地化环境来确定它们应该使用的地区设置。   例如，让我们观察下面的页面片断：

<jsp:useBean id="now" class="java.util.Date" />
<fmt:formatDate value="＄{now}" timeStyle="long" dateStyle="long" />
<p>
<fmt:bundle basename="Messages">
   <fmt:formatDate value="＄{now}" timeStyle="long" dateStyle="long" />
</fmt:bundle>
如果 HTTP Accept-Language 地区设置是 fr 和 en，并且基础的 Java 运行环境对这两种语言的日期格式都支持（但  web 应用程序的 Messages 束只存在于 en），那么第一个日期采用法文格式，而第二个则采用英文格式。因此，页面设计者可以决定是使用统一的语言还是通过选择适当的标记嵌套来利用所有现有的本地化信息。

最后，为什么本地化环境使用请求地区设置而不使用由资源束找到的地区设置？ 答案是，这样可以避免丢失重要的信息，某些格式标记可能需要这些信息。很多应用程序不能区分相同语言中不同变量之间的区别，而且只提供（例如）英文资源束，期望着这些文本在英国、澳大利亚和新加坡都能被同样理解。然而对于日期格式，国家是很关键的——对于英国读者来说，“2/6/02”表示 “ 2002 年 6 月 2日”，但对于习惯美国规范的读者来说，则表示“2002 年 2 月 6 日”。所以，在很多情况下，如果使用了请求地区设置（而不是资源束地区设置），则国家信息将会被保留。
这边文章讲得很详细了。。。你看看吧：
http://hi.zhaoxi.net/daisyseason/blog/item/2f7ff7caed6d794ff31fe758.html

上一个：java中输入点后自动弹出方法列表？
下一个：求问JAVA是怎么回事??