Java解惑2——字符谜题（易混淆13处）

Java解惑2——字符谜题（易混淆13处）

备注：

本博客所有代码，本人均在Myeclipse，JDK版本1.6下实验调试通过，调试时间为2013.11.16。

Java谜题：

谜题11：最后的笑声

下面的程序将打印出什么呢？

public class LastLaugh{
    public static void main(String[] args){
        System.out.print("H"+"a");
        System.out.print('H'+'a');
    }
}

你可能会认为这个程序将打印HaHa。该程序看起来好像是用两种方式连接了H和a，但是你所见为虚。如果你运行这个程序，就会发现它打印的是Ha169。那么，为什么它会产生这样的行为呢？

正如我们所期望的，第一个对System.out.print的调用打印的是Ha：它的参数是表达式"H"+"a"，显然它执行的是一个字符串连接。而第二个对System.out.print的调用就是另外一回事了。问题在于'H'和'a'是字符型字面常量，因为这两个操作数都不是字符串类型的，所以 + 操作符执行的是加法而不是字符串连接。

编译器在计算常量表达式'H'+'a'时，是通过我们熟知的拓宽原始类型转换将两个具有字符型数值的操作数（'H'和'a'）提升为int数值而实现的。从char到int的拓宽原始类型转换是将16位的char数值零扩展到32位的int。对于'H'，char数值是72，而对于'a'，char数值是97，因此表达式'H'+'a'等价于int常量72 + 97，或169。

站在语言的立场上，若干个char和字符串的相似之处是虚幻的。语言所关心的是，char是一个无符号16位原始类型整数——仅此而已。对类库来说就不尽如此了，类库包含了许多可以接受char参数，并将其作为Unicode字符处理的方法。

那么你应该怎样将字符连接在一起呢？你可以使用这些类库。例如，你可以使用一个字符串缓冲区：

StringBuffer sb = new StringBuffer();
sb.append('H');
sb.append('a');
System.out.println(sb);

这么做可以正常运行，但是显得很丑陋。其实我们还是有办法去避免这种方式所产生的拖沓冗长的代码。 你可以通过确保至少有一个操作数为字符串类型，来强制 + 操作符去执行一个字符串连接操作，而不是一个加法操作。这种常见的惯用法用一个空字符（""）作为一个连接序列的开始，如下所示：

	System.out.println("" + 'H' + 'a');

这种惯用法可以确保子表达式都被转型为字符串。尽管这很有用，但是多少有一点难看，而且它自身可能会引发某些混淆。你能猜到下面的语句将会打印出什么吗？如果你不能确定，那么就试一下：

	System.out.print("2 + 2 = " + 2+2);

如果使用的是JDK 5.0，你还可以使用

	System.out.printf("%c%c", 'H', 'a');

总之，使用字符串连接操作符使用格外小心。+ 操作符当且仅当它的操作数中至少有一个是String类型时，才会执行字符串连接操作；否则，它执行的就是加法。如果要连接的没有一个数值是字符串类型的，那么你可以有几种选择：

• 预置一个空字符串；
• 将第一个数值用String.valueOf显式地转换成一个字符串；
• 使用一个字符串缓冲区；
• 或者如果你使用的JDK 5.0，可以用printf方法。

这个谜题还包含了一个给语言设计者的教训。操作符重载，即使在Java中只在有限的范围内得到了支持，它仍然会引起混淆。为字符串连接而重载 + 操作符可能就是一个已铸成的错误。

谜题12：ABC

这个谜题要问的是一个悦耳的问题，下面的程序将打印什么呢？

public class ABC{
    public static void main(String[] args){
        String letters = "ABC";
        char[] numbers = {'1', '2', '3'};
        System.out.println(letters + " easy as " + numbers);
    }
}

