JAVA网页编程之深切分析JSP和Servlet对中文的处置
java也能做一些底层语言开发做的事情（难度很高，不是java顶尖高手是做不来的），js|servlet|中文天下上的各区域都有当地的言语。区域差别间接招致了言语情况的差别。在开辟一个国际化程序的过程当中，处置言语成绩就显得很主要了。这是一个天下局限内都存在的成绩，以是，Java供应了天下性的办理办法。本文形貌的办法是用于处置中文的，可是，推而广之，关于处置天下上别的国度和区域的言语一样合用。
汉字是双字节的。所谓双字节是指一个双字要占用两个BYTE的地位（即16位），分离称为高位和低位。中国划定的汉字编码为GB2312，这是强迫性的，今朝几近一切的能处置中文的使用程序都撑持GB2312。GB2312包含了一二级汉字和9区标记，高位从0xa1到0xfe，低位也是从0xa1到0xfe，个中，汉字的编码局限为0xb0a1到0xf7fe。
别的有一种编码，叫做GBK，但这是一份标准，不是强迫的。GBK供应了20902个汉字，它兼容GB2312，编码局限为0x8140到0xfefe。GBK中的一切字符都能够逐一映照到Unicode2.0。
在不久的未来，中国会公布另外一种尺度：GB18030-2000（GBK2K）。它收录了躲、蒙等多数平易近族的字型，从基本上办理了字位不敷的成绩。注重：它不再是定长的。其二字节部分与GBK兼容，四字节部分是扩大的字符、字形。它的首字节和第三字节从0x81到0xfe，二字节和第四字节从0x30到0x39。
本文不盘算先容Unicode，有乐趣的能够扫瞄“http://www.unicode.org/”检察更多的信息。Unicode有一个特征：它包含了天下上一切的字符字形。以是，各个区域的言语都能够创建与Unicode的映照干系，而Java恰是使用了这一点以到达异种言语之间的转换。
在JDK中，与中文相干的编码有：
表1 JDK中与中文相干的编码列表
编码称号申明ASCII7位，与ascii7不异ISO8859-18-位，与8859_1,ISO-8859-1,ISO_8859-1,latin1...等不异GB2312-8016位，与gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381,1383,Cp1383,ISO2022CN,ISO2022CN_GB...等不异GBK与MS936不异，注重：辨别巨细写UTF8与UTF-8不异GB18030与cp1392、1392不异，今朝撑持的JDK很少
在实践编程时，打仗得对照多的是GB2312（GBK）和ISO8859-1。
为何会有“?”号
上文说过，异种言语之间的转换是经由过程Unicode来完成的。假定有两种分歧的言语A和B，转换的步骤为：先把A转化为Unicode，再把Unicode转化为B。
举例申明。有GB2312中有一个汉字“李”，其编码为“C0EE”，欲转化为ISO8859-1编码。步骤为：先把“李”字转化为Unicode，失掉“674E”，再把“674E”转化为ISO8859-1字符。固然，这个映照不会乐成，由于ISO8859-1中基本就没有与“674E”对应的字符。
当映照不乐成时，成绩就产生了！当从某言语向Unicode转化时，假如在某言语中没有该字符，失掉的将是Unicode的代码“uffffd”（“u”暗示是Unicode编码，）。而从Unicode向某言语转化时，假如某言语没有对应的字符，则失掉的是“0x3f”（“?”）。这就是“?”的由来。
比方：把字符流buf=“0x800x400xb00xa1”举行newString(buf,"gb2312")操纵，失掉的了局是“ufffdu554a”，再println出来，失掉的了局将是“?啊”，由于“0x800x40”是GBK中的字符，在GB2312中没有。
再如，把字符串String="u00d6u00ecu00e9u0046u00bbu00f9"举行newString(buf.getBytes("GBK"))操纵，失掉的了局是“3fa8aca8a6463fa8b4”，个中，“u00d6”在“GBK”中没有对应的字符，失掉“3f”，“u00ec”对应着“a8ac”，“u00e9”对应着“a8a6”，“0046”对应着“46”（由于这是ASCII字符），“u00bb”没找到，失掉“3f”，最初，“u00f9”对应着“a8b4”。把这个字符串println一下，失掉的了局是“?ìéF?ù”。看到没？这里其实不满是问号，由于GBK与Unicode映照的内容中除汉字外另有字符，本例就是最好的明证。
以是，在汉字转码时，假如产生庞杂，失掉的纷歧建都是问号噢！不外，错了毕竟是错了，50步和100步并没有质的不同。
大概会问：假如源字符会合有，而Unicode中没有，了局会怎样？回覆是不晓得。由于我手头没有能做这个测试的源字符集。但有一点是一定的，那就是源字符集不敷标准。在Java中，假如产生这类情形，是会抛出非常的。
甚么是UTF
UTF，是UnicodeTextFormat的缩写，意为Unicode文本格局。关于UTF，是如许界说的：
（1）假如Unicode的16位字符的头9位是0，则用一个字节暗示，这个字节的首位是“0”，剩下的7位与原字符中的后7位不异，如“u0034”（0000000000110100），用“34”(00110100)暗示；（与源Unicode字符是不异的）；
（2）假如Unicode的16位字符的头5位是0，则用2个字节暗示，首字节是“110”开首，前面的5位与源字符中撤除头5个零后的最高5位不异；第二个字节以“10”开首，前面的6位与源字符中的低6位不异。如“u025d”（0000001001011101），转化后为“c99d”（1100100110011101）；
（3）假如不切合上述两个划定规矩，则用三个字节暗示。第一个字节以“1110”开首，后四位为源字符的高四位；第二个字节以“10”开首，后六位为源字符两头的六位；第三个字节以“10”开首，后六位为源字符的低六位；如“u9da7”（1001110110100111），转化为“e9b6a7”（111010011011011010100111）；
能够这么形貌JAVA程序中Unicode与UTF的干系，固然不停对：字符串在内存中运转时，体现为Unicode代码，而当要保留到文件或别的介质中往时，用的是UTF。这个转化历程是由writeUTF和readUTF来完成的。
好了，基本性的叙述差未几了，上面进进正题。
先把这个成绩想成是一个黑匣子。先看黑匣子的一级暗示：
input(charsetA)-＞process(Unicode)-＞output(charsetB)
复杂，这就是一个IPO模子，即输出、处置和输入。一样的内容要经由“从charsetA到unicode再到charsetB”的转化。
再看二级暗示：
SourceFile(jsp,java)-＞class-＞output
在这个图中，能够看出，输出的是jsp和java源文件，在处置过程当中，以Class文件为载体，然后输入。再细化到三级暗示：
jsp-＞tempfile-＞class-＞browser,osconsole,db
app,servlet-＞class-＞browser,osconsole,db
这个图就更分明了。Jsp文件师长教师成两头的Java文件，再天生Class。而Servlet和一般App则间接编译天生Class。然后，从Class再输入到扫瞄器、把持台或数据库等。
JSP：从源文件到Class的历程
Jsp的源文件是以“.jsp”开头的文本文件。在本节中，将论述JSP文件的注释和编译历程，并跟踪个中的中文变更。
1、JSP/Servlet引擎供应的JSP转换工具（jspc）搜刮JSP文件顶用＜%@pagecontentType="text/html;charset=＜Jsp-charset＞"%＞中指定的charset。假如在JSP文件中未指定＜Jsp-charset＞，则取JVM中的默许设置file.encoding，一样平常情形下，这个值是ISO8859-1；
2、jspc用相称于“javacCencoding＜Jsp-charset＞”的命令注释JSP文件中呈现的一切字符，包含中笔墨符和ASCII字符，然后把这些字符转换成Unicode字符，再转化成UTF格局，存为JAVA文件。ASCII码字符转化为Unicode字符时只是复杂地在后面加“00”，如“A”，转化为“u0041”（不必要来由，Unicode的码表就是这么编的）。然后，经由到UTF的转换，又变回“41”了！这也就是可使用一般文本编纂器检察由JSP天生的JAVA文件的缘故原由；
3、引擎用相称于“javacCencodingUNICODE”的命令，把JAVA文件编译成CLASS文件；
先看一下这些过程当中中笔墨符的转换情形。有以下源代码：
＜%@pagecontentType="text/html;charset=gb2312"%＞
＜html＞＜body＞
＜%
Stringa="中文";
out.println(a);
%＞
＜/body＞＜/html＞
这段代码是在UltraEditforWindows上编写的。保留后，“中文”两个字的16进制编码为“D6D0CEC4”（GB2312编码）。经查表，“中文”两字的Unicode编码为“u4E2Du6587”，用UTF暗示就是“E4B8ADE69687”。翻开引擎天生的由JSP文件变化而成的JAVA文件，发明个中的“中文”两个字的确被“E4B8ADE69687”替换了，再检察由JAVA文件编译天生的CLASS文件，发明了局与JAVA文件中的完整一样。
再看JSP中指定的CharSet为ISO-8859-1的情形。
＜%@pagecontentType="text/html;charset=ISO-8859-1"%＞
＜html＞＜body＞
＜%
Stringa="中文";
out.println(a);
%＞
＜/body＞＜/html＞
一样，该文件是用UltraEdit编写的，“中文”这两个字也是存为GB2312编码“D6D0CEC4”。先摹拟一下天生的JAVA文件和CLASS文件的历程：jspc用ISO-8859-1来注释“中文”，并把它映照到Unicode。因为ISO-8859-1是8位的，且是拉丁语系，其映照划定规矩就是在每一个字节前加“00”，以是，映照后的Unicode编码应为“u00D6u00D0u00CEu00C4”，转化成UTF后应当是“C396C390C38EC384”。好，翻开文件看一下，JAVA文件和CLASS文件中，“中文”公然都暗示为“C396C390C38EC384”。
假如上述代码中不指定＜Jsp-charset＞，即把第一行写成“＜%@pagecontentType="text/html"%＞”，JSPC会利用file.encoding的设置来注释JSP文件。在RedHat6.2上，其处置了局与指定为ISO-8859-1是完整不异的。
到如今为止，已注释了从JSP文件到CLASS文件的变化过程当中中笔墨符的映照历程。一句话：从“JspCharSet到Unicode再到UTF”。下表总结了这个历程：
表2 “中文”从JSP到CLASS的转化历程
Jsp-CharSetJSP文件中JAVA文件中CLASS文件中GB2312D6D0CEC4(GB2312)从u4E2Du6587(Unicode)到E4B8ADE69687(UTF)E4B8ADE69687(UTF)ISO-8859-1D6D0CEC4
(GB2312)从u00D6u00D0u00CEu00C4(Unicode)到C396C390C38EC384(UTF)C396C390C38EC384(UTF)无（默许＝file.encoding）同ISO-8859-1同ISO-8859-1同ISO-8859-1
下节先会商Servlet从JAVA文件到CLASS文件的转化历程，然后再注释从CLASS文件怎样输入到客户端。之以是如许布置，是由于JSP和Servlet在输入时处置办法是一样的。
Servlet：从源文件到Class的历程
Servlet源文件是以“.java”开头的文本文件。本节将会商Servlet的编译历程并跟踪个中的中文变更。
用“javac”编译Servlet源文件。javac能够带“-encoding＜Compile-charset＞”参数，意义是“用＜Compile-charset＞中指定的编码来注释Serlvet源文件”。
源文件在编译时，用＜Compile-charset＞来注释一切字符，包含中笔墨符和ASCII字符。然后把字符常量变化成Unicode字符，最初，把Unicode变化成UTF。
在Servlet中，另有一个中央设置输入流的CharSet。一般在输入了局前，挪用HttpServletResponse的setContentType办法来到达与在JSP中设置＜Jsp-charset＞一样的效果，称之为＜Servlet-charset＞。
注重，文中一共提到了三个变量：＜Jsp-charset＞、＜Compile-charset＞和＜Servlet-charset＞。个中，JSP文件只与＜Jsp-charset＞有关，而＜Compile-charset＞和＜Servlet-charset＞只与Servlet有关。
看下例：
importjavax.servlet.*;
importjavax.servlet.http.*;
classtestServletextendsHttpServlet
{
publicvoiddoGet(HttpServletRequestreq,HttpServletResponseresp)
throwsServletException,java.io.IOException
{
resp.setContentType("text/html;charset=GB2312");
java.io.PrintWriterout=resp.getWriter();
out.println("＜html＞");
out.println("#中文#");
out.println("＜/html＞");
}
}
该文件也是用UltraEditforWindows编写的，个中的“中文”两个字保留为“D6D0CEC4”（GB2312编码）。
入手下手编译。下表是＜Compile-charset＞分歧时，CLASS文件中“中文”两字的十六进制码。在编译过程当中，＜Servlet-charset＞不起任何感化。＜Servlet-charset＞只对CLASS文件的输入发生影响，实践上是＜Servlet-charset＞和＜Compile-charset＞一同，到达与JSP文件中的＜Jsp-charset＞不异的效果，由于＜Jsp-charset＞对编译和CLASS文件的输入城市发生影响。
表3 “中文”从Servlet源文件到Class的变化历程
Compile-charsetServlet源文件中Class文件中等效的Unicode码GB2312D6D0CEC4
(GB2312)E4B8ADE69687(UTF)u4E2Du6587(在Unicode中＝“中文”)ISO-8859-1D6D0CEC4
(GB2312)C396C390C38EC384(UTF)u00D6u00D0u00CEu00C4(在D6D0CEC4后面各加了一个00)无（默许）D6D0CEC4(GB2312)同ISO-8859-1同ISO-8859-1
一般Java程序的编译历程与Servlet完整一样。
CLASS文件中的中文暗示法是否是昭然若揭了？OK，接上去看看CLASS又是如何输入中文的呢？
Class：输入字符串
上文说过，字符串在内存中体现为Unicode编码。至于这类Unicode编码暗示了甚么，那要看它是从哪一种字符集映照过去的，也就是说要看它的先人。这比如在托运转李时，表面都是纸箱子，内里装了甚么就要看寄邮件的人实践邮了甚么工具。
看看下面的例子，假如给一串Unicode编码“00D600D000CE00C4”，假如不作转换，间接用Unicode码表来对比它时，是四个字符（并且是特别字符）；假设把它与“ISO8859-1”举行映照，则间接往失落后面的“00”便可失掉“D6D0CEC4”，这是ASCII码表中的四个字符；而假设把它看成GB2312来举行映照，失掉的了局极可能是一年夜堆乱码，由于在GB2312中有大概没有（也有大概有）字符与00D6等字符对应（假如对应不上，将失掉0x3f，也就是问号，假如对应上了，因为00D6等字符太靠前，估量也是一些特别标记，真实的汉字在Unicode中的编码从4E00入手下手）。
列位看到了，一样的Unicode字符，能够注释成分歧的模样。固然，这个中有一种是我们希冀的了局。以上例而论，“D6D0CEC4”应当是我们所想要的，当把“D6D0CEC4”输入到IE中时，用“简体中文”体例检察，就可以看到分明的“中文”两个字了。（固然了，假如你必定要用“西欧字符”来看，那也没举措，你将得不就任何有什么时候何地的工具）为何呢？由于“00D600D000CE00C4”原本就是由ISO8859-1转化已往的。
给出以下结论：
在Class输入字符串前，会将Unicode的字符串依照某一种内码从头天生字撙节，然后把字撙节输出，相称于举行了一步“String.getBytes(???)”操纵。???代表某一种字符集。
假如是Servlet，那末，这类内码就是在HttpServletResponse.setContentType()办法中指定的内码，也就是上订婚义的＜Servlet-charset＞。
假如是JSP，那末，这类内码就是在＜%@pagecontentType=""%＞中指定的内码，也就是上订婚义的＜Jsp-charset＞。
假如是Java程序，那末，这类内码就是file.encoding中指定的内码，默许为ISO8859-1。
当输入对象是扫瞄器时
以盛行的扫瞄器IE为例。IE撑持多种内码。假设IE吸收到了一个字撙节“D6D0CEC4”，你能够实验用各类内码往检察。你会发明用“简体中文”时能失掉准确的了局。由于“D6D0CEC4”原本就是简体中文中“中文”两个字的编码。
OK，完全地看一遍。
JSP：源文件为GB2312格局的文本文件，且JSP源文件中有“中文”这两个汉字
假如指定了＜Jsp-charset＞为GB2312，转化历程以下表。
表4 Jsp-charset=GB2312时的变更历程
序号步骤申明了局1编写JSP源文件，且存为GB2312格局D6D0CEC4
（D6D0=中CEC4=文）2jspc把JSP源文件转化为一时JAVA文件，并把字符串依照GB2312映照到Unicode，并用UTF格局写进JAVA文件中E4B8ADE696873把一时JAVA文件编译成CLASS文件E4B8ADE696874运转时，先从CLASS文件顶用readUTF读出字符串，在内存中的是Unicode编码4E2D6587（在Unicode中4E2D=中6587=文）5依据Jsp-charset=GB2312把Unicode转化为字撙节D6D0CEC46把字撙节输入到IE中，并设置IE的编码为GB2312（作者按：这个信息埋没在HTTP头中）D6D0CEC47IE用“简体中文”检察了局“中文”（准确显现）
假如指定了＜Jsp-charset＞为ISO8859-1，转化历程以下表。
表5 Jsp-charset=ISO8859-1时的变更历程
序号步骤申明了局1编写JSP源文件，且存为GB2312格局D6D0CEC4
（D6D0=中CEC4=文）2jspc把JSP源文件转化为一时JAVA文件，并把字符串依照ISO8859-1映照到Unicode，并用UTF格局写进JAVA文件中C396C390C38EC3843把一时JAVA文件编译成CLASS文件C396C390C38EC3844运转时，先从CLASS文件顶用readUTF读出字符串，在内存中的是Unicode编码00D600D000CE00C4
（啥都不是！！！）5依据Jsp-charset=ISO8859-1把Unicode转化为字撙节D6D0CEC46把字撙节输入到IE中，并设置IE的编码为ISO8859-1（作者按：这个信息埋没在HTTP头中）D6D0CEC47IE用“西欧字符”检察了局乱码，实际上是四个ASCII字符，但因为年夜于128，以是显现出来的怪模怪样8改动IE的页面编码为“简体中文”“中文”（准确显现）
奇异了！为何把＜Jsp-charset＞设成GB2312和ISO8859-1是一个样的，都能准确显现？由于表4表5中的第2步和第5步互逆，是互相“抵消”的。只不外当指定为ISO8859-1时，要增添第8步操纵，殊为方便。
再看看不指定＜Jsp-charset＞时的情形。
表6 未指定Jsp-charset时的变更历程
序号步骤申明了局1编写JSP源文件，且存为GB2312格局D6D0CEC4
（D6D0=中CEC4=文）2jspc把JSP源文件转化为一时JAVA文件，并把字符串依照ISO8859-1映照到Unicode，并用UTF格局写进JAVA文件中C396C390C38EC3843把一时JAVA文件编译成CLASS文件C396C390C38EC3844运转时，先从CLASS文件顶用readUTF读出字符串，在内存中的是Unicode编码00D600D000CE00C45依据Jsp-charset=ISO8859-1把Unicode转化为字撙节D6D0CEC46把字撙节输入到IE中D6D0CEC47IE用收回哀求时的页面的编码检察了局视情形而定。假如是简体中文，则能准确显现，不然，需实行表5中的第8步
Servlet：源文件为JAVA文件，格局是GB2312，源文件中含有“中文”这两个汉字
假如＜Compile-charset＞＝GB2312，＜Servlet-charset＞=GB2312
表7 Compile-charset=Servlet-charset=GB2312时的变更历程
序号步骤申明了局1编写Servlet源文件，且存为GB2312格局D6D0CEC4
（D6D0=中CEC4=文）2用javacCencodingGB2312把JAVA源文件编译成CLASS文件E4B8ADE69687 （UTF）3运转时，先从CLASS文件顶用readUTF读出字符串，在内存中的是Unicode编码4E2D6587(Unicode)4依据Servlet-charset=GB2312把Unicode转化为字撙节D6D0CEC4(GB2312)5把字撙节输入到IE中并设置IE的编码属性为Servlet-charset=GB2312D6D0CEC4(GB2312)6IE用“简体中文”检察了局“中文”（准确显现）
假如＜Compile-charset＞＝ISO8859-1，＜Servlet-charset＞=ISO8859-1
表8 Compile-charset=Servlet-charset=ISO8859-1时的变更历程
序号步骤申明了局1编写Servlet源文件，且存为GB2312格局D6D0CEC4
（D6D0=中CEC4=文）2用javacCencodingISO8859-1把JAVA源文件编译成CLASS文件C396C390C38EC384 （UTF）3运转时，先从CLASS文件顶用readUTF读出字符串，在内存中的是Unicode编码00D600D000CE00C44依据Servlet-charset=ISO8859-1把Unicode转化为字撙节D6D0CEC45把字撙节输入到IE中并设置IE的编码属性为Servlet-charset=ISO8859-1D6D0CEC4(GB2312)6IE用“西欧字符”检察了局乱码（缘故原由同表5）7改动IE的页面编码为“简体中文”“中文”（准确显现）
假如不指定Compile-charset或Servlet-charset，其默许值均为ISO8859-1。
当Compile-charset=Servlet-charset时，第2步和第4步能互逆，“抵消”，显现了局均能准确。读者可试着写一下Compile-charset＜＞Servlet-charset时的情形，一定是不准确的。
当输入对象是数据库时
输入到数据库时，道理与输入到扫瞄器也是一样的。本节只是Servlet为例，JSP的情形请读者自行推导。
假定有一个Servlet，它能吸收来自客户端（IE，简体中文）的汉字字符串，然后把它写进到内码为ISO8859-1的数据库中，然后再从数据库中掏出这个字符串，显现到客户端。
表9 输入对象是数据库时的变更历程（1）
序号步骤申明了局域1在IE中输出“中文”D6D0CEC4IE2IE把字符串变化成UTF，并送进传输流中E4B8ADE696873Servlet吸收到输出流，用readUTF读取4E2D6587(unicode)Servlet4编程者在Servlet中必需把字符串依据GB2312复原为字撙节D6D0CEC45编程者依据数据库内码ISO8859-1天生新的字符串00D600D000CE00C46把重生成的字符串提交给JDBC00D600D000CE00C47JDBC检测到数据库内码为ISO8859-100D600D000CE00C4JDBC8JDBC把吸收到的字符串依照ISO8859-1天生字撙节D6D0CEC49JDBC把字撙节写进数据库中D6D0CEC410完成数据存储事情D6D0CEC4数据库以下是从数据库中掏出数的历程11JDBC从数据库中掏出字撙节D6D0CEC4JDBC12JDBC依照数据库的字符集ISO8859-1天生字符串，并提交给Servlet00D600D000CE00C4(Unicode)13Servlet取得字符串00D600D000CE00C4(Unicode)Servlet14编程者必需依据数据库的内码ISO8859-1复原成原始字撙节D6D0CEC415编程者必需依据客户端字符集GB2312天生新的字符串4E2D6587
（Unicode）Servlet筹办把字符串输入到客户端16Servlet依据＜Servlet-charset＞天生字撙节D6D0CEC4Servlet17Servlet把字撙节输入到IE中，假如已指定＜Servlet-charset＞，还会设置IE的编码为＜Servlet-charset＞D6D0CEC418IE依据指定的编码或默许编码检察了局“中文”（准确显现）IE
注释一下，表中第4第5步和第15第16步是用白色标志的，暗示要由编码者来作转换。第4、5两步实在就是一句话：“newString(source.getBytes("GB2312"),"ISO8859-1")”。第15、16两步也是一句话：“newString(source.getBytes("ISO8859-1"),"GB2312")”。敬爱的读者，你在如许编写代码时是不是意想到了个中的每个细节呢？
至于客户端内码和数据库内码为别的值时的流程，和输入对象是体系把持台时的流程，请读者本人想吧。分明了上述流程的道理，信任你能够轻松地写出来。
行文至此，已可告一段落了。尽头又回到了出发点，关于编程者而言，几近是甚么影响都没有。
由于我们早就原告之要这么做了。
以下给出一个结论，作为开头。
1、在Jsp文件中，要指定contentType，个中，charset的值要与客户端扫瞄器所用的字符集一样；关于个中的字符串常量，不需做任何内码转换；关于字符串变量，请求能依据ContentType中指定的字符集复原成客户端能辨认的字撙节，复杂地说，就是“字符串变量是基于＜Jsp-charset＞字符集的”；
2、在Servlet中，必需用HttpServletResponse.setContentType()设置charset，且设置成与客户端内码分歧；关于个中的字符串常量，必要在Javac编译时指定encoding，这个encoding必需与编写源文件的平台的字符集一样，一样平常说来都是GB2312或GBK；关于字符串变量，与JSP一样，必需“是基于＜Servlet-charset＞字符集的”。
轮性能微软曾做过一个例子，就是同一个项目用java和.net来作，结果开发周期，.net是java的一半，性能java是.net的十分之一，代码量java是.net的三倍。呵呵，这说明了什么，.net的全方位比java好。但是有的人说.net不能跨平台，这个问题我和我同学曾讨论过，都认为微软的.net很可能早都可以跨平台了，但是微软为了保护他们的操作系统，所以才没有推出跨平台的.net，只是推出了跨语言的.net， 不过，每次的执行编译后的字节码需要消耗一定的时间，这同时也在一定程度上降低了 Java 程序的运行效率。 设计模式是高级程序员真正掌握面向对象核心思想的必修课。设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧 是一种为 Internet发展的计算机语言 应用在电视机、电话、闹钟、烤面包机等家用电器的控制和通信。由于这些智能化家电的市场需求没有预期的高，Sun公司放弃了该项计划。随着1990年代互联网的发展 设计模式是高级程序员真正掌握面向对象核心思想的必修课。设计模式并不是一种具体"技术",它讲述的是思想，它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧 是一种使网页(Web Page)产生生动活泼画面的语言 任职于太阳微系统的詹姆斯·高斯林等人于1990年代初开发Java语言的雏形，最初被命名为Oak，目标设置在家用电器等小型系统的程序语言 那么我书也看了，程序也做了，别人问我的问题我都能解决了，是不是就成为高手了呢？当然没那么简单，这只是万里长征走完了第一步。不信？那你出去接一个项目，你知道怎么下手吗，你知道怎么设计吗，你知道怎么组织人员进行开发吗？你现在脑子里除了一些散乱的代码之外，可能再没有别的东西了吧！ 你就该学一学Servlet了。Servlet就是服务器端小程序，他负责生成发送给客户端的HTML文件。JSP在执行时，也是先转换成Servlet再运行的。虽说JSP理论上可以完全取代Servlet，这也是SUN推出JSP的本意，可是Servlet用来控制流程跳转还是挺方便的，也令程序更清晰。接下来你应该学习一下Javabean了，可能你早就看不管JSP在HTML中嵌Java代码的混乱方式了，这种方式跟ASP又有什么区别呢？ Pet Store.（宠物店）是SUN公司为了演示其J2EE编程规范而推出的开放源码的程序，应该很具有权威性，想学J2EE和EJB的朋友不要 错过了。 一直感觉JAVA很大，很杂，找不到学习方向，前两天在网上找到了这篇文章，感觉不错，给没有方向的我指了一个方向，先不管对不对，做下来再说。 《JAVA语言程序设计》或《JAVA从入门到精通》这两本书开始学，等你编程有感觉的时候也可以回看一下。《JAVA读书笔记》这本书，因为讲的代码很多，也很容易看懂，涉及到面也到位。是你学习技术巩固的好书，学完后就看看《JAVA编程思想》这本书，找找一个自己写的代码跟书上的代码有什么不一样。 你一定会高兴地说，哈哈，原来成为Java高手就这么简单啊!记得Tomjava也曾碰到过一个项目经理，号称Java很简单，只要三个月就可以学会。 学Java必读的两个开源程序就是Jive和Pet Store.。 Jive是国外一个非常著名的BBS程序，完全开放源码。论坛的设计采用了很多先进的技术，如Cache、用户认证、Filter、XML等，而且论坛完全屏蔽了对数据库的访问，可以很轻易的在不同数据库中移植。论坛还有方便的安装和管理程序，这是我们平时编程时容易忽略的一部份（中国程序员一般只注重编程的技术含量，却完全不考虑用户的感受，这就是我们与国外软件的差距所在）。
页:
[1]