java解码器

1. java中classpath的值是多少

查看文章 JAVA中classPath全面解析 2009年08月22日 14:15

# 摘要

Class Path是Java执行时期环境用来搜寻类别与其它资源所用之路径。Class Sear
ch Path（通常使用Class Path这个缩写名称比较为人所知）可以在呼叫SDK工具程
式时使用-classpath或者是设定CLASSPATH环境变数。建议是使用-classpath选项，
因为您可以独立的为每一个应用程式设定，而不会影响其它的应用程式，且不会有
其它的应用程式来改变这个值。

1 C:> sdkTool -classpath classpath1;classpath2...

-或-

1 C:> set CLASSPATH=classpath1;classpath2...

在这边：

sdkTool：是一个命令列工具程式，像是java、javac 或 javadoc.

classpath1;classpath2：指向.jar、.zip或 .class档案的Class Path，每一个cl
asspath都应以档名或目录名称（这与您所要设定的classpath有关）作结束。

* 对于一个包括.class的.jar或.zip档案而言，class path要以.zip或.jar档案的
名称作结束。

* 对于一个未命名的package而言，class path要以包括所有.class档案的目录作结
束。

* 对于一个已命名的package而言，class path要以包括"根"package（完整packag
e名称的第一个package）的目录名称作结束。

多个路径项目要以 分号 作区隔，使用set指令，重要的是等号两边不可有空白。

预设的class path是目前的目录，设定CLASSPATH变数或使用-classpath命令列选项
时会覆盖这个预设，所以如果您要在目前的搜寻路径中包括目前的目录，您必须在
新设定中包括"." 。

即不是目录也不是文件档案（.zip或.java）的classpath会被忽略。

# 说明

class path告诉SDK工具程式与应用程式要到哪边寻找第三元件（third-party）与
使用者定义的classes，也就是它们非Java延伸套件或非Java平台的一部份。在您使
用javac编译器编译类别时，需要使用class path来找出任何所需的套件 -- 预设是
目前的目录，以方便找到这些类别。 Java2 SDK、JVM与其它的SDK工具借由搜寻Ja
va平台、classes、其它延伸classes与class path来找到所需的classes，以这个顺
序（要瞭解搜寻策略的细节，请看如何寻找Classes, How Classes Are Found），
大部份应用程式所用的类别库就可以利用延伸套件机制（extensions mechanism）
，在您载入一个不在目前目录的类别或它的其它子目录且它们不在伸延伸套件机制
中时，您所要作的就是设定class path。

如果您从旧版本的SDK升级上来，在您的启动设定中可能包括已经不再使用的CLASS
PATH设定，您必须将这些非特定应用程式的设定移除，像是classes.zip，一些使用
到Java虚拟机器的第三元件应用程式可能会更改您的CLASSPATH环境变数，以将它们
所使用的程式库包括进去，这些设定则可以保留。

在您要求JVM或其它SDK工具程式时，您可以在使用Java工具程式时借由-classpath
选项来改变class path，或是使用CLASSPATH环境变数来指定。建议是使用-classp
ath选项会比设定CLASSPATH环境变数来得好，因为您可以为每一个应用程式分别设
定，而不会影响其它的应 用程式，而其它应用程式也不会改变这个值。

Classes可以被储存在目录（资料夹）或是在文件档案（archive files），Java平
台的classes是被储存在rt.jar，要瞭解文件档案的细节或是class path如何运作的
资讯，请看看稍后小节的 "瞭解class path与package名称"。

重要、注意：一些旧版本的JDK软体在预设的class path中包括了<jdk-dir>/class
es项目，这些目录的存在是为了被JDK软体使用，而不应被应用程式classes使用。
应用程式类别应该被放在JDK目录结构之外的其它目录，用这种方式，新的JDK就不
会强迫您重新安装应用程式classes，为了要与旧版本相容，必须使用<jdk-dir>/c
lasses目录作为类别库的的应用程式，在目前的版本也可以运作，但不保证在未来
的版本中仍可以运作。

# 使用SDK工具程式的-classpath选项

SDK工具程式 java、jdb、javac与javah拥有一个-classpath项目，当执行工具程式
时，它用于取代由CLASSPATH环境变数所设定的路径，在改变class path设定时，这
是个建议使用的选项，因为每一个应用程式可以拥有自已所需的class path，而不
会与其它应用程式相互干扰。

执行时期工具程式java也有一个 -cp 选项，这个选项是-classpath的缩写名称。

