1 java,javac,jar 命令

源代碼目錄

src

src/javactest/pa/A.java

src/javactest/pb/B.java

其中A引用B

類目錄

classes

src 和classes目錄同級，假設父目錄為test

（一）關于javac

   （1）先編譯B再編譯A

     cd test

     javac -d classes src/javactest/pb/B.java

     javac -cp classes src/javactest/pa/A.java

   （2）使用sourcepath編譯A,如果java有變更，會重新編譯

     cd test

     javac -d classes -sourcepath src src/javactest/pa/A.java

     或

     javac -d classes -sourcepath src -cp classes src/javactest/pa/A.java

（二）關于jar

   （1）創(chuàng)建jar

i）

     cd classes

     jar cvf javactest.jar .

則jar包生成在classes目錄下

     ii)

     cd test

     jar cvf javactest.jar –C classes .

則jar包生成在test目錄下

注意-C classes相當于把當前路徑改為classes，jar包中不會出現(xiàn)classes目錄。

如果：

cd test

    jar cvf javactest.jar classes

這里有問題，jar中會將classes目錄加入

iii) 以自己的manifest.mf來創(chuàng)建jar，在test目錄下創(chuàng)建manifest.mf文件

cd test

     jar cvfm javactest.jar manifest.mf –C classes .

（2）列出jar中內容

   cd test

   jar tvf javactest.jar

（3）提取jar中內容

   cd test

   jar xvf javactest.jar META-INF/MANIFEST.MF

 （3）更新jar

cd test

jar –uvf javactest.jar images/icon_button.gif

加入images/icon_button.gif

注意：不能加入META-INF/MANIFEST.MF

（4）更新MANIFEST.MF

修改MANIFEST.MF,加入

Main-Class: javactest.pa.A

注意：Main-Class后的冒號后必須有空格，并且最后必須換行

cd test

jar uvfm javactest.jar META-INF/MANIFEST.MF

（三）關于java

   java –jar javactest.jar

java -cp javactest.jar javactest.pa.A

參考資料

http://www.idevelopment.info/data/Programming/java/miscellaneous_java/Using_CLASSPATH_and_SOURCEPATH.html

http://www.idevelopment.info/data/Programming/java/miscellaneous_java/Using_CLASSPATH_and_Other_APIs.pdf

http://www.idevelopment.info/data/Programming/java/miscellaneous_java/Using_the_JAR_Utility.pdf

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html

http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html

2 jar file specification

http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html

NamedDispatcher

Returns a RequestDispatcher object that acts as a wrapper for the named servlet.

getNamedDispatcher(String) method takes the name of the Servlet as parameter which is declared via Deployment descriptor.

Example: Deployment Descriptor


<servlet>
    <servlet-name>FirstServlet</servlet-name>
    <servlet-class>com.example.ServletExample</servlet-class>
</servlet>


 RequestDispatcher dispatch = request.getNamedDispatcher(?FirstServlet??);

Note: A servlet instance can determine its name using servletConfig.getServletName(); This method returns the name of the class that implements the Servlet interface or extends the HttpServlet class.

RequestDispatcher

Returns a RequestDispatcher object that acts as a wrapper for the resource located at the given path.

 RequestDispatcher dispatch = request.getRequestDispatcher("/tes");

Here "/tes" represents the url-pattern element value of the servlet class.


<servlet-mapping>
    <servlet-name>Test</servlet-name>
    <url-pattern>/tes</url-pattern>
</servlet-mapping>


It represents the path of the servlet class. Since both the base as well as target servlet are in the same package structure by just specifying the url-pattern element value we will be able to access the target servlet.

We shouldn't specify the entire path like

 String str = "/WEB-INF/classes/com/example/posr/Test"

 RequestDispatcher dispatch = request.getRequestDispatcher(str);

To forward a request to a JSP page we use

 RequestDispatcher dispatch = request.getRequestDispatcher("/TestJspOne.jsp");

Is Tomcat an application server?

What's the difference between Tomcat and JBoss/Geronimo?

In the strictest sense, one could say: A web server serves up static HTML pages and nothing else. Tomcat is a Servlet/JSP container, and 'Java application servers' are those which support the full JEE (formerly J2EE) stack.

The distinctions between these terms, however, have always been blurry, and continue to become more so over time, and will vary depending on where and with whom your discussion takes place. To understand this requires a little history lesson.