可能大家希望这个程序打印出ABC easy as 123。遗憾的是，它没有。如果你运行它，就会发现它打印的是诸如ABC easy as [C@16f0472之类的东西。为什么这个输出会如此丑陋？

尽管char是一个整数类型，但是许多类库都对其进行了特殊处理，因为char数值通常表示的是字符而不是整数。例如，将一个char数值传递给println方法会打印出一个Unicode字符而不是它的数字代码。字符数组受到了相同的特殊处理：println的char[]重载版本会打印出数组所包含的所有字符，而String.valueOf和StringBuffer.append的char[]重载版本的行为也是类似的。

然而，字符串连接操作符在这些方法中没有被定义。该操作符被定义为先对它的两个操作数执行字符串转换，然后将产生的两个字符串连接到一起。对包括数组在内的对象引用的字符串转换定义如下[JLS 15.18.1.1]：

如果引用为null，它将被转换成字符串"null"。否则，该转换的执行就像是不用任何参数调用该引用对象的toString方法一样；但是如果调用toString方法的结果是null，那么就用字符串"null"来代替。

那么，在一个非空char数组上面调用toString方法会产生什么样的行为呢？数组是从Object那里继承的toString方法[JLS 10.7]，规范中描述到：“返回一个字符串，它包含了该对象所属类的名字，'@'符号，以及表示对象散列码的一个无符号十六进制整数”[Java-API]。有关Class.getName的规范描述到：在char[]类型的类对象上调用该方法的结果为字符串"[C"。将它们连接到一起就形成了在我们的程序中打印出来的那个丑陋的字符串。

有两种方法可以订正这个程序。你可以在调用字符串连接操作之前，显式地将一个数组转换成一个字符串：

System.out.println(letters + " easy as " +
                       String.valueOf(numbers));

或者，你可以将System.out.println调用分解为两个调用，以利用println的char[]重载版本：

System.out.print(letters + " easy as ");
System.out.println(numbers);

请注意，这些订正只有在你调用了valueOf和println方法正确的重载版本的情况下，才能正常运行。换句话说，它们严格依赖于数组引用的编译期类型。

下面的程序说明了这种依赖性。看起来它像是所描述的第二种订正方式的具体实现，但是它产生的输出却与最初的程序所产生的输出一样丑陋，因为它调用的是println的Object重载版本，而不是char[]重载版本。

class ABC2{
   public static void main(String[] args){
       String letters = "ABC";
       Object numbers = new char[] { '1', '2', '3' };
       System.out.print(letters + " easy as ");
       System.out.println(numbers); 
   }
}

总之，char数组不是字符串。要想将一个char数组转换成一个字符串，就要调用String.valueOf(char[])方法。某些类库中的方法提供了对char数组的类似字符串的支持，通常是提供一个Object版本的重载方法和一个char[]版本的重载方法，而之后后者才能产生我们想要的行为。

对语言设计者的教训是：char[]类型可能应该覆写toString方法，使其返回数组中包含的字符。更一般地讲，数组类型可能都应该覆写toString方法，使其返回数组内容的一个字符串表示。

谜题13：畜牧场

George Orwell的《畜牧场（Animal Farm）》一书的读者可能还记得老上校的宣言：“所有的动物都是平等的。”下面的Java程序试图要测试这项宣言。那么，它将打印出什么呢？

public class AnimalFarm{
    public static void main(String[] args){
        final String pig = "length: 10";
        final String dog = "length: " + pig.length();
        System.out. println("Animals are equal: "
                            + pig == dog);
    }
}

对该程序的表面分析可能会认为它应该打印出Animal are equal: true。毕竟，pig和dog都是final的string类型变量，它们都被初始化为字符序列“length: 10”。换句话说，被pig和dog引用的字符串是且永远是彼此相等的。然而，==操作符测试的是这两个对象引用是否正好引用到了相同的对象上。在本例中，它们并非引用到了相同的对象上。

你可能知道String类型的编译期常量是内存限定的。换句话说，任何两个String类型的常量表达式，如果标明的是相同的字符序列，那么它们就用相同的对象引用来表示。如果用常量表达式来初始化pig和dog，那么它们确实会指向相同的对象，但是dog并不是用常量表达式初始化的。既然语言已经对在常量表达式中允许出现的操作作出了限制，而方法调用又不在其中，那么，这个程序就应该打印Animal are equal: false，对吗？

嗯，实际上不对。如果你运行该程序，你就会发现它打印的只是false，并没有其它的任何东西。它没有打印Animal are equal: 。它怎么会不打印这个字符串字面常量呢？毕竟打印它才是正确的呀！谜题11的解谜方案包含了一条暗示：+ 操作符，不论是用作加法还是字符串连接操作，它都比 == 操作符的优先级高。因此，println方法的参数是按照下面的方式计算的：

System.out.println(("Animals are equal: " + pig) == dog);

这个布尔表达式的值当然是false，它正是该程序的所打印的输出。

有一个肯定能够避免此类窘境的方法：在使用字符串连接操作符时，总是将非平凡的操作数用括号括起来。更一般地讲，当你不能确定你是否需要括号时，应该选择稳妥地做法，将它们括起来。如果你在println语句中像下面这样把比较部分括起来，它将产生所期望的输出Animals are equal: false ：

System.out.println("Animals are equal: " + (pig == dog));

可以论证，该程序仍然有问题。

如果可以的话，你的代码不应该依赖于字符串常量的内存限定机制。内存限定机制只是设计用来减少虚拟机内存占有量的，它并不是作为程序员可以使用的一种工具而设计的。就像这个谜题所展示的，哪一个表达式会产生字符串常量并非总是很显而易见。

更糟的是，如果你的代码依赖于内存限定机制实现操作的正确性，那么你就必须仔细地了解哪些域和参数必定是内存限定的。编译器不会帮你去检查这些不变量，因为内存限定的和不限定的字符串使用相同的类型（String）来表示的。这些因在内存中限定字符串失败而导致的bug是非常难以探测到的。

在比较对象引用时，你应该优先使用equals方法而不是 == 操作符，除非你需要比较的是对象的标识而不是对象的值。通过把这个教训应用到我们的程序中，我们给出了下面的println语句，这才是它应该具有的模样。很明显，在用这种方式订正了该程序之后，它将打印出true：

System.out.println("Animals are equal: " + pig.equals(dog));

这个谜题对语言设计者来说有两个教训。

• 字符串连接的优先级不应该和加法一样。这意味着重载 + 操作符来执行字符串连接是有问题的，就像在谜题11中提到的一样。
• 还有就是，对于不可修改的类型，例如String，其引用的等价性比值的等价性更加让人感到迷惑。也许 == 操作符在被应用于不可修改的类型时应该执行值比较。要实现这一点，一种方法是将 == 操作符作为equals方法的简便写法，并提供一个单独的类似于System.identityHashCode的方法来执行引用标识的比较。

谜题14：转义字符的溃败

下面的程序使用了两个Unicode的转义字符，它们是用其十六进制代码来表示Unicode字符。那么，这个程序会打印什么呢？

public class EscapeRout{
    public static void main(String[] args){
        // \u0022 是双引号的Unicode转义字符
        System.out.println("a\u0022.length()
+\u0022b".length());
    }
}

对该程序的一种很肤浅的分析会认为它应该打印出26，因为在由两个双引号"a\u0022.length()+\u0022b"标识的字符串之间总共有26个字符。

稍微深入一点的分析会认为该程序应该打印16，因为两个Unicode转义字符每一个在源文件中都需要用6个字符来表示，但是它们只表示字符串中的一个字符。因此这个字符串应该比它的外表看其来要短10个字符。 如果你运行这个程序，就会发现事情远不是这么回事。它打印的既不是26也不是16，而是2。

理解这个谜题的关键是要知道：Java对在字符串字面常量中的Unicode转义字符没有提供任何特殊处理。编译器在将程序解析成各种符号之前，先将Unicode转义字符转换成为它们所表示的字符[JLS 3.2]。因此，程序中的第一个Unicode转义字符将作为一个单字符字符串字面常量（"a"）的结束引号，而第二个Unicode转义字符将作为另一个单字符字符串字面常量（"b"）的开始引号。程序打印的是表达式"a".length()+"b".length()，即2。

如果该程序的作者确实希望得到这种行为，那么下面的语句将要清楚得多：

System.out.println("a".length()+"b".length());

更有可能的情况是该作者希望将两个双引号字符置于字符串字面常量的内部。使用Unicode转义字符你是不能实现这一点的，但是你可以使用转义字符序列来实现[JLS 3.10.6]。表示一个双引号的转义字符序列是一个反斜杠后面紧跟着一个双引号（\”）。如果将最初的程序中的Unicode转义字符用转义字符序列来替换，那么它将打印出所期望的16：

System.out.println("a\".length()+\"b".length());

许多字符都有相应的转义字符序列，包括单引号（\'）、换行（\n）、制表符（\t）和反斜线（\\）。你可以在字符字面常量和字符串字面常量中使用转义字符序列。

实际上，你可以通过使用被称为八进制转义字符的特殊类型的转义字符序列，将任何ASCII字符置于一个字符串字面常量或一个字符字面常量中，但是最好是尽可能地使用普通的转义字符序列。

普通的转义字符序列和八进制转义字符都比Unicode转义字符要好得多，因为与Unicode转义字符不同，转义字符序列是在程序被解析为各种符号之后被处理的。

ASCII是字符集的最小公共特性集，它只有128个字符，但是Unicode有超过65,000个字符。一个Unicode转义字符可以被用来在只使用ASCII字符的程序中插入一个Unicode字符。一个Unicode转义字符精确地等价于它所表示的字符。

Unicode转义字符被设计为用于在程序员需要插入一个不能用源文件字符集表示的字符的情况。它们主要用于将非ASCII字符置于标识符、字符串字面常量、字符字面常量以及注释中。偶尔地，Unicode转义字符也被用来在看起来颇为相似的数个字符中明确地标识其中的某一个，从而增加程序的清晰度。

总之，在字符串和字符字面常量中要优先选择的是转义字符序列，而不是Unicode转义字符。Unicode转义字符可能会因为它们在编译序列中被处理得过早而引起混乱。不要使用Unicode转义字符来表示ASCII字符。在字符串和字符字面常量中，应该使用转义字符序列；对于除这些字面常量之外的情况，应该直接将ASCII字符插入到源文件中。

谜题15：令人晕头转向的Hello

下面的程序是对一个老生常谈的例子做出了稍许的变化之后的版本。那么，它会打印出什么呢？

/**
 * Generated by the IBM IDL-to-Java compiler, version 1.0
 * from F:\TestRoot\apps\a1\units\include\PolicyHome.idl
 * Wednesday, June 17, 1998 6:44:40 o’clock AM GMT+00:00
 */
public class Test{
    public static void main(String[] args){
        System.out.print("Hell");
        System.out.println("o world");
    }
}

这个谜题看起来相当简单。该程序包含了两条语句，第一条打印Hell，而第二条在同一行打印o world，从而将两个字符串有效地连接在了一起。因此，你可能期望该程序打印出Hello world。但是很可惜，你犯了错，实际上，它根本就通不过编译。

问题在于注释的第三行，它包含了字符\units。这些字符以反斜杠（\）以及紧跟着的字母u开头的，而它（\u）表示的是一个Unicode转义字符的开始。遗憾的是，这些字符后面没有紧跟四个十六进制的数字，因此，这个Unicode转义字符是病构的，而编译器则被要求拒绝该程序。Unicode转义字符必须是良构的，即使是出现在注释中也是如此。

在注释中插入一个良构的Unicode转义字符是合法的，但是我们几乎没有什么理由去这么做。程序员有时会在JavaDoc注释中使用Unicode转义字符来在文档中生成特殊的字符。

// Unicode转义字符在JavaDoc注释中有问题的用法
/**
 * This method calls itself recursively, causing a
 * StackOverflowError to be thrown.
 * The algorithm is due to Peter von der Ah\u00E9.
 */

这项技术表示了Unicode转义字符的一种没什么用处的用法。在Javadoc注释中，应该使用HTML实体转义字符来代替Unicode转义字符：

/**
 * This method calls itself recursively, causing a
 * StackOverflowError to be thrown.
 * The algorithm is due to Peter von der Ahé.
 */

前面的两个注释都应该是的在文档中出现的名字为“Peter der Ahé”，但是后一个注释在源文件中还是可理解的。

可能你会感到很诧异，在这个谜题中，问题出在注释这一信息来源自一个实际的bug报告。该程序是机器生成的，这使得我们很难追踪到问题的源头——IDL-to-Java编译器。为了避免让其他程序员也陷入此境地，在没有将Windows文件名进行预先处理，以消除的其中的反斜杠的情况下，工具应该确保不将Windows文件名置于所生成的Java源文件的注释中。

总之，要确保字符\u不出现在一个合法的Unicode转义字符上下文之外，即使是在注释中也是如此。在机器生成的代码中要特别注意此问题。

谜题16：行打印程序

行分隔符（line separator）是为用来分隔文本行的字符或字符组合而起的名字，并且它在不同的平台上是存在差异的。在Windows平台上，它是CR字符（回车）和紧随其后的LF字符（换行）组成的，而在UNIX平台上，通常单独的LF字符被当作换行字符来引用。下面的程序将这个字符传递给了println方法，那么，它将打印出什么呢？它的行为是否是依赖于平台的呢？

public class LinePrinter{
    public static void main(String[] args){
    // Note: \u000A is Unicode representation of linefeed (LF) 
        char c = 0x000A;
        System.out.println(c);   
    }
}

这个程序的行为是平台无关的：它在任何平台上都不能通过编译。如果你尝试着去编译它，就会得到类似下面的出错信息：

LinePrinter.java:3: ';' expected
// Note: \u000A is Unicode representation of linefeed (LF)
^
1 error

如果你和大多数人一样，那么这条信息对界定问题是毫无用处的。

这个谜题的关键就是程序第三行的注释。与最好的注释一样，这条注释也是一种准确的表达，遗憾的是，它有一点准确得过头了。编译器不仅会在将程序解析成为符号之前把Unicode转义字符转换成它们所表示的字符（谜题14），而且它是在丢弃注释和空格之前做这些事的[JLS 3.2]。

这个程序包含了一个Unicode转移字符（\u000A），它位于程序唯一的注释行中。就像注释所陈述的，这个转义字符表示换行符，编译器将在丢弃注释之前适时地转换它。遗憾的是，这个换行符是表示注释开始的两个斜杠符之后的第一个行终结符（line terminator），因此它将终结该注释[JLS 3.4]。所以，该转义字符之后的字（is Unicode representation of linefeed (LF)）就不是注释的一部分了，而它们在语法上也不是有效的。

订正该程序的最简单的方式就是在注释中移除Unicode转义字符，但是更好的方式是用一个转义字符序列而不是一个十六进制整型字面常量来初始化c，从而消除使用注释的必要：

public class LinePrinter{
    public static void main(String[] args){
        char c = '\n';
        System.out.println(c);   
    }
}

只要这么做了，程序就可以编译并运行，但是这仍然是一个有问题的程序：它是平台相关的，这正是本谜题所要表达的真正意图。在某些平台上，例如UNIX，它将打印出两个完整的行分隔符；但是在其它一些平台上，例如Windows，它就不会产生这样的行为。尽管这些输出用肉眼看起来是一样的，但是如果它们要被存储到文件中，或是输出到后续的其它处理程序中，那就很容易引发问题。

如果你想打印两行空行，你应该调用println两次。如果使用的是JDK 5.0，那么你可以用带有格式化字符串"%n%n"的printf来代替println。%n的每一次出现都将导致printf打印一个恰当的、与平台相关的行分隔符。

我们希望，上面三个谜题已经使你信服：Unicode转义字符绝对会产生混乱。教训很简单：除非确实是必需的，否则就不要使用Unicode转义字符。它们很少是必需的。

谜题17：嗯？

下面的是一个合法的Java程序吗？如果是，它会打印出什么呢？

\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020\u0020
\u0063\u006c\u0061\u0073\u0073\u0020\u0055\u0067\u006c\u0079
\u007b\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020
\u0020\u0020\u0020\u0020\u0073\u0074\u0061\u0074\u0069\u0063
\u0076\u006f\u0069\u0064\u0020\u006d\u0061\u0069\u006e\u0028
\u0053\u0074\u0072\u0069\u006e\u0067\u005b\u005d\u0020\u0020
\u0020\u0020\u0020\u0020\u0061\u0072\u0067\u0073\u0029\u007b
\u0053\u0079\u0073\u0074\u0065\u006d\u002e\u006f\u0075\u0074
\u002e\u0070\u0072\u0069\u006e\u0074\u006c\u006e\u0028\u0020
\u0022\u0048\u0065\u006c\u006c\u006f\u0020\u0077\u0022\u002b
\u0022\u006f\u0072\u006c\u0064\u0022\u0029\u003b\u007d\u007d

这当然是一个合法的Java程序！这不是很显而易见吗？它会打印Hello World。噢，可能是不那么明显。事实上，该程序根本让人无法理解。每当你没必要地使用了一个Unicode转义字符时，都会使你的程序的可理解性更缺失一点，而该程序将这种做法发挥到了极致。如果你很好奇，可以看看下面给出的该程序在Unicode转义字符都被转换为它们所表示的字符之后的样子：

public 
class Ugly
{public
static
void main(
String[]
args){
System.out
.println(
“Hello w”+
“orld”);}}

下面给出了将其进行格式化整理之后的样子：

public class Ugly {
  public static void main(String[] args){
     System.out.println("Hello w"+"orld");
  }
}

这个谜题的教训是：仅仅是因为你可以不以应有的方式去进行表达。或者说，如果你这么做会造成损害，那么就请不要这么做！更严肃地讲，这个谜题是对前面三个教训的补充：Unicode转义字符只有在你要向程序中插入用其他任何方式都无法表示的字符时才是必需的，除此之外的任何情况都不应该避免使用它们。Unicode转义字符降低了程序的清晰度，并且增加了产生bug的可能性。

对语言的设计者来说，也许使用Unicode转义字符来表示ASCII字符应该被定义为是非法的。这样就可以使得在谜题14、15和17（本谜题）中的程序非法，从而消除了大量的混乱。这个限制对程序员并不会造成任何困难。

谜题18：字符串奶酪

下面的程序从一个字节序列创建了一个字符串，然后迭代遍历字符串中的字符，并将它们作为数字打印。请描述一下程序打印出来的数字序列：

public class StringCheese {
    public static void main(String[] args) {
        byte bytes[] = new byte[256];
        for (int i = 0; i < 256; i++)
             bytes[i] = (byte)i;
        String str = new String(bytes);
        for (int i = 0, n = str.length(); i < n; i++)
             System.out.println((int)str.charAt(i) + " ");
    }
}

首先，byte数组用从0到255每一个可能的byte数值进行了初始化，然后这些byte数值通过String构造器被转换成了char数值。最后，char数值被转型为int数值并被打印。打印出来的数值肯定是非负整数，因为char数值是无符号的，因此，你可能期望该程序将按顺序打印出0到255的整数。

如果你运行该程序，可能会看到这样的序列。但是在运行一次，可能看到的就不是这个序列了。我们在四台机器上运行它，会看到四个不同的序列，包括前面描述的那个序列。这个程序甚至都不能保证会正常终止，比打印其他任何特定字符串都要缺乏这种保证。它的行为完全是不确定的。

这里的罪魁祸首就是String(byte[])构造器。有关它的规范描述道：“在通过解码使用平台缺省字符集的指定byte数组来构造一个新的String时，该新String的长度是字符集的一个函数，因此，它可能不等于byte数组的长度。当给定的所有字节在缺省字符集中并非全部有效时，这个构造器的行为是不确定的”[Java-API]。

到底什么是字符集？从技术角度上讲，它是“被编码的字符集合和字符编码模式的结合物”[Java-API]。换句话说，字符集是一个包，包含了字符、表示字符的数字编码以及在字符编码序列和字节序列之间来回转换的方式。转换模式在字符集之间存在着很大的区别：某些是在字符和字节之间做一对一的映射，但是大多数都不是这样。ISO-8859-1是唯一能够让该程序按顺序打印从0到255的整数的缺省字符集，它更为大家所熟知的名字是Latin-1[ISO-8859-1]。

J2SE运行期环境（JRE）的缺省字符集依赖于底层的操作系统和语言。如果你想知道你的JRE的缺省字符集，并且你使用的是5.0或更新的版本，那么你可以通过调用java.nio.charset.Charset.defaultCharset()来了解。如果你使用的是较早的版本，那么你可以通过阅读系统属性“file.encoding”来了解。

幸运的是，你没有被强制要求必须去容忍各种稀奇古怪的缺省字符集。当你在char序列和byte序列之间做转换时，你可以且通常是应该显式地指定字符集。除了接受byte数字之外，还可以接受一个字符集名称的String构造器就是专为此目的而设计的。如果你用下面的构造器去替换在最初的程序中的String构造器，那么不管缺省的字符集是什么，该程序都保证能够按照顺序打印从0到255的整数：

String str = new String(bytes, "ISO-8859-1");

这个构造器声明会抛出UnsupportedEncodingException异常，因此你必须捕获它，或者更适宜的方式是声明main方法将抛出它，要不然程序不能通过编译。尽管如此，该程序实际上不会抛出异常。Charset的规范要求Java平台的每一种实现都要支持某些种类的字符集，ISO-8859-1就位列其中。

这个谜题的教训是：每当你要将一个byte序列转换成一个String时，你都在使用某一个字符集，不管你是否显式地指定了它。如果你想让你的程序的行为是可预知的，那么就请你在每次使用字符集时都明确地指定。对API的设计者来说，提供这么一个依赖于缺省字符集的String(byte[])构造器可能并非是一个好主意。

谜题19：漂亮的火花

下面的程序用一个方法对字符进行了分类。这个程序会打印出什么呢？

public class Classifier {
    public static void main(String[] args) {
        System.out.println(
             classify('n') + classify('+') + classify('2'));
    }
    static String classify(char ch) {
        if ("0123456789".indexOf(ch) >= 0)
             return "NUMERAL ";
        if ("abcdefghijklmnopqrstuvwxyz".indexOf(ch) >= 0)
             return "LETTER ";
        /* (Operators not supported yet)
            if ("+-*/&|!=" >= 0)
                 return "OPERATOR ";
        */
        return "UNKNOWN";
    }
}

如果你猜想该程序将打印LETTER UNKNOWN NUMERAL，那么你就掉进陷阱里面了。这个程序连编译都通不过。让我们再看一看相关的部分，这一次我们用粗体字突出注释部分：

if ("abcdefghijklmnopqrstuvwxyz".indexOf(ch) >= 0)
             return "LETTER ";
        /* (Operators not supported yet)
        if ("+-*/&|!=" >= 0)
                 return "OPERATOR ";
        */
        return "UNKNOWN";
    }
}

