BTW：本文参考了网上的诸多文献，对作者们表示感谢

    MD5即Message-Digest Algorithm 5（信息-摘要算法5），是一种用于产生数字签名的单项散列算法，在1991年由MIT Laboratory for Computer Science（IT计算机科学实验室）和RSA Data Security Inc（RSA数据安全公司）的Ronald L. Rivest教授开发出来，经由MD2、MD3和MD4发展而来。MD5算法的使用不需要支付任何版权费用。它的作用是让大容量信息在用数字签名软件签私人密匙前被"压缩"成一种保密的格式（将一个任意长度的“字节串”通过一个不可逆的字符串变换算法变换成一个128bit的大整数，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。）
   
   在 Java 中，java.security.MessageDigest 中已经定义了 MD5 的计算，所以我们只需要简单地调用即可得到 MD5 的128 位整数。然后将此 128 位计 16 个字节转换成 16 进制表示即可。

    代码如下：

    测试代码如下：

import com.tsinghua.*;

public class TestMD5
{
 public static void main( String xu[] )
 { // 计算 "a" 的 MD5 代码，应该为：0cc175b9c0f1b6a831c399e269772661
  System.out.println( MD5.getMD5("a".getBytes()) );
 }
}

使用 tomcat 时，相信大家都回遇到中文乱码的问题，具体表现为通过表单取得的中文数据为乱码。

一、初级解决方法

通过一番检索后，许多人采用了如下办法，首先对取得字符串按照 iso8859-1 进行解码转换，然后再按照 gb2312 进行编码，最后得到正确的内容。示例代码如下：

String  para = new String( request.getParameter("para").getBytes("iso8859-1"), "gb2312");

具体的原因是因为美国人在写 tomcat 时默认使用 iso8859-1 进行编码造成的。

 然而，在我们的 servlet 和 jsp 页面中有大量的参数需要进行传递，这样转换的话会带来大量的转换代码，非常不便。

二、入门级解决方法

后来，大家开始写一个过滤器，在取得客户端传过来的参数之前，通过过滤器首先将取得的参数编码设定为 gb2312 ，然后就可以直接使用 getParameter 取得正确的参数了。这个过滤器在 tomcat 的示例代码
jsp-examples 中有详细的使用示例,   其中过滤器在 web.xml 中的设定如下，示例中使用的是日文的编码，我们只要修改为 gb2312 即可

    <filter>
        <filter-name>Set Character Encoding</filter-name>
        <filter-class>filters.SetCharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>EUC_JP</param-value>
        </init-param>
    </filter>

过滤器的代码如下：
public class SetCharacterEncodingFilter implements Filter {

    // 编码的字符串
    protected String encoding = null;

   // 过滤器的配置
    protected FilterConfig filterConfig = null;

   // 是否忽略客户端的编码
    protected boolean ignore = true;

   // 销毁过滤器
    public void destroy() {

        this.encoding = null;
        this.filterConfig = null;

    }

   // 过滤方法
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain)
          throws IOException, ServletException {

        // 如果使用过滤器，忽略客户端的编码，那么使用通过过滤器设定编码
        if (ignore || (request.getCharacterEncoding() == null)) {
            String encoding = selectEncoding(request);
            if (encoding != null)
                request.setCharacterEncoding(encoding);
        }

        // 传送给下一个过滤器
        chain.doFilter(request, response);

    }

    // 初始化过滤器
    public void init(FilterConfig filterConfig) throws ServletException {

        this.filterConfig = filterConfig;
        this.encoding = filterConfig.getInitParameter("encoding");
        String value = filterConfig.getInitParameter("ignore");
        if (value == null)
            this.ignore = true;
        else if (value.equalsIgnoreCase("true"))
            this.ignore = true;
        else if (value.equalsIgnoreCase("yes"))
            this.ignore = true;
        else
            this.ignore = false;

    }

    // 返回过滤器设定的编码
    protected String selectEncoding(ServletRequest request) {

        return (this.encoding);

    }
}

