1 java,javac,jar 命令

源代碼目錄

src

src/javactest/pa/A.java

src/javactest/pb/B.java

其中A引用B

類目錄

classes

src 和classes目錄同級(jí)，假設(shè)父目錄為test

（一）關(guān)于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有變更，會(huì)重新編譯

     cd test

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

     或

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

（二）關(guān)于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相當(dāng)于把當(dāng)前路徑改為classes，jar包中不會(huì)出現(xiàn)classes目錄。

如果：

cd test

    jar cvf javactest.jar classes

這里有問題，jar中會(huì)將classes目錄加入

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

cd test

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

（2）列出jar中內(nèi)容

   cd test

   jar tvf javactest.jar

（3）提取jar中內(nèi)容

   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后的冒號(hào)后必須有空格，并且最后必須換行

cd test

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

（三）關(guān)于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ā)中的應(yīng)用

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

級(jí)別： 初級(jí)

殷 健, 軟件工程師，IBM CSDL

2006 年 7 月 27 日

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

UTF-8 編碼介紹

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

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

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

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

回頁首

HTTP 通訊協(xié)議

HTTP 請(qǐng)求

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

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

                        

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

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

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());

                        

服務(wù)器端的輸出結(jié)果為：

[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 響應(yīng)

當(dāng)服務(wù)器端收到請(qǐng)求后，會(huì)處理請(qǐng)求并發(fā)回應(yīng)答。服務(wù)器通過應(yīng)答消息的頭部來指明諸如服務(wù)器軟件和相應(yīng)的內(nèi)容類型等信息。以下是一個(gè)應(yīng)答消息頭的示例：

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 表明了應(yīng)答消息的 MIME 類型和應(yīng)答消息體的字符集，瀏覽器會(huì)用相應(yīng)的字符集來顯示消息內(nèi)容。例如，在以上示例中字符集是 UTF-8，瀏覽器會(huì)用 UTF-8 編碼來解析和現(xiàn)實(shí)返回的消息體。同時(shí)頁面輸入也會(huì)被用 UTF-8 編碼。

回頁首

Web 頁面顯示編碼

可以通過以下幾種方式來設(shè)置內(nèi)容類型。

在 HTML 中設(shè)置頁面的編碼方式

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

<!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>

                        

標(biāo)記"<META http-equiv="Content-Type" content="text/html; charset=UTF-8">" 將應(yīng)答消息頭中 Content_type 設(shè)置為"text/html; charset=UTF-8".

在 Servlet 中設(shè)置頁面顯示編碼方式

在 Servlet 中，我們可以通過以下方式來設(shè)置應(yīng)答消息的內(nèi)容類型。

protected void insertproc(HttpServletRequest req, HttpServletResponse resp)

                        throws ServletException, IOException{

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

                        

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

在 JSP 中設(shè)置頁面顯示編碼方式

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

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

                        

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

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

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

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

1. 通知瀏覽器應(yīng)答消息使用的字符集。

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

回頁首

Web 頁面輸入編碼

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

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

頁面輸入編碼設(shè)定

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

頁面輸入輸出過程編碼設(shè)置

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

以下是一個(gè)用來提示用戶輸入的 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"，這會(huì)向?yàn)g覽器指明頁面是按照 UTF-8 編碼的，并且所有用戶通過頁面的輸入也會(huì)按照 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>");

                        

                        

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

如果我們注釋掉語句：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>");

                        

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

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

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

回頁首

結(jié)論

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

參考資料

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

 關(guān)于UTF8,UTF16,UTF32,UTF16-LE,UTF16-BE

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

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

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

        由于對(duì)于歐洲和北美，實(shí)際上使用的編碼范圍在0x0000- 0x00FF之間，只需要一個(gè)字符就可以表示所有的字符。即使是使用UTF16來作為內(nèi)存的存取方式，還是會(huì)帶來巨大的空間浪費(fèi)，因此就有了UTF8的編 碼方式。這是一種很靈活的編碼，對(duì)于只需要1個(gè)字節(jié)的字符，就使用一個(gè)字節(jié)，對(duì)于中日韓等原本需要兩個(gè)字節(jié)才能表示的字符，則通過一個(gè)UTF16－ UTF8的算法實(shí)現(xiàn)相互之間的轉(zhuǎn)換（一般需要3個(gè)字節(jié)才能表示），而對(duì)于需要4個(gè)字節(jié)才能表示的字符，UTF8可以擴(kuò)展到6個(gè)字節(jié)每個(gè)字符。UTF8使用 的算法很有意思，大致映射關(guān)系如下：
        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可以方便的轉(zhuǎn)換為UTF16和UTF32（不需要碼表，轉(zhuǎn)換算法可以在Unicode.org上找到C代碼）。而且UTF8在每個(gè)操作系統(tǒng)平臺(tái)上的實(shí)現(xiàn)都是一樣的，也不存在跨平臺(tái)的問題，所以UTF8成為跨平臺(tái)的Unicode很好的解決方案。當(dāng)然，對(duì)于中文來說，由于每個(gè)字符需要3個(gè)字節(jié)才能表示，還是有點(diǎn)浪費(fèi)的。
        
            
        

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