基于EasyExcel二开支持导入合并的单元格解析一

目录

• 基于EasyExcel二开支持导入合并的单元格解析二

二开的原因

在一次开发产品需求中产品要求系统要支持批量导入一批数据，这批数据为一对多数据涉及到合并单元格问题，在调研了多个工具后选择了Gitee上GVP项目EasyPoi，然而在实际使用中却困难重重。

EasyPoi遇到的问题

EasyPoi为一个公司开源的一个傻瓜式的excel解析工具，相对原生的apche poi来讲简单易用且功能强大，其具体的优点在官网上都有可以自行查看，这里主要说一下我遇到的问题

1、空白行的判断。EasyPoi的空白行判断非常智障以第1列或指定列为主键标定该列必须有值，如遇到中间出现空行的情况下则认为已读到最后一行数据。如下表格示例，当我们以标题一为主键列时，当读到第3行时由于主键列数据为空，则认为是最后一行最张只读取了2行数据。

行号	标题一	标题二	标题三
1	a	a	a
2	b	b	b
3
4	c	c	c

2、读取合并单元格。当我设计一个如以下的数据结构时，EasyPoi在处理list部分的数据会判断当前的主键列是否为空且当前处理的数据是否为list，如果条件成立则会循环的读取每一行的list数据，相反如果条件不成立且主键列不为空，则新起一个对象做为新的数据来处理。

数据结构

public class Student{
	private String name;
	private int age;
	private List<Work> list;
}
public clss Work{
	private String workName;
	private String workDescription;
}

解析List部分数据的判断

if (params.getKeyIndex() != null
          && (row.getCell(params.getKeyIndex()) == null
          || StringUtils.isEmpty(getKeyValue(row.getCell(params.getKeyIndex()))))
          && object != null){
          //读取每一行List部分数据
}

3、EasyPoi的校验简直是一个半成品big bug。他的校验是在代码里植入一个接口来进行校验，在导入含有合并单元格且需要解析List结构时，它竟然将单行数据进行校验，而不是将合并好后的对象数据进行校验。
这样就会产生：理想的数据结构是一个Object对象其中含有单值属性和List结构属性(size大于1)，然后将整个解析完整的Object进行校验，然而实际是只解析了一行excel数据后就进行校验。如下数据结构可看出，在实际的校验入参里第2次的入参只有List部分数据，因为第2次校验实际是第1次的校验数据没有合并导致
我提出的issues有图例可以看下：https://gitee.com/lemur/easypoi/issues/I53DJV

表格数据

//理想中的校验入参
{
  "title1": "1",
  "title2": "1",
	"list": [
    {
      "小title1": "1",
      "小title2": "1",
      "小title3": "1"
    },
    {
      "小title1": "2",
      "小title2": "2",
      "小title3": "2"
    },
    {
      "小title1": "3",
      "小title2": "3",
      "小title3": "3"
    }
  ]
}
//实际的校验入参
第1次校验
{
  "title1": "1",
  "title2": "1",
	"list": [
    {
      "小title1": "1",
      "小title2": "1",
      "小title3": "1"
    }
  ]
}
第2次校验
{
  "title1": null,
  "title2": null,
	"list": [
    {
      "小title1": "2",
      "小title2": "2",
      "小title3": "2"
    }
  ]
}

在经历了上面3个问题以后产生了要修复一下这个bug，然而由于空白行判断的问题陷入了一个死循环，如果要空白行判断就无法读取完整的list数据，如果要读取list数据就无法处理空白的问题。在后面几天我看了gitee上issues发现这个作者已经推出收费版本了停留在issues上的bug有些可以追溯到几年前，随后放弃了修复。