然而在 tomcat5 中，即使使用过滤器，仍然可能取得乱码，原因何在呢？

三、高级解决方法

这是因为，在 tomcat4 和 tomcat5 中对参数的处理是不一样的，在 tomcat4 中 get 与 post 的编码是一样的，所以只要在过滤器中通过 request.setCharacterEncoding 设定一次就可以解决 get 与 post 的问题。然而，在 tomcat5 中，get 与 post 的处理是分开进行的

在 tomcat 5 中，为了解决编码问题，tomcat 的作者作了很多努力，具体表现为在 tomcat 的配置文件 server.xml 中对 Connector 元素增加了如下的配置参数，专门用来对编码进行直接的配置

URIEncoding   用来设定通过 URI 传递的内容使用的编码，tomcat 将使用这里指定的编码对客户端传送的内容进行编码。

什么是 URI 呢？
java doc 的说明中如下说明：URI 是统一资源标识符，而 URL 是统一资源定位符。因此，笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。

也就是说，我们通过 get 方法提交的参数实际上都是通过 uri 提交的，都由这个参数管理，如果没有设定这个参数，则 tomcat 将使用默认的 iso8859-1 对客户端的内容进行编码。

useBodyEncodingForURI 使用与 Body 一样的编码来处理 URI, 这个设定是为了与 tomcat4保持兼容，原来在 tomcat4 和 tomcat5 中队参数的处理是不一样的，在 tomcat4 中 get 与 post 的编码是一样的，所以只要在过滤器中通过 request.setCharacterEncoding 设定一次就可以解决 get 与 post 的问题。然而，在 tomcat5 中，get 与 post 的处理是分开进行的，对 get 的处理通过 前面的 URIEncoding 进行处理，对 post 的内容依然通过 request.setCharacterEncoding 处理，为了保持兼容，就有了这个设定。

将 useBodyEncodingForURI 设定为真后，就可以通过 request.setCharacterEncoding 直接解决 get 和 post 中的乱码问题。

这样，我们可以通过在 server.xml 中设定 URIEncoding 来解决 get 方法中的参数问题，使用过滤器来解决 post 方法中的问题。

或者也可以通过在 server.xml 中设定 useBodyEncodingForURI 为 true ，配合过滤器来解决编码的问题。

在这里，我强烈建议在网站的创作过程中，全程使用 utf-8 编码来彻底解决乱码问题。

具体操作如下：
1、页面内容使用 utf-8 格式保存，在页面中加入 <mete http-equiv="contentType" content="text/html;charst=utf-8">

2、服务器端的 server.xml 中设定 useBodyEncodingForURI = true

3、使用过滤器，过滤器设定编码为 utf-8

1.百度语言翻译机
百度的工程师们是非常注重效率的，在长期的开发与测试过程中，他们逐渐创造了一套独特的缩略语。他们在平时的交谈、会议，甚至在各种技术文档中都会大量运用。

为了让新员工可以更快地适应百度的文化，更好地阅读公司的技术文档，人力资源部决定开发一套专用的翻译系统，把相关文档中的缩略语和专有名词翻译成日常语言。

输入要求：
输入数据包含三部分：
1. 第一行包含一个整数N(N<=10000)，表示总共有多少个缩略语的词条；
2. 紧接着有N行的输入，每行包含两个字符串，以空格隔开。第一个字符串为缩略语（仅包含大写英文字符，长度不超过10字节），第二个字符串为日常语言（不包含空格，长度不超过255字节）；
3. 从第N+2开始到输入结束为包含缩略语的相关文档（总长度不超过1000000个字节）。例：
6
PS 门户搜索部
NLP 自然语言处理
PM 产品市场部
HR 人力资源部
PMD 产品推广部
MD 市场发展部
百度的部门包括PS，PM，HR，PMD，MD等等，其中PS还包括NLP小组。
样例：in.txt