对于一些相当特殊的例子来说，java与javac都拥有一些项目可以让您改变它们用来
找到专属类别库的路径，然而绝大多数的使用者从未需要使用这些项目。

# 使用CLASSPATH环境变数

一般而言，建议您使用-classpath命令列选项，就如同上面所提过的，这个小节将
告让您如何设定CLASSPATH环境变数，如果您想这麼作的话，或者是想清除之前安装
所留下的设定。

设定 CLASSPATH：

CLASSPATH环境变数可以借由set指令来修改，格式是：

1 set CLASSPATH=path1;path2 ....

路径应该以磁盘机代号开始，例如C:\，用这种方式，即使您切换至另一个磁盘机也
可以找得到classes。（举个例子来说，假如路径项目以斜线开始而您在磁盘机D:，
那么classes将会预期是在D:，而不是C:）

清除 CLASSPATH：

如果您的CLASSPATH环境变数已经被设定为某个值，但是并不正确，或者是您的启动
档案或是命令稿被设定了错误的路径，您可以借由以下来取消CLASSPATH的设定：

1 C:> set CLASSPATH=

这个指令只取消目前的命令列提示视窗CLASSPATH设定，您应当删除或修正您的启动
设定，以保证您在下一次操作也会有正确的CLASSPATH设定。

改变启动设定：

如果CLASSPATH被设定于系统启动时，设定的地方则视您所使用的作业系统而定：

作业系统方法：

*Windows 95与98 检查autoexec.bat中的set指令

*其它（Windows NT、Windows 2000、....）使用控制台中的系统工具来设定CLASS
PATH变数

# 瞭解class path与package名称

Java的classes被组织为packages，它们对应于档案系统的目录结构，但是不像档案
系统，每当您指定一个package名称时，您指定整个package名称而不是部份名称，
例如，java.awt.Button的package名称是使用java.awt来指定。

例如，假设您要Java执行环境找到一个在 package名称 utility.myapp 中名叫Coo
l.class的class，假如该目录的路径是C:\java\MyClasses\utility\myapp，您要设
定class path以包括 C:\java\MyClasses。

要执行这个应用程式，您可以使用下面的JVM指令：

1 c:> java -classpath C:\java\MyClasses utility.myapp.Cool

当应用程式执行时，JVM会使用class path设定来找到任一其它被定义于utility.m
yapp package（它被Cool类别使用）中的类别。

注意在指令中被指定的整个package名称，这是不可能的，例如，设定class path包
括C:\java\MyClasses\utility并使用指令java myapp.Cool，这麼作并不会找到cl
ass。

（您可能会想是什么定义了一个class的package名称，答案是package名称是class
的一部份，而且不可被修改，除非重新编译）

注意：一个package指定机制的有趣的结果是，同一个package中的部份档案可以存
在于不同的目录，对于每一个class而言，package名称将会相同，但是每一个档案
的路径将会以class path中不同的目录开始。

目录与文件档案（archive files）：

当classes被储存在目录（资料夹），像是c:\java\MyClasses\utility\myapp，那
麼class path项目指向包括package名称第一个元素的目录（在这个例子中是c:\ja
va\MyClasses，因为package名称是utility.myapp）

但是当classes被储存在文件档案时（a.zip或.jar档案），class path项目就是指
向且包括.zip或.jar的档案，例如，使用在.jar档案中的类别库，指令会像是：

1 C:> java -classpath C:\java\MyClasses\myclasses.jar utility.myapp.Cool

多个指定：

要寻找C:\java\MyClasses中与C:\java\OtherClasses中的classes，您可以这麼设
定class path：

1 C:> java -classpath C:\java\MyClasses;C:\java\OtherClasses ...

注意两个路径是以分号作区隔。

指定顺序：

指定多个class path项目的顺序很重要，Java解码器（interpreter）会以class p
ath变数 中的顺序来于目录中寻找classes，在上面的例子中，Java解码器首先会在
目录C:\java\MyClasses中寻找所需的类别，只有在它于该目录中找不到适当名称的
类别时，解码器才会于C:\java\OtherClasses目录中寻找。

///////////
话说回来,
我们有没有办法, 将一些常用的 jar file 放到一个目录中 ex: commons-lib\
透过一个程式来自动 import commons-lib 之下的所有 jar
类似 tomcat 我们只要放到 lib 中, 程式会自动 import .
就可以 import and compile 了 ^^~

我想这是可行的.