Tomcat started its life as the JServ module for Apache HTTPD (now known as the Apache web server). It was only a servlet container and was incapable of handling web requests on its own. When combined, HTTPD would handle all web requests, would serve up all the static content on its own and forward any dynamic requests to JServ. Httpd was the web server and JServ was the servlet container.

Eventually, JServ was replaced by the Tomcat application server, and a connector was added that allowed Tomcat to operate as a standalone web/application server. At the time Tomcat alone was not fast enough for use in heavy traffic production environments, and didn't support SSL so it was standard practice to combine Tomcat with the Apache web server; much in the same way that JServ and httpd were used. This is still not uncommon today and there are still valid reasons for wanting to do so.

Over time, both Tomcat and the Java Virtual machine, with its Just In Time compiler, have made huge gains in performance, and in many cases running Tomcat as a standalone application server is just as fast or faster than running it in conjunction with the Apache web server. (Testing your application in both configurations under load is the only way to know for sure). Tomcat also has full support for SSL.

So, as you can see, in the case of Tomcat, the lines between application server and web server have blurred over the years.

The lines are also somewhat blurry when you look at the Apache web server itself. It has been hosting large commercial applications using CGI (Common Gateway Interface) for over a dozen years. In addition, many modules, such as the one that allows the popular PHP scripting language to run natively, have become almost standard in an Apache web server installation.

Another popular web/application server, Microsoft's IIS (Internet Information Server), is also used as both a web server and application server. It too can be configured to pass requests for dynamic content to Tomcat via an ISAPI filter. It can also be configured to support popular scripting languages such as PHP, and has native support for Microsoft's own ASP and ASP.NET platforms. Here also, the distinction between web server and application server is blurry.

In some circles, in order to qualify as a "Java application server" the server must support the entire JEE (formerly known as J2EE) stack. Tomcat does not do this. It does not support EJB (Enterprise Java Beans), amongst other APIs. JBoss and Apache's Geronimo application server do support the entire JEE stack. Their servlet and JSP capabilities come from an embedded version of Tomcat (or some other servlet container).

Since one actually contains and relies on the other, the question "Which is better - Tomcat or JBoss" or the phrase, "Tomcat vs JBoss" is not answerable. They are not legitimate comparisons.

Many large, commercial applications are hosted on Tomcat; both with and without an external HTTP web server and without EJB.

UTF-8 字符處理在 Web 開發(fā)中的應用

文檔選項 未顯示需要 JavaScript 的文檔選項 將此頁作為電子郵件發(fā)送

級別： 初級

殷 健, 軟件工程師，IBM CSDL

2006 年 7 月 27 日

Web 應用要適應多語言的需求。不同國家的用戶應該可以輸入本國語言的字符， 同時 Web 應用又應該可以根據(jù)不同的區(qū)域設置來用多國語言顯示頁面。 當前，不同的語言有不同的編碼方式來顯示對應的語言信息，例如中文可以用 GB2312 編碼來顯示,日文可以用 Shift-JIS 編碼來顯示。但 UTF-8 編碼方式幾乎可以包括了所有的語言字符。用 UTF-8 編碼來處理 Web 應用信息的輸入和顯示可以使不同 Web 應用之間的信息交互標準化，并且可以簡化應用的開發(fā)過程。

UTF-8 編碼介紹

UTF-8 編碼是一種被廣泛應用的編碼，這種編碼致力于把全球的語言納入一個統(tǒng)一的編碼，目前已經將幾種亞洲語言納入。UTF 代表 UCS Transformation Format.

UTF-8 采用變長度字節(jié)來表示字符，理論上最多可以到 6 個字節(jié)長度。UTF-8 編碼兼容了 ASC II(0-127)， 也就是說 UTF-8 對于 ASC II 字符的編碼是和 ASC II 一樣的。對于超過一個字節(jié)長度的字符，才用以下編碼規(guī)范：

左邊第一個字節(jié)1的個數(shù)表示這個字符編碼字節(jié)的位數(shù)，例如兩位字節(jié)字符編碼樣式為為：110xxxxx 10xxxxxx； 三位字節(jié)字符的編碼樣式為：1110xxxx 10xxxxxx 10xxxxxx.；以此類推，六位字節(jié)字符的編碼樣式為：1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx。 xxx 的值由字符編碼的二進制表示的位填入。只用最短的那個足夠表達一個字符編碼的多字節(jié)串。例如：

Unicode 字符： 00 A9（版權符號） = 1010 1001， UTF-8 編碼為：11000010 10101001 = 0x C2 0xA9; 字符 22 60 (不等于符號) = 0010 0010 0110 0000， UTF-8 編碼為：11100010 10001001 10100000 = 0xE2 0x89 0xA0