正如你之所见，注释在包含了字符*/的字符串内部就结束了，结果使得程序在语法上变成非法的了。我们将程序中的一部分注释出来的尝试之所以失败了，是因为字符串字面常量在注释中没有被特殊处理。

更一般地讲，注释内部的文本没有以任何方式进行特殊处理[JLS 3.7]。因此，块注释不能嵌套。请考虑下面的代码段：

/* Add the numbers from 1 to n */
int sum = 0;
for (int i = 1; I <= n; i++)
sum += i;

现在假设我们要将该代码段注释成为一个块注释，我们再次用粗体字突出整个注释：

/*
/* Add the numbers from 1 to n */
int sum = 0;
for (int i = 1; I <= n; i++)
sum += i;
*/

正如你之所见，我们没有能够将最初的代码段注释掉。好在所产生的代码包含了一个语法错误，因此编译器将会告诉我们代码存在着问题。

你可能偶尔看到过这样的代码段，它被一个布尔表达式为常量false的if语句禁用了：

//code commented out with an if statement - doesn't always work!
if (false) {
     /* Add the numbers from 1 to n */
     int sum = 0;
     for (int i = 1; i <= n; i++)
            sum += i;
}

语言规范建议将这种方式作为一种条件编译技术[JLS 14.21]，但是它不适合用来注释代码。除非要被禁用的代码是一个合法的语句序列，否则就不要使用这项技术。

