利用 JavaServer Pages 技术开发多言语 Web 运用程序
利用 JavaServer Pages 技术开发多言语 Web 运用程序
JavaServerPages(JSP)技术现已成为深受Web运用程序开发者欢迎的工具。利用JSP技术，开发者不需求其余的编程知识就可能设计出动态的web网页。同时，Web开发者可能利用一种可扩充的标记机制来治理根底软件组件的性能。
经过Java标准制订组织（JavaCommunityProcess）开发的一个扩充性能可为多言语运用程序的开发提供更有力的支持。JavaServerPages标准标记库除了其余一些性能，还定义了一套可完老本地化和地区敏感（locale-sensitive）格式化的标记。
行文方面，本文首先对JavaServerPages技术停止了扼要引见，以使您可以更好天文解如何利用它们处理国际化的成绩。然后，我会针对多言语web运用程序的开发探讨几个外围成绩，并引见如何利用JavaServerPages技术处理它们：这些成绩包括地区确定和本地化、字符编码、格式化以及解析。
JavaServerPages技术
JavaServerPages（和几种相干技术）造成了web运用程序的示意层。利用JSP技术，开发者可能创建动态的web页面，这些页面可能与商业逻辑（businesslogic）、数据库以及其余可从网络上获取的服务构成互动关系。
JavaServerPages
利用JSP技术开发的网页联合了HTML、XML或其余含有类似XML标记（这些标记与根底软件库衔接）的静态内容，通常这些软件库利用Java编程言语编写。在这种环境中，十分重要的Java技术有JavaBeans组件架构（作为JSP和Java类之间的常规用途接口）、用于访问SQL数据库的Java数据库衔接（JDBC）API以及各种用于XML解决的库。
JSP页面自身依照servlet格式被编译为Java代码，以便执行。Servlet是web服务器的扩充，它被编译并关联至服务器，从而可能获得比脚本言语更快的执行速度。Servlet间接以Java编程言语编写，并常常与JSP网页一同利用，其中servlet作为控制局部而JSP页面作为运用程序的视图局部。
JavaServerPages和底层的servlet技术为解决HTTP申请和回应信息，以及利用Cookies或URL重写停止会话维护都提供了宽泛的支持。
利用JSP技术的一个很重要的缘由在于它可能将网页作者和运用程序开发者的工作停止分离。虽然可能将Java语句间接嵌入JSP网页，然而，开发者们已经意识到最好避免如此，而如今更偏差于利用自定义标记。
JavaServerPages标准标记库
JavaServerPages标准标记库（JSTL）蕴含了一系列涵盖数个性能畛域的自定义操作，这些性能在JSP网页中常常被利用。该库建设在许多参与者开发本人的库时所获得的阅历根底之上，它提供了一种运用程序可能依托的标准接口，并且可能独立于他们运转的服务器之外。
除了自定义标记，JSTL还引入了一种表达言语，这种言语运进一步地缩小了在JSP网页中利用脚本言语的须要，同时还引进了标记库验证程序以限度在JSP网页上对脚本和标记库的利用。这种改进版本的表达言语，以及限度脚本的性能已在随后被集成到JSP2.0规范之中，所以只要利用JSP1.2时才要求JSTL。
自定义操作包括的次要内容是：
变量操作：“外围”库中的一些操作，可在不同的畛域（网页、申请、会话和运用程序）中定义、删除变量或许将变量植入生成的页面中。
控制流：“外围”库中的几种操作，提供了基于标记的控制流构造（例如条件和迭代器），以缩小对嵌入脚本言语代码的须要。
URL相干操作：“外围”库中的一些操作，可让JSP网页导入由URL定义的内容，可将内部方式的URL重写为外部方式（这能够包括搜集会话跟踪信息）或重新定向至一个不同的网页。
XML解决：“xml”库中的操作，包括解析XML文档并利用XPath表达式来解紧缩内容，基于XPath表达式的控制流以及利用XSLT样式表停止的转换。
关系数据库访问：“sql”库中的操作，容许web运用程序执行简略的SQL查询和更新。
国际化和格式化（本文的中心内容）：“fmt”库中的操作，支持地区确定、本地化、字符编码决议和地区敏感格式化与解析。
地区确定和本地化
设计多言语web运用程序时，您必须首先决议如何确定用户的言语和地区首选项，以及如何使这些首选项与该运用程序和根底的Java运转环境支持的一套地区设置相婚配。这局部首先形容了web运用程序必须具备的外部环境和要求。下一步，咱们将了解相干的Java2StandardEdition(J2SE)平台提供的性能，最后咱们将了解JavaServerPages标准标记库的标记如何衔接到环境和J2SE中。
确定用户首选项
web运用程序有两种方法来确定用户的言语首选项：首先，它可能由阅读器利用HTTP申请报头字段Accept-Language传输至服务器的言语和地区首选项。虽然标准规定了许多言语标记，然而普通利用ISO639言语代码（如ja为日文）和ISO3166国家代码（如IT代表意大利）。阅读器通常让用户创建一个言语列表作为其首选项的一局部。但是，这种方法不太可靠；用户不肯定会创建该列表，而且该列表不肯定会蕴含该运用程序支持的地区设置。因为这些不确定性，多言语运用程序通常采用第二种方法：他们让用户间接从支持言语的列表中抉择，并把抉择的言语作为用户材料的一局部停止保存，或只在停止该会话的时分保存。一个好的方法是，在对用户无所不知的情况下，首先利用Accept-Language信息，在运用程序的末尾页面中给予用户间接抉择言语的时机。
将Accept-Language地区设置次要用于言语和文明首选项是没什么意义的。例如，它们不应该被解释为示意用户居住的国家。异样，在很多情况下阅读器提供的地区设置只要一个言语代码，而一些地区敏感的性能（例如，日期格式）则随着国家的不同而相异。在很多情况下，经过言语假定次要国家的规范是正当的（假设没有指定国家）；例如，假设指定了日本语，则可利用日本通用的日期格式。但是，假设是依据国家而设置的重要性能（例如货币），则必须给用户一个时机来批改该假定。
在许多情况下，web运用程序是由若干组件组合而来的，这些组件能够已经本地化为不同的言语。一个顺便值得一提的组件是Java运转环境，它在一些地区敏感区域能够具有支持超过40种言语中的100种区域设置的性能（例如日期格式），远远超出了典型的web运用程序。因此，运用程序开发者必须决议能否在整个运用程序中限度所支持言语的本地化性能，或许充散施展每个组件的性能劣势。第一种方法的劣势在于用户可能看到的全副页面都利用同一言语，而第二种方法能够导致页面中存在不同的言语——其中一种言语出如今绝大少数文本中，而另一种则出如今例如日期的格式中。
Java2StandardEditionPlatform中的本地化
为了了解JSTL如何确定运用程序被哪些地区设置支持，咱们来看看在根底的Java2StandardEdition平台中是如何停止本地化的。java.util软件包的外围次要有两种类：Locale和ResourceBundle。
Locale对象只是用来确定地区设置的：它们联合了ISO639言语代码（例如，ja代表日文）和ISO3166国家代码（例如，IT代表意大利），还能够蕴含一个（非标准化的）变量字符串。留意，HTTP的地区标识符利用相反的ISO标准，所以对比通常比较容易。
ResourceBundle对象是本地化对象的容器，构成成键/值对。一个根底资源束定义了一个根底束的称号、一套键以及默许值（通常是英文值，但不是必须的）。例如，一个简略的Messages资源束能够定义greeting-day键的默许值为Hello。其余的特定言语和国家束可能被定义，其称号由根底称号组成（经过后缀批示其言语、国家和变量）并提供已本地化的值。例如，德语Messages_de资源束可能给出GutenTag值（针对greeting-day键），而一个奥天时Messages_de_AT束能够用Servus值来笼罩该值。资源束可能作为Java类或简略的“属性”文本文件来执行。
JavaServerPages运用程序的本地化方法
要对基于JavaServerPages技术的运用程序停止本地化，方法通常有两个。第一个方法是利用国际化的页面，这些页面常可能经过自定义标记从资源束获得与特定地区设置相干的内容。假设页面需求保持简单的构造并与一切地区设置同步，则通常会采取这种方法。第二种方法利用单独的特定地区设置页面以及散发到适当页面的servlet（取决于用户的地区抉择）。假设页面蕴含的次要是文本或许地区设置间的构造一模一样时，则通常会采取这种方法。
地区确定和JSTL中的本地化
JSTL构建于J2SE工具之上，它可停止地区确定和本地化。利用任何一种JSP本地化方法（如上所述）均可能停止地区确定，而本地化性能的目标是为国际化的页面提供支持。
JSTL对上述两种确定用户地区首选项的方法都提供支持。运用程序可能利用JSTL的<fmt:setLocale>操作，指定一个固定的地区（通常是用户从支持言语列表中所间接抉择的）。一旦利用了该操作，指定的地区设置将运用于一切的地区敏感操作中。假设没有利用<fmt:setLocale>操作，地区敏感操作将会从地区抉择列表中搜查第一种支持的地区设置，这些地区设置通常由Accept-Language报头提供。
下面是一些您可能用于web运用程序末尾页面的代码片断。这些代码片断可让用户十分轻松地抉择他或她的地区设置。假定这些代码是locale-choice.jsp页面中的一局部：
<%--Interpretuser'slocalechoice--%>
<c:iftest="${param['locale']!=null}">
<fmt:setLocalevalue="${param['locale']}"scope="session"/>
</c:if>
<%--Offerlocalechoicetouser--%>
<ahref="locale-choice.jsp?locale=en-US">USA</a>-
<ahref="locale-choice.jsp?locale=de-DE">Deutschland</a>-
<ahref="locale-choice.jsp?locale=ja-JP">日本</a>
<%--UseURLrewritingtoensurepropersessiontracking--%>
<formmethod="get"action="<c:urlvalue='/locale-choice.jsp'/>">
<inputtype=submitvalue="Stayinsession">
</form>第一部份（此局部必须在生成的HTML页面任何内容之前）示意用户的地区抉择，该抉择作为一个申请参数显示在JSP页面上。假设定义了locale参数，则它将被用于停止会话的地区设置。
第二局部（此局部是生成的HTML页面内容的一局部）为用户提供了前往同一页面的链接，然而依据选定的国家提供了locale参数设置。留意，在本地言语中已经给出国家的称号，所以即使页面的其余局部已经本地化为用户不能辨认的言语，然而用户仍然可能容易地辨认这些称号。例如，“日本”是“日本”的数字字符引用，即“日本”的日语单词。新版的阅读器假设装有日本字体，将会正确地转换这些文本；对于旧版的阅读器，利用图片则能够更适合一些。
最后一局部显示如何利用<c:url>标记生成URL，此URL蕴含了一个会话ID，假设需求对该会话停止追踪的话（假设用户启用了cookies，则cookies将代替URL重写）。这将确保一旦抉择了地区设置，该抉择将运用于该web运用程序中的一切页面。
假设从web运用程序自身的用户界面中抉择了地区设置，然后利用<fmt:setLocale>停止设置，那么就可能假定该运用程序的确支持此地区设置。另一方面，假设没有利用<fmt:setLocale>并且JSTL必须从Accept-Language报头中的地区设置列表中找到一个支持的地区设置，那么情况会变得更简单。
要决议哪个地区设置是被支持的，JSTL将参考该运用程序所利用的资源束。有两种操作可用于访问资源束：<fmt:bundle>和<fmt:setBundle>。它们的根本性能是相反的：它们查询一个资源束并创建一个“本地化环境”，在这个“本地化环境”中蕴含了对该资源束和用于申请该资源束的地区设置的引用。
<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。没有利用<fmt:setLocale>标记。下表显示最终本地化环境的束和地区设置（用于一些申请地区设置列表）：
被申请的地区设置
后果束
后果地区设置
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:setBundlebasename="Errors"var="errorBundle"/>
<fmt:bundlebasename="Messages">
<%--Localizationcontextestablishedby<fmt:bundle>tag--%>
<fmt:messagekey="greeting"/>
<p>
<%--Localizationcontextestablishedby<fmt:setBundle>tag--%>
<fmt:messagekey="emptyField"bundle="${errorBundle}"/>
</fmt:bundle>其次，为什么有一个申请地区设置与本地化环境相干联？这个地区设置是JSTL将格式化标记限度到运用程序所支持的言语范围内的方法，这样展如今读者面前的页面言语将齐全一致。嵌套于<fmt:bundle>标记中的格式化操作利用该标记的本地化环境来确定它们应该利用的地区设置。例如，让咱们观察下面的页面片断：
<jsp:useBeanid="now"class="java.util.Date"/>
<fmt:formatDatevalue="${now}"timeStyle="long"dateStyle="long"/>
<p>
<fmt:bundlebasename="Messages">
<fmt:formatDatevalue="${now}"timeStyle="long"dateStyle="long"/>
</fmt:bundle>假设HTTPAccept-Language地区设置是fr和en，并且根底的Java运转环境对这两种言语的日期格式都支持（但web运用程序的Messages束只存在于en），那么第一个日期采用法文格式，而第二个则采用英文格式。因此，页面设计者可能决议是利用一致的言语还是经过抉择适当的标记嵌套来应用一切现有的本地化信息。
最后，为什么本地化环境利用申请地区设置而不利用由资源束找到的地区设置？答案是，这样可能避免失落重要的信息，某些格式标记能够需求这些信息。很多运用程序不能区分相反言语中不同变量之间的区别，而且只提供（例如）英文资源束，希冀着这些文本在英国、澳大利亚和新加坡都能被异样理解。但是对于日期格式，国家是很要害的——对于英国读者来说，“2/6/02”示意“2002年6月2日”，但对于习气美国规范的读者来说，则示意“2002年2月6日”。所以，在很多情况下，假设利用了申请地区设置（而不是资源束地区设置），则国家信息将会被保留。
字符编码
以后，咱们利用两种一模一样的模块示意存储在计算机中或经过网络传输的文本：旧的字符编码形式专门用于较小的言语汇合、国家和/或操作系统（包括如ISO8859系列、Windows代码页和EUC编码）；而新的基于Unicode编码的形式可以（至少理论上可以）示意一切的言语并可能在任何中央利用。
旧的模块具备很大的优势：
每种旧的字符编码方法通常只支持一个小的言语汇合。例如，Shift-JIS支持日文和英文，但不支持其余的亚洲或欧洲言语。ISO8859-1支持一些西欧言语但不支持东欧言语。
字符转换能够会带来意料之外的信息失落。开发者通常抉择ISO8859-1作为德语、法语和其它西欧言语的编码方法，然后会很诧异地发现“€”字符（德国、法国和许多其余欧洲国家通用货币的标志）不被这种编码所支持。为了防止这种信息失落，您必须利用Windows-1252、ISO8859-15或其余编码方法，这取决于阅读器的根底操作系统。
以后版本的次要软件系统所蕴含的创建、散发和解释web内容都支持新的模块；它们通常将Unicode用于内部解决，或许至少知道怎样利用（用于web、基于Unicode编码的）UTF-8。基于Unicode的编码有着以下分明的劣势：它们支持多言语页面并明晰区分地区设置（从字符编码解决）成绩。异样，由于编码转换而带来的信息失落的危险也很小，同时基于Unicode的编码与如今的服务器和客户端系统比较吻合。
虽然如此，很多web开发者仍然不太情愿利用UTF-8。其中的缘由能够包括对旧版本的阅读器支持不充分，或许短少支持它的工具。
JavaServerPages技术对新旧两种模块都支持。如今咱们来看看字符编码成绩所触及的各种不同畛域，并了解JSP技术和JSTL如何解决它们。
解决源程序页编码
JSP源文件的编码通常由可用的编辑工具决议，所以能够利用特定国家和操作系统的编码。字符编码与JSP运转环境（“容器”)之间的通信方法有许多种，随着工夫推移其中的机制和规则已始终改进。同时JSP源文件相应存在着两种语法：标准语法和基于XML的新语法。
在检测字符编码时，JSP2.0规范将在这两种语法中停止辨别。对于采用XML语法的文件，编码将被检测为采用XML规范；这象征着UTF-8或UTF-16为默许的编码，而其余的编码必须在文件末尾处的XML申明中予以阐明。对于采用标准语法的文件，容器将思考两种次要的信息起源：首先它们访问运用程序的配置形容符，查询一个page-encoding元素，该元素位于jsp-property-group（其URL格式与文件相婚配）；然后在此页中查询pageEncoding属性。假设两者都没有，容器也会寻觅contentType属性中的charset（参阅下一局部“解决Web页面编码”），或利用ISO8859-1作为最终的备用抉择。
以下是基于JSP2.0的运用程序的一些简略建议：对于采用XML语法的文件，确保没有利用UTF-8或UTF-16编码的文件可以正确辨认它们的字符编码。对于采用标准语法的文件，假设您对一切源文件利用UTF-8，则请在配置形容符中只利用一个元素page-encoding来论述它。假设您利用特定地区设置编码，则依据该地区设置来组织或命名您的文件，并利用page-encoding元从来形容它们的关系。例如，假设全副的韩文文件以EUC-KR编码并保存在/ko/KRweb的运用程序的子目录中，请利用以下语句：
<jsp-property-group>
<url-pattern>/ko/KR/*</url-pattern>
<page-encoding>EUC-KR</page-encoding>
</jsp-property-group>假设运用程序中的源文件不能以这种模式组织，则为每个源文件减少pageEncoding属性。不过请切记，此属性必须可以在文件的末尾处找到并且只能用于标识ASCII扩充码的字符编码。后一个限度思考到了UTF-8和许多旧的字符编码，但没思考UTF-16或基于EBCDIC的编码。不建议依据contentType属性中的charset值来标识源程序页编码；这个值应只用于标识web页面编码（参见下一局部）。
关于源文件字符编码，JSP1.2规范没有清楚地区分利用标准语法的文件和利用XML语法的文件。它也没有提供辨认配置形容符中的字符编码的方法。为确保正确检测字符编码，设计用于JSP1.2容器的运用程序应总是辨认每个利用pageEncoding属性的源文件中的字符编码。
JSTL定义了一个<c:import>操作，该操作容许蕴含由URL指定到JSP生成的页面的外部数据。该操作容许字符编码规范，假设外部数据没有指定它自身的编码时会利用此规范。
解决Web页面编码
web运用程序必须抉择生成的web页中利用的字符编码（该编码被称为“反应字符编码”），它基于指标阅读器的功能、页面内容的编写系统和言语以及能够的阅读器主机的操作系统。依据HTTP规范，字符编码在Content-Type实体报头的charset参数中被指定。
假设一切指标阅读器都支持UTF-8，普通来说最好利用这种编码，这样就可能支持多言语文档并避免字符转换带来的信息失落。
假设不能利用UTF-8，必须小心审慎地利用运用程序将字符编码与利用的言语相婚配，包括一些特殊字符。为防止出现谬误，能够需求在整个页面里利用同一种言语，如本文末尾局部“地区确定和本地化”中所述。异样，也有必要避免利用“€”字符。
Web运用程序可能间接指定一个页面的字符编码，也可能让JSP技术依据地区设置信息直接决议。
经过页面的contentType属性的显式规范最为简便，该属性可让运用程序连同生成页面的内容类型一同来指定字符编码。假设运用程序在解决申请时需求设置字符编码，则它需求利用一个自定义操作或一些Java代码来调用javax.servlet.ServletResponse.setContentType方法或新的（在Servlet2.4中）javax.servlet.ServletResponse.setCharacterEncoding方法。
直接地，每当字符编码创建一个本地化环境时，它们也是由JSTL格式化操作（包括<fmt:message>）以及<fmt:bundle>、<fmt:setBundle>和<fmt:setLocale>操作无条件地来决议。经过ServletResponse.setLocale方法，它们将本地化环境的地区设置或指定的地区设置映射到一个字符编码并依据页面的内容类型对其停止设置。Servlet2.4规范经过配置形容符中的locale-encoding-mapping-list元素为运用程序提供了一个控制映射的方法。假设运用程序没有提供此元素，或许当您利用基于旧的Servlet规范的容器时，那么从地区设置到字符编码的映射取决于该容器；典型的完成依赖于旧的字符编码。
直接决议字符编码是可行的，只需旧的字符编码可能被承受，并且整个页面利用相反的言语而且避免出现常用字符编码所不支持的特殊字符。但是，若要应用UTF-8则要求利用显式规范。由于Servlet2.4规范使显式规范优先于隐式规范，所以将字符编码设置为contentType属性的一局部已足够——随后利用JSTL格式化操作不会影响字符的编码。不过，在早期版本的Servlet规范中，并不保证地区设置信息中的显式规范优先于隐式决议。假设需求与基于旧规范的容器兼容，您必须经过在显式字符编码规范和初次利用自定义操作之间调用ServletResponse.flushBuffer来解冻字符编码，这些自定义操作能够直接决议字符编码。
解决申请参数编码
JSP技术不只可以生成web页面，而且还可能接纳和解释与HTTP申请一同收到的参数——通常是来自某种表格的输入，这种表格属于后面熟成的web页面的一局部。用于这些参数的字符编码并非在任何中央都被指定，但实践标准是阅读器利用的编码要与蕴含这些表格的网页利用的编码相反。
这象征着web运用程序需求跟踪先前生成的网页的编码。一个常用的机制是把编码的称号存储到表格自身的一个隐藏域中，在下一个申请时解紧缩为第一个参数，然后用它来解码出其余的参数。但是，JSP页面还可能利用会话治理来跟踪申请之间的信息。
运用程序可能利用JSTL自定义操作<fmt:requestEncoding>来指定要编码的参数的编码方法。假设运用程序总是发送UTF-8编码的页面，那么可能简略指定这种编码为申请编码。否则，假设它将间接指定生成页面的编码，它应该将该编码作为会话信息的一局部停止跟踪并间接将其传递给<fmt:requestEncoding>操作。假设它依赖于字符编码的直接决议，则它会简略地利用<fmt:requestEncoding>操作而无需指定一种字符编码；直接决议生成页面的编码这一操作还会在会话中贮存信息，<fmt:requestEncoding>可能检索和利用这些信息。
格式化和解析
以本地化的格式示意数据（如数字和日期）是任何类型地运用程序都要实现的常见义务，就好像用户提供的输入解释。不同言语和文明所利用的格式区别很大，所以假设开发者不依托现有的库的话，那么这个工作就不会是一项简略的义务。
幸运的是，的确存在这样的库。Java2StandardEdition(J2SE)平台提供了在java.text软件包中用于格式化和解析常用数据类型的类库，并且Sun已将这些类库本地化为100多种地区设置。
JavaServerPages标准标记库提供了自定义操作，可将这些性能间接运用到JSP页面中。
用于格式化和解析操作的地区确定
您可能在预约义的本地化环境中对数字和日期利用格式化和解析的操作（例如，假设标记嵌套于一个<fmt:bundle>标记中），或许在这种环境以外停止操作。假设您在预约义的本地化环境中利用操作，则它们将利用此本地化环境的地区设置。否则，它们将决议<fmt:bundle>和<fmt:setBundle>操作（如前文所述）的，用于修正的资源束查询策略所利用的地区设置。次要的区别在于：与查找资源束不同，算法经过利用java.text.NumberFormat.getAvailableLocales方法（用于数字格式化和解析操作）或许java.text.DateFormat.getAvailableLocales方法（用于日期和工夫格式化和分解操作）来决议受支持的地区设置。
数字格式化和解析
JSTL用于数字格式化和解析的自定义操作<fmt:formatNumber>和<fmt:parseNumber>基于J2SE类java.text.NumberFormat，用于解决简略的数字以及百分比和货币值。
顺便值得一提的是它们对货币格式化的支持。传统上，许多格式化库假定货币符号可能从地区设置中得出——例如，假设地区设置是中国，那么货币符号就是人民币（RMB）。在一个跨境买卖的环境中，这并没有多大的意义。假设某个英国公司以英镑来计算价钱，而web运用程序将价钱显示为人民币（RMB）的方式，就会出现两个成绩：第一，人民币的汇率比英镑低；其次，人民币换回英镑会比较艰巨。因为货币的抉择属于商业上的决议，所以货币必须作为值的一局部而不是格式的一局部。
因此，<fmt:formatNumber>操作可能让运用程序指定一个ISO4217货币代码或货币符号，它将笼罩本地化数字格式利用的默许货币。假定运用程序利用一个带有值和货币属性的价钱bean，下面的页面语句片断可能对价钱停止格式化：
<fmt:formatNumbertype="currency"value="${price.value}"
currencyCode="${price.currency}"/>假设JSP页面指定了一个货币代码，则底层的NumberFormat对象会尝试对指定的货币利用一个货币符号，该指定的货币已本地化为所处本地化环境的地区设置。例如，假设为美元指定货币代码USD，则它能够会利用符号“$”（假设地区设置是en_US），在其余可承受该货币符号的地区设置中将利用US$，或许假设本地化符号未知，则利用备用货币代码USD。
日期和工夫的格式化和解析
用于日期和工夫的格式化和解析的JSTL自定义操作<fmt:formatDate>和<fmt:parseDate>基于J2SE类java.text.DateFormat并用于解决不同的日期和工夫示意方法。
令人感兴味的一点是显示的日期和工夫不只仅取决于一种指定地区设置的格式，还取决于时区信息。用户通常对服务器时区不感兴味，但另一方面，要找出用户所在地的时区却并不简略。运用程序可能经过利用一些客户端的JavaScript代码来找出用户的以后时区与格林尼治标准工夫的偏向，或让用户指定以后时区并将其作为用户信息的一局部。JSTL操作并没有处理这个成绩，但它们提供了两个自定义操作，可能用来告知无关时区的日期和工夫的格式化和解析：<fmt:timeZone>和<fmt:setTimeZone>。与<fmt:bundle>和<fmt:setBundle>一样，<fmt:timeZone>标记可为嵌套标记定义时区，而<fmt:setTimeZone>将时区贮存在一个变量中以供后继操作利用。
信息格式化
<fmt:message>操作（后面已提及）岂但能从一个资源束中获取一个字符串并将其插入至生成的页面中，而且它还可能执行参数交流并依据需求格式化参数。它基于java.text.MessageFormat类，因此该操作获取的字符串实践上是一个MessageFormat形式字符串。<fmt:param>操作提供了必要的自变量。
例如，假设JSP页面蕴含了以下语句：
<jsp:useBeanid="now"class="java.util.Date"/>
<fmt:bundlebasename="Messages">
<fmt:messagekey="greeting">
<fmt:paramvalue="${now}"/>
</fmt:message>
</fmt:bundle>并且找到的资源束是德语，而且为greeting键提供了“Willkommen!Heuteistder{0,date,long}.”值，那么生成日期为（假定）2002年6月21日的页面内容将会是“Willkommen!Heuteistder21.Juni2002.”
论断
如本文所述，JavaServerPages技术（顺便是JavaServerPages标准标记库）为您提供了一个开发多言语运用程序的松软根底。您需求细心思考以下几个设计抉择：如何确定用户的言语和地区设置首选项，如何结构您用于本地化的JSP页面，能否采用单一言语的页面或充分应用现有的地区设置支持，以及利用哪一种字符编码模块。JSP技术使您可以抉择其中恣意一种，这样您就可能将页面以最佳的模式展示给全世界的读者，而且最重要的是，以他们本人的言语来展示。
参考书目
R.Fieldingetal.:HypertextTransferProtocol--HTTP/1.1.RFC2616.TheInternetSociety,1999.
DaveRaggettetal.(ed.):HTML4.01Specification.WorldWideWebConsortium,1999.
TimBrayetal.(ed.):ExtensibleMarkupLanguage(XML)1.0(SecondEdition).WorldWideWebConsortium,2000.
Java2Platform,StandardEdition,v1.4.2APISpecification.SunMicrosystems,2002.
DannyCoward(ed.):JavaServletSpecification.Version2.3.SunMicrosystems,2001.
DannyCoward,YutakaYoshida(ed.):JavaServletSpecification.Version2.4.SunMicrosystems,2003.
EduardoPelegrlopart(ed.):JavaServerPagesSpecification.Version1.2.SunMicrosystems,2001.
MarkRoth,EduardoPelegrlopart(ed.):JavaServerPagesSpecification.Version2.0.SunMicrosystems,2003.
PierreDelisle(ed.):JavaServerPagesStandardTagLibrary.Version1.0.SunMicrosystems,2002.
PierreDelisle(ed.):JavaServerPagesStandardTagLibrary.Version1.1.SunMicrosystems,2003.
关于作者
NorbertLindenberg是SunMicrosystems的JavaWebServices团队内JavaInternationalization技术主管。在加盟Sun之前，曾经供职于GeneralMagic和AppleComputer，参与过多个国际化名目。他毕业于德国的卡尔斯鲁厄大学，领有计算机科学理科硕士学位。