输出要求：
输出将缩略语转换成日常语言后的文档。（将缩略语转换成日常语言，其他字符保留原样）。例：
百度的部门包括门户搜索部，产品市场部，人力资源部，产品推广部，市场发展部等等，其中门户搜索部还包括自然语言处理小组。
样例：out.txt

2.饭团的烦恼
“午餐饭团”是百度内部参与人数最多的民间组织。
同一个部门的、同一所大学的、同一年出生的、使用同一种型号电脑的员工们总是以各种理由组织各种长期的、临时的饭团。

参加饭团，不仅可以以优惠的价格尝到更加丰富的菜式，还可以在吃饭的时候和同事们增进感情。
但是，随着百度的员工越来越多，各个饭团的管理变得繁杂起来。特别是为了照顾员工们越来越挑剔的胃，饭团的点菜负责人的压力也越来越大。现在，这个任务就交给“百度之星”了，因为，你将要为所有的百度饭团设计一个自动点菜的算法。

饭团点菜的需求如下：
1．经济是我们要考虑的一个因素，既要充分利用百度员工的午餐补助，又不能铺张浪费。因此，我们希望最后的人均费用越接近12元越好。
2．菜式丰富是我们要考虑的另一个因素。为简单起见，我们将各种菜肴的属性归结为荤菜，素菜，辛辣，清淡，并且每个菜只能点一次。
3．请谨记，百度饭团在各大餐馆享受8折优惠。

输入要求：
1．输入数据第一行包含三个整数N，M，K(0<N<=16，0<M<=N，0<K<=12)，分别表示菜单上菜的数目，饭团需要点的菜的数目，就餐的人数；
2．紧接着N行，每行的格式如下：
菜名（长度不超过20个字符） 价格（原价，整数） 是否荤菜（1表示是，0表示否） 是否辛辣（1表示是，0表示否）；
3．第N+2行是 a b c d 四个整数，分别表示需要点的荤菜，素菜，辛辣，清淡菜的数目。例：
3 2 2
水煮鱼 30 1 1
口水鸡 18 1 1
清炖豆腐 12 0 0
1 1 1 1
样例：in.txt

输出要求：
对于每组测试数据，输出数据包含M+1行，前M行每行包含一个菜名（按菜名在原菜单的顺序排序）。第M+1行是人均消费，结果保留两位小数。例：
口水鸡
清炖豆腐
12.00
样例：out.txt

3.变态比赛规则
为了促进各部门员工的交流，百度举办了一场全公司范围内的“拳皇”（百度内部最流行的格斗游戏）友谊赛，负责组织这场比赛的是百度的超级“拳皇”迷W.Z。W.Z不想用传统的淘汰赛或者循环赛的方式，而是自己制定了一个比赛规则。

由于一些员工（比如同部门或者相邻部门员工）平时接触的机会比较多，为了促进不同部门之间的交流，W.Z希望员工自由分组。不同组之间的每两个人都会进行一场友谊赛而同一组内的人之间不会打任何比赛。

比如4个人，编号为1~4,如果分为两个组并且1，2一个组，3，4一个组，那么一共需要打四场比赛：1 vs 3，1 vs 4，2 vs 3，2 vs 4。 而如果是1，2，3一组，4单独一组，那么一共需要打三场比赛: 1 vs 4，2 vs 4，3 vs 4。

很快W.Z意识到，这样的比赛规则可能会让比赛的场数非常多。W.Z想知道如果有N个人，通过上面这种比赛规则，总比赛场数有可能为K场吗？比如3个人，如果只分到一组则不需要比赛，如果分到两组则需要2场比赛，如果分为三组则需要3场比赛。但是无论怎么分都不可能恰需要1场比赛。

相信作为编程高手的你一定知道该怎么回答这个问题了吧？ 那么现在请你帮助W.Z吧。

输入要求：
每行为一组数据，包含两个数字 N, K(0<N<=500, K>=0)。例：
2 0
2 1
3 1
3 2
样例：in.txt