注释掉一个代码段的最好的方式是使用单行的注释序列。大多数IDE工具都可以自动化这个过程：

//code commented out with an if statement - doesn't always work!
//     /* Add the numbers from 1 to n */
//     int sum = 0;
//     for (int i = 1; i <= n; i++)
//            sum += i;

总之，块注释不能可靠地注释掉代码段，应该用单行的注释序列来代替。对语言设计者来说，应该注意到可嵌套的块注释并不是一个好主意。他们强制编译器去解析块注释内部的文本，而由此引发的问题比它能够解决的问题还要多。

谜题20：我的类是什么？①

下面的程序被设计用来打印它的类文件的名称。如果你不熟悉类字面常量，那么我告诉你Me.class.getName()将返回Me类完整的名称，即“com.javapuzzlers.Me”。那么，这个程序会打印出什么呢？

package com.javapuzzlers;
public class Me {
    public static void main(String[] args){
        System.out.println(
             Me.class.getName().
                replaceAll(".","/") + ".class");
    }
}

该程序看起来会获得它的类名（“com.javapuzzlers.Me”），然后用“/”替换掉所有出现的字符串“.”，并在末尾追加字符串“.class”。你可能会认为该程序将打印com/javapuzzlers/Me.class，该程序正式从这个类文件中被加载的。如果你运行这个程序，就会发现它实际上打印的是///////////////////.class。到底怎么回事？难道我们是斜杠的受害者吗？

