JAVA/JSP 中文乱码
自从接触Java和JSP以来，就不断与Java的中文乱码问题打交道，现在终于得到了彻底的解决，现将我们的解决心得与大家共享。
一、Java中文问题的由来
Java的内核和class文件是基于unicode的，这使Java程序具有良好的跨平台性，但也带来了一些中文乱码问题的麻烦。原因主要有两方面，Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。
首先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成
class文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。基于这种乱码，建议在Java文件中尽量不要写中文（注释部分不参与编译，写
中文没关系），如果必须写的话，尽量手动带参数－ecoding GBK或－ecoding
gb2312编译；对于JSP，在文件头加上或基本上就能解决这类乱码问题。
本文要重点讨论的是第二类乱码，即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介，如数据库，文件，流等的存储方式都是基于字节流的，Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换，具体情况如下：
从页面form提交数据到java程序 byte－>char
从java程序到页面显示 char?>byte
从数据库到java程序 byte?>char
从java程序到数据库 char?>byte
从文件到java程序 byte－>char
从java程序到文件 char－>byte
从流到java程序 byte－>char
从java程序到流 char－>byte
如果在以上转换过程中使用的编码方式与字节原有的编码不一致，很可能就会出现乱码。
二、解决方法
前面已经提到了Java程序与其他媒介交互时字符和字节的转换过程，如果这些转换过程中容易产生乱码。解决这些乱码问题的关键在于确保转换时使用的编码方式与字节原有的编码方式保持一致，下面分别论述（Java或JSP自身产生的乱码请参看第一部分）。
1、JSP与页面参数之间的乱码
JSP获取页面参数时一般采用系统默认的编码方式，如果页面参数的编码类型和系统默认的编码类型不一致，很可能就会出现乱码。解决这类乱码问
题的基本方法是在页面获取参数之前，强制指定request获取参数的编码方
式：request.setCharacterEncoding("GBK")或
request.setCharacterEncoding("gb2312")。
如果在JSP将变量输出到页面时出现了乱码，可以通过设置
respons
相关文档：
学习Java值传递方法-武汉北大青鸟
值传递是在一个函数中，调用另外一个函数，其中含有参数传递的情况。往往值传递就是把数据传递到另外一个函数中进行进一步处理，以更清楚地显示函数的表达意思。在函数调用的时候会有数据传递，同样要考虑形参和实参的问题，如下面的一个程序：
on error resume next ShockMode ......
手上一个项目需要通过usb口去读取usbkey的信息，厂家提供的只有C/C++的接口，而主应用是java的，所以需要使用java去调用动态链接库，所以花了点时间研究了下JNI技术，jdk对JNI技术封装得很到位，使用起来非常简单，JNI技术最关键还是在于jni数据类型和本地数据类型的转换。先简单罗列下JNI� ......
1、Java.util的集合类中的元素必须是对象化的，他们不能是基本类型。如不能声明Set<char>或List<int>。但对List<Integer>，可以往里面加int型数据，它会用Java的autoboxing机制自动转换成Integer对象。
2、参数化类中的类型参数可以是数组类型，如Map< ......
编写多线程的程序一直都是一件比较麻烦的事情，要考虑很多事情，处理不好还会出很多意想不到的麻烦。加上现在很多开发者接触到的项目都是打着企业级旗号的B/S项目，大多数人都很少涉及多线程，这又为本文的主角增加了一份神秘感。
讲到Java多线程，大多数人脑海中跳出来的是Thread、Runnable、synchronized…&hellip ......
