|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
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, |
|