问题在于String.replaceAll接受了一个正则表达式作为它的第一个参数，而并非接受了一个字符序列字面常量。（正则表达式已经被添加到了Java平台的1.4版本中。）正则表达式“.”可以匹配任何单个的字符，因此，类名中的每一个字符都被替换成了一个斜杠，进而产生了我们看到的输出。

要想只匹配句点符号，在正则表达式中的句点必须在其前面添加一个反斜杠（\）进行转义。因为反斜杠字符在字面含义的字符串中具有特殊的含义——它标识转义字符序列的开始——因此反斜杠自身必须用另一个反斜杠来转义，这样就可以产生一个转义字符序列，它可以在字面含义的字符串中生成一个反斜杠。把这些合在一起，就可以使下面的程序打印出我们所期望的com/javapuzzlers/Me.class：

package com.javapuzzlers;
public class Me {
    public static void main(String[] args){
        System.out.println(
            Me.class.getName().replaceAll("\\.","/") + ".class");
    }
}

为了解决这类问题，5.0版本提供了新的静态方法java.util.regex.Pattern.quote。它接受一个字符串作为参数，并可以添加必需的转义字符，它将返回一个正则表达式字符串，该字符串将精确匹配输入的字符串。下面是使用该方法之后的程序：

package com.javapuzzlers;
import java.util.regex.Pattern;
public class Me {
    public static void main(String[] args){
        System.out.println(Me.class.getName().
			replaceAll(Pattern.quote("."),"/") + ".class");
    }
}

