// 解析数据 public Map<String, String> parsePipeSeparatedData(String fileCONTENT) { // 处理转义的换行符 fileCONTENT = fileCONTENT.replace("\\n", "\n"); Map<String, String> dataMap = new LinkedHashMap<>(); String[] lines = fileCONTENT.split("\n"); if (lines.length >= 2) { String[] headers = lines[0].split("\\|"); String[] values = lines[1].split("\\|"); int minLength = Math.min(headers.length, values.length); for (int i = 0; i < minLength; i++) { dataMap.put(headers[i], values[i]); } } return dataMap; } "filE_CONTENT": "PALLET_ID|KNBOXNO|CARRIER|COC|CTRY|HAWB|PO|ORIGIN|INVOICENO|CARTONS|SHIPID|SHIP_DATE|TEL|SSCC|RETURN_TO1|RETURN_TO2|RETURN_TO3|RETURN_TO4|RETURN_TO5|RETURN_TO6|RETURN_TO7|RETURN_TO8|SHIP_TO1|SHIP_TO2|SHIP_TO3|SHIP_TO4|SHIP_TO5|SHIP_TO6|SHIP_TO7|SHIP_TO8|LINEITEM1|MPN1|QTY1|LINEITEM2|MPN2|QTY2|LINEITEM3|MPN3|QTY3|\nFO2501000233P0002||DGF-AD|NL|NL|8VG8286|0638138589|PVG|8VG8286|61/84|73292885370002|06/01/2025|00000000|001959499064098506|ADI EMEIA Logistics|Inbound Department|||||||PEGATRON CORPORATION|c/o DP World Logistics Netherlands BV|Van Hilststraat 23|5145 RK Waalwijk,Netherlands|5145 RK Waalwijk Netherlands||||00010|MLPF3AA/A|10|"我的值 { "code": 500, "msg": "sys.option.failed", "data": [ { "checkType": "FIELD", "fieldName": "\"filE_CONTENT\": \"PALLET_ID", "expected": "FO2501000233P0002", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "CARRIER", "expected": "DGF-AD", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "COC", "expected": "NL", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "CTRY", "expected": "NL", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "HAWB", "expected": "8VG8286", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "PO", "expected": "0638138589", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "ORIGIN", "expected": "PVG", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "INVOICENO", "expected": "8VG8286", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "CARTONS", "expected": "61/84", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIPID", "expected": "73292885370002", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_DATE", "expected": "06/01/2025", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "TEL", "expected": "00000000", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SSCC", "expected": "001959499064098506", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "RETURN_TO1", "expected": "ADIEMEIALogistics", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "RETURN_TO2", "expected": "InboundDepartment", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_TO1", "expected": "PEGATRONCORPORATION", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_TO2", "expected": "c/oDPWorldLogisticsNetherlandsBV", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_TO3", "expected": "VanHilststraat23", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_TO4", "expected": "5145RKWaalwijk,Netherlands", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "SHIP_TO5", "expected": "5145RKWaalwijkNetherlands", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "LINEITEM1", "expected": "00010", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "MPN1", "expected": "MLPF3AA/A", "actual": "Not Found", "valid": false }, { "checkType": "FIELD", "fieldName": "LINEITEM2", "expected": "\"", "actual": "Not Found", "valid": false } ] }是对的 有一个数据是有问题的 { "checkType": "FIELD", "fieldName": "LINEITEM2", "expected": "\"", "actual": "Not Found", "valid": false } 这个值

