Which characters does JVM use(JVM使用那种字符表示)？
A. ASCII characters B. Unicode characters
C. Cp1252 D. UTF-8
解析：看题目，根据平常开发的经验，马虎一点的可能会选D，因为我们开发时用到最多的字符时D。但是我们来仔细分析一下。答案应该是B。
JVM的设计者当初设计JVM中的字符形式时，是不允许使用各种编码方式的字符共存的。这个是因为如果内存中的Java字符可以GB2321、UTF-16、BIG5等各种的形式存在，那么对开发者来说，最基本的字符串打印，字符串连接都会变得寸步难行。
例如：一个 GB2312 的字符串后面连接一个 UTF-8的字符串，那么最终打印的结果是什么呢？显然，选择哪一个都是没有道理的。
我们作为Java开发者，必须牢牢记住，在Java中只有一种字符存在，那就是 Unicode (不选择任何特定编码，直接使用他们在字符集中的编号，这是统一的唯一方法)。
这里又有一个问题，所谓 “在Java中 ”，是指哪里呢？经过思考，我们不难得出答案——是指在JVM中，在内存当中，在我们代码中申明的每一个 “char 、String”变量当中。
例如：
你在程序中这样的： char han = '永';
在内存中相应的区域，这个字符就表示为 0x6c38 ，可以用下面代码证明：
char han = '永';
System.out.format("%x",(short)han);
test.png
输出的最中结果是如上图。那么如果反过来呢，我们用 Unicode 编码来指定一个字符，像这样的：
char han = 0x6c38;
System.out.println(han);
image.png
输出结果如上图。
这其实也就是说，只要我们正确读入‘永’字，那么他在内存中表现形式一定0x6c38。
再延伸的来说，这其实就是一种约定。JVM的这种约定使用一个字符有两部分：JVM内部和OS文件系统。在JVM内部中，统一使用 Unicode 表示，当这个字符从 JVM 内部移到外部（即保存为文件系统中一个文件内容时），就使用了具体的编码方案进行转换。
因此，我们可以这样理解，所有发生编码转换只发生在边界的地方，JVM 和 OS 文件系统交界的地方，也就是各种输入流/输出流（或者是reader，writer类）的起作用的地方。
所有的IO可以分为两大阵营：面向字符的输入/输出流，面向字节的输入/输出流。这里又又一个问题“面向字符或面向字节中的 ‘面向’，是指这些了类中进行输入/输出的时候，在哪个意义上是保持一致的？”
如果是面向字节，那么需要保证的系统中文件二进制内容和读入JVM内的二进制内容一致。这种输入和输出的方式很适合视频和音频文件。或者任何不需要做变换的文件。
而面向字符的I/O是指希望系统中的文件的字符和读入内存的“字符”（注意和字节的区别）要一致。例如：我们的中文WwindowsXP系统上又一个GBK文本文件，其中有一个“永”字，这个字的GBK编码什么都不用管，当我们使用面向字符的I/O把它读入内存并保存在一个 char 型变量中时，我希望I/O系统不要直接把“永”字的GBK编码放到这个 （char）型变量中，，我不关心这个char 型变量的具体的二进制内容到底是多少，我只希望这个字符镀金来之后仍然是“永”字。
从这个意义上也可以看出，面向字符的I/O类，也就是Reader 和 Writer类，实际上是隐式的做了编码转换，在输出时，将内存中的 Unicode 字符使用系统默认的编码方式进行类编码，而输入时，将文件系统中已经编码过的字符使用默认的编码方案进行类还原。这里要注意：Reader 和 Writer 只会使用这个默认的编码来进行转换，而不能为一个Reader 和 Writer 制定转换时使用的编码。这也意味着，如果使用中文版的 WindoowsXP 系统，其中存放来一个 UTF-8 编码的文件，当采用 Reader 类来读入的时候，它还会使用GBK来做转换，转换后的内容当然是不对的。这其实是一种傻瓜式的功能提供方式，对大多数初级用户（以及不需要跨平台的高级用户）来说反而是一件好事。
如果用到 GBK 编码以外的文件，就必须采用编码转换；一个字符和字节之间的转换。因此，Java的 I/O 系统中能够指定转换编码的地方，也就在于字符和字节转换的地方，那就是 InputStreamReader 和 OutputStreamWriter。这两个类是字节流和字符流之间的适配器，他们承担编码转换的任务。
（后面解析有的百度的，加深自己的理解）
网友评论