回頁首

HTTP 通訊協(xié)議

HTTP 請求

在 HTTP 通訊中，在客戶端發(fā)出的請求報文中，首先設置的是方法。方法是用來告訴服務器客戶端發(fā)起的動作請求。在請求的報文頭部，客戶端還可以同時發(fā)送附加的信息， 比如客戶端使用的瀏覽器和客戶端可以解釋的內容類型等。這些信息可以被服務器端應用程序使用以生成響應。下面是一個 HTTP 請求消息的示例：

GET /intro.html HTTP/1.0

                        User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)

                        Accept: image/gif, image/jpeg, text/*, */*

                        Accept-language : zh

                        Accept-Charset: iso-8859-1

                        

這個請求通過 GET 方法來獲取資源 /intro.htm。User-Agent 提供了客戶端瀏覽器的信息，同時 Accept 提供了客戶端可以接受的媒體類型。Accep-language 指出了客戶端瀏覽器的首選語言， Accept-Charset 提供了瀏覽器的首選字符集，服務器端程序能夠根據(jù)客戶端的要求來生成需要的響應。 用戶可以通過配置瀏覽器來設置首選語言。以 IE 為示例如下：

當瀏覽器發(fā)出請求后，可以通過以下代碼來讀取客戶端瀏覽器的首選語言和國家代碼。

