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 了。