该程序的另一个问题是：其正确的行为是与平台相关的。并不是所有的文件系统都使用斜杠符号来分隔层次结构的文件名组成部分的。要想获取一个你正在运行的平台上的有效文件名，你应该使用正确的平台相关的分隔符号来代替斜杠符号。这正是下一个谜题所要做的。

谜题21：我的类是什么？②

下面的程序所要做的事情正是前一个谜题所做的事情，但是它没有假设斜杠符号就是分隔文件名组成部分的符号。相反，该程序使用的是java.io.File.separator，它被指定为一个公共的String域，包含了平台相关的文件名分隔符。那么，这个程序会打印出其正确的、平台相关的类文件名吗？

package com.javapuzzlers;
import java.io.File;
public class MeToo {
    public static void main(String[] args){
        System.out.println(MeToo.class.getName().
			replaceAll("\\.", File.separator) + ".class");
    }
}

这个程序根据底层平台的不同会显示两种行为中的一种。如果文件分隔符是斜杠，就像在UNIX上一样，那么该程序将打印com/javapuzzlers/MeToo.class，这是正确的。但是，如果文件分隔符是反斜杠，就像在Windows上一样，那么该程序将打印像下面这样的内容：

Exception in thread "main" 
java.lang.StringIndexOutOfBoundsException: String index out of range: 1
        at java.lang.String.charAt(String.java:558)
        at java.util.regex.Matcher.appendReplacement(Mather.
java:696)
        at java.util.regex.Matcher.replaceAll(Mather.java:806)
        at java.lang.String.replaceAll(String.java:2000)
        at com.javapuzzlers.MeToo.main(MeToo.java:6)

