1.UTF-8
原来用惯了GBK，被大家一再怂恿，才下定决心整个项目换用UTF-8编码。
编码问题几乎与所有国内Java项目相伴而生，不同内核的Linux、英文版日文版的WindowsXP总是让GBK很头痛，而改用UTF-8后，忽然就轻爽了，UTF-8，全世界语系连马尔代夫语都有自己的座位，实在找不到理由为什么还要用只支持大中华的GBK。
而且Springside也成了一个带有大量UTF-8中文注释的项目。
原GBK项目的转换方法
把自己当成车衣厂女工，机械的使用UltraEdit和EditPlus的转换功能，忙活一两个小时，怎么都可以转完所有文件了。
其中UltraEdit的转换方法是文件--〉转换--〉ASCII to UTF-8(Unicode编辑)。最好在Advanced-〉本地代码页那里也设一下UTF-8。
然后就可以用设了UTF-8选项的IDE如IDEA,Eclipse直接编辑了。
2.国际化 I18N
后台的menu.jsp 和 editBook.jsp 还有业务异常类，演示了i18N的应用。
2.1 i18N基础
1.编写messages.zh_CN.properties
用中文写完后，用java带的native2ascii.exe或者ant的native任务把它转成非人类的Unicode编码。
2.在纯Java API里，国际化是这样做的：
ResourceBundle rb = ResourceBundle.getBundle("messages");
String welcome = rb.getString("welcome");
String welcomeCalvin = MessageFormat.format(welcome,new
String[]{"calvin"});
第一二句从classpath里找到messages_zh_CN.properties，读出"欢迎你，{0}"字样。
第三局把上文格式化成"欢迎你，calvin"
3.在Servlet环境下，国际化是这样做的
<%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
<fmt:message key="welcome"/>
可以用context-param来定义默认的properties文件
<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
<param-value>messages</param-value>
</context-param>
不过这样定义的缺点是只能定义一个文件，如果所有信息都集中在一个文件会好长，而如果有多个properties，就惟有在页面用<fmt:bundle>绑定了。
2.2 Spring的messageSource增强
Spring增加了MessageSource的概念
一是ApplicationContext将充当一个单例的角色，不再需要每次使用i18时都初始化一次ResourceBundle
二是可以代表多个Resource Bundle.
在ApplicationContext的定义文件中，增加如下节点：
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename" value= "messages"/>
</bean>
在pure Java中
context.getMessage("welcome", null, LocaleContextHolder.getLocale())
而经Spring MVC JSTL ViewResolver调用的JSP，<fmt:message>将继续发挥它的功效。
不过这里挺麻烦的，第一如果不是从MVC JSTL转的，messageSource的定义就会失效。而如果定义了<context-param>，则messageSource的定义又会失效.......
还有，<spring:message> 鸡肋一块，因为它如果找不到key对应的就会抛异常，好恐怖。
还还有，spring还有有趣的theme机制，和i18n一样的原理，解决了"做成图片的文字"的国际化，让不同语言的美术字图片的路径分别定义在theme_zh_CN.properties和theme_en_US.properties里面。