我有一个 UTF16LE 编码的输入。当这个输入到达我的代码时，它已经通过一个 FileInputStream 封装在一个 FileReader 中，FileReader 封装在一个 LineNumberReader 中。
读取的第一行给出如下字符串:
“1条数据如字符串”
但是，查看此 String 的值将类似于:
[, 1, p, i, ...]
注意开始的空元素。
不，这个字符串在这里和那里通过几个函数传递，转换为 Object 并且基本上正在通过它的步伐。在某个时候，应该只是字符串的第一部分(1 或在我的例子中包括小数在内的任何数字)被传递给一个函数，该函数必须将其解析为实际数字。
此字符串的内容似乎是 "1" 但在值中它表示:
[, 1, p, i, ...]
所以整个字符串仍然在那里。
在任何情况下它都会返回一个 ParseException 并且我将无法解析的数字打印到异常消息中并且我的日志记录告诉我“1”是一个无法解析的数字。
真正的问题似乎是前导空元素，因为后续行显示类似的行为，除了前导空元素并且它们解析。
最佳答案
String(至少是 OpenJDK 中的实现)存储 char[]、偏移量和计数。 String 的实际内容是 char[] 中的字符，索引 offset 到 offset+count.
这意味着 char[] 可以容纳比 String 实际表示的更多的字符。
这样做是为了能够在不同的 String 实例之间共享 char[]。
例如，如果您有一个值为 foobar 的 String 并且您在其上调用了 .substring(3)，那么结果String 将表示 bar，但它们实际上可能引用相同的 char[]。第二个 String 的 offset 比原来的 String 大 3，而 count 小 3。
所有这一切之所以有效，是因为 String 对象是真正不可变的:因为没有任何一个 String 会以任何方式修改它的 char[] ，他们分享它是绝对安全的。
这意味着在调试器中检查 String 对象可能会给人一种错误的印象。因此，如果您想逐个检查 String 字符，最安全的做法是调用 toCharArray()或调用charAt()在一个循环中。
关于Java 字符串包含无关数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4946045/