尽管这种行为是平台相关的，但是它并非就是我们所期待的。在Windows上出了什么错呢？

事实证明，String.replaceAll的第二个参数不是一个普通的字符串，而是一个替代字符串（replacement string），就像在java.util.regex规范中所定义的那样[Java-API]。在替代字符串中出现的反斜杠会把紧随其后的字符进行转义，从而导致其被按字面含义而处理了。

当你在Windows上运行该程序时，替代字符串是单独的一个反斜杠，它是无效的。不可否认，抛出的异常应该提供更多一些有用的信息。

那么你应该怎样解决此问题呢？5.0版本提供了不是一个而是两个新的方法来解决它。第一个方法是java.util.regex.Matcher.quoteReplacement，它将字符串转换成相应的替代字符串。下面展示了如何使用这个方法来订正该程序：

System.out.println(MeToo.class.getName().replaceAll("\\.", 
	Matcher.quoteReplacement(File.separator)) + ".class");

引入到5.0版本中的第二个方法提供了一个更好的解决方案。该方法就是String.replace(CharSequence, CharSequence)，它做的事情和String.replaceAll相同，但是它将模式和替代物都当作字面含义的字符串处理。下面展示了如何使用这个方法来订正该程序：

System.out.println(MeToo.class.getName().
	replace(".", File.separator) + ".class");

但是如果你使用的是较早版本的Java该怎么办？很遗憾，没有任何捷径能够生成替代字符串。完全不使用正则表达式，而使用String.replace(char,char)也许要显得更容易一些：

System.out.println(MeToo.class.getName().
	replace('.', File.separatorChar) + ".class");

本谜题和前一个谜题的主要教训是：在使用不熟悉的类库方法时一定要格外小心。当你心存疑虑时，就要求助于Javadoc。还有就是正则表达式是很棘手的：它所引发的问题趋向于在运行时刻而不是在编译时刻暴露出来。

对API的设计者来说，使用方法具名的模式来以明显的方式区分方法行为的差异是很重要的。Java的String类就没有很好地遵从这一原则。对许多程序员来说，对于哪些字符串替代方法使用的是字面含义的字符串，以及哪些使用的是正则表达式或替代字符串，要记住这些都不是一件容易事。

谜题22：URL的愚弄

本谜题利用了Java编程语言中一个很少被人了解的特性。请考虑下面的程序将会做些什么？

public class BrowserTest {
    public static void main(String[] args) {
        System.out.print("iexplore:");
        http://www.google.com;
        System.out.println(":maximize");
    }
}

这是一个有点诡异的问题。该程序将不会做任何特殊的事情，而是直接打印iexplore::maximize。在程序中间出现的URL是一个语句标号（statement label）[JLS 14.7]后面跟着一行行尾注释（end-of-line comment）[JLS 3.7]。在Java中很少需要标号，这多亏了Java没有goto语句。在本谜题中所引用的“Java编程语言中很少被人了解的特性”实际上就是你可以在任何语句前面放置标号。这个程序标注了一个表达式语句，它是合法的，但是却没什么用处。

它的价值所在，就是提醒你，如果你真的想要使用标号，那么应该用一种更合理的方式来格式化程序：

public class BrowserTest {
    public static void main(String[] args) {
        System.out.print("iexplore:");
    http:      //www.google.com;
        System.out.println(":maximize");
    }
}

这就是说，我们没有任何可能的理由去使用与程序没有任何关系的标号和注释。

本谜题的教训是：令人误解的注释和无关的代码会引起混乱。要仔细地写注释，并让它们跟上时代；要切除那些已遭废弃的代码。还有就是如果某些东西看起来过于奇怪，以至于不像对的，那么它极有可能就是错的。

谜题23：不劳而获

下面的程序将打印一个单词，其第一个字母是由一个随机数生成器来选择的。请描述该程序的行为：

import java.util.Random;
public class Rhymes {
   private static Random rnd = new Random();
   public static void main(String[] args) {
      StringBuffer word = null;
      switch(rnd.nextInt(2)) {
          case 1:  word = new StringBuffer('P');
          case 2:  word = new StringBuffer('G');
          default: word = new StringBuffer('M');
      }
      word.append('a');
      word.append('i');
      word.append('n');
      System.out.println(word);
   }
}

