扫描仪的nextLine（），仅获取部分
所以，使用像这样的东西：
for (int i = 0; i < files.length; i++) {
if (!files[i].isDirectory() && files[i].canRead()) {
try {
Scanner scan = new Scanner(files[i]);
System.out.println("Generating Categories for " + files[i].toPath());
while (scan.hasNextLine()) {
count++;
String line = scan.nextLine();
System.out.println(" ->" + line);
line = line.split("t", 2)[1];
System.out.println("!- " + line);
JsonParser parser = new JsonParser();
JsonObject object = parser.parse(line).getAsJsonObject();
Set<Entry<String, JsonElement>> entrySet = object.entrySet();
exploreSet(entrySet);
}
scan.close();
// System.out.println(keyset);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
}
}
当一个人通过Hadoop输出文件时，中间的一个JSON对象正在中断...因为scan.nextLine（）在将其分割之前没有获取整行。 即输出是：
->0 {"Flags":"0","transactions":{"totalTransactionAmount":"0","totalQuantitySold":"0"},"listingStatus":"NULL","conditionRollupId":"0","photoDisplayType":"0","title":"NULL","quantityAvailable":"0","viewItemCount":"0","visitCount":"0","itemCountryId":"0","itemAspects":{ ... "sellerSiteId":"0","siteId":"0","pictureUrl":"http://somewhere.com/45/x/AlphaNumeric/$(KGrHqR,!rgF!6n5wJSTBQO-G4k(Ww~~
!- {"Flags":"0","transactions":{"totalTransactionAmount":"0","totalQuantitySold":"0"},"listingStatus":"NULL","conditionRollupId":"0","photoDisplayType":"0","title":"NULL","quantityAvailable":"0","viewItemCount":"0","visitCount":"0","itemCountryId":"0","itemAspects":{ ... "sellerSiteId":"0","siteId":"0","pictureUrl":"http://somewhere.com/45/x/AlphaNumeric/$(KGrHqR,!rgF!6n5wJSTBQO-G4k(Ww~~
大部分上述数据已被清理（不是URL（大部分）），但是......）
并且URL继续如下：$（KGrHqZHJCgFBsO4dC3MBQdC2）Y4Tg ~~ 60_1.JPG？set_id = 8800005007在文件....
所以它略微猛烈。
这也是条目＃112，我有其他文件解析没有错误...但这是一个拧我的脑海，主要是因为我没有看到如何scan.nextLine（）不工作...
通过调试输出，JSON错误是由于字符串没有正确拆分而导致的。
几乎忘了，如果我试图将违规行放在自己的文件中并解析它，它也可以正常工作。
编辑：也炸毁了，如果我删除在同一地点的违规行。
尝试使用JVM 1.6和1.7
解决方法：BufferedReader scan = new BufferedReader（new FileReader（files [i]））; 代替扫描仪....
根据你的代码，我能想到的最好的解释是根据Scanner.nextLine()使用的标准，行确实在"~~"之后结束。
行尾标准是：
"rn|[nru2028u2029u0085]"或 你说文件在"~~"之后继续，所以让我们把EOF放在一边，看看正则表达式。 这将匹配以下任何一项：
通常的分隔线：
<CR> <NL> <CR><NL> ......以及Scanner也认识到的三种不同寻常的线条分隔符。
<NEL>或“下一行”控制代码 我的理论是，你的输入文件中有一种“不寻常”的形式，并且这不会显示在......你用来检查文件的任何工具。
我建议你使用一个可以显示文件实际字节的工具来检查输入文件; 例如Linux / Unix系统上的od实用程序。 此外，请检查这不是由某种字符编码不匹配造成的......或者尝试将二进制数据读取或写入为文本。
如果这些没有帮助，那么下一步应该是使用IDE的Java调试器运行应用程序，并通过Scanner.hasNextLine()和nextLine()调用单步执行，以找出代码实际正在执行的内容。
几乎忘了，如果我试图将违规行放在自己的文件中并解析它，它也可以正常工作。
那很有意思。 但是如果你用来提取这条线的工具与没有显示（假设的）不同寻常的线分隔符的工具是一样的，那么这个证据是不可靠的。 提取过程可能正在改变导致问题的“东西”。
链接地址: http://www.djcxy.com/p/96059.html