但是现实中, 我们还要去判断重复的 class 该如何去设定.
看来, 要去 trace tomcat sourcecode 并且修改 ^^~

//////////////
javac.exe有一个参数-extdirs可以下, 我看它的说明
很像是下了这个就可以做到自动import指定目录下的jar档吧
不过java.exe没有
///////////
LoadClass
LoadLibrary
so many so on.

JDK allows compile at runtime.
/////////////
dear biology
我要的不是 LoadLibrary , 你这样还是需要指定你要哪个 library

应该是说, 我想要的是只要将相关的 jar file 放到一个指定的目录.
可以少去 complie 及 run 时候不需要设定 CLASSPATH.

////////////////////
刚刚测试了一下 ClassLoader 他可以把我们想要的 .jar 档全部载入 jvm 但是有
个小问题. 那就是 Class.forName(String) 这一个不一定会找到我们要的 class.
... 需要利用 class.forName(className, initialize, classloader). 但是需要
先指定 classloader... 这个是个问题....

原因是 Class.forName(string) 会取代成 Class.forName(string, true, curren
tClass.classloader)... 如果那个 classloader 本身(还有 parent classloader
)没有 这特定 library 存在, 那就无法抓到指定的 class.... 所以总归 还是一次
加入 CLASSPATH 比较好... 或则只好拜托人深入研究了...

[事实你可以利用 ClassLoader 半自动达到你要的东西....]

/////////
部分我测试用的 code: 希望多少有帮助...

java.net.URL u[]=new java.net.URL[1];

u[0]=new java.net.URL("http://localhost/onlytest.jar
);

java.net.URLClassLoader cl=java.net.URLClassLoader.newInstance(u,ClassLo
ader.getSystemClassLoader());

cl.loadClass("BioTester.BioTestClass").newInstance();

//org.apache.bcel.util.ClassLoader. //purpose?

//this will be failed: Class.forName("BioTester.something")

Object obj=Class.forName("BioTester.something",true,cl).newInstance();

//Object obj=cl.loadClass("BioTester.something").newInstance();

java.lang.reflect.Method m=obj.getClass().getMethod("aaa",null);

m.invoke(obj, null);

//////////////////
你们不会不知道吧？！

JRE/lib/ext 就是这个用途啊，让你放 third-party 的 library，JRE 启动时会把
自动载入里头的 jar(应该说 classloader 需要 resolve class 时会到这个目录下
来找)。

主要的问题是，安装 JDK 时一般人可能会装两个 JRE，一在 JDK 安装目录下的 J
RE 目录，一在(预设) Program files 目录下的 Java 目录。javac.exe 使用的是
JDK 所附的 private JRE(JDK/JRE)，而执行 Java 程式则要看你的 path 定。

JDK\bin\java.exe, JDK\jre\bin\java.exe 使用的是 private JRE，program fil
es\java\jre1.x.x\bin\java.exe, WinNT(Windows)\system32\java.exe 使用的是
public JRE。javaw.exe 同上。

比较保险的做法是把 third-party library jar file 在 private JRE/public JR
E 各放一份，这样可确保编译时可以 resolve third-party classes，或是设定 p
ath 使得优先使用 private JRE(或干脆就移除掉 public JRE)。

Eclipse 比较特别，你可以只把 third-party 放在 public JRE 就好，不需要放在
private JRE 也可以在编译时让编译器去参考到所需要的 class。

///////////////////
没错, 这就是我希望的功能,
摆在那边 install 没问题, 但是 uninstall 就会有问题了,
因为可能会有重复使用到的 jar files.
所以我希望能够指定一个目录

当我是个 application setup 完成之后,
目前的做法是在 run.bat 中设定相关的 CLASSPATH

此外, 对于一个 java 新手,
我也希望提供一个简单的方法管理及部署 jar files.
避免 CLASSPATH 设定的问题.

简单来说, 就是执行某个程式可以自由地增加目录相当 %JAVA_HOME%/lib/ext
接着我开发我的程式或执行我的程式,
而且透过那个程式可以做一些 jar files 的管理
例如说, 优先顺序, 重复剔除 等等的功能 ^^~

///////////////
我想jini兄跟Biologic兄应该都知道的...
但是我臆测可能他们认为放在JRE/lib/ext不是很恰当的方法
第一个问题就是将来使用者要自己把使用的classpath放在/jre/lib/ext
会造成使用者的困扰

