• 2005-12-03

    Keep it Simple

    Views: 6724 | 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 2005-12-03 20:58:51
  • 2005-12-01

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

    Views: 6796 | 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: 5923 | 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: 5894 | 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: 5916 | 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
  • 2005-11-30

    打谱软件Overture的操作指南

    Views: 10632 | No Comments

    也许您正为如何把自己的作品用线谱打印出来而发愁,也许您创作出的作品是冷冰冰的谱纸却听不到实际的声音效果,Overture打谱软件能满足您的各种要求!Overture打谱软件是专业打谱软件,打印出的乐谱质量绝对一流!它的功能十分强大,能制作包括单声部五线谱、钢琴谱、重奏谱、管弦乐队总谱、吉他六线谱、鼓谱等你所能用到的任何曲谱,更神奇的是它能将您的曲谱直接转化为实际的音响,丰富的音色、自如的音强、速度等的变化及一些特殊音响的运用定能使您对Overture爱不释手,而且目前网络上的各种乐谱资料,大多是ove格式,喜爱MIDI制作却又买不起昂贵设备的非专业人士也可以用它来满足您的需求,因此学会它的用法,一定会使您受益无穷!今天,我就给大家介绍如何用这种软件制作乐谱。

    下载安装

    您的电脑配置应该能合乎下列要求:

    CPU(奔腾166MMX以上),硬盘(2G以上),内存(32M以上),声卡(16位)

    如果您的英语不过关,可下载汉化版。

    下载并安装后就是您充分展现自己才华的时候!

    输入乐谱

    Overture最基本的和主要的功能就是制作乐谱,它是窗口界面,一些基本操作和一般Windows窗口的操作一样。下面我就介绍如何用Overture制作乐谱。

    1、 选择谱表

    将Overture打开后,如果没有自动弹出“新建琴谱”窗口的话,您可选择菜单中“文件”→“新建”,也可直接选择“新建”按钮 ,这时就会弹出“新建琴谱”窗口。

    在这个窗口中您可以选择您需要的各种谱表,Overture为您准备了单谱表、钢琴大谱表、吉他六线谱、以及重奏、交响乐总谱等多种模板,如果上面没有您需要的,您可以选择与您的音乐类似的模板后做增删修改。

    在这个窗口,您还可以直接选择调号、节拍、速度(可选择是否显示速度),可注明作品的标题、作者、版权。

    如果您的谱子是弱起,您须选择“不完全小节”选项。

    如果您想每次打开此软件都自动弹出此窗口,您要选择“启动时打开此对话框”。

    最后您点击“确定”!

    2、 关于工具栏

    Overture 的工具栏分三种,有标准工具栏、主工具栏、和输出工具栏。标准工具栏是进行窗口操作必须的新建、打开、存盘、打印、复制等按钮,主工具栏是指 Overture所特有的乐谱输入按钮,输出工具栏则为声音输出按钮。主工具栏中很多按钮都有很多子按钮的组群,为方便输入,您可以把常用的按钮组单独拖出,方法是鼠标左键点住按钮将其拖出至便于操作的空闲位置。

    3、 输入五线谱音符

    点击“音符”按钮 ,并将其拖出,会出现它的子按钮组,里面包含了各种时值的音符休止符以及临时变音记号。在您需要的音符上点一下,然后在五线谱相应的位置上点一下,就完成了此音的输入,音箱这时也会发出相应的声音效果。

    输入附点音符。以四分附点音符为例,先点四分音符 ,再点虚的符点音符图标 ,就可以输入了。

    输入倚音。用上面的方法,先选几分音符,确定倚音时值,再点倚音图标 ,然后输入即可。

    输入临时变化音,只要将变音记号在符头上点击即可。

    4、 音值组合

    音值组合是个较复杂的问题,复杂在音值组合的多样性。一般的音值组合你可以选择菜单中“选项”→ “自动调整符尾”,这样系统就会按常规自动为您组合音符。下面我介绍一些特别的组合方法。

    2/4 节拍中八分音符组合。2/4节拍一小节中如是四个八分音符,如您设置的是“自动调整符尾”,系统会自动组合成四个音的符尾相连,如果您想组合成两个单位,有两个方法,一是点击选择按钮,拖左键把需要的音符框住,音符变成红色,再从菜单中选“音符”→“符尾”→“根据节拍”,即可实现两音的组合,这种方法适合小范围的调整,第二种方法一劳永逸,需提前设置,选择菜单“小节”→“设置节拍”,这时系统弹出“设置节拍”对话框,在“符尾”选项的“初级”中填入“2+2”即可,初级的意思是四分音符的第一层拆分即八分音符。用此方法还可把3/8的整小节组合变为三个单独的八分音符,您只需填入“1+1+1”。在谱表开头拍号处点击右键也会弹出此对话框 (在此对话框“符尾”中您还可以对次级十六分音符和三十二分音符的组合方式进行特别组合)。

    人工组合。拖左键把需要组合的音符框住,选择“音符”→“符尾”→“手工指定”,您就可以完成组合。

    连音的组合。三连音的组合很简单,以三个八分音符的三连音为例:在音符工具中点八分音符 和三连音图标,输入即可。五、七、九……连音要先输入音符,并用选择按钮定义,再从菜单中选择“音符”→“组”→“连音”,出现对话框,第一行为两个空格,第一个为连音数目,第二个为连音代替的时值,您根据需要向上填写,然后您可选择输入风格后按“确定”即可(比如您想写五个八分音符的五连音,需要代替四个八分音符的时值,您可填入“5/4”)。

    5、 演奏记号

    演奏记号包含常用记号、装饰音记号、力度记号、表情记号等。“记号”图标 、“装饰音记号”图标 、“力度”记号图标 、“表情记号”图标 ,它们中各包含了一些常用的演奏记号,前两类您可选择后点击音符符头,后两类您只需选中后加入乐谱的合适位置即可。

    6、 反复记号

    一般的反复记号(双纵线)只要在“小节线”图标中选反复记号,在乐谱相应位置点击就行,反复的遍数可任意设定:在设置好的反复记号上双击,弹出对话框,填充需要的遍数即可。

    “跳房子”式的反复记号(即类似1、2段结尾不同的反复)要从“小节线”图标 中选择。

    “跳房子”的反复次数(如1-3段反复后接4结尾),可双击段落数字处,弹出对话框,在空格中分别填“1-3”和“4”即可。

    其他的反复记号要在菜单“小节”→“反复记号”中选择:

    打开“反复记号” 对话框。

    “$”(这个符号应该是两边有两个点,我在WORD里没找到,找个类似的充一下)要与其他符号连用,表示反复从此处开始。设置时先将光标移至反复处,选“Segno”也就是第一项“$”即可。

    “Φ”(这个符号应该是还有一个横线,也是找个类似的充一下)要两个结合着使用,表示反复时跨过此两个符号中间的部分。设置时将“Coda”(第二项)设置在开始跨越处,将“To Coda”设置在跨越结束处。

    “D.S.al Cod”表示到此处后再从“$”处反复。

    “D.S.al Fin”表示到此处后再从“$”处反复,并且到fine处结束。

    “D.C.al Cod”表示到此处后从头反复。

    “D.C.al Fin”表示到此处后从头反复并且到fine处结束。

    “Fine”为乐曲结束标记。

    以上设置时都要注意先将光标移到目标处。

    “文字”选项可默认(“D.S.al Fin”类似这样的符号一般简称“D.S.” “D.C.”),也可输入汉字的反复记号说明,比如“曲终”等。

    下面举几个例子:

    1 ?2 ?$ 3 ? 4 ? 5 ? 6 Fine ‖ 7 ?8 D.S.al Fin ‖

    表示从1到8,然后从从3到6结束。

    1 ?2 ? 3 ? 4 ? 5 ? 6 Fine ‖ 7 ?8 D.C.al Fin ‖

    表示从1到8,然后从1到6结束。

    1 ?2 ?Φ 3 ?4 ?Φ5 ? 6? 7 Fine ‖ 8 ?9 D.C.al Fin ‖

    表示从1到9,再从1到2,跨过3、4、5。从6到7结束。

    有一个问题,就是“D.S.al Fin”这一类符号无法移到线谱下方,可在设置“文字”选项时保持其为空格,设置后在符号标记处拉出文本框填上正确的标记即可。文本框的设置见下一内容。

    7、 文字输入

    标题选项。标题选项中包含题目、注解、作者、版权、页眉、页脚选项。点击菜单“乐谱”→“标题属性页”,您可输入对应文字及调整字体、字号。

    歌词输入。点击“文本框”图标 ,在谱面对应位置拉出文本框,输入文字就可以了,为了便于调整歌词位置,您最好一个文本框只输入一个字。文字字体、字号可从自动弹出的操作窗口设置、调整。

    8、吉他六线谱、鼓谱的输入方法和五线谱类似,您只需点击它们的对应选项即可。关于鼓谱有个问题,打击乐的音色很多,在线谱上的位置也或很高或很低,这样写谱会很不美观,而且很多音色的符头标记也有各自的习惯用法,怎样才能按照自己的意愿修改各种鼓的线谱位置和符头标记?比如安排低音鼓在一线,军鼓在三线……;低音鼓用黑符头,踩镲用叉号……?

    选单谱表Bass Drum或Drums,如果你是插入鼓谱,要选“乐谱”→“插入音轨”,弹出对话框,点第三项“打击乐”插入即可。

    a 在鼓谱的专用谱号“‖”上点击右键,出现“音轨设置”对话框,右边的白窗就是需要您设置的选项。“Name” 与“Pitch”是软件原来设置的打击乐音色与线谱的对应位置,注意下加一线为“C4”,“Head”是各音色的符头标记,“Pos”是指您需要指定的音色的目标位置。

    b 好了,假如您想把低音鼓设置在一线,您可用左键按住某一行的“Name” 或“Pitch”选项,你的面前即出现所有打击乐的音色,您选“B1”或“C2”(它们都是低音鼓音色),松开,此选项即变成了您选中的音色,然后您点 “Head”选项,选择您需要的符头,点“Pos”,拉动黑方块至您需要的一线位置,按确定,您对低音鼓的设置即大功告成。

    c 您用同样的方法可设置其他您想用到的打击乐音色。

    d 您最好将输入一行谱表的各种音色分成几个声部,这样可使谱面清洁、美观、易于输入、修改。比如您可设置低音鼓在声部“1”,符干向下,踩镲在声部“2”,符干向上……。(多声部的输入法见下一项内容中的多声部输入)

    修改调整

    首先要了解小箭头“选择”图标 的用法:a、光标移动。b、按住左键拖拉定义操作目标。C、移至目标处变为十字星花时可将目标移至谱面任意位置。

    然后注意鼠标右键的使用。许多功能都能通过点右键弹出相应的操作对话框。

    还要注意“撤消”、“剪切”、“复制”、“粘贴”“合并”“清除”功能的运用。“撤消”功能在菜单“编辑”→“撤消”,可以撤回你前面的操作。“剪切”、 “复制”、“粘贴”在标准工具栏,操作方法与一般Windows窗口的操作一样。合并的方法:如想将B合到A,先将B剪切,再定义A,选菜单“编辑”→ “合并”。“清除”可先定义,再选“编辑”→“清除”,也可用“清除”图标 点击目标清除。

    下面介绍一些常用的修改与调整:

    音高的修改。光标移至该音变成星花后点击定义,然后按住鼠标左键上下移动至目标高度。

    大段音符音高的移高、移低有两种方法,一是先定义音符,再将鼠标指针移至音符上变成星花后,拉动所有音符上下移动至目标处即可;二是先定义音符,再选“音符”→“移调”,出现对话框,上面是移动的类型(全、半音)和移动的方向,下面是移动多大的音程,可从小白窗中选择。

    音轨的设置。选菜单“乐谱”→“音轨设置”,弹出对话框,在“正式”和“缩写”中写入或选入名称(从右边“乐器”栏点第一个条形框选择),设置合适的字体,设定需要显示的对象及格式。

    节拍的设置。选菜单“小节”→“设置节拍”,弹出“设置节拍”对话框,可改变节拍。如果上行提供的拍号没有您需要的,您可在“主要”栏中改变数值。如果是混合拍子,您想以组合的形式出现,比如“3/8+2/8+2/8”,您先在“主要”栏标示“7/8”,把此栏“显示”的“√”去掉,再把组合栏中的“显示” 标为“√”,并在此栏的三、四行分别填“3+2+2”和“8+8+8”,即“3/8+2/8+2/8”,如果您想显示“7/8(3/8+2/8+ 2/8)”,只需把“主要”“组合” 栏的“显示” 都选中,同时选中组合中的“显示”选项即可。散板的拍号可先在拍号位置拉出文字框,再从软键盘中选日文片假名中的“サ”即可。

    谱号的修改。可从工具栏“谱号” 中来选,选中后在相应的位置一点即可,也可在菜单“音轨设置”中选择。

    调号的变化。可从“小节”“设置调号”中选择并加入谱中相应的位置。 如果您想将输好的乐谱移调,您也可从“设置调号”中选“移调”,再调整新调设置即可。

    插入。输完一页乐谱,您选“乐谱”→“插入页”,弹出对话框后设置插入的页数即可。音轨的插入选“乐谱”→“插入音轨”,弹出对话框后选择合适的音轨谱表,并别忘了选择插入当前音轨的位置。小节的插入选“小节”→“插入”。谱表的插入从“谱表”图标中选择,注意要想插入在当前谱表的上面,则点击当前谱表的三线以上位置,反之则点三线以下。(比如在钢琴大谱表中插入一钢琴谱表制成四手联弹谱表,您只需从“谱表”图标中选择钢琴大谱表,在原谱表上行的三线以上或下行的三线以下点击即可。)

    单行谱表。单行谱表头端有一多余的小节线,您可用工具栏的“小节线”按钮点击第一小节前端部分,每行前端多余小线即被消除。

    多声部输入。有的乐谱一行谱表中就有多个声部,如果是小范围的,先打上第一声部,定义后选“音符”→“符干”→“符干向上”,再选视窗下面,点击“全部”,选“2”,这时先前打的乐谱变虚,打上第二声部,设成“符干向下”,如还有声部,选“3”,方法同上,类推……,最后点击“All”,所有声部即正常显示。如果是大段落的多声部,可选“窗口”→“音轨窗口”,弹出对话框,点击第一栏 中需要改动的音轨的三角号, 再将Voice 1(声部1)、Voice 2(声部2)……等选项的“Stem”(符干)标记为向上或向下 。

    琶音的输入法。在一行谱表中,可先定义音符,再选“音符”→“标记为琶音”,如果是贯穿上下两行谱表的琶音,可先标记上行的记号,再点琶音记号下端下拉即可。

    连线的标记。可选图标中的不同连线将音符框住标记,也可先定义需要连接的音符,再选“音符”→“组”→“同音高连线”或“不同音高连线”。跨上下行相连时的音符,应按Ctrl 键两次定义,再加连线。钢琴大谱表左右手相连的情况,可先在一个音轨打好音,将左手音定义,选“音符”→“移至(上)下一音轨”,再将需要连接的音定义,并加连线。

    五线谱大小。如果您想对五线谱的显示比例进行修改,可选“乐谱”→“音轨设置”,再改变“五线谱”栏的显示百分比即可,也可先点 图标,再用鼠标框住需修改部分,弹出对话框后修改数据即可。

    谱面设置。可选“乐谱”→“重设谱距”,让系统自动设置谱面,也可从“乐谱”→“谱面布局”或“乐谱”→“调整谱表”或“乐谱”→“谱面设置”中进行相关数据的调整。小节的宽窄可选“小节”→“缩排”“扩排”来调整。此外,您可将鼠标移至任何能变成星花的地方进行上下左右的随意调节。

    纸张的大小可从“乐谱”→“纸张尺寸”的对话框调整,如果里面是以“in.”为单位,可点击它改为“cm.”。

    试听

    初步完成,您可点击输出工具栏的相应图标 试听,检查是否有错误、疏漏。当然,由于您还没对音响效果予以设置(比如力度、速度、特殊效果等),声音可能过于机械,但如果您只是需要打印曲谱,则无须设置。

    打印

    如果谱面检查无误,您就可以付印了,注意如果您需外出打印,则必须在打印的计算机上下载本程序,否则无法打印。总谱要想打印分谱,则选“文件”→“分离声部”即可。您也可象打印文档一样进行打印预览、页面设置。

    好了,点击打印选项,您就拥有了一份高质量的线谱曲谱!

    上面我主要把打谱软件Overture的乐谱谱面制作方法向大家作了个基本介绍,Overture是个有声软件,乐谱输入后,就会产生相应的声音,但这声音没有丝毫的变化,音乐中需要的力度、速度、音色及一些特殊音响效果都没有体现,要想使Overture产生出类似真人演奏的效果,就得对其进行设置、调整。今天就给大家谈谈如何调整设置音效的问题。

    力度的调整

    “力度”图标内有从“pppp”→“ffff”以及“sf”“fz”等力度标记,这些符号输入要调整好对应位置,但按住鼠标拖动时要注意把自动产生的指向虚线对准目标音,这样,音强的变化就从目标音开始。关于这些力度的参数可自由设置,位置是菜单“选项”→“参数设置”,弹出对话框选“力度”,然后改变相应数值即可。

    力度图标中还有渐强、渐弱符号,包括字母标记的和拉线标记的,您要选好按钮,字母标记的直接把符号点在相应位置,拉线标记的,从力度变化起始点按住拉向终点即可,但都要注意把指向虚线对准起始音。

    以上两种方法虽能有变化效果,但变化太死板,不能更灵活细致的变化,而且谱面上也不允许有繁琐的力度记号,还有一种更好的方法作出力度的细致变化,那就是利用“图解窗口”。

    选菜单“窗口”→“图解窗口”,您的面前就会展现出一个分上下两个区域的图形窗口,从左上的小白窗口选“力度”,右上的小白窗选择修改的音轨,鼠标从左上工具栏选小画笔,然后在下面的区域您就可以自由划出力度变化曲线,上面对应的数字是小节数,左面对应的数字是力度范围(0-127),如果您嫌数小节太麻烦,可边播放着边紧跟着光标划线,划完后再边播放边修改。

    速度的调整

    乐曲的速度的改变要先把光标移到需要改变处,选“小节”→“设置速度”,然后修改相应选项中的数值即可。

    这种方法适合大段落的速度改变,如果要作出更细微的灵活多变的速度调整,还得靠“图解窗口”。打开“图解窗口”,从左上小白窗选“tempo”,选择好要修改的音轨,然后用小画笔在下面的编辑区域划线,变化范围是(0-150)。

    音色的调整

    如果您对当前的音色不太满意,可从“音轨窗口”中调整。选“窗口”→“音轨窗口”,鼠标按住您要修改的音轨的“Patch”选项,再从自动出现的音色库中选择即可,音色库是英文的,您可用“金山快译”来翻译它。

    装饰音的设置

    虽然我们可从“装饰音记号”的图标里选择各种装饰音符号标记在谱面中,但它们只是作为谱面的视觉呈示,大多没有相应的音效,要想得到完美的音响效果,必须进行特别的设置。常见的设置方法有:

    1、“点击符头”法。以震音为例,在工具栏“记号”图标组,您选择震动次数合适的震音按钮后,点击该音符头,便会自动生成有音效的震音。用此种方法来标记颤音“tr”也会产生相应的颤音效果。但对于其他标记用此法,只能生成谱面,不能产生音效。

    2、“标记为”法。以琶音为例,先按实际演奏效果打上曲谱,再将这些音符定义,然后选“音符”→“标记为”→“琶音”即可。用同样的方法,还可标记颤音(tr)、回音、倚音等。

    3、 “隐藏曲谱”法。第一步:先打上应该显示的谱面,然后从下窗口“声部:”栏选“2”,这时刚打上的谱子变虚,您现在打上实际演奏效果的谱子并定义,选“编辑”→“隐藏”。第二步:打开“窗口”→“音轨窗口”,点刚才输入音轨的三角号,在“Voice1”的“M”栏点一下,出现“M”标记,刚才先打上的谱面的声音即被隐藏,退出音轨窗口别忘了把“声部:”改回“All(全部)”。现在是看到的谱面听不到声音,听到的声音却是隐藏的谱面。此种方法适用于大多数装饰音的音效处理。

    4、“图解窗口”调节法。图解窗口的上面编辑区域为音高、音长、及音符始、终的位置调整窗口,黑色的方块代表音符,方块的高度对应左窗的键盘,C4为中央C,方块的长度代表时值,每一个方格代表一拍,您可以自由的调节它的高度、长度、以及左右位置。方法是将鼠标移至目标音,当光标变为横的双箭头时,上下移动可改变音高,曲谱内的音高标记位置相应改变;当其变成竖的双箭头时,可拉宽、缩窄黑方块改变音的演奏时值,也可左右移动方块改变发音的起始、结束位置,曲谱的标记不会产生变化。琶音、倚音、跳音等都可用此法(具体方法见下面介绍)。

    下面是某些装饰音音效的设置方法。

    震音的设置。产生音效的震音设置方法有三种:第一种,点击符头法。第二种,隐藏曲谱法。第三种,定义目标音,选“音符”→“符尾”→“八分(十六、三十二、六十四分)音符震音”,该音便被标记为有音效的震音。

    跳音的设置。跳音的标记符号也在工具栏“记号”组,可是没有音效,让它产生断音效果的方法有三种:第一种,选中该音符,选“音符”→“修改”,弹出对话框,下拉左小窗,选“Scale”,中间小窗选“Duration”,然后修改右小窗的百分比数值即可。第二种,利用“图解窗口”,跳音的长短可通过调整上面区域黑方块的宽窄实现,方法是鼠标移到目标音变成横的双箭头时,左右拉动黑方块。第三种,“标记为”的方法,先打出音符实际演奏的时值,别忘了把剩余的时值用休止符补上,然后将音符休止符共同定义,再选“音符”→“标记为”→“断音”。此外,您也可用“隐藏曲谱”法。

    琶音的设置。除了用上面介绍的“标记为”法、“隐藏曲谱”法,您还可以用“图解窗口”调节法,您将窗口上区域要标记为琶音的黑方块位置左右调一下,听听效果就知道了。

    倚音的设置。用“标记为”法、“隐藏曲谱”法及“图解窗口”调节法都可以,但Overture把倚音算在前面音的时值内,要想调节出理想的效果,您最好使用后两种方法。

    刮奏的设置。用“隐藏曲谱”法,记录实际音响效果时,您要先选择一些音符,把它们定义成连音,并设置好连音选项(比如总时值的数据设置),再把它隐藏。

    特殊效果的设置

    还有一些特殊效果,也有特别的设置:

    钢琴踏板的设置。如果您用“点击符头”法标记踏板,则只有谱面,没有音效,如果您想作出效果,有两种方法。一是将记号放在目标音的下方,注意调节位置时让自动产生的指向虚线对准目标音即可。第二种要用到图解窗口,从左上的白小窗选“Control”,紧挨者的小白窗选“64-pedal (sustain)”,然后用小画笔在下面的编辑区域点击,点“0”以上的地方出现竖线,点“0”以下的地方则出现小点,竖线表示踩踏板,小点表示松踏板。

    波浪式颤音。用图解窗口,左小白窗选“Control”,紧挨者的小白窗选“1-Modulation”,然后用画笔在下面编辑区画即可。这种音响适用于小提琴等乐器拖长音时的修饰。

    弯音的设置。也用图解窗口,从左上小白窗选“Wheel”,然后用画笔在下面编辑区画即可。这种音响适用于模仿电吉他推弦技巧。

    以上介绍的是关于打谱软件Overture设置方面的一些基本方法,真正要使您创作的作品谱面更整洁美观、音乐更优美动听,需要您在实践中不断摸索,愿Overture能真正成为您得力的助手!

    转载自:http://www.korw.com/bbs.cgi?menu=show&id=200402082047&slttitle=20050207200627&page=1

    Posted by ideawu at 2005-11-30 16:40:00
|<<<115116117118119120121122123>>>| 121/123 Pages, 734 Results.