读者数据转换窗口，用于将dt1000的MARC格式读者数据，转换成dp2系统的XML格式读者数据，进入对应的读者库。
===
根据MARC数据中的读者信息，创建实体XML记录
<barcode> -- 读者证条码：从MARC记录中的100$a获得。
<password> -- 密码：从MARC记录中的080$a获得。dt1000读者数据中的密码为明码，而转换到dp2读者记录中后，需要转换为hash码。
<readerType> -- 读者类型：从MARC记录中的110$a获得。
<createDate> -- 发证日期：dt1000读者信息中缺此项。保持空白。
<expireDate> -- 失效期：从MARC记录中的110$d获得。需要从8字符格式转换为RFC1123格式。
<state> -- 停借原因：从MARC记录中的982$b获得。此元素为本次新增元素。如果读者证状态正常，就不应有此元素或者保持此元素的文本内容为空。
<name> -- 姓名：从MARC记录中的200$a获得。
<namePinyin> -- 姓名拼音：从MARC记录的200$A获得。这是本次新增的元素。
<gender> -- 性别：从MARC记录的200$d获得。
<bornDate> -- 生日：dt1000读者记录中缺乏此信息。保持空白。
<idCardNumber> -- 身份证号：dt1000读者记录中缺乏此信息。保持空白。
<department> -- 单位：从MARC记录的300$a中获得。
<address> -- 通信地址：从MARC记录的400$b中获得。
<zipcode> -- 邮政编码：从MARC记录的400$a中获得。
<tel> -- 电话：从MARC记录的300$b中获得。
<email> -- Email地址：dt1000读者记录中缺乏此信息。保持空白。
---
<borrows> -- 借阅信息（集合）。该元素下可有若干<borrow>元素，每个<borrow>元素表示一册图书的借阅信息。
<borrow> -- 借阅信息（单册）：从MARC记录的986字段中的一个子字段组获得。该元素有若干属性：
barcode属性 -- 册条码：从子字段组$a中获得。
borrowDate属性 -- 借阅日期：从子字段组$t中获得。需要从8字符格式转换为RFC1123格式。
no属性 -- 续借次数：从子字段组$y中获得。表示续借次数。1表示?
borrowPeriod属性 -- 借阅期限：子字段组中$v为应还日期，根据它和借阅日期$t计算出借阅期限。也许这个借阅期限不是很准确，因为可能dt1000的应还日期是按照还书日越过了非工作日计算出来的，而dp2的借阅期限是不考虑工作日和非工作日的。 这个计算出来的借阅期限可能偏长。
---
<overdues> -- 超期罚款信息（集合）。该元素下可有若干<overdue>元素，每个<overdue>元素表示一册图书的超期罚款信息。
<overdue> -- 超期罚款信息（单册）：从MARC记录的988字段中的一个子字段组获得。该元素有若干属性：
barcode属性 -- 册条码：从子字段组中$a获得。
borrowDate属性 -- 借阅日期：从子字段组中$e获得。需要从8字符格式转换为RFC1123格式。
returnDate属性 -- 应还日期：从子字段组中$t获得。需要从8字符格式转换为RFC1123格式。这里设计放应还日期，而不是放借阅期限，是因为超期罚款字段处理的是已经还回的、有超期情况的册，而尚未还回的、已处于超期状态的册，不在超期罚款字段处理之列。
borrowPeriod属性 -- 借阅期限：这是dp2系统中应有的信息。但是在dt1000的读者记录988字段中缺乏这个信息。所以只好空缺。好在缺乏这个信息，并不影响超期罚款字段的主要功能：收缴罚款、阻止缴罚款前读者后续的借阅，只是少了有关借阅期限的参考信息。
price属性 -- 罚款额：从子字段组中$c获得。这是为dt1000数据升级而专门增补的属性。而在dp2系统中，一般采用的是通过over属性（超期时间）和罚款政策动态计算款额的办法。这样，dp2系统的罚款款额获得办法，就变成了两个：如果有price属性，就用它；如果没有，就用over属性结合其他信息计算出来。
type属性 -- 罚款类型：从子字段组中$b获得。其值有“罚金”“租金”“赔偿”等等。这是因为升级dt1000数据而则增补的属性。
---
<reservations> -- 预约信息（集合）。该元素下可有若干<request>元素，每个<request>元素表示一个独立的预约请求。
<request> -- 预约请求：从MARC记录的984字段中的一个子字段组获得。该元素有若干属性：
items属性 -- 预约的册条码列表：从子字段组中$a获得。dt1000的984字段中每个子字段组只是表示了对一册的预约，当作一个独立的预约请求；而dp2中，可以把多个册条码组合为一个独立的预约请求，当其中任何一个册到达时，预约请求就算满足了，该请求就会被整体处理，多余的其他册条码也即将被一同消除，不再发生作用。所以，从dt1000升级上来的数据，只是用到了dp2系统的一种可能：预约的册条码列表中只有一个条码。
requestDate -- 请求的日期：从子字段组中$b获得。需要从8字符格式转换为RFC1123格式。
注：子字段组中的$c为到书日期。升级软件如果发现一个子字段组有这个子字段，就会跳过这个子字段组，不把其升级到dp2系统中。这样就避免了对已到预约册的升级处理，软件会简单一些。
在后面的交叉处理过程中，需要根据读者记录中的预约请求信息，对相关的实体记录进行信息增补处理。