乍一看，这个程序可能会在一次又一次的运行中，以相等的概率打印出Pain，Gain或 Main。看起来该程序会根据随机数生成器所选取的值来选择单词的第一个字母：0选M，1选P，2选G。谜题的题目也许已经给你提供了线索，它实际上既不会打印Pain，也不会打印Gain。也许更令人吃惊的是，它也不会打印Main，并且它的行为不会在一次又一次的运行中发生变化，它总是在打印ain。

有三个bug凑到一起引发了这种行为。你完全没有发现它们吗？第一个bug是所选取的随机数使得switch语句只能到达其三种情况中的两种。Random.nextInt(int)的规范描述道：“返回一个伪随机的、均等地分布在从0（包括）到指定的数值（不包括）之间的一个int数值”[Java-API]。这意味着表达式rnd.nextInt(2)可能的取值只有0和1，Switch语句将永远也到不了case 2分支，这表示程序将永远不会打印Gain。nextInt的参数应该是3而不是2。

这是一个相当常见的问题源，被熟知为“栅栏柱错误（fencepost error）”。这个名字来源于对下面这个问题最常见的但却是错误的答案，如果你要建造一个100英尺长的栅栏，其栅栏柱间隔为10英尺，那么你需要多少根栅栏柱呢？11根或9根都是正确答案，这取决于是否要在栅栏的两端树立栅栏柱，但是10根却是错误的。要当心栅栏柱错误，每当你在处理长度、范围或模数的时候，都要仔细确定其端点是否应该被包括在内，并且要确保你的代码的行为要与其相对应。

第二个bug是在不同的情况（case）中没有任何break语句。不论switch表达式为何值，该程序都将执行其相对应的case以及所有后续的case[JLS 14.11]。因此，尽管每一个case都对变量word赋了一个值，但是总是最后一个赋值胜出，覆盖了前面的赋值。最后一个赋值将总是最后一种情况（default），即new StringBuffer{'M'}。这表明该程序将总是打印Main，而从来不打印Pain或Gain。

在switch的各种情况中缺少break语句是非常常见的错误。从5.0版本起，javac提供了-Xlint:fallthrough标志，当你忘记在一个case与下一个case之间添加break语句是，它可以生成警告信息。不要从一个非空的case向下进入了另一个case。这是一种拙劣的风格，因为它并不常用，因此会误导读者。十次中有九次它都会包含错误。如果Java不是模仿C建模的，那么它倒是有可能不需要break。对语言设计者的教训是：应该考虑提供一个结构化的switch语句。

最后一个，也是最微妙的一个bug是表达式new StringBuffer('M')可能没有做哪些你希望它做的事情。你可能对StringBuffer(char)构造器并不熟悉，这很容易解释：它压根就不存在。StringBuffer有一个无参数的构造器，一个接受一个String作为字符串缓冲区初始内容的构造器，以及一个接受一个int作为缓冲区初始容量的构造器。在本例中，编译器会选择接受int的构造器，通过拓宽原始类型转换把字符数值'M'转换为一个int数值77[JLS 5.1.2]。换句话说，new StringBuffer('M')返回的是一个具有初始容量77的空的字符串缓冲区。该程序余下的部分将字符a、i和n添加到了这个空字符串缓冲区中，并打印出该字符串缓冲区那总是ain的内容。

为了避免这类问题，不管在什么时候，都要尽可能使用熟悉的惯用法和API。如果你必须使用不熟悉的API，那么请仔细阅读其文档。在本例中，程序应该使用常用的接受一个String的StringBuffer构造器。

下面是该程序订正了这三个bug之后的正确版本，它将以均等的概率打印Pain、Gain和Main：

import java.util.Random;
public class Rhymes1 {
   private static Random rnd = new Random();
   public static void main(String[] args) {
      StringBuffer word = null;
      switch(rnd.nextInt(3)) {
          case 1:  
             word = new StringBuffer("P");
             break;
          case 2:  
             word = new StringBuffer("G");
             break;
          default:
             word = new StringBuffer("M");
             break;
      }
      word.append('a');
      word.append('i');
      word.append('n');
      System.out.println(word);
   }
}

尽管这个程序订正了所有的bug，它还是显得过于冗长了。下面是一个更优雅的版本：

import java.util.Random;
public class Rhymes2 {
   private static Random rnd = new Random();
   public static void main(String[] args) {
      System.out.println("PGM".charAt(rnd.nextInt(3)) + "ain");
   }
}

下面是一个更好的版本。尽管它稍微长了一点，但是它更加通用。它不依赖于所有可能的输出只是在它们的第一个字符上有所不同的这个事实：

import java.util.Random;
public class Rhymes3 {
   public static void main(String[] args) {
      String a[] = {"Main","Pain","Gain"};
      System.out.println(randomElement(a));
   }
   private static Random rnd = new Random();
   private static String randomElement(String[] a){
      return a[rnd.nextInt(a.length)];
   }      
}

总结一下：首先，要当心栅栏柱错误。其次，牢记在 switch 语句的每一个 case 中都放置一条 break 语句。第三，要使用常用的惯用法和 API，并且当你在离开老路子的时候，一定要参考相关的文档。第四，一个 char 不是一个 String，而是更像一个 int。最后，要提防各种诡异的谜题。