输出要求：
对输入的N,K 如果N个员工通过一定的分组方式可以使比赛场数恰好为K，则输出"YES"，否则输出"NO"（请全部使用大写字母），每组数据占一行。例：
YES
YES
NO
YES
样例：out.txt

4.蝈蝈计分
蝈蝈小朋友刚刚学会了0~9这十个数字,也跟爸爸妈妈来参加百度每周进行的羽毛球活动。但是他还没有球拍高，于是大人们叫他记录分数。聪明的蝈蝈发现只要记录连续得分的情况就可以了，比如用“3 2 4”可以表示一方在这一局中连得三分后，输了两分，接着又连得到四分。可是，后来大人们发现蝈蝈只会用0~9这十个数字，所以当比赛选手得分超过9的时候，他会用一个X来表示10完成记分。但问题是，当记录为“X 3 5”的时候，蝈蝈自己也记不起来是一方连续得到十三分后，再输五分；还是先赢十分输三分再赢五分。

因为百度内部就要开始进行羽毛球联赛了，要先摸清大家的实力才好分组比赛呢～于是，大人们想知道以前每局的比分是怎样的，以及谁获得了胜利。要是遇到了根据比赛记录无法确认比赛过程的情况，也要输出相应的提示哦。

需要进一步说明的是，比赛是五局三胜的，每局先获得二十一分的为胜，但是胜方必须领先对手两分或以上，否则必须继续比赛直到一方超出对手两分为止，比分多的一方获胜。任何一方先获胜三局后就获得最终胜利，比赛也相应的结束。而且蝈蝈保证是完整的无多余信息的记录了比赛。

输入要求：
1．文件中第一行只有一个整数M，表示蝈蝈记录了多少场比赛的分数；
2．在接下来的2M行里，每场比赛用两行记录，第一行是一个整数N(N<=1000)表示当前这个记录中有多少个字符，第二行就是具体的N个字符表示记录的分数（相邻字符用空格隔开）。例：
3
23
9 7 3 6 2 4 7 8 3 2 7 9 X 2 2 1 2 1 X 1 X 1 1
25
9 3 8 5 4 8 3 9 8 4 X X X X 2 X X X X 2 8 4 9 2 4
43
7 7 7 7 7 3 4 5 6 7 6 5 4 2 1 3 5 7 9 7 5 3 1 3 0 9 9 3 9 3 2 1 1 1 5 1 5 1 5 1 5 5 1
样例：in.txt

输出要求：
对应每一个分数记录，输出相应的每局分数，每局分数都使用两个整数表示，表示两个选手的得分，中间用":"分隔开；每组分数记录间使用一个空行分隔开。如果相应的比赛结果无法预测，以“UNKNOWN”一个单词独占一行表示（请全部使用大写字母）。例：
21:17
24:22
21:3

UNKNOWN

21:14
20:22
21:23
21:16
21:9
样例：out.txt

5.座位调整
百度办公区里到处摆放着各种各样的零食。百度人力资源部的调研发现，员工如果可以在自己喜欢的美食旁边工作，效率会大大提高。因此，百度决定进行一次员工座位的大调整。

调整的方法如下：
1．首先将办公区按照各种零食的摆放分成N个不同的区域（例如：可乐区，饼干区，牛奶区等等）；
2．每个员工对不同的零食区域有不同的喜好程度（喜好程度是1~100的整数， 喜好程度越大表示该员工越希望被调整到相应的零食区域）；
3．由于每个零食区域可以容纳的员工数量有限，人力资源部希望找到一个最优的调整方案使得总的喜好程度最大。

输入要求：
文件第一行包含两个整数N，M(N>=1，M<=300)。分别表示N个区域和M个员工；
第二行是N个整数构成的数列a，其中a[i]表示第i个区域可以容纳的员工数(1<=a[i]<=M，a[1]+a[2]+...+a[N]=M)；
紧接着是一个M*N的矩阵P，P(i,j)表示第i个员工对第j个区域的喜好程度。例：
3 3
1 1 1
100 50 25
100 50 25
100 50 25
样例：in.txt