protected void insertproc(HttpServletRequest req, HttpServletResponse resp)

                        throws ServletException, IOException{

                        Locale reqLocal = req.getLocale();

                        System.out.println("The country is :" + reqLocal.getCountry());

                        System.out.println("The language is :" + reqLocal.getLanguage());

                        

服務器端的輸出結果為：

[06-3-10 14:56:32:516 CST] 6ce078f9 SystemOut     O The country is :CN

                        [06-3-10 14:56:32:516 CST] 6ce078f9 SystemOut     O The language is :zh

                        

HTTP 響應

當服務器端收到請求后，會處理請求并發(fā)回應答。服務器通過應答消息的頭部來指明諸如服務器軟件和相應的內容類型等信息。以下是一個應答消息頭的示例：

Date: Saturday, 23-May-98 03:25:12 GMT

                        Server: JavaWebServer/1.1.1

                        MIME-version: 1.0

                        Content-type: text/html; charset=UTF-8

                        Content-length: 1029

                        Last-modified: Thursday, 7-May-98 12:15:35 GMT

                        

Content-type 表明了應答消息的 MIME 類型和應答消息體的字符集，瀏覽器會用相應的字符集來顯示消息內容。例如，在以上示例中字符集是 UTF-8，瀏覽器會用 UTF-8 編碼來解析和現(xiàn)實返回的消息體。同時頁面輸入也會被用 UTF-8 編碼。

回頁首

Web 頁面顯示編碼

可以通過以下幾種方式來設置內容類型。

在 HTML 中設置頁面的編碼方式

如果被訪問的是一個靜態(tài)的 HTML 頁面。可以通過以下方式來設置頁面的編碼方式。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

                        <HTML>

                        <HEAD>

                        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">

                        <TITLE>example.html</TITLE>

                        </HEAD>

                        <BODY>

                        </BODY>

                        </HTML>

                        

標記"<META http-equiv="Content-Type" content="text/html; charset=UTF-8">" 將應答消息頭中 Content_type 設置為"text/html; charset=UTF-8".

在 Servlet 中設置頁面顯示編碼方式

在 Servlet 中，我們可以通過以下方式來設置應答消息的內容類型。

protected void insertproc(HttpServletRequest req, HttpServletResponse resp)

                        throws ServletException, IOException{

                        resp.setContentType("text/html;charset=UTF-8");

                        

代碼行"resp.setContentType("text/html;charset=UTF-8");"將應答消息頭中 Content_type 設置為"text/html; charset=UTF-8"。

在 JSP 中設置頁面顯示編碼方式

我們通過以下示例說明如何在 JSP 中設置頁面的編碼格式。

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

                        

在這行的頁面指令中的"text/html; charset=UTF-8"將應答消息中的"Content-type" 設置為"text/html; charset=UTF-8"。

"pageEncoding"只是指明了 JSP 頁面本身的編碼格式，指明了 JSP 是以什么編碼方式保存。容器在讀取文件時將起轉化為內部使用的 Unicode. 當應答發(fā)送回至瀏覽器時，容器會將內部使用的 Unicode 轉化為在 Content-type 中指定的字符集。

如果沒有指定 PageEncoding，可以通過使用 Content-type 指定的字符集來解釋 JSP 頁面字節(jié)。

為了能正常顯示 UTF-8 編碼的字符，要滿足以下兩個條件：

1. 通知瀏覽器應答消息使用的字符集。

2. 配置瀏覽器使其能有正常顯示 UTF-8 編碼的字體。

回頁首

Web 頁面輸入編碼

HTML 的表單可以接受非西歐語言字符的輸入。當需要創(chuàng)建一個需要接受非西歐語言字符輸入的表單時，必須通知瀏覽器應該為用戶輸入使用哪個字符集，我們可以通過設置 page 指令的 contentType 屬性來設置。

我們需要注意的是，當表單被提交后，瀏覽器會將表單字段值轉換為指定字符集對應的字節(jié)值，然后根據(jù) HTTP 標準 URL 編碼方案對結果字節(jié)進行編碼。當使用 ISO-8859-1 編碼時，任何 a 到 z， A 到 Z 和 0 到 9 之外的字符都會被轉化為十六進制格式的字節(jié)值，并在前面加上一個百分號（%）.例如，如果表單的字符集被設為 UTF-8, 字符"中文"被傳遞的編碼格式為："%E4%B8%AD%E6%96%87"。為了對輸入的信息進行處理，容器必須知道瀏覽器是使用什么字符集對輸入進行 編碼的。問題是當今多數(shù)的瀏覽器并不提供這種信息，因此你必須自己提供這種信息，并告訴容器用哪個字符集對輸入進行解碼。

頁面輸入編碼設定

在本文第3部分中說明了如何設置頁面的顯示編碼，在設置頁面編碼的同時，也就指定了頁面的輸入方式。如果頁面的顯示被設置為UTF-8，那么用戶所有的頁面輸入都會按照 UTF-8 編碼。

頁面輸入輸出過程編碼設置

服務器端程序在讀取表單輸入之前要設定輸入編碼。我們可以看一下示例。

以下是一個用來提示用戶輸入的 JSP 頁面：

<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

                        <HTML>

                        <HEAD>

                        <TITLE>insertdb.jsp</TITLE>

                        </HEAD>

                        <BODY>

                        <P>

                        <FORM METHOD=POST ACTION="./InsertDbProcDs">

                        <TABLE>

                        <TR>

                        <TD>Name:</TD>

                        <TD><input type="text" name="col2" value=""></TD>

                        <TR>

                        <TD><INPUT type="submit" value="submit"></TD>

                        </TR>

                        </TR>

                        </TABLE>

                        </RORM>

                        </P>

                        </BODY>

                        </HTML>

                        

頁面指令元素的屬性 Content-type 值為"text/html; charset=UTF-8"，這會向瀏覽器指明頁面是按照 UTF-8 編碼的，并且所有用戶通過頁面的輸入也會按照 UTF-8 編碼。被 Action 所觸發(fā)的 Servlet 如下例所示。

    protected void insertproc(HttpServletRequest req, HttpServletResponse resp)

                        throws ServletException, IOException{

                        String test1 = req.getParameter("col2");

                        PrintWriter out = resp.getWriter();

                        resp.setContentType("text/html;charset=UTF-8");

                        out.println("<HTML>");

                        out.println("The input is " + test1);

                        out.println("</HTML>");

                        

                        

通過表單頁面輸入"中文"并提交表單，得到的結果為：

如果我們注釋掉語句：resp.setContentType("text/html;charset=UTF-8")， 如下例：

protected void insertproc(HttpServletRequest req, HttpServletResponse resp)

                        throws ServletException, IOException{

                        String test1 = req.getParameter("col2");

                        PrintWriter out = resp.getWriter();

                        //resp.setContentType("text/html;charset=UTF-8")

                        out.println("<HTML>");

                        out.println("The input is " + test1);

                        out.println("</HTML>");

                        

輸入"中文"并提交表單，得到的結果為：

頁面不能正確顯示 UTF-8 編碼的字符。

在被觸發(fā)的 Servlet 中通過設置 resp.setContentType("text/html;charset=UTF-8") 來向瀏覽器指明輸出的編碼字符集為 UTF-8，瀏覽器會用正確的字符集來顯示輸出。如果 Servlet 中沒有顯示的調用 resp.setContentType("text/html;charset=UTF-8") 來設定輸出字符集，瀏覽器將不能正確的解碼和顯示輸出。

回頁首

結論

本文給出了一些在 Web 應用開發(fā)中如何顯示和輸入 UTF-8 編碼字符的方法。便于讀者在開發(fā)實踐中參考。

參考資料

• 參考資源：
  Java Servlet Programming()
  Java server Pages()
  
  
  
• 相關資源：
  在developerworks 關于字符編碼的文章：
  JAVA 編程／WAS 對多語言（雙字節(jié)）的支持
  Java 編程技術中漢字問題的分析及解決
  JSP/Servlet 中的漢字編碼問題

 關于UTF8,UTF16,UTF32,UTF16-LE,UTF16-BE

        Unicode 是Unicode.org制定的編碼標準，目前得到了絕大部分操作系統(tǒng)和編程語言的支持。Unicode.org官方對Unicode的定義是： Unicode provides a unique number for every character。可見，Unicode所做的是為每個字符定義了一個相應的數(shù)字表示。比如，“a“的Unicode值是0x0061,“一”的 Unicde值是0x4E00，這是最簡單的情況，每個字符用2個字節(jié)表示。

        Unicode.org定義了百萬個以上的 字符，如果將所有的字符用統(tǒng)一的格式表示，需要的是4個字節(jié)。“a“的Unicode表示就會變成0x00000061，而“一“的Unicode值是 0x00004E00。實際上，這就是UTF32，Linux操作系統(tǒng)上所使用的Unicode方案。

        但是，仔細分析可 以發(fā)現(xiàn)，其實絕大部分字符只使用2個字節(jié)就可以表示了。英文的Unicode范圍是0x0000-0x007F，中文的Unicode范圍是0x4E00 -0x9F**，真正需要擴展到4個字節(jié)來表示的字符少之又少，所以有些系統(tǒng)直接使用2個字節(jié)來表示Unicode。比如Windows系統(tǒng)上， Unicode就是兩個字節(jié)的。對于那些需要4個字節(jié)才能表示的字符，使用一種代理的手法來擴展(其實就是在低兩個字節(jié)上做一個標記，表示這是一個代理， 需要連接上隨后的兩個字節(jié)，才能組成一個字符)。這樣的好處是大量的節(jié)約了存取空間，也提高了處理的速度。這種Unicode表示方法就是UTF16。一 般在Windows平臺上，提到Unicode,那就是指UTF16了。
        
        至于UTF16-LE和 UTF16-BE，與計算機的CPU構架有關。LE指Little Endian，而BE指Big Endian。關于這方面的信息，網上有很多相關的帖子。我們一般的X86系統(tǒng)都是Little Endian的，可以認為UTF16=UTF16-LE.

        由于對于歐洲和北美，實際上使用的編碼范圍在0x0000- 0x00FF之間，只需要一個字符就可以表示所有的字符。即使是使用UTF16來作為內存的存取方式，還是會帶來巨大的空間浪費，因此就有了UTF8的編 碼方式。這是一種很靈活的編碼，對于只需要1個字節(jié)的字符，就使用一個字節(jié)，對于中日韓等原本需要兩個字節(jié)才能表示的字符，則通過一個UTF16－ UTF8的算法實現(xiàn)相互之間的轉換（一般需要3個字節(jié)才能表示），而對于需要4個字節(jié)才能表示的字符，UTF8可以擴展到6個字節(jié)每個字符。UTF8使用 的算法很有意思，大致映射關系如下：
        UTF-32                                    UTF8
        0x00000000 - 0x0000007F          0xxxxxxx 
         0x00000080 - 0x000007FF           110xxxxx 10xxxxxx
         0x00000800 - 0x0000FFFF          1110xxxx 10xxxxxx 10xxxxxx
         0x00010000 - 0x001FFFFF          11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
         0x00200000 - 0x03FFFFFF          111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
         0x04000000 - 0x7FFFFFFF          1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 
        可以發(fā)現(xiàn)這和IP的分址算法很是相像。
        由于UTF8可以方便的轉換為UTF16和UTF32（不需要碼表，轉換算法可以在Unicode.org上找到C代碼）。而且UTF8在每個操作系統(tǒng)平臺上的實現(xiàn)都是一樣的，也不存在跨平臺的問題，所以UTF8成為跨平臺的Unicode很好的解決方案。當然，對于中文來說，由于每個字符需要3個字節(jié)才能表示，還是有點浪費的。
        
            
        

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=160958