• 2006-01-29

    英语对于编程重要吗?

    Views: 13344 | 5 Comments

    有些人问:英语对于编程重要吗?那你就看看下面的例子就知道了:

    6d61696e(){
    	7072696e7466("你好啊,世界!");
    }
    

    好吧,这是一个C语言Hello world! 但它不能用TC或者BC等编绎器编绎----会出错。为了能把它编绎,你再请一个“用英语”编程的人帮你编个程序,将上面的程序转为TC和BC可以认识的源代码。转换过程很简单,因为在ASCII码中,m=6d, a=61, n=6e, p=70, r=72, i=69, t=74, f=66, 以上都是十六进制数值。

    这种“程序”,就算你不会英语也会编出来吧?就算你不会英语也不会妨碍你成为高手吧?因为所有人都能轻易学会0-9和a-e。

    我曾经看到有人用中文“编写”C语言程序----把main换为“主函数”,把int换为“整型”,把printf换为“打印”......,就是:

    主函数(){
    	打印("你好啊,世界!");
    }
    

    我认为这种方法不比我的方法好,因为别人还得学习汉字。我的方法即使是中文文盲也能很容易学习。

    我的意思是,中文编程不是简单的将英文单词“一一对应”地翻译为中文名词就行了,而应该是发明出一种符合“汉语思维”的编程方法。这种“一一对应”的中文编程只不过是一种无聊的作法。在各种编程语言的函数库和类库中,都是以英文词汇(或者26个英文字母,数字,下划线的组合)命名,当然你也可以把它们全都翻译为表示中文意思的中文词汇,或者按照我所说的方法翻译,然后就可以“使用中文(或者不使用英语)编程”了,可是,这有什么意义?

    所以,结论是:英语对编程很重要。

    Posted by ideawu at 2006-01-29 18:18:56
  • 2006-01-07

    在中国怎么利用软件挣钱?

    Views: 13054 | 2 Comments

    在中国怎么利用软件挣钱?如果你在考虑这个问题的话,请学习微软的作法。

    我认为,要想在中国利用软件挣钱,必须做到以下几点:

    1. 软件必须符合中国人的使用习惯,能解决问题。
    2. 软件应该是定价高昂的收费软件。
    3. 软件能够被轻易得到,复制和传播。
    4. 软件对于个人使用,法律上是违法的,但事实上是免费和自由使用的。
    5. 软件对于企业用户是收费的,法律上不允许他们免费使用,但事实上允许他们免费试用。
    6. 合法地利用法律手段迫使企业用户为他们所使用的非法拷贝付钱,但对于个人用户保持宽容。

    这是一种利用“鸦片原理”的,道德上保留,但法律上合法,效果十分明显的作法。

    因为你的软件有价值,所以会有人使用。又因为事实上免费传播,所以用户数目会呈指数增长。当用户建立或进入企业之后,发现自己无法离开你的软件,他们就会想当然地使用非法拷贝。而国家的法律是能够顺利执行的,所以你可以随时上门收钱。

    不要做以下几点:

    1. 销售软件。因为没几个人会买的----即使你定价十分低廉,甚至你赔本出售。
    2. 服务收费模式。这是行不通的。因为中国人是有智慧的,他们能够自给自足。
    3. 目的过于明显。因为你会让他们反感你的软件的。
    Posted by ideawu at 2006-01-07 10:53:04
  • 2005-12-18

    为什么计算机系的学生应该主要使用国外的教材

    Views: 9409 | No Comments

    To be or not to be? That is a question!

    为什么计算机系的学生应该主要使用国外的教材?因为计算机的核心技术掌握在外国人(美国,日本等少数几个国家)手里。是的,这就是最好的理由。

    但是,我的说法看起来是不正常的,因为现在国内的大学使用的计算机教材几乎全是国人自己编的。我不是说我们自己写的教材一无是处。谭浩强写的《C语言程序设计》也很不错。但是,即使是这样好的一本国人自己写的教材,也不是大部分学校都作为教材。不少大学的非计算机系几乎不用这本教材,而是使用他们学校某几个老师编的小册子,水平差得不用说。他们是有理由的---谁都有理由---非计算机系的学生学习这本教材太难了!

    学习过这本教材的人都知道,谭浩强的《C语言程序设计》是一本非学易学的教材。这本教材的目的就是让从未写过程序甚至是从未接触电脑的人学习程序设计。所以,某些人编的小册子不一定比它简单。

    国外的教材,特别是一些名家写的基础教材,是经过十几年甚至几十年的时间考验的。不过,同意使用国外教材的人又过分强调英文原版的作用,认为:

    1. 最新的技术都是先用英文发表的。
    2. 翻译的书不能很好保留原作的意思,即使译者水平极高,那往往是初版发表半年或者一年甚至更久。

    这两个观点我是绝对赞成的。不过,对于一些基础的教材,特别是那些经久不衰的名家手笔,使用中译本更好。因为中译本也经过了时间的验证。

    反对使用国外教材的人认为:

    1. 外国人的思维习惯和中国人不同,中国的学生很难看懂和理解他们的书。
    2. 既然我们写出了教材,为什么不使用我们的。应该支持民族的东西。

    我认为是极为可笑的。首先,他们过分地强调西方人和中国人思维习惯的差异性。我只发现美国人食物的烹饪方法和我们极不相同,并没有发现美国人的思维和我们有多大的差异,特别是对科学的描述方面的差异(或者说他们的“怪异”之处)。而且,没有一个正常的译者是采用直译的方法。

    对于第二点,我们都知道,国人写的计算机方面的好教材是屈指可数。

    不过有一点我们必须注意到,当前有不少出版社(包括知名的)因为引进的国外教材的热销,而有意地引进了不少外国人写的没有多少水平的书。这需要我们聪明地选择了。

    好吧,既然这样,我们为什么不主要使用国外的教材呢?对于学生来说,开始是不了解哪本教材好,主要是老师介绍(或者统一购买---当然大部分是自愿的,并没有强迫)。所以使用什么教材是老师(不是某个人,而是一个群体,或者他们的领导)说的算。

    既然我们学生拥有自由,有什么理由不选择真正的知识来学习呢?

    我们是要像十六世纪西方宗教改革前的农民向宗教势力购买赎罪券一样购买那些以次充好的教材,还是花两倍或者更多的价钱从美国人手里买来我们想要的教材?这是个问题!

    2005年12月18日

    Posted by ideawu at 2005-12-18 13:46:35
  • 2005-12-01

    Java中文问题及最优解决方法

    Views: 9032 | No Comments

    Java中文问题及最优解决方法

    由于Java编程中的中文问题是一个老生常谈的问题,在阅读了许多关于 Java中文问题解决方法之后,结合作者的编程实践,我发现过去谈的许多方法都不能清晰地说明问题及解决问题,尤其是跨平台时的中文问题。于是我给出此篇文章,内容包括对控制台运行的class、Servelets、JSP及EJB类中的中文问题我剖析和建议解决办法。希望大家指教。

    Abstract:本文深入分析了Java程序设计中Java编译器对java源文件和JVM对class类文件的编码/解码过程,通过此过程的解析透视出了Java编程中中文问题产生的根本原因,最后给出了建议的最优化的解决Java中文问题的方法。

    1、中文问题的来源

    计算机最初的操作系统支持的编码是单字节的字符编码,于是,在计算机中一切处理程序最初都是以单字节编码的英文为准进行处理。随着计算机的发展,为了适应世界其它民族的语言(当然包括我们的汉字),人们提出了UNICODE编码,它采用双字节编码,兼容英文字符和其它民族的双字节字符编码,所以,目前,大多数国际性的软件内部均采用UNICODE编码,在软件运行时,它获得本地支持系统(多数时间是操作系统)默认支持的编码格式,然后再将软件内部的 UNICODE转化为本地系统默认支持的格式显示出来。Java的JDK和JVM即是如此,我这里说的JDK是指国际版的JDK,我们大多数程序员使用的是国际化的JDK版本,以下所有的JDK均指国际化的JDK版本。我们的汉字是双字节编码语言,为了能让计算机处理中文,我们自己制定的gb2312、 GBK、GBK2K等标准以适应计算机处理的需求。所以,大部分的操作系统为了适应我们处理中文的需求,均定制有中文操作系统,它们采用的是GBK, GB2312编码格式以正确显示我们的汉字。如:中文Win2K默认采用的是GBK编码显示,在中文WIN2k中保存文件时默认采用的保存文件的编码格式也是GBK的,即,所有在中文WIN2K中保存的文件它的内部编码默认均采用GBK编码,注意:GBK是在GB2312基础上扩充来的。

    由于Java语言内部采用UNICODE编码,所以在JAVA程序运行时,就存在着一个从UNICODE编码和对应的操作系统及浏览器支持的编码格式转换输入、输出的问题,这个转换过程有着一系列的步骤,如果其中任何一步出错,则显示出来的汉字就会出是乱码,这就是我们常见的JAVA中文问题。

    同时,Java是一个跨平台的编程语言,也即我们编写的程序不仅能在中文windows上运行,也能在中文Linux等系统上运行,同时也要求能在英文等系统上运行(我们经常看到有人把在中文win2k上编写的JAVA程序,移植到英文Linux上运行)。这种移植操作也会带来中文问题。

    还有,有人使用英文的操作系统和英文的ie等浏览器,来运行带中文字符的程序和浏览中文网页,它们本身就不支持中文,也会带来中文问题。

    几乎所有的浏览器默认在传递参数时都是以utf-8编码格式来传递,而不是按中文编码传递,所以,传递中文参数时也会有问题,从而带来乱码现象。

    总之,以上几个方面是java中的中文问题的主要来源,我们把以上原因造成的程序不能正确运行而产生的问题称作:java中文问题。

    2、java编码转换的详细过程

    我们常见的java程序包括以下类别:

    *直接在console上运行的类(包括可视化界面的类)

    *jsp代码类(注:jsp是servlets类的变型)

    *servelets类

    *ejb类

    *其它不可以直接运行的支持类

    这些类文件中,都有可能含有中文字符串,并且我们常用前三类java程序和用户直接交互,用于输出和输入字符,如:我们在jsp和servlet中得到客户端送来的字符,这些字符也包括中文字符。无论这些java类的作用如何,这些java程序的生命周期都是这样的:

    *编程人员在一定的操作系统上选择一个合适的编辑软件来实现源程序代码并以.java扩展名保存在操作系统中,例如我们在中文win2k中用记事本编辑一个java源程序;

    *编程人员用jdk中的javac.exe来编译这些源代码,形成.class类(jsp文件是由容器调用jdk来编译的);

    *直接运行这些类或将这些类布署到web容器中去运行,并输出结果。

    那么,在这些过程中,jdk和jvm是如何将这些文件如何编码和解码并运行的呢?

    这里,我们以中文win2k操作系统为例说明java类是如何来编码和被解码的。

    第一步,我们在中文win2k中用编辑软件如记事本编写一个java源程序文件(包括以上五类java程序),程序文件在保存时默认采用了操作系统默认支持 gbk编码格式(操作系统默认支持的格式为file.encoding格式)形成了一个.java文件,也即,java程序在被编译前,我们的java 源程序文件是采用操作系统默认支持的file.encoding编码格式保存的,java源程序中含有中文信息字符和英文程序代码;要查看系统的 file.encoding参数,可以用以下代码:

    public class showsystemdefaultencoding {
    	public static void main(string[] args) {
    		string encoding = system.getproperty("file.encoding");
    		system.out.println(encoding);
    	} 
    }
    

    第二步,我们用jdk的javac.exe文件编译我们的java源程序,由于jdk是国际版的,在编译的时候,如果我们没有用-encoding参数指定我们的java源程序的编码格式,则javac.exe首先获得我们操作系统默认采用的编码格式,也即在编译java程序时,若我们不指定源程序文件的编码格式,jdk首先获得操作系统的file.encoding参数(它保存的就是操作系统默认的编码格式,如win2k,它的值为gbk),然后jdk 就把我们的java源程序从file.encoding编码格式转化为java内部默认的unicode格式放入内存中。然后,javac把转换后的 unicode格式的文件进行编译成.class类文件,此时.class文件是unicode编码的,它暂放在内存中,紧接着,jdk将此以 unicode编码的编译后的class文件保存到我们的操作系统中形成我们见到的.class文件。对我们来说,我们最终获得的.class文件是内容以unicode编码格式保存的类文件,它内部包含我们源程序中的中文字符串,只不过此时它己经由file.encoding格式转化为unicode格式了。

    这一步中,对于jsp源程序文件是不同的,对于jsp,这个过程是这样的:即web容器调用jsp编译器,jsp编译器先查看 jsp文件中是否设置有文件编码格式,如果jsp文件中没有设置jsp文件的编码格式,则jsp编译器调用jdk先把jsp文件用jvm默认的字符编码格式(也即web容器所在的操作系统的默认的file.encoding)转化为临时的servlet类,然后再把它编译成unicode格式的class 类,并保存在临时文件夹中。如:在中文win2k上,web容器就把jsp文件从gbk编码格式转化为unicode格式,然后编译成临时保存的 servlet类,以响应用户的请求。

    第三步,运行第二步编译出来的类,分为三种情况:

    A、 直接在console上运行的类

    B、 EJB类和不可以直接运行的支持类(如JavaBean类)

    C、 JSP代码和Servlet类

    D、 JAVA程序和数据库之间

    下面我们分这四种情况来看。

    A、直接在console上运行的类

    这种情况,运行该类首先需要JVM支持,即操作系统中必须安装有JRE。运行过程是这样的:首先java启动JVM,此时JVM读出操作系统中保存的 class文件并把内容读入内存中,此时内存中为UNICODE格式的class类,然后JVM运行它,如果此时此类需要接收用户输入,则类会默认用 file.encoding编码格式对用户输入的串进行编码并转化为unicode保存入内存(用户可以设置输入流的编码格式)。程序运行后,产生的字符串(UNICODE编码的)再回交给JVM,最后JRE把此字符串再转化为file.encoding格式(用户可以设置输出流的编码格式)传递给操作系统显示接口并输出到界面上。

    对于这种直接在console上运行的类,它的转化过程可用图1更加明确的表示出来:

    (不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    以上每一步的转化都需要正确的编码格式转化,才能最终不出现乱码现象。

    B、EJB类和不可以直接运行的支持类(如JavaBean类)

    由于EJB类和不可以直接运行的支持类,它们一般不与用户直接交互输入和输出,它们常常与其它的类进行交互输入和输出,所以它们在第二步被编译后,就形成了内容是UNICODE编码的类保存在操作系统中了,以后只要它与其它的类之间的交互在参数传递过程中没有丢失,则它就会正确的运行。

    这种EJB类和不可以直接运行的支持类, 它的转化过程可用图2更加明确的表示出来:

    图2

    (不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    C、JSP代码和Servlet类

    经过第二步后,JSP文件也被转化为Servlets类文件,只不过它不像标准的Servlets一校存在于classes目录中,它存在于WEB容器的临时目录中,故这一步中我们也把它做为Servlets来看。

    对于Servlets,客户端请求它时,WEB容器调用它的JVM来运行Servlet,首先,JVM把Servlet的class类从系统中读出并装入内存中,内存中是以UNICODE编码的Servlet类的代码,然后JVM在内存中运行该Servlet类,如果Servlet在运行的过程中,需要接受从客户端传来的字符如:表单输入的值和URL中传入的值,此时如果程序中没有设定接受参数时采用的编码格式,则WEB容器会默认采用ISO-8859- 1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。Servlet运行后生成输出,输出的字符串是 UNICODE格式的,紧接着,容器将Servlet运行产生的UNICODE格式的串(如html语法,用户输出的串等)直接发送到客户端浏览器上并输出给用户,如果此时指定了发送时输出的编码格式,则按指定的编码格式输出到浏览器上,如果没有指定,则默认按ISO-8859-1编码发送到客户的浏览器上。这种JSP代码和Servlet类,它的转化过程可用图3更加明确地表示出来:

    (不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    D、Java程序和数据库之间

    对于几乎所有数据库的JDBC驱动程序,默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的,所以,我们的程序在向数据库内存储包含中文的数据时,JDBC首先是把程序内部的UNICODE编码格式的数据转化为ISO-8859-1的格式,然后传递到数据库中,在数据库保存数据时,它默认即以ISO-8859-1保存,所以,这是为什么我们常常在数据库中读出的中文数据是乱码。

    对于JAVA程序和数据库之间的数据传递,我们可以用图4清晰地表示出来

    图4(不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    3、分析常见的JAVA中文问题几个必须清楚的原则

    首先,经过上面的详细分析,我们可以清晰地看到,任何JAVA程序的生命期中,其编码转换的关键过程是在于:最初编译成class文件的转码和最终向用户输出的转码过程。

    其次,我们必须了解JAVA在编译时支持的、常用的编码格式有以下几种:

    *ISO-8859-1,8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等编码

    *Cp1252,美国英语编码,同ANSI标准编码

    *UTF-8,同unicode编码

    *GB2312,同gb2312-80,gb2312-1980等编码

    *GBK , 同MS936,它是gb2312的扩充

    及其它的编码,如韩文、日文、繁体中文等。同时,我们要注意这些编码间的兼容关体系如下:

    unicode和UTF-8编码是一一对应的关系。GB2312可以认为是GBK的子集,即GBK编码是在gb2312上扩展来的。同时,GBK编码包含了20902个汉字,编码范围为:0x8140-0xfefe,所有的字符可以一一对应到UNICODE2.0中来。

    再次,对于放在操作系统中的.java源程序文件,在编译时,我们可以指定它内容的编码格式,具体来说用-encoding来指定。注意:如果源程序中含有中文字符,而你用-encoding指定为其它的编码字符,显然是要出错的。用-encoding指定源文件的编码方式为GBK或gb2312,无论我们在什么系统上编译含有中文字符的JAVA源程序都不会有问题,它都会正确地将中文转化为UNICODE存储在class文件中。

    然后,我们必须清楚,几乎所有的WEB容器在其内部默认的字符编码格式都是以ISO-8859-1为默认值的,同时,几乎所有的浏览器在传递参数时都是默认以 UTF-8的方式来传递参数的。所以,虽然我们的Java源文件在出入口的地方指定了正确的编码方式,但其在容器内部运行时还是以ISO-8859- 1来处理的。

    4、中文问题的分类及其建议最优解决办法

    了解以上JAVA处理文件的原理之后,我们就可以提出了一套建议最优的解决汉字问题的办法。

    我们的目标是:我们在中文系统中编辑的含有中文字符串或进行中文处理的JAVA源程序经编译后可以移值到任何其它的操作系统中正确运行,或拿到其它操作系统中编译后能正确运行,能正确地传递中文和英文参数,能正确地和数据库交流中英文字符串。

    我们的具体思路是:在JAVA程序转码的入口和出口及JAVA程序同用户有输入输出转换的地方限制编码方法使之正确即可。

    具体解决办法如下:

    1、 针对直接在console上运行的类

    对于这种情况,我们建议在程序编写时,如果需要从用户端接收用户的可能含有中文的输入或含有中文的输出,程序中应该采用字符流来处理输入和输出,具体来说,应用以下面向字符型节点流类型:

    对文件:FileReader,FileWrieter

    其字节型节点流类型为:FileInputStream,FileOutputStream

    对内存(数组):CharArrayReader,CharArrayWriter

    其字节型节点流类型为:ByteArrayInputStream,ByteArrayOutputStream

    对内存(字符串):StringReader,StringWriter

    对管道:PipedReader,PipedWriter

    其字节型节点流类型为:PipedInputStream,PipedOutputStream

    同时,应该用以下面向字符型处理流来处理输入和输出:

    BufferedWriter,BufferedReader

    其字节型的处理流为:BufferedInputeStream,BufferedOutputStream

    InputStreamReader,OutputStreamWriter

    其字节型的处理流为:DataInputStream,DataOutputStream

    其中InputStreamReader和InputStreamWriter用于将字节流按照指定的字符编码集转换到字符流,如:

    InputStreamReader in = new InputStreamReader(System.in,"GB2312");

    OutputStreamWriter out = new OutputStreamWriter (System.out,"GB2312");

    例如:采用如下的示例JAVA编码就达到了要求:

    //Read.java
    import java.io.*;
    public class Read {
    	public static void main(String[] args) throws IOException {
    		String str = "\n中文测试,这是内部硬编码的串"+"\ntest english character";
    		String strin= "";
    		BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in,"gb2312")); //设置输入接口按中文编码
    		BufferedWriter stdout = new BufferedWriter(new OutputStreamWriter(System.out,"gb2312")); //设置输出接口按中文编码
    		stdout.write("请输入:");
    		stdout.flush();
    		strin = stdin.readLine();
    		stdout.write("这是从用户输入的串:"+strin);
    		stdout.write(str);
    		stdout.flush();
    	} 
    }
    

    同时,在编译程序时,我们用以下方式来进行:

    javac -encoding gb2312 Read.java

    其运行结果如图5所示:

    图5(不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    2、 针对EJB类和不可以直接运行的支持类(如JavaBean类)

    由于这种类它们本身被其它的类调用,不直接与用户交互,故对这种类来说,我们的建议的处理方式是内部程序中应该采用字符流来处理程序内部的中文字符串(具体如上面一节中一样),同时,在编译类时用-encoding gb2312参数指示源文件是中文格式编码的即可。

    3、 针对Servlet类

    针对Servlet,我们建议用以下方法:

    在编译Servlet类的源程序时,用-encoding指定编码为GBK或GB2312,且在向用户输出时的编码部分用response对象的 setContentType("text/html;charset=GBK");或gb2312来设置输出编码格式,同样在接收用户输入时,我们用 request.setCharacterEncoding("GB2312");这样无论我们的servlet类移植到什么操作系统中,只有客户端的浏览器支持中文显示,就可以正确显示。如下是一个正确的示例:

    //HelloWorld.java
    package hello;
    import java.io.*;
    import javax.servlet.*;
    import javax.servlet.http.*;
    public class HelloWorld extends HttpServlet
    {
    	public void init() throws ServletException { }
    	public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException
    	{
    		request.setCharacterEncoding("GB2312"); //设置输入编码格式
    		response.setContentType("text/html;charset=GB2312"); //设置输出编码格式
    		PrintWriter out = response.getWriter(); //建议使用PrintWriter输出
    		out.println("<hr>");
    		out.println("Hello World! This is created by Servlet!测试中文!");
    		out.println("<hr>");
    	}
    	public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException
    	{
    		request.setCharacterEncoding("GB2312"); //设置输入编码格式
    		response.setContentType("text/html;charset=GB2312"); //设置输出编码格式
    		String name = request.getParameter("name");
    		String id = request.getParameter("id");
    		if(name==null) name="";
    		if(id==null) id="";
    		PrintWriter out = response.getWriter(); //建议使用PrintWriter输出
    		out.println("<hr>");
    		out.println("你传入的中文字串是:" + name);
    		out.println("<hr>你输入的id是:" + id);
    		out.println("<hr>");
    	}
    	public void destroy() { }
    }
    

    请用javac -encoding gb2312 HelloWorld.java来编译此程序。

    测试此Servlet的程序如下所示:

    <%@page contentType="text/html; charset=gb2312"%>
    <%request.setCharacterEncoding("GB2312");%>
    <html><head><title></title>
    <Script language="JavaScript">
    function Submit() {
    	//通过URL传递中文字符串值给Servlet
    	document.base.action = "./HelloWorld?name=中文";
    	document.base.method = "POST";
    	document.base.submit();
    }
    </Script>
    </head>
    
    <body bgcolor="#FFFFFF" text="#000000" topmargin="5">
    <form name="base" method = "POST" target="_self">
    <input name="id" type="text" value="" size="30">
    <ahref = "JavaScript:Submit()">传给Servlet</a>
    </form></body></html>
    

    其运行结果如图6所示:

    图6(不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    4、 JAVA程序和数据库之间

    为避免JAVA程序和数据库之间数据传递出现乱码现象,我们建议采用以下最优方法来处理:

    1、 对于JAVA程序的处理方法按我们指定的方法处理。

    2、 把数据库默认支持的编码格式改为GBK或GB2312的。

    如:在mysql中,我们可以在配置文件my.ini中加入以下语句实现:

    区增加:

    default-character-set=gbk

    并增加:

    default-character-set=gbk

    在SQL Server2K中,我们可以将数据库默认的语言设置为Simplified Chinese来达到目的。

    5、 针对JSP代码

    由于JSP是在运行时,由WEB容器进行动态编译的,如果我们没有指定JSP源文件的编码格式,则JSP编译器会获得服务器操作系统的 file.encoding值来对JSP文件编译的,它在移植时最容易出问题,如在中文win2k中可以很好运行的jsp文件拿到英文linux中就不行,尽管客户端都是一样的,那是因为容器在编译JSP文件时获取的操作系统的编码不同造成的(在中文wink中的file.encoding和在英文 Linux中file.encoding是不同的,且英文Linux的file.encoding对中文不支持,所以编译出来的JSP类就会有问题)。网络上讨论的大多数是此类问题,多是因为JSP文件移植平台时不能正确显示的问题,对于这类问题,我们了解了JAVA中程序编码转换的原理,解决起来就容易多了。我们建议的解决办法如下:

    1、我们要保证JSP向客户端输出时是采用中文编码方式输出的,即无论如何我们首先在我们的JSP源代编中加入以下一行:

    <%@page contentType="text/html; charset=gb2312"%>

    2、为了让JSP能正确获得传入的参数,我们在JSP源文件头加入下面一句:

    <%request.setCharacterEncoding("GB2312");%>

    3、为了让JSP编译器能正确地解码我们的含有中文字符的JSP文件,我们需要在JSP源文件中指定我们的JSP源文件的编码格式,具体来说,我们在JSP源文件头上加入下面的一句即可:

    <%@page pageEncoding="GB2312"%>或<%@page pageEncoding="GBK"%>

    这是JSP规范2.0新增加的指令。

    我们建议使用此方法来解JSP文件中的中文问题,下面的代码是一个正确做法的JSP文件的测试程序:

    //testchinese.jsp
    <%@page pageEncoding="GB2312"%>
    <%@page contentType="text/html; charset=gb2312"%>
    <%request.setCharacterEncoding("GB2312");%>
    <%
    	String action = request.getParameter("ACTION");
    	String name = "";
    	String str = "";
    	if(action!=null && action.equals("SENT"))
    	{
    		name = request.getParameter("name");
    		str = request.getParameter("str");
    	}
    %>
    <html>
    <head>
    <title></title>
    <Script language="JavaScript">
    function Submit()
    {
    	document.base.action = "?ACTION=SENT&str=传入的中文";
    	document.base.method = "POST";
    	document.base.submit();
    }
    </Script>
    </head>
    <body bgcolor="#FFFFFF" text="#000000" topmargin="5">
    <form name="base" method = "POST" target="_self">
    <input type="text" name="name" value="" size="30">
    <a href = "JavaScript:Submit()">提交</a>
    </form>
    <%
    if(action!=null && action.equals("SENT"))
    {
    	out.println("<br>你输入的字符为:"+name);
    	out.println("<br>你通过URL传入的字符为:"+str);
    }
    %>
    </body>
    </html>
    

    如图7是此程序运行的结果示意图:

    图7(不好意思,图传不上来,只好让大家自己去想像图的样子了,我想看了上文是可以想来图来的。)

    5、总结

    在上面的详细分析中,我们清晰地给出了JAVA在处理源程序过程中的详细转换过程,为我们正确解决JAVA编程中的中文问题提供了基础。同时,我们给出了认为是最优的解决JAVA中文问题的办法。

    作 者: javabin

    http://gceclub.sun.com.cn/NASApp/sme/jive/thread.jsp?forum=8&thread=13425

    Posted by ideawu at 2005-12-01 13:24:52
  • 2005-12-01

    从微软一道面试题议中国的说“不”

    Views: 8073 | No Comments

    先将近期我国外交上的重要事件列举如下:

    5月16日,国务院总理温家宝在会见美国商会代表团时,表示“人民币汇率改革属中国主权,不屈从外界压力”。

    5月23日,国务院副总理吴仪紧急取消了原定与日本首相小泉的会谈。

    5月30日,国家商务部部长薄熙来宣布我国从6月1日起对81项纺织品取消征收出口关税。

    6月1日,中国常驻联合国代表王光亚明确表示,由“四国联盟”提出的要求增加安理会常任理事国的决议草案危害联合国改革进程,如四国执意将这一决议草案付诸表决,中国将投票反对。

    6月21日,中国常驻联合国代表王光亚在第59届联合国大会发言时重申,中国反对人为的为安理会改革设定时限,如果强行表决尚有重大分歧的安理会改革方案,中国将坚定地投反对票。

    在短短的一个多月时间内,中国对美国说不,对日本说不,对欧盟说不,对德日巴印四国联盟说不。一时间,国际媒体一片愕然,国内媒体以及网络社区则是一致热评,有网友甚至惊呼“中国人民已经从站起来、富起来进入到了硬起来的时代”!笔者也同大多数网友一样,对今日中国外交方面的强硬举措欢欣鼓舞,扬眉吐气。

    在激动之余,不禁想起了网上流传的一道著名的微软面试题??海盗分金币。题目的大意是:

    5个海盗抢得100枚金币后,讨论如何进行公正分配。他们商定的分配原则是:

    (1)抽签确定各人的分配顺序号码(1,2,3,4,5);

    (2)由抽到1号签的海盗提出分配方案,然后5人进行表决,如果方案得到超过半数的人同意,就按照他的方案进行分配,否则就将1号扔进大海喂鲨鱼;

    (3)如果1号被扔进大海,则由2号提出分配方案,然后由剩余的4人进行表决,当且仅当超过半数的人同意时,才会按照他的提案进行分配,否则也将被扔入大海;

    (4)依此类推。

    这里假设每一个海盗都是绝顶聪明而理性,他们都能够进行严密的逻辑推理,并能很理智的判断自身的得失,即能够在保住性命的前提下得到最多的金币。同时还假设每一轮表决后的结果都能顺利得到执行,那么抽到1号的海盗应该提出怎样的分配方案才能使自己既不被扔进海里,又可以得到更多的金币呢?

    此题公认的标准答案是:1号海盗分给3号1枚金币,4号或5号2枚金币,自己则独得97枚金币,即分配方案为(97,0,1,2,0)或(97,0,1,0,2)。现来看如下各人的理性分析:

    首先从5号海盗开始,因为他是最安全的,没有被扔下大海的风险,因此他的策略也最为简单,即最好前面的人全都死光光,那么他就可以独得这100枚金币了。

    接下来看4号,他的生存机会完全取决于前面还有人存活着,因为如果1号到3号的海盗全都喂了鲨鱼,那么在只剩4号与5号的情况下,不管4号提出怎样的分配方案,5号一定都会投反对票来让4号去喂鲨鱼,以独吞全部的金币。哪怕4号为了保命而讨好5号,提出(0,100)这样的方案让5号独占金币,但是5号还有可能觉得留着4号有危险,而投票反对以让其喂鲨鱼。因此理性的4号是不应该冒这样的风险,把存活的希望寄托在5号的随机选择上的,他惟有支持3号才能绝对保证自身的性命。

    再来看3号,他经过上述的逻辑推理之后,就会提出(100,0,0)这样的分配方案,因为他知道4号哪怕一无所获,也还是会无条件的支持他而投赞成票的,那么再加上自己的1票就可以使他稳获这100金币了。

    但是,2号也经过推理得知了3号的分配方案,那么他就会提出(98,0,1,1)的方案。因为这个方案相对于3号的分配方案,4号和5号至少可以获得1 枚金币,理性的4号和5号自然会觉得此方案对他们来说更有利而支持2号,不希望2号出局而由3号来进行分配。这样,2号就可以屁颠屁颠的拿走98枚金币了。

    不幸的是,1号海盗更不是省油的灯,经过一番推理之后也洞悉了2号的分配方案。他将采取的策略是放弃2号,而给3号1枚金币,同时给4号或5号2枚金币,即提出(97,0,1,2,0)或(97,0,1,0,2)的分配方案。由于1号的分配方案对于3号与4号或5号来说,相比2号的方案可以获得更多的利益,那么他们将会投票支持1号,再加上1号自身的1票,97枚金币就可轻松落入1号的腰包了。

    看到这里,读者一定会问,这个海盗分金币的题目与中国说“不”有何关联呢?好,下面就切入正题。

    海盗分金币模型的最终答案可能会出乎很多人的意料,因为从直觉来看,此模型中如此严酷的规定,若谁抽到1号真是天底下最不幸的人了。因为作为第一个提出方案的人,其存活的机会真是微乎其微,即使他一个金币也不要,都无私的分给其他4个人,那4个人也很可能因为觉得他的分配不公而反对他的方案,那他也就只有死路一条了。可是看起来处境最凶险的1号,却凭借着其超强的智慧和先发的优势,不但消除了喂鲨鱼的危险,而且最终还使自己的收益最大化,这不正像是当今国际社会国与国之间在政治、经济等领域相互博弈过程中,先发制人的智慧和优势的凸现吗?而5号表面上看起来是最安全的,可以坐山观虎斗,先让前面的海盗拼个你死我活而坐收渔翁之利,可实际上最后却不得不看别人的脸色行事,勉强分得一杯小羹,这不正是本想以静制动,后发制人而反得劣势的写照吗?看到这里,大家应当已经明白笔者所要表达的意思了,而很多事实也已证明,如果中国人总是处于5号位置,总是坐等着别人制定规则,那么就无法避免陷入“看人脸色”行事的不利处境。

    1989年前后,面对当时特殊的国际环境,邓小平先生提出了“冷静观察,稳住阵脚,沉着应付,韬光养晦,有所作为” 的方针,强调“决不当头”,之后中国就以一种中庸的姿态出现在国际舞台上。1989年9月16日,邓小平在会见李政道时说:“别国的事情,我们管不了”,从而道破其“韬光养晦”对国际事务做壁上观的玄机。笔者认为,“韬光养晦”的目的是着眼于国际竞争中的最后胜利,主张国家在经济和军事力量处于相对弱势时,收敛锋芒,保持克制,积累实力,不意气行事,甚至不惜以局部让步来谋求整体利益的最大化。其本质是为图强而忍辱,为进攻而防御,一旦功成,实力达就,破关而出,便可变退为进、转守反攻而致全胜。“韬光养晦”可以说是中国特定时期的特定外交策略。

    在这一策略的引导下,中国以经济建设为中心,埋头发展自身经济,对外则近睦远和,努力营造有利于经济建设的外部环境,避免与别国发生直接正面的冲突与对抗。在过去的二十多年里,中国人小心翼翼地为自己成功营造了相对和平稳定的发展空间,并使中国成为全球发展最快的大型经济体,其GDP以年均超过8%的速度增长,成为世界第六大经济体和第二大外汇储备国。“韬光养晦”策略确保了中国经济的腾飞,大幅提升了国家在世界经济中的影响力。

    但是,在另一方面,中国人有时却不得不承受将愤怒埋藏于心中的痛苦。1993年美国一手制造了“银河号”事件,1999年美国轰炸中国驻南大使馆,2001年美国侦察机冲撞中国军机;而另一个邻国则以参拜靖国神社、美化侵略史、宣称对钓鱼岛拥有主权等恶行一而再、再而三的挑战中国的忍耐极限。而通常情况下,中国虽然“很生气”,但所作反应的后果却不会“很严重”,最愤慨的也不过是表示“最强烈的抗议”。世人也已经习惯了作为五大常任理事国之一的中国,在面对国际重大突发事件上,总是以投弃权票而圆滑的平衡利益各方。

    我们大家都明白“小洞不补,大洞尺五”的道理,在一些局部利益上暂时的退让与妥协是理智的,可若长此以往,谁又能保证这样的退让不会更加助长对方的气焰,而最终导致自己权利的丧失呢?在中国蓄练健韧之后,该是到了转换博弈策略的时侯了。这次,吴仪副总理因不满日本首相小泉决意参拜靖国神社的言论拂袖而去;中国政府面对美国强逼人民币升值的巨大压力,面临欧美对中国纺织品设限的威胁,没有一味退让妥协,而是依托现有国际规范,据理力争,尽最大努力维护国家利益;特别是针对日本“入常”问题上明确说“不”,一扫中国政府以往在联合国中动辄“弃权”的模糊形象,向世界明示了中国的态度,向国际社会展示出中国的外交魄力,也使得日本不得不被迫接受由中国人参与制定的“游戏规则”。此后日本等四国联盟成员表示新常任理事国的否决权问题,可以等到安理会扩大完成的15年后再予以解决便是明证。在国际格局向多极化趋势发展,世界政治和经济新秩序亟待重塑的大背景下,中国必须直面外交挑战,并积极的有所作为。正如我国外交部长李肇星在与日本外相会谈时所指出的,在历史问题、台湾问题和钓鱼岛问题上挑战中国的核心利益,是非常危险的。道理很简单,中国的综合国力早已今非昔比,任何势力来挑战中国的核心国家利益,都会付出代价。这也就难怪有网友会惊呼中国“硬起来” 了,而这一切在让国人感觉痛快淋漓的同时,也表明了中国新一代领导人正力图以更积极的态度介入国际事务,把握外交主动权,发挥先发优势。这也预示着中国正在告别多年来“太极推手”式模棱两可、谦逊忍让的时代,而逐步进入了作风强硬,棱角分明,态度明朗,昂扬务实的后“韬光养晦”时代。

    也许有人会担心,这样说不正是给某些不怀好意的国家散布“中国威胁论”找到借口吗?这让笔者又想起了一则笑话。说的是狼和狐狸遇见了一只山羊,就立刻指责其对自身安全构成了威胁,因为山羊长了角。后狼和狐狸又遇见了一只老虎,狼立刻提出双方建立“合作伙伴”乃至“战略伙伴”关系,而狐狸则声称要和老虎“世世代代友好下去”。中国必须习惯于与“中国威胁论”共生存,加大对地区事务和国际事务的参与力度,坚定地发出自己的声音,一个政治稳定、经济繁荣、社会和谐、军事强大的中国,将会是国际上许许多多国家愿意与之“世世代代友好”交往的国度。正如晨枫在《西线观察》里所谈到的,“中国的理想还不应仅仅是强国,而且应该更为远大。中国应该按照自己的世界观来示范和推动一个‘世界新秩序’??按照中国文化传统中的‘和而不同’的理想来对世界做出中国的贡献。”

    让我们把话题再次回到海盗分金币模型上来。显然,海盗分金币的模型相对于现实来说,实在是太粗糙了,现实中的情况远要比它复杂千万倍。

    首先,现实中肯定不可能人人都绝顶聪明并富有理性,海盗中只要3号、4号或5号中任何一人偏离此假设,1号就极有可能被抛入大海。因此,现实中的1号必须首先考虑他的兄弟们是否足够的聪明与理性,而断然不能顾自取走那97枚金币。

    其次,在这一涉及个人重大利益的分配过程中,阴谋会像杂草一般疯长,而谎言与虚假承诺也就有了用武之地。假如,2号事先对3、4、5号海盗大放烟雾弹,称基于1号所提出的任何分配方案,他都会再多加1个金币给他们,那结果可能又会是另一番景象了。

    再次,正如吴思先生在其所著的《血酬定律》一书中提到的,“所有规则的设立,说到底,都遵循一条根本规则:暴力最强者说了算。这是一条元规则,决定规则的规则”。在发生争执时,如果在肉体上消灭对方是最合算的,付出成本也是最低的话,那么当5个海盗中最强悍的那个将刀架在其余海盗脖子上,并大喝道“要命还是要金币”的时候,那么任何的争执都不难解决,任何的意见也就不难统一了。

    当然,即使1号是那最强悍的海盗,其余4人也还是有可能组成一个反1号大联盟,并经过精心策划和充分准备而起来“造反”,合力将1号制服并扔进大海,再由这4人重新商定分配规则。

    已经无需讨论更多的情况,相信大家已同意现实实在是太复杂的看法了。但是,海盗分金币的模型还是不乏有启示意义,即任何“分配者”想让自己的方案获得通过,其关键是在于事先要考虑清楚“挑战者”所可能会提出的分配方案,然后尽力拉拢“挑战者”分配方案中最不得意的人,用最小的代价使自己的利益最大化,总之是离不开过人的智慧和高超的策略。

    毋庸讳言,随着中国国力的不断增强,我们在发展过程中所遇到的阻力和挑战也将会不断升级,中国与某些国家在政治、经济等领域的摩擦也将进入短兵相接的“巷战”时代。因此,中国不仅要适时的说“不”,更需要以超强的智慧、更娴熟的外交手腕去处理各种纷繁复杂的国际事务。但不管怎么说,这次对日本的当头棒喝,至少要比以往多次“强烈抗议”参拜靖国神社更能让日本当局正视他们的历史和现状。中国近期在经济、外交上的一系列强硬政策所体现出的“软的更软,硬的更硬”的新策略,可以说既有日益强盛的国力作实质支撑,又有国际竞争的实际需要,并且符合当今中国的民意潮流。愿我们祖国更加强盛,让妥善解决领土争端、能出游钓鱼岛看日出的日子早点到来!

    转自:http://publishblog.blogchina.com/blog/tb.b?diaryID=3486297

    Posted by ideawu at 13:23:49
  • 2005-12-01

    从“六十万游戏人才” 谈教育者职业操守

    Views: 8086 | No Comments

    从“六十万游戏人才” 谈教育者职业操守

    2005.11.17 来自:eNet硅谷动力

    最近看到一系列的文章,都包含着一个非常刺眼的内容:“中国的游戏开发行业上出现的人才缺口是六十万人(也有一说是“二十万”的)”,据说还是引用的信息产业部公布的数字。如果你还没有被这个数字惊呆,我想提供给你一个参考标准:六十万大约就是中国人民解放军现役全部海军和空军官兵的总和。现在估计你已经被吓着了。对游戏行业进行稍加了解,你就会更加觉得这简直就是彻头彻尾的疯话。

    中国游戏行业目前谁是老大?感谢福布斯等机构的努力,类似这样的问题是不存在多大的争议的,答案当然是上海的盛大。但从盛大公司提交给美国证券交易委员会的报告可以看到,截至最近,盛大公司的员工总数1, 400多人,而且这其中还包括着市场、运营甚至人力资源和财务这样的非开发人员。在2004 年4月2日盛大公司出具的官方报告上精确地注明,至2004年3月31日,该公司的游戏开发人员一共186人而已。同样查一查网易等大公司的相关文件,就会看到,这些公司的开发人员的数量,普遍都只在百人的数量级上。是不是这些大公司所占的市场份额不够大,游戏人才都在其他更小的公司里?好像不是。即便是在鼓吹游戏人才缺口几十万人的那类文章上,关于网络游戏市场规模的描述,也只是说在二十五亿元左右。而盛大一家公司在过去十二个月(2004年8月至 2005年8月)的营业收入,就已经达到了十六亿元,显然,市场主体确是在这些大公司的手中的。那么,这六十万人究竟谁来领走呢?争论至此,“六十万”的鼓吹者们,似乎也只好把我们的视线指向两个方向,一个是国外,一个是未来。

    顺便说一句,近些年来,“国外如何如何”已经成了大小骗子们的防空洞了,似乎一扯到国外,所有荒谬的东西都具备了合理性,满口“某某国等国家很先进,研发很厉害,我们必须追赶才行”。让我们看看真实的所谓国外的情况。韩国和ACTOZ,应该是所有关注游戏行业发展的人们无比熟悉的两个词。韩国之所以让人熟悉,因为它已经成为了网络游戏的“好莱坞”;如果前面的比喻成立,那么ACTOZ公司无疑可以被叫做游戏“二十一世纪福克斯”。ACTOZ这个网络游戏研发的航母,是包括盛大在内的几个国内网游公司的上游开发商《传奇》、《A3》等众多著名网络游戏的版权拥有者。对于盛大,研发的命脉掌握在外人手中的可怖威胁,终于使得陈首富在若干个夜晚的辗转反侧后下定决心,于在2004年对ACTOZ 进行了收购,巩固了盛大的大后方。查看韩国KOSDAQ(相当于美国纳斯达克的韩国证券市场)的注册资料,你会惊奇地发现,即使是ACTOZ这样一个研发型的、具有行业领导地位的公司,也不过区区162人而已(2004年6月的数字),注意,是全部员工数字,前台接电话的小姐已经包含在内了!可见,即便是在韩国,真正从事游戏开发工作的人也是相当有限的。游戏作为一个信息类产品,最大的特点就是几乎为零的 “边际成本”。通俗地说,就是一个产品开发好以后,究竟给多少人提供服务对成本的影响不会非常大。在鼓吹游戏人才缺口的文章中,有人感叹道,“一方面是两千万的游戏玩家,一方面是仅仅三千人的开发队伍”,言下之意,这人才短缺不是显而易见了吗。那么,我不禁要问,在目前“两千万用户”及“三千开发人员”的 “窘迫”状况下,有多少玩家在游戏过程中感受到游戏公司的人手短缺了?好莱坞的电影拥有观众不下十亿,按照这样的逻辑,究竟安排几百万人去美国做电影比较合适呢?从用户数量和从业人员的数量之悬殊就得出从业人员数量将要增加的结论,是“六十万”理论最大的无知之处。

    最后,一个相对难以通过查资料解决、求证的问题出现了:“这六十万人是否会出现在将来”?先看看“六十万”们的预测吧。这些文章当中说,“近年来,中国的游戏产业发展迅速,去年网络游戏市场规模达到二十四点七亿元人民币,比上一年增长近五成,预计经过三至四年的发展,中国网络游戏市场销售收入将达到一百亿元左右。”即便不去讨论这些数字的预测是否过于乐观,即便我们认定这样的增长一直会持续下去,我们也必须看到,游戏这类信息类产品的特点,决定了从业人员的增长必将大大落后于行业的规模增长速度。还是从盛大公司的情况看,在最近公布季度财务报告上,盛大的季度销售收入同比增加了93.1%,但是员工的数量仅从2004年3月底的931人,增加到了目前的1,429人,增长率仅53%。因此,以这样的速度,盛大的营业收入即使再翻一倍,员工也仅仅会增加不到1,000人,而且,我们有理由相信,这部分的增长,也会是以客服人员而不是以更加专业的开发人员为主的。盛大公司现在人均实现销售收入约 100万元。按照这样的标准测算,即便那个行业收入过百亿的时代真的来了,这个行业也就能养活一万人而已。考虑到竞争使人均创收能力降低等因素,游戏行业顶多可以容纳2-3万人,而且是在不知道多久的将来。

    对于所谓“六十万”的鼓噪,如果仅仅因为盲从与无知,可能还是尚可原谅的,但是此次宣传之猛烈,意图之明显,使稍有头脑的人都可以清楚地看到,其背后似有利益团体的操纵,而更加让人拍案的,是操纵者似乎是一批本该“为人师表”的教育工作者。笔者认为,要缔造所谓的和谐社会,有两类人的良心是万万坏不得的,一是媒体工作者,二是教育工作者。媒体工作者的职业良知之所以重要,是因为他们可以影响人群之广泛;教育工作者的职业操守之所以必须,是因为他们对受教育者产生的影响之深远。可悲的是,“六十万”论恰是在这两个人群当中少部分人的互动中所勾勒出的骗局。

    在中国,从事教育工作是令人骄傲的。在“一日为师,终生为父”的训诫下,即便是改革的大潮涤荡、冲刷掉了绝大多数的传统遗风后,对教师的尊重依然存留于大多数人的心间。但是,我们的教育工作者在为别人“解惑”的同时,是否对“你们的责任有多大”这个问题,有着比较正确的答案?从事教育工作,特别是职业教育领域的人员,应该意识到,你们的教育对象-处于二十岁左右的青年,是处在他们职业生涯的“方向选择”阶段。在二十岁到三十岁前的这段时间,一个人尽管未必能实现在事业发展上的道路上行进多远,但对将来终生从事的职业方向,已经会有一个相对明确的取舍了。“六十万” 们是否想过,在二十岁这样一个人的热情最高涨,但自信最脆弱的阶段,引导他走向一个所谓“游戏英雄”的海市蜃楼,最后的结果会是一个多大的灾难。一两万元的学费、一两年时间的损失也就罢了,但对于他们,当发现人生第一个他们所热爱并全心投入的、“社会急需的”、“老师们也都说好”的职业发展目标,竟是一个可望不可及的幻影时,梦想被击碎的他们将会用多长时间,才能理智地认识到这一切并非他们的无能,而是目标原本就被人悄悄移偏了方向?而当最终发现这个误导他们的人竟然是他们尊敬的老师时,他们会不会发出“如果老师都骗人,这个世界上我们究竟还可以相信谁”的哀叹?!教育假药是最毒的假药,不仅因为它们一旦服下就会危害终生,更因为服这个假药的一两年时间中,你可能无法同时摄入其他的营养;而且,你可能需要未来十年的时间,才认识到这剂药的质量存在瑕疵。不要忘了,在这些热血沸腾地选择游戏作为毕生事业的学员当中,有相当部分本来已经陷入游戏不能自拔了,这时以“社会最需要的就是你们这样的人才,缺口几十万”的光彩理由把他们再向前推,无疑将把他们送上事业上的不归迷途。

    笔者供职的机构,也在进行游戏开发人才的培养工作。稍有不同的是,我们并不打算因为公众对游戏的热情、因为商业上的利益就把我们的判断力与良知拿出来待价而沽。在2005年,我们的培养计划仅仅是在百人数量级而已。教育机构、特别是职业教育机构应该认识到,教育机构真正扮演的角色是为各行业进行人力资源配套供应的服务性工作。在对行业进行定向人才培养时,应该时刻关注行业的人力资源需求情况,既不能超前,也不能落后,而是必须像影子一样仅仅跟随。在IT相关的领域当中,技能是无法保鲜的,即便游戏行业真的需要六十万开发人才,如果不能选择合适的时机进行培养,对这些学员来说,这个时间上的提前量也会造成灾难性的后果。

    我们相信对学员前途而不是经营利润的真正关注,才是教育机构、包括经营性教育机构长期生存的根本,才是教育者职业操守的核心。我在这里非常希望提醒“六十万派”们,未来再准备放这类似“六十万”的卫星,先自己用手摸摸两个部位:摸一下头-确实不烧,摸一下心-当真无愧,再把这类惊人观点抛出来不迟。

    Posted by ideawu at 13:21:56
|<<<789101112131415>>>| 14/15 Pages, 86 Results.