输出要求：
对于每个测试数据，输出可以达到的最大的喜好程度。例：
175
样例：out.txt

6.剪刀石头布
N个小孩正在和你玩一种剪刀石头布游戏（剪刀赢布，布赢石头，石头赢剪刀）。N个小孩中有一个是裁判，其余小孩分成三组（不排除某些组没有任何成员的可能性），但是你不知道谁是裁判，也不知道小孩们的分组情况。然后，小孩们开始玩剪刀石头布游戏，一共玩M次，每次任意选择两个小孩进行一轮，你会被告知结果，即两个小孩的胜负情况，然而你不会得知小孩具体出的是剪刀、石头还是布。已知各组的小孩分别只会出一种手势（因而同一组的两个小孩总会是和局），而裁判则每次都会随便选择出一种手势，因此没有人会知道裁判到底会出什么。请你在M次剪刀石头布游戏结束后，猜猜谁是裁判。如果你能猜出谁是裁判，请说明最早在第几次游戏结束后你就能够确定谁是裁判。

输入要求：
输入文件包含多组测试数据，每组测试数据第一行为两个整数N和M(1<=N<=500，0<M<=2000)，分别为小孩的个数和剪刀石头布游戏进行的次数。接下来M行，每行两个整数且中间以一个符号隔开。两个整数分别为进行游戏的两个小孩各自的编号（为小于N的非负整数）。符号的可能值为“=”、“>”和“<”，分别表示和局、第一个小孩胜和第二个小孩胜三种情况。例：
3 3
0<1
1<2
2<0
3 5
0<1
0>1
1<2
1>2
0<2
4 4
0<1
0>1
2<3
2>3
1 0
样例：in.txt

输出要求：
1．每组测试数据输出一行，若能猜出谁是裁判，则输出裁判的编号，并输出在第几次游戏结束后就能够确定谁是裁判，小孩的编号和游戏次数以一个空格隔开；
2．如果无法确定谁是裁判，输出-2；如果发现剪刀石头布游戏的胜负情况不合理（即无论谁是裁判都会出现矛盾），则输出-1。例：
-2
1 4
-1
0 0
样例：out.txt

Sun 官方的中文版 Java API 文档发布了，地址为：http://gceclub.sun.com.cn/download/Java_Docs/html_zh_CN.zip, 下载后请参考如下步骤配合 eclipse3.1 使用

1. 点击菜单 <窗口> - > <设定>
2. 点击左边项目列表中的 <Java> ->  <已安装的 JRE>
3. 选中你已经安装好的 JRE5.0 ，单击右边的编辑
4. 点击对话框下边的库列表中的 rt.jar 左边的加号 “+”，展开 rt.jar 的配置
5. 选中第二项，JavaDoc Location ，单击右边的编辑，如果右边的编辑是灰色的，将库列表上边的“使用默认的系统库” (use default system libraries) 的复选框取消选择。
6. 在弹出的对象框中，上边是使用解压后的文件来进行帮助，下面使用未解压的压缩包帮助。
7. 我们使用未解压的压缩包，选择下面的 javaDoc in Archive.
8. 需要输入两个内容，一个是压缩包所在的位置 (Archive Path ), 可以选择右边的浏览选择，第二个是压缩包里面的路径 ( Paht within Archive)，也可以使用右边的浏览进行选择，一直到 api 文件夹为止。完成后，在浏览的下面有一个检验的按钮 (validate) 可以进行检查。
9. 完成后，确定关闭。

现在，在 Java 编辑器中选中一个系统的方法，按 F1 即可在帮助窗口中看到对应的 JavaDoc 的帮助入口，点击后，就可以直接看到对应的 JavaAPI 的 Doc 了。