<think>我们分析问题：用户提供的错误信息中，有一个字段"LINEITEM2"的校验失败，预期值是双引号（"\""），但实际解析中这个字段在Map中不存在（"Not Found"）。同时，用户提供的原始数据字符串末尾有一个孤立的双引号。 问题定位： 在原始数据中，数据行是： "FO2501000233P0002||DGF-AD|...|00010|MLPF3AA/A|10|\"" 注意最后是：|10|" （这里有一个孤立的双引号） 在解析时，我们使用split("\\|")，那么最后这个双引号会被解析为一个单独的字段（即LINEITEM2的值）。但是，在标题行中，最后一个字段是"LINEITEM3|MPN3|QTY3|"，而数据行中，在QTY1（值为10）之后，就没有数据了，然后出现了一个双引号。因此，数据行中字段的数量比标题行少。 当前解析方法： ```java String[] headers = lines[0].split("\\|"); String[] values = lines[1].split("\\|"); int minLength = Math.min(headers.length, values.length); for (int i = 0; i < minLength; i++) { dataMap.put(headers[i], values[i]); } ``` 问题：数据行中，由于最后有一个双引号，所以split后，values数组的最后一个元素是那个双引号（即一个字符串`"\""`，注意这里split后得到的是包含双引号的字符串，而不是转义）。但是，标题行有38个字段（从PALLET_ID到QTY3），而数据行split后只有24个字段（因为数据行在QTY1之后只有两个字段：10和双引号，所以总共24个字段）。因此，在循环中，我们只取了前24个字段（因为minLength=24），所以从第25个字段（即LINEITEM2）开始，在数据行中不存在，所以没有放入map。而在校验时，校验器期望LINEITEM2字段存在，并且值为双引号，但实际上在map中这个字段不存在（因为循环只到24，而LINEITEM2在标题行中的索引是29，已经超过了24），所以校验失败。 具体分析字段位置： 标题行：0: PALLET_ID, 1: KNBOXNO, 2: CARRIER, ... 29: LINEITEM2, ... 37: QTY3 数据行：0: "FO2501000233P0002", 1: "", 2: "DGF-AD", ... 23: "10", 24: "\"" 所以，在数据行中，第24个字段（即第25个元素，因为数组从0开始）是那个双引号。但是，这个双引号对应的标题应该是哪个？我们数一下标题行中第24个字段（索引24）是什么？标题行中： 索引0: PALLET_ID 索引1: KNBOXNO 索引2: CARRIER 索引3: COC 索引4: CTRY 索引5: HAWB 索引6: PO 索引7: ORIGIN 索引8: INVOICENO 索引9: CARTONS -> 值为61/84 索引10: SHIPID -> 73292885370002 索引11: SHIP_DATE -> 06/01/2025 索引12: TEL -> 00000000 索引13: SSCC -> 001959499064098506 索引14: RETURN_TO1 -> ADI EMEIA Logistics 索引15: RETURN_TO2 -> Inbound Department 索引16: RETURN_TO3 -> 空（因为数据行中这里没有值，但标题有） 索引17: RETURN_TO4 索引18: RETURN_TO5 索引19: RETURN_TO6 索引20: RETURN_TO7 索引21: RETURN_TO8 索引22: SHIP_TO1 -> PEGATRON CORPORATION 索引23: SHIP_TO2 -> c/o DP World Logistics Netherlands BV 索引24: SHIP_TO3 -> Van Hilststraat 23 索引25: SHIP_TO4 -> 5145 RK Waalwijk,Netherlands 索引26: SHIP_TO5 -> 5145 RK Waalwijk Netherlands （注意这里数据行中SHIP_TO5没有值，但标题有，所以数据行中索引26位置应该是空？实际上数据行中在SHIP_TO4之后就没有了，所以索引26及以后都没有） 但是，在数据行中，从SHIP_TO3（索引24）和SHIP_TO4（索引25）之后，接下来是： 索引26: LINEITEM1 -> 00010 索引27: MPN1 -> MLPF3AA/A 索引28: QTY1 -> 10 索引29: 应该是LINEITEM2，但数据行中索引29位置是那个双引号（即数据行数组的第30个元素？不对，因为数据行只有25个元素？） 重新计算数据行字段数： 标题行：38个字段（以|分割，注意最后还有一个|，所以split后会有39个元素？因为末尾的|会产生一个空字符串？） 实际上，split的机制：如果字符串以分隔符结尾，则会产生一个空字符串。但这里标题行最后是"QTY3|"，所以split后会产生39个元素（因为最后一个|后面没有内容，所以最后一个元素是空字符串？）。但数据行最后是双引号，然后没有|，所以数据行split后是25个元素（因为从0到24）。 验证标题行分割： "PALLET_ID|...|QTY3|" -> 分割后最后一个元素是空字符串？所以headers.length=39。 数据行：最后是双引号，没有|，所以values.length=25（因为从0到24，共25个元素）。 因此，在循环中，minLength=25（因为headers.length=39，values.length=25）。所以，我们只将前25个标题和值放入map。 那么，标题行中索引25（即第26个字段）是SHIP_TO5，而数据行中索引25的值是什么？在数据行中，索引25是SHIP_TO4之后的值，但数据行中SHIP_TO4已经是最后一个地址字段，后面应该是LINEITEM1等，所以数据行中索引25应该是空？但实际上，数据行中在SHIP_TO4之后是SHIP_TO5，但数据行中SHIP_TO5没有值，所以应该是空？但实际上，数据行在SHIP_TO4之后是三个竖线（|||）？不对，我们看原始数据： 原始数据行： "FO2501000233P0002||DGF-AD|NL|NL|8VG8286|0638138589|PVG|8VG8286|61/84|73292885370002|06/01/2025|00000000|001959499064098506|ADI EMEIA Logistics|Inbound Department|||||||PEGATRON CORPORATION|c/o DP World Logistics Netherlands BV|Van Hilststraat 23|5145 RK Waalwijk,Netherlands|5145 RK Waalwijk Netherlands||||00010|MLPF3AA/A|10|\"" 我们数一下竖线（|）分隔的字段： 1. FO2501000233P0002 -> 0 2. 空 -> 1 3. DGF-AD -> 2 4. NL -> 3 5. NL -> 4 6. 8VG8286 -> 5 7. 0638138589 -> 6 8. PVG -> 7 9. 8VG8286 -> 8 10. 61/84 -> 9 11. 73292885370002 -> 10 12. 06/01/2025 -> 11 13. 00000000 -> 12 14. 001959499064098506 -> 13 15. ADI EMEIA Logistics -> 14 16. Inbound Department -> 15 17. 空 -> 16（对应RETURN_TO3） 18. 空 -> 17 19. 空 -> 18 20. 空 -> 19 21. 空 -> 20 22. 空 -> 21（对应RETURN_TO8） 23. PEGATRON CORPORATION -> 22（SHIP_TO1） 24. c/o DP World Logistics Netherlands BV -> 23（SHIP_TO2） 25. Van Hilststraat 23 -> 24（SHIP_TO3） 26. 5145 RK Waalwijk,Netherlands -> 25（SHIP_TO4） 27. 5145 RK Waalwijk Netherlands -> 26（SHIP_TO5） 注意这里数据行中这个字段有值，但后面还有三个竖线（表示SHIP_TO6, SHIP_TO7, SHIP_TO8为空）？ 然后： 28. 空 -> 27（SHIP_TO6） 29. 空 -> 28（SHIP_TO7） 30. 空 -> 29（SHIP_TO8） 31. 00010 -> 30（LINEITEM1） 32. MLPF3AA/A -> 31（MPN1） 33. 10 -> 32（QTY1） 34. 双引号 -> 33（这里应该是LINEITEM2，但数据行中这个位置是双引号） 所以，数据行总共有34个字段（0到33），但标题行有39个字段（因为最后一个|后面还有一个空字段，所以是39个）。 因此，在解析时，minLength=34（因为headers.length=39, values.length=34）。所以，我们只解析了前34个字段。那么，标题行中第34个字段（索引33）是什么？标题行中： 索引33: MPN2 索引34: QTY2 索引35: LINEITEM3 索引36: MPN3 索引37: QTY3 索引38: 空（因为标题行最后有一个|，所以分割后最后一个元素是空字符串） 而数据行中索引33的值是双引号，所以它被放入了map，对应的标题是第34个字段（索引33）即MPN2。但是，校验器期望的是LINEITEM2字段（标题行中索引29）有值，而数据行中索引29的值是空字符串（因为数据行中第29个字段是空，即SHIP_TO8之后，LINEITEM1之前有三个空字段，所以索引29是空字符串）。所以，LINEITEM2在数据行中并没有出现，它的位置是空的，而校验器期望它是双引号，这显然不对。 实际上，校验器期望的LINEITEM2的值是双引号，是因为在原始数据行中，最后一个字段（索引33）是双引号，而校验器错误地将这个双引号对应到了LINEITEM2字段？或者是因为数据行中字段缺失，导致字段错位。 根本原因：数据行中字段数量不足，导致后面的字段错位。而我们的解析方法（按最小长度）会忽略掉标题行中多出来的字段，所以LINEITEM2字段（在标题行索引29）在数据行中对应索引29的值是空字符串（因为数据行中索引29是空），而校验器期望的是双引号，所以失败。 但是，错误信息中显示，LINEITEM2字段在map中不存在。这是因为在循环中，我们只循环到minLength（34），而LINEITEM2字段在标题行中的索引是29（小于34），所以它应该被放入map，值为空字符串（因为数据行索引29是空字符串）。为什么错误信息说“Not Found”呢？ 可能是因为在构建map时，字段名是标题行中的字段，但注意标题行中的字段名可能有空格？或者大小写？我们看错误信息中，其他字段都是存在的（如PALLET_ID等），所以LINEITEM2字段名应该也是存在的。 但是错误信息中有一个字段检查失败： "fieldName": "LINEITEM2", "expected": "\"", "actual": "Not Found", // 注意这里实际是“Not Found”，而不是空字符串 这很奇怪，因为如果map中有这个字段，即使值为空字符串，也应该显示空字符串，而不是“Not Found”。所以，可能是校验逻辑在map中找不到这个字段。 我们再看解析代码：我们使用的是`headers[i]`作为键，而数据行中索引29对应的标题是LINEITEM2（标题行中索引29的字段名就是LINEITEM2），所以应该放入了。那为什么校验时找不到？ 可能原因：在标题行分割时，LINEITEM2字段名可能被分割成了包含换行符或空格？或者有引号？ 观察标题行字符串： "PALLET_ID|KNBOXNO|CARRIER|COC|CTRY|HAWB|PO|ORIGIN|INVOICENO|CARTONS|SHIPID|SHIP_DATE|TEL|SSCC|RETURN_TO1|RETURN_TO2|RETURN_TO3|RETURN_TO4|RETURN_TO5|RETURN_TO6|RETURN_TO7|RETURN_TO8|SHIP_TO1|SHIP_TO2|SHIP_TO3|SHIP_TO4|SHIP_TO5|SHIP_TO6|SHIP_TO7|SHIP_TO8|LINEITEM1|MPN1|QTY1|LINEITEM2|MPN2|QTY2|LINEITEM3|MPN3|QTY3|\n" 注意：标题行最后有一个换行符，然后紧接着是数据行。我们分割时用split("\n")，所以标题行就是第一个元素（不包含换行符）。所以标题行字符串是： "PALLET_ID|...|QTY3|" （注意最后有一个|，然后换行符被去掉了） 分割标题行：split("\\|")，那么最后会得到一个数组，最后一个元素是空字符串（因为最后有一个|）。所以，标题行数组有39个元素，最后一个元素是空字符串。 数据行：我们取lines[1]（即第二行），分割后得到34个元素（因为数据行最后没有|，所以不会多出一个空元素）。 因此，在循环中，i从0到33（共34次），将headers[0]到headers[33]和values[0]到values[33]放入map。而LINEITEM2在标题行中的索引是29（从0开始），所以它会被放入map，键为"LINEITEM2"，值为数据行中索引29的值（即空字符串，因为数据行中索引29位置是空）。 那么，为什么校验器说“Not Found”呢？可能是因为校验器在map中找不到这个键？或者是因为字段名不一致？注意错误信息中，其他字段名都是正常的，所以应该不是大小写问题。 再看错误信息中，第一个校验失败： "fieldName": "\"filE_CONTENT\": \"PALLET_ID\"", ... 这个字段名很奇怪，可能是整个字符串被当做一个字段名了？但后面的字段名是正常的（如CARRIER等）。所以，第一个校验失败可能是其他原因。 我们重点看LINEITEM2的校验失败： "fieldName": "LINEITEM2", "expected": "\"", "actual": "Not Found" 所以，校验器在map中查找键"LINEITEM2"，但没有找到，所以返回"Not Found"。 为什么map中没有这个键？我们再看解析代码，在循环中，我们使用： dataMap.put(headers[i], values[i]); 所以，如果headers[i]就是"LINEITEM2"，那么就会放入。但注意，标题行中索引29的字段名是"LINEITEM2"（没有空格），所以键就是"LINEITEM2"。 那么，问题可能出在：在数据行中，索引29的位置是空字符串，所以map中"LINEITEM2"对应的值是空字符串。而校验器期望的是双引号（即字符串内容是一个双引号）。但是，校验器报告说没有找到这个字段，这很奇怪。 可能的原因：在解析后，有人修改了map？或者校验器在查找字段时，字段名被修改了？或者有额外的处理逻辑去除了空字段？ 我们并没有在解析代码中去除空字段，所以每个字段都会放入map，包括值为空字符串的。 因此，我们推测校验器可能只检查非空字段？或者校验器在检查字段时，如果值为空就认为不存在？但错误信息中其他字段值为空字符串的并没有报告“Not Found”，例如： "fieldName": "KNBOXNO", // 在数据行中索引1是空字符串，但错误信息中没有这个字段的校验失败？因为错误信息中只列出了部分字段。 错误信息中列出了23个字段的失败，其中包含LINEITEM2。而数据行中KNBOXNO也是空字符串，但错误信息中没有KNBOXNO的校验失败？所以校验器可能只检查了部分字段（即那些在期望值中非空的字段）。而LINEITEM2的期望值非空（是一个双引号），所以被检查了。 但是，为什么校验器说没有找到LINEITEM2字段？可能是因为在map中，这个键不存在？我们检查一下标题行中索引29的字符串：有没有可能包含不可见字符？比如换行符、空格等？ 我们检查标题行字符串：在"LINEITEM2"前后，都是|，所以应该是干净的。但是，在标题行中，LINEITEM2后面是MPN2，所以标题行中该位置是"LINEITEM2"，没有多余字符。 因此，我们只能怀疑在解析标题行时，split函数将字段名改变了？我们可以打印一下headers[29]是什么。 建议调试：在解析后，打印map中所有的键，看是否存在"LINEITEM2"。 另一种可能：在数据行中，由于字段数不足，导致LINEITEM2字段在数据行中对应的索引29的值是空字符串，这没有问题。但是，校验器期望LINEITEM2字段的值是双引号，而实际是空字符串，所以校验失败。但是错误信息中为什么说“Not Found”而不是显示空字符串？这可能是校验器在报告实际值时，如果字段不存在就报告“Not Found”，如果存在但值不匹配就报告实际值。 所以，如果校验器报告“Not Found”，说明这个字段在map中不存在。那么，我们就要确认：在map中，键"LINEITEM2"是否存在。 可能的原因：在标题行中，索引29的字段名是"LINEITEM2"（注意是字符串），但可能包含回车符（\r）？因为原始字符串是Windows换行符（\r\n）？我们在split("\n")时，标题行可能包含\r。 处理：在分割行之前，应该去除每行的\r。 修改解析代码： ```java String[] lines = fileCONTENT.split("\n"); // 处理每一行的回车符 for (int i = 0; i < lines.length; i++) { lines[i] = lines[i].trim().replace("\r", ""); } ``` 这样，可以避免标题字段名包含\r导致键不匹配。 另外，关于数据行中最后的双引号，它被解析为MPN2字段的值（因为标题行中索引33是MPN2），而校验器并没有检查MPN2字段，所以没有报错。 但是，校验器检查了LINEITEM2字段，而LINEITEM2字段在数据行中对应的位置是空字符串（索引29），所以map中LINEITEM2的值是空字符串。校验器期望它是双引号，所以应该报告值不匹配（expected="\"", actual=""），而不是字段不存在。 所以，问题转化为：为什么校验器认为这个字段不存在？ 可能的原因：在构建map之后，可能有一个步骤移除了值为空字符串的字段？或者校验器在读取map时，如果值为空字符串，就认为字段不存在？ 由于用户没有提供校验部分的代码，我们只能猜测。 因此，针对这个具体错误，我们需要： 1. 确保字段名正确：去除标题字段名的\r和空格。 2. 确保不因为空字符串而移除字段。 修改解析代码（增强健壮性）： ```java public Map<String, String> parsePipeSeparatedData(String fileCONTENT) { // 处理转义的换行符 fileCONTENT = fileCONTENT.replace("\\n", "\n"); Map<String, String> dataMap = new LinkedHashMap<>(); String[] lines = fileCONTENT.split("\n"); // 清理每一行：去除回车符和首尾空格 for (int i = 0; i < lines.length; i++) { lines[i] = lines[i].replace("\r", "").trim(); } if (lines.length >= 2) { String[] headers = lines[0].split("\\|", -1); // 使用-1保留空字符串 String[] values = lines[1].split("\\|", -1); int minLength = Math.min(headers.length, values.length); for (int i = 0; i < minLength; i++) { String header = headers[i].trim(); String value = values[i].trim(); dataMap.put(header, value); } // 如果标题字段更多，则剩余字段设为空字符串 for (int i = minLength; i < headers.length; i++) { String header = headers[i].trim(); if (!header.isEmpty()) { dataMap.put(header, ""); } } } return dataMap; } ``` 修改点： 1. 清理每行的回车符和首尾空格。 2. 分割时使用split("\\|", -1)确保即使字段为空，也会保留空字符串。 3. 循环中，对每个header和value进行trim()，避免空格问题。 4. 如果标题字段多于数据行字段，将多余的标题字段放入map，值为空字符串。 这样，即使数据行中缺少字段，标题行中所有的字段都会出现在map中（值为空字符串）。因此，LINEITEM2字段一定会出现在map中，值为空字符串（因为数据行中索引29的值为空）。 那么，校验器现在应该能找到LINEITEM2字段，但值不匹配（期望双引号，实际空字符串）。但用户期望LINEITEM2的值是双引号，这可能是数据源的问题。我们解析到的数据行中，LINEITEM2的位置是空字符串，而双引号出现在MPN2的位置。 所以，用户需要检查数据源的格式是否正确。如果数据源中LINEITEM2的值应该是双引号，那么它应该出现在数据行的第30个字段（索引29）的位置，而不是第34个字段（索引33）的位置。 综上所述，我们修改了解析代码，确保所有标题字段都会出现在map中（即使数据行中缺失）。这样，校验器就不会报告字段不存在，而是报告字段值不匹配（空字符串 vs 双引号）。至于值不匹配的问题，需要检查数据源格式。 但是，用户提供的错误信息中，LINEITEM2的期望值是双引号，这可能是由于数据行中最后那个双引号应该属于LINEITEM2？如果是这样，那么数据行中字段数量不足，导致双引号被解析到了MPN2字段。所以，根本解决方法是修复数据源，确保数据行字段数量和标题行一致。 最后，关于那个双引号，如果数据行最后那个双引号是数据错误，应该去除，那么可以在解析前清洗数据： ```java // 如果数据行以双引号结尾，去除它 if (lines.length >= 2) { lines[1] = lines[1].trim(); if (lines[1].endsWith("\"")) { lines[1] = lines[1].substring(0, lines[1].length()-1); } } ``` 这样，数据行最后那个双引号就被去除了，不会作为一个字段。 综合以上，我们给出最终修复的解析方法。</think>### 问题分析与修复方案 您遇到的 `LINEITEM2` 字段解析问题根本原因在于 **数据行格式不完整** 和 **解析逻辑对字段缺失的处理不足**。以下是详细分析： #### 核心问题：数据行字段缺失 1. **标题行有 39 个字段**（以 | 分割，包含末尾的空字段） 2. **数据行只有 34 个字段**（实际有效数据到 QTY1 结束） 3. 数据行末尾有孤立的双引号 `"`，导致解析错位 4. `LINEITEM2` 字段在数据行中不存在，但校验器期望值为 `"` #### 修复后的解析方法 ```java public Map<String, String> parsePipeSeparatedData(String fileCONTENT) { // 处理转义字符 fileCONTENT = fileCONTENT.replace("\\n", "\n"); Map<String, String> dataMap = new LinkedHashMap<>(); // 分割行并清洗数据 String[] lines = fileCONTENT.split("\n", -1); if (lines.length < 2) return dataMap; // 清洗行首尾空格和特殊字符 String headerLine = lines[0].trim().replace("\"", ""); String dataLine = lines[1].trim(); // 关键修复：移除数据行末尾的孤立双引号 if (dataLine.endsWith("|\"") || dataLine.endsWith("\"")) { dataLine = dataLine.substring(0, dataLine.length() - 1); } // 使用 -1 保留空字段 String[] headers = headerLine.split("\\|", -1); String[] values = dataLine.split("\\|", -1); // 完整字段映射（处理缺失字段） for (int i = 0; i < headers.length; i++) { String header = headers[i].trim(); String value = (i < values.length) ? values[i].trim() : ""; // 特殊处理孤立引号 if (value.startsWith("\"") && !value.endsWith("\"")) { value = value.substring(1); } dataMap.put(header, value); } return dataMap; } ``` ### 关键修复说明 1. **数据清洗增强** ```java // 移除数据行末尾孤立双引号 if (dataLine.endsWith("|\"") || dataLine.endsWith("\"")) { dataLine = dataLine.substring(0, dataLine.length() - 1); } ``` - 修复数据行末尾的格式错误 2. **完整字段映射** ```java for (int i = 0; i < headers.length; i++) { String value = (i < values.length) ? values[i].trim() : ""; dataMap.put(header, value); } ``` - 保证所有标题字段都有对应值（缺失字段设为空字符串） 3. **空字段保留** ```java split("\\|", -1) // 使用-1参数保留末尾空字段 ``` ### 问题字段 `LINEITEM2` 处理结果 | 字段 | 修复前 | 修复后 | |------|--------|--------| | **LINEITEM2** | 不存在（Not Found） | 空字符串 ("") | | **校验期望值** | "\"" | 应改为 "" | | **实际值** | 无 | "" | ### 验证测试 ```java // 测试数据 String testData = "PALLET_ID|LINEITEM2|\nvalue|"; // 执行解析 Map<String, String> result = parsePipeSeparatedData(testData); // 验证结果 System.out.println(result.get("LINEITEM2")); // 输出: "" (空字符串) System.out.println(result.containsKey("LINEITEM2")); // 输出: true ``` ### 校验器修正建议 ```json { "checkType": "FIELD", "fieldName": "LINEITEM2", "expected": "", // 应修正为期望空字符串 "actual": "", "valid": true // 校验通过 } ``` ### 最终建议 1. 数据源端应确保数据行字段数与标题行一致 2. 添加数据完整性检查： ```java if (headers.length != values.length) { log.warn("字段数不匹配: 标题{}列 vs 数据{}列", headers.length, values.length); } ```