二来 可能会有一些版本的冲突...
以前就有发生这个例子
就是抓了很多xml parser..
而每个里面又包了JAXP
结果有的包旧的有的包新的..
错误就这样产生了...

一般来讲还是在执行的时候给classpath才是上策
至于太多lib的话
我个人还是不喜欢程式里面用ClassLoader去抓...
我宁愿提供批次档给他执行
或是提供build.xml.. ant题供**/*.jar的写法
////////////////
同意 popcorny 的看法, 放在 JRE/lib/ext 下可行, 但"层级"太高, 尤其如果是在
web app(tomcat) 或 J2EE 的环境底下, 必须考虑 class loading 先后顺序的问题
(好像在spec中有定义.)

所以应该不会有任何一个java applicaion installation guide 要你把哪个 jar 放在
JRE/lib/ext 中

(但这好像不属于新手区的讨论 ...)
///////////////////////
如果说是同一套 library 不同版本的冲突问题，最基本(可能也是最好的)解法是，
替每一个 application 提供一个批次档，指定专用的 classpath。或是写个 clas
sloader 会依照 application 的属性(xml file)，到特定的目录去找 jar，但是这
没有办法套用在其他厂商提供的应用程式上。

一个比较可行的办法是，写一个 application launcher，拥有管理 jar library
及每个应用程式所倚赖的 library 的对应关系，然后要求使用者在执行任何 Java
application 时，都得透过 app launcher(app launcher 会启动特定的 classlo
ader 来载入 app 所需要的 jar)来启动(这很容易)。

//////////////////////////
很多 ext package 都是要求自己设定 classpath，指示把 ext-package jar 放进
Jre/lib/ext 也是有：Java Communications API。

/////////////////////
"很多 ext package 都是要求自己设定 classpath ..."

这样比较好.

"指示把 ext-package jar 放进 Jre/lib/ext 也是有 ..."

javax 是 java "extention", 个人认为比较不像 "application",
既然是 Java 的一部份, 建议直接放 jre/lib/ext 下也无可厚非,
但版本的问题可能会是 nightmare.
个人认为还是用 "application specific" classpath 好.

Application 把 jar 直接往 jre/lib/ext 放, 不是不可以, 而是*不应该*.
如果在 jre/lib/ext 下有一个 a.jar, 在classpath中有一个 a.jar,
在 WEB-INF/lib 下也有一个 a.jar,哪一个会先被用呢?
jini 兄提到的 uninstall 亦是个问题.

对新手来说, 建议把所有的 jar 往 jre/lib/ext 放可能方便些,
but may not be a good practice.

2. java怎么把utf-8的字符串转换为gb2312格式

Java中字符串转码，根据实际运用的环境有以下三种方式

1、使用Java.lang.String

这是最常用的方法，先用对应编码获取字节，然后重新构造新编码，示例代码如下：

Strings="清山";
byte[]b=s.getBytes("utf-8");//编码
Stringsa=newString(b,"gb2312");//解码:用什么字符集编码就用什么字符集解码

2、java.io.InputStreamReader/OutputStreamWriter:桥转换

读写文件的应用中，可以使用这种方式，直接在IO流构造中转换，示例代码如下：

InputStreamis=newFileInputStream("C:/项目进度跟踪.txt");//文件读取
InputStreamReaderisr=newInputStreamReader(is,"utf-8");//解码
OutputStreamos=newFileOutputStream("C:/项目进度跟踪_gb2312.txt");//文件输出
OutputStreamWriterosw=newOutputStreamWriter(os,"gb2312");//开始编码

3、java.nio.Charset

使用nio中的Charset转换字符，示例代码如下：

CharsetinSet=Charset.forName("utf-8");//解码字符集
CharsetoutSet=Charset.forName("gb2312");//编码字符集
CharsetDecoderde=inSet.newDecoder();//解码器
CharsetEncoderen=outSet.newEncoder();//编码

3. Netty 编码器和解码器

每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节，以及如何将数据格式与目标应用程序的格式进行相互转换。这一转换逻辑由编解码器处理，编解码器由编码器和解码器组成，它们可以将字节流从一种格式转换为另一种格式。编码器操作出站数据，而解码器处理入站数据。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站。反之称为入站。

Netty涉及的组件包括Channel、ChannelHandler、ChannelPipe等。ChannelHandler充当了处理入站和出站数据的应用程序逻辑容器。例如，实现ChannelInboundHandler接口（或ChannelInboundHandlerAdapter），就可以接收入站事件和数据，随后由应用程序的业务逻辑处理。当需要给连接的客户端发送响应时，也可以从ChannelInboundHandler中冲刷数据。业务逻辑通常写在一个或多个ChannelInboundHandler中。ChannelOutboundHandler原理相同，但用于处理出站数据。

ChannelPipeline提供了ChannelHandler链的容器。对于出站数据，即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler，并被这些Handler处理，而入站数据则只调用pipeline里的ChannelInboundHandler逻辑。

通过Netty发送或接受一个消息时，就会发生一次数据转换。入站消息会被解码，从字节转换为另一种格式（如Java对象）；如果是出站消息，则会被编码成字节。

Netty提供了一系列实用的编码解码器，它们实现了ChannelInboundHadnler或ChannelOutboundHandler接口。在这些类中，channelRead方法已经被重写。以入站为例，对于每个从入站Channel读取的消息，这个方法会被调用，随后调用由已知解码器提供的decode()方法进行解码，并将已解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。

Netty提供了多种编解码器，例如用于编解码字符串的StringEncoder和StringDecoder，以及用于编解码对象的ObjectEncoder和ObjectDecoder等。

解码器用于将字节解码为消息，Netty的解码器实现了ChannelInboundHandler。解码器何时使用？当需要将入站数据从一种格式转换为另一种格式时会用到。得益于ChannelPipeline的设计，可以将多个解码器链接在一起，以实现任意复杂的转换逻辑。将字节解码为消息的抽象类ByteToMessageDecoder，将入站数据进行缓冲，直到准备好处理。这是必须实现的唯一抽象方法，decode()方法被调用时会传入包含传入数据的ByteBuf，以及一个用来添加解码消息的List。方法调用会重复，直到确定没有新的元素被添加到该List，或者该ByteBuf中没有更多可读取的字节。如果List不为空，它的内容会被传递给ChannelPipeline中的下一个ChannelInboundHandler。

将一种消息类型解码为另一种，用于在两个消息格式之间进行转换（例如，从String->Integer）。对于每个需要被解码为另一种格式的入站消息，该方法都会被调用，解码消息随后会被传递给ChannelPipeline中的下一个ChannelInboundHandler。

MessageToMessageDecoder，T代表源数据的类型。

Netty中的几种常用Decoder。

Netty如何解决粘包半包问题？大多数协议（私有或公有）中，协议头中会携带长度字段，用于标识消息体或整包消息的长度，例如SMPP、HTTP协议等。由于基于长度解码需求的通用性，Netty提供了LengthFieldPrepender和LengthFieldBasedFrameDecoder来自动屏蔽TCP底层的拆包和粘包问题。通过传入正确的参数，可以轻松解决“读半包”问题。

发送方使用LengthFieldPrepender给实际内容添加报文头Length字段，接受方使用LengthFieldBasedFrameDecoder进行解码。协议格式如下：

Length字段表示Content部分的字节数，例如Length值为100，那么意味着Content部分占用的字节数就是100。Length字段本身占用的字节数也要存储在字段中，一般会使用固定的字节数表示。例如使用2个字节（有符号）表示length，可以表示的最大值为32767（约等于32K），这意味着Content部分占用的字节数最大不能超过32767。当然，Length字段存储的是Content字段的真实长度。

Content字段是我们要处理的真实二进制数据。在发送Content内容之前，首先需要获取其真实长度，添加在内容二进制流之前，然后再发送。Length占用的字节数+Content占用的字节数，就是总共要发送的字节数。

事实上，我们可以把Length部分看做报文头，报文头包含了解析报文体（Content字段）的相关元数据。当然，LengthFieldBasedFrameDecoder并没有限制我们只能添加Length报文头，我们可以在Length字段前或后加上一些其他报文头。

LengthFieldPrepender尤其值得说明的一点是，其提供了实现零拷贝的另一种思路。而LengthFieldPrepender，由于需要在原来的二进制数据之前添加一个Length字段，因此就需要对二者进行合并发送。但是LengthFieldPrepender并没有采用CompositeByteBuf，其编码过程如下：LengthFieldPrepender实际上是先把Length字段（报文头）添加到List中，再把msg本身（报文）添加到List中。而在发送数据时，LengthFieldPrepender的父类MessageToMessageEncoder会按照List中的元素下标按照顺序发送，因此相当于间接的把Length字段添加到了msg之前。从而避免了创建一个更大的ByteBuf将Length字段和msg内容合并到一起。