• 2005-12-03

    Keep it simple, stupid!

    Views: 8495 | No Comments

    The Dalai Lama once said that simplicity is the key to happiness in
    the modern world. This philosophy can be adapted into the realm of web
    design and digital interface design.
    The expressions "Keep it simple, stupid", "Kill your darlings" and
    "Less is more" all pinpoint the fact that simplicity is important.
    Simplicity lasts. Simplicity is necessary in order to properly convey any idea.

    Content is King, Consistency is Queen

    When performing an oral presentation, it is said that the message is
    composed of 60% body language, 10% speech and 30% tone of voice.
    If this were to be at least partially true for web design, we could
    say that on the web, a message is composed of 60% design, 10% actual
    content and 30% writing style.
    I believe that content is king. It always will be. But?evidently?an
    excellently written text easily disappears if placed in an improperly
    designed environment, and excels when appearing in a well-designed
    context.
    Consistency helps to create simplicity. In an environment where
    nothing is constant, interface consistency is of the essence. I'm all
    for innovative interfaces. But when pressing an arrow that points
    downwards, most people expect an element (e.g. a text block) to move
    down, not up.
    The best designs are simple, because they contain no unnecessary
    elements... and contain the necessary elements in a way that seems
    logical.

    The Three Elements of Design

    The three fundamental elements of graphic design are balance, contrast and invisible lines.
    Balance refers to the overall composition of images, graphical
    elements and typography within a design. Contrast refers to the
    interaction between design elements. Invisible lines are the areas
    created between the different parts of a design (for example, the
    palpable but invisible lines that run vertically and horizontally
    between the crop marks on a printed page).
    Good design, regardless of target medium or audience, takes these
    elements into account. If one element is neglected, the design will be
    unbalanced. For instance, a design could be extremely visually balanced
    and quite graphically sophisticated, but still incomplete because of a
    dull choice of color. All elements are equally important.
    Being aware of the three elements of design is a key to obtaining simplicity.
    When a design doesn't feel quite right, many designers are inclined
    to add elements instead of removing unnecessary ones, resulting in
    overloaded designs. Sometimes, it's better to start over instead of
    trying to fix or change the design. To quote hell.com; "trying to fix
    or change something, only guarantees and perpetuates its existence."
    Learning the skill of asking oneself "does this really need to be
    here?" is the first step towards creating simplicity. The next is
    understanding the motivations of your audience.

    How do People Work?

    If I truly understood how people work, I wouldn't be writing this
    article, but rather sipping a perfectly mixed daquiri underneath the
    palm trees on a beach somewhere quite far away from Sweden.
    However, I do understand a little, just by examining my own
    behavior. Over the years, I've found that in order to design well, it's
    important to take into consideration how people generally work.
    1. People want to be entertained: This explains why games and
    pornography are so popular on the web. It also explains why so many
    people are TV slaves, because television is an excellent way to create
    a constant flow of varied visual and audio stimuli. This suits our
    brains perfectly, since the brain easily loses interest in things that
    don't provide stimulus.
    To entertain means to capture attention. The classic quote, "Tell me
    and I forget, show me and I remember, involve me and I'm yours"
    underscores the fact that emotionally engaging communication is the
    most efficient form of getting a message across.
    For instance, two speakers at a conference could deliver the same
    speech with two very differing results, leaving behind one satisfied
    and one dissatisfied audience. The difference? 60% body language, 30%
    tone of voice. (The 10% message is the same.) It's not until all
    elements of communication fully interact that efficient and emotionally
    engaging communication can be achieved.
    2. People want to feel smart and discover things: That's why the expression "show, don't tell" was invented (and that's also why we all despise toothpaste commercials).
    Form a circle with your thumb and index finger. Let the circle
    symbolize communication. Now open the circle by moving the fingers away
    from each other.
    The gap between the fingers symbolizes a communication gap. If the
    communication gap is too wide, the message is too obscure for people to
    understand. If the circle is too narrow, the message is too obvious
    (toothpaste) and therefore uninteresting.
    3. People don't have time to learn things that are too complicated:
    Thousands of people have never programmed their VCR. WAP (wireless
    application protocol) has not become truly successful because it's
    complicated and the obvious benefits are obscured. Many people are
    hesitant to book flights online, because the actual booking process is
    complicated and it's much easier to just call a travel agent. Hundreds
    of dot-coms have gone bankrupt because they didn't have a business
    concept that people could understand.
    Whether you're designing a website, developing a new product, or
    trying to get your point across in a discussion, it's good to remember
    that most people do have limited patience.
    That's why simplicity is important.

    A Definition of Simplicity

    What is simplicity? It could be defined as "the absence of unnecessary elements," or even shorter "the essence."
    Simplicity doesn't equal boring. Simplicity doesn't equal shallow.
    Simplicity is especially important when designing information- and
    media-rich interfaces.
    Simplicity isn't a design style, it's a perspective on design, an
    approach which often creates the most beautiful and the most usable
    results.
    A common mistake is to think that obtaining simplicity is a matter
    of reduction, of reducing something which is more complete than the
    "simple" end result. On the contrary, simplicity requires serious
    thought and effort.
    As I wrote in my article Fragments of time; "A modern paradox is that it's simpler to create complex interfaces because it's so complex to simplify them."

    How to Obtain Simplicity

    Simplicity isn't easy to obtain. I have, however, roughly devised a formula that lays the foundation for simplicity.
    Albert Einstein said; "If A is to succeed in life, then A = x + y + z. Work is x, y is play and z is to listen."
    A functioning formula for simplicity (where A equals simplicity)
    could be A = x + y + z. x is good research and prototyping, y is play
    and z is the reduction of unnecessary elements.
    By genuinely knowing your audience and your objectives, and building for them, you've won the first battle.


    By creating a design that engages the visitor on a sensory (or perhaps sensual) level, you've won the second battle.
    If you hold onto these gains and let go of the things that are unneeded, you win the war that earns a satisfied visitor.


    Written under the influence of: Flesh Quartet, Cibo Matto, Laika, Weekenders and Beatnuts.


    Bulgarian translation

    By P?r Almqvist

    Copyright ? 1994-2005 Digital Web Magazine. All Rights Reserved.

    Posted by ideawu at 2005-12-03 21:02:57
  • 2005-12-03

    Keep it Simple

    Views: 9019 | No Comments

    The first site I made as a professional web developer used 17 frames.
    My first professional assignment was coding the World Press Photo
    site. In those days sites had to be compatible with Netscape and
    Explorer 3 and 4. That wasn't a problem - that's what I'd been hired
    for.
    The site needed three content areas inside a static design of
    navigation and decoration. Nowadays we might use iframes for the
    content areas, but back then only one of the four popular browsers
    supported them. So I coded the site in frames and found that... I
    needed more than expected.
    The cause was Netscape. It was impossible to be certain that in
    Netscape a frame had the exact width and height you defined, so I
    devised a workaround to make sure all frames fit snugly, whatever their
    actual width and height might be. I ended up with 17 frames.
    Nothing wrong with that, I thought, and proceeded to add
    boatloads of JavaScripts to make sure the frames cooperated properly
    (and without which, incidentally, the site wouldn't work).
    When the site went online, I felt proud. I'd proven to myself and to the world that I was a web developer.

    Complexity

    One year later all of the photos on the site had to be republished.
    I'd gained a lot of experience meanwhile, was promoted to head of
    Client Side Programming at my company and consequently made responsible
    for the cleanliness of our code.
    I looked at the site anew and had a vague feeling of unease.
    Mightn't it contain slightly too many frames and scripts? Unfortunately
    the budget didn't call for a redesign, merely for new content. I
    nonetheless spent an entire day in study and judiciously merged two
    frames, making for a total of 16. I couldn't remove more frames without
    destroying the cross-browser compatibility of the design.
    It took me another six months to realize that the whole thing was
    too complex. Since I was paid to worry about such matters, I thought
    long and hard. What had gone wrong? Could we avoid making the same mistakes again?
    At first I blamed the design. In a literal sense this was correct:
    if the design hadn't called for three content frames and one very
    problematical line, the coding could have been much cleaner. But this
    only meant shifting the blame from myself to the designer, so it wasn't
    a real answer. Why had the design been so complicated? Why didn't we
    keep it simple?
    The answer I found is that for most people simple =
    dull
    . A site made by a creative web development company
    must never be dull, ergo it should be complicated.

    KISS

    People were already protesting against this point of view. "Keep It
    Simple, Stupid!", they said. Of course other people disagreed. One mail
    succinctly stated: "KISS leads to LOVE (Leave Out Virtually
    Everything)".
    This reaction accurately mirrored my fears. If we'd leave out the
    newest technologies, the well-designed Flash movie, the nifty DHTML
    script, what kind of site would remain? Just text and the tiniest bit
    of HTML? Booooring.
    But then I discovered two things.
    First of all sites should be exciting only when their purpose is to
    be exciting. An entertainment site should be exciting, sure. But what
    about an e-commerce site? A corporate site? A government site should be a bit dull, I'd think, to underline the importance of the information it provides.
    Secondly, the whole idea of exciting vs. simple is a beginner's
    mistake, and in 1999 I was very much a beginner. Clients make this
    mistake all the time because they are beginners by definition. They
    (and many developers) are misled by the magic words "interactive
    multimedia". A site should be interactive! It should be multimedial!
    (whatever that may mean) The site should move, dance, prance, and who
    cares whether the subject calls for it? We're creative, right?

    Simplicity

    The old World Press Photo site was a typical example of this school
    of thought. It didn't contain any moving stuff, but to make up for that
    we used a tiny Java applet to mimic a dropdown box navigation - why keep it dull if we can make it complex? I replaced it with JavaScript during the review a year later. It can be argued that the site is still too complicated.
    The good news is that in 2001 I got the chance to completely
    recreate the site, this time on better principles. We stopped using
    frames, and we changed the complex navigation scripts to slightly less
    complex DHTML scripts that enhanced the site but didn't contain vital
    functions. The result is a site that fulfills its purpose: showing the World Press Photos of the Year.
    This made me rethink the whole complex-but-exciting approach and at
    the moment I'm on the move toward simplicity. I keep the purpose of the
    site firmly in mind and don't add unnecessary stuff just because it's
    possible. The newest browsers help a lot: CSS goes a long way towards
    creating appealing but simple sites.
    In the next months I'll share my thoughts on simplicity in this
    column on Digital Web Magazine. Why do people make complex sites? When
    does a site become too complex? How should you judge whether a site
    needs to be complex? What techniques should you use to avoid complexity?
    To make it absolutely clear, at the moment I write this I don't
    have the faintest idea what the answers will be. Let's hope they'll be
    simple...

    By Peter-Paul Koch
    Published on August 26, 2002

    Copyright ? 1994-2005 Digital Web Magazine. All Rights Reserved.

    Posted by ideawu at 20:58:51
  • 2005-12-01

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

    Views: 8975 | 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: 8046 | 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: 8059 | 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
  • 2005-12-01

    Linux离我们还有多远?谈Linux系统的中文问题

    Views: 8169 | No Comments

    1.前言

    随着更多的国际巨头将目光投向Linux,这一充满传奇色彩的操作系统迅速地在全世界范围内得到了广泛的应用??不管是科学领域,还是在商务领域、桌面领域,Linux都表现得游刃有余。

    不过在中国,在政府采购之外,我们却完全看不到这种景象。令人奇怪的是,中国甚至还拥有几个自己的Linux发行版,可是既没有宣传攻势,也没有媒体关注,甚至市场上也很难见到和买到。而Linux相关技术对于中国软件业的重要性无异于一根救命稻草,中国的软件企业却大都对它视若无睹。

    如今,在整个国际环境发生变化之后,国内终于有越来越多的人开始关注并使用Linux。可是形势却很令人迷惑:在市场上,他们只能买到redhat(红帽子)公司的发行版(包括redhat和fedora core),而对于国内开发商,顶多也只听说过红旗。于是,在中国,redhat=最好的Linux,红旗=国产Linux,人们无法选择其他闻所未闻的发行版。

    事实上,redhat9、红旗尽管中文支持相当优秀,但在其他方面实在是差强人意,与新的发行版如fedora core、suse、mandriva等根本无法相提并论。而在部分人通过网络下载到这类一流的Linux发行版并安装后,许多人失望了:Linux也许很漂亮,也许很易用,也许很稳定,可是我们没法用??中文显示乱七八糟,中文软件寥寥可数。最后,还是去用多年前最好的Linux或者国产Linux吧……

    这到底是为什么?Linux到底离我们有多远?本文仅就Linux在中国推广过程中出现的两大问题??字体、软件本地化,进行分析和讨论。

    2.现状

    我们说Linux的中文支持存在问题,是和Windows相比较而言的。Windows的中文支持相当优秀。相比较而言,Linux下的中文显示简直乱七八糟,许多世界一流的发行版哪怕是安装过程中选择了中文(中国),在安装之后,要不就是中文显示缺字,或者很难看,或者是乱码,或者干脆就没有中文。当我们背着“盗版”的罪名把Windows下的宋体字体拷过来之后,这才发现系统根本无法显示中文的粗体和斜体效果……如果你愿意的话,可以到网上搜一下Linux安装和配置方面的文章,最常见的问题肯定是:字体美化。那些乱七八糟的命令和一大堆配置文件足以让无数初接触Linux的人知难而退。

    在经历了痛苦和艰辛之后,你终于可以使系统正常显示中文了,这时却发现了新的问题:无数应用软件根本没有中文的。Linux的应用软件不少,但有中文界面的却着实不多(和Windows下的相比)。对于一个Linux新手而言,最痛苦的莫过于为了做一件在Windows下可以舒舒服服就完成的事情,不得不在因特网的海洋中大肆搜索Linux下的替代品,然后是忍受那满屏的英文……

    3.原因

    假若中国人没有中文字体和中文软件可用,应该怪谁呢?

    字体

    很多人在埋怨,为什么Redhat以外的国外Linux开发商不重视中国市场,连字体都不愿意提供?

    有一点我们必须明白:当某个软件在某个区域的支持上表现不佳时,往往可以归咎于这个区域而非软件本身,至少在Linux世界往往如此。

    与中文支持形成鲜明对比的是,一般的Linux发行版的日文、韩文乃至阿拉伯文的支持都很好(这是当然的),系统中往往已经附带了一批这些语言的字体。这总是让人产生“Linux不重视中国市场”的错觉。也许是微软的Windows出色的中文支持让大家逐渐遗忘了事实:Windows中自带的中文字体并非微软出产,而是我国的中易公司制作的。问题是Windows是一个商业桌面系统,微软有充足的金钱来购买中国字体公司制作的字体,或者雇用中国的开发团队来为他们进行本地化工作。Redhat、红旗之所以具有良好的中文支持,也正是采用了同样的方法。而今天的Suse、Mandriva等Linux开发商也已经开始走上同样的道路。

    似乎这个问题就此解决了。可是,为什么我们的邻居??日本和韩国,却根本没有发生这样的问题呢?难道是因为他们的经济比我们要发达么??对于那些社区开发的Linux发行版,又是采用什么方法来解决其他亚洲语言字体的呢?

    事实上,不管是在日本还是在韩国,这类字体都是由商业公司免费提供给Linux使用的,面对这一可能将对自己民族产生巨大利益的自由操作系统,他们无法只是盯着那点利润不放。在台湾,文鼎公司也一次提供了14套中文字体供Linux使用者免费使用。然而,中国大陆则根本没有任何一家字体公司宁可任由别人去盗版自己的字体,也不愿意将自己的任何一款字体在Linux下授权免费使用。结果,我们目前所能找到的所有开源的或是免费的简体中文字体,几乎全部是出自大陆以外的华人同胞之手!至于欧美的情况,看看任何一款Linux发行版中所附带的近百种令人眼花缭乱的英文字体,就应该可以明白这些资本主义国家中的字体公司是如何看待这个问题的了。

    目前的情况还真是有些可笑,我们明明有那么多的企业拥有字体,可是作为中国人,我们却没有一款大陆公司或大陆开源社区制作的简体中文字体可用。

    粗斜体问题

    很多人觉得很奇怪,在Linux下,默认情况通常是无法显示中文粗斜体效果的,但英文的粗斜体效果却很好,恐怕不由得又开始怀疑别人的“中国市场政策”了。

    不过,这次是Linux本身的问题。我们如果要看到粗斜体效果,其实有两种方法:一是字体本身带有粗体、斜体、粗斜体,即每个同名字体会有4个文件;二是字体本身只有一个文件,由操作系统计算粗斜体效果,这种粗斜体称为模拟粗斜体。现在大家应该明白了,Linux之所以无法显示中文粗斜体,正是因为我们在Windows常用的中文字体,都根本没带有粗斜体,完全是由系统模拟的,而Linux默认没有计算模拟粗斜体的功能。而Linux之所以对英文的粗斜体支持不错,则是因为几乎所有的英文字体,都是本身带有粗斜体文件的!

    现在我们知道,Linux在这方面确实存在不足;而我们也知道了,其实我们自己完全可以解决这个问题。有人也许会抱怨多套字体占空间,不过这种抱怨是无用的,因为你系统中的英文字体已经采用了这样的解决方案。我们当然可以等待Linux将模拟粗斜体的计算模块纳入默认的发布版中,但是在那之前,我们完全可以先通过制作粗斜体字体的方法来解决。也许有人会觉得很麻烦,其实这一切都是可以由软件来完全搞定的,费不了什么事,不过有个前提:必须有字体公司授权或者字体公司自己愿意做。尽管网络上已经出现了多款这样的字体,但是目前并没有任何一款是获得字体公司合法授权的,而且本身也存在着各种问题。而在盗版Windows的长期统治下,似乎没有任何一家中国的字体公司意识到自己有必要解决这个问题。

    中文软件

    这里说的“中文软件”指两种,一种是我们自己做的中文软件,一种是对老外的软件进行了汉化之后的软件。

    首先,我们自己做的Linux中文软件比较少,这一点是很容易理解的,因为中国的Linux用户和开发人员都比较少,随着Linux的普及程度得到加强,这个问题也会逐渐得到解决。

    对于汉化软件的缺乏,我们可以回顾一下上面所说过的那一条:当某个软件在某个区域的支持上表现不佳时,往往可以归咎于这个区域而非软件本身,至少在Linux世界往往如此。在Linux世界中,中文翻译人员还是很多的,而且我们可以看到,像KDE、GNOME、Firefox之类的大型软件项目的中文本地化程度都很高。不过,跟Windows下的情况相比,又存在一些不同。

    在windows下,以商业软件占多数,因此汉化工作主要有两种。一种是厂商主动进行中文本地化以在中国市场进行推广,这种本地化通常质量比较高。另一种也就是常见的所谓“汉化破解”,一般由用户中的一些高手在未得到厂商许可的情况下,为了方便而自行进行汉化,这种汉化的质量通常取决于个人的实力。在Windows下,前一种情况更常见些。

    在linux下,则以自由软件占多数,汉化工作也就更依赖于普通用户。自由软件为了方便用户进行本地化,通常在国际化支持方面都会做得比较好,以便用户只需要提供一个语言文件即可。而且在Linux下,汉化工作通常是由一群爱好者组成的一个汉化小组进行的,因此在质量方面也比较有保障。

    也就是说,Linux的汉化软件之所以不多,正是因为中国的普通用户很少愿意去为软件进行汉化工作,而这种工作通常是无偿的。

    尽管客观上存在着用户数不高的原因,但这并不是一个很好的借口,因为其他语言的本地化情况则完全不同。通常每个软件出来之后,都是首先出现拉丁语系的语言文件,然后必定是日本和俄国的,紧接着就是繁体中文的,最后才有可能出现简体中文的。许多简体中文包根本就是基于繁体中文包的基础上制作的。中国是世界上人口最多的国家,可是在汉化工作上则是亚洲最落后的国家。不愿奉献而只顾索取,正是现代众多中国人精神面貌的一大特色。

    4.解决方案

    要解决以上这些问题,其实并不是那么困难。

    首先,最好还是有一些(哪怕有一个也好)商业字体公司为Linux用户提供一份免费使用授权协议,如果能附带粗斜体字体就更好了,这种做法对公司本身就是很好的宣传。如果我们的字体公司不愿意免费提供,我们的政府也完全可以以很小的代价购买这些字体的使用权并使它们对最终用户免费。另外,我们还可以号召中国的Linux爱好者募集资金成立一个基金会,由基金会来购买字体并且进行字体相关的一些工作。此外,我们还可以大力发展我们自己的开源社区,以开源的方式制作和发布字体,这方面文泉驿项目(不过似乎原本还是由我们的港澳台同胞牵的头)就做得相当不错。

    至于中文软件,大力推广和普及Linux和跨平台技术是个不错的解决方法。但要从根本上改变的话,则还是需要大力推动开源社区建设,以开源的方式来制作中文软件或是汉化软件,这对于发扬我们的共享精神和奉献精神也是很有帮助的。

    5.总结和曙光

    Linux离我们还有多远?当某个软件在某个区域的支持上表现不佳时,往往可以归咎于这个区域而非软件本身,至少在Linux世界往往如此。要在中国普及Linux,需要靠我们中国人自己的努力。

    - 作者: Addone 访问统计:30 2005年11月3日, 星期四 07:30

    天堂一角 http://addone.blogchina.com/blog/3399985.html

    Posted by ideawu at 13:07:14
|<<<130131132133134135136137138>>>| 136/138 Pages, 825 Results.