我有一个UTF16LE编码的输入。当此输入到达我的代码时，它通过封装在LineNumberReader中的FileReader中的FileInputStream。
读取的第一行给出了一个字符串，如：
"1 piece of data like a string"
但是，查看此String的值将是：
[, 1, p, i, ...]
注意要开始的空元素。
没有这个字符串在这里和那里通过几个函数传递，转换为Object，基本上是通过它的步伐。在某一点，什么应该只是字符串的第一部分（1或在我的情况下任何数字，包括小数）被传递给一个函数，该函数必须将其解析为实际的数字。
此字符串的内容似乎为"1"，但其值为：
[, 1, p, i, ...]
所以整个字符串仍在那里。
在任何情况下它都返回ParseException并且我将不可解析的数字打印到异常消息，我的日志记录告诉我“1”是一个不可解析的数字。
真正的问题似乎是领先的空元素，因为后续行显示类似的行为，除了前导空元素并且它们解析。
答案 0 :(得分：2)
String（至少是OpenJDK中的实现）存储char[]，偏移量和计数。 String的实际内容是char[]中的字符，其中offset指数最高为offset+count。
这意味着char[]可以容纳的字符多于String实际代表的字符数。
这样做是为了能够在不同char[]个实例之间共享String。
例如，如果您的String的值为foobar，并且您在其上调用了.substring(3)，那么结果String将代表bar，但他们实际上可能会引用相同的char[]。第二个String只有offset，其中3比原始String大，而count只有3更小。
所有这一切都有效，因为String个对象确实是不可变的：因为没有任何一个String会以任何方式修改它char[]，所以它们分享它是完全安全的。 / p>
这意味着检查调试器中的String对象可能会给人一种错误的印象。因此，如果您想要检查String字符为字符，最安全的做法是调用toCharArray()或在循环中调用charAt()。
答案 1 :(得分：0)
我想我有答案。编码不是UTF16LE。它通过自动字符检测算法设置为UTF16LE。编码是带有BOM的utf16。但是，由于各种类认为编码是UTF16LE，因此他们没有摆脱LE版本中不应存在的BOM。