dp2 新的条码校验规则应用

该文档介绍关于dp2系统条码校验的功能。

一、条码前端界面校验与服务器API校验概述
二、如何打开/关闭条码校验开关
- 2.1 打开/关闭服务器API校验开关
- 2.2 打开/关闭内务前端界面的校验开关
三、各功能界面校验与服务器API校验的匹配依据
- 3.1 读者窗，编辑读者信息
- 3.2 种册窗，一般册登记
- 3.3 种册窗，快速册登记
- 3.4 册登记窗，册登记
- 3.5 快捷出纳窗，借还
- 3.6 读者查询窗，校验读者记录
- 3.7 实体查询窗，校验册记录
四、条码规则编写与应用案例
- 4.1 单套系统，统一的条码规则
- 4.2 单套系统，馆藏地规则不同
- 4.3 总分馆系统，分馆内统一的条码规则
- 4.4 总分馆系统，分馆下馆藏地规则不同
五、关于条码自动转换

将原有的C#校验函数变更为新的校验规则，配置流程包含：配置xml校验函数--删除原有相关函数--打开校验开关。

删除原有的C#脚本程序和client.cs前端校验函数

另外，如果系统之前有配置了c#脚本函数和client.cs前端校验函数，在配置新的校验规则后，需要删除c#脚本函数中已经配置了新规则的部分和client.cs前端校验，

删除前要注意先将library.xml和client.cs都拷贝下来存在NAS设备上的用户服务目录里，再删除library.xml相关函数部分，然后完整删除client目录。

删除c#脚本函数

C#脚本函数在【功能】-【系统维护】-【系统管理】-【脚本程序】界面，需要删除verify barcode一节内容，如果C#中还配置了条码转换函数，还要同步删除trans函数其他内容保留）。

删除client.cs前端校验函数

用户可以先从内务观察client.cs文件是否存在，路径为：【功能】-【系统维护】-【系统管理】-【内核】-【!】-【cfgs】-【client】下是否存在client.cs文件。如果存在，需要到服务器所在的电脑上删除。

**如果是标准版服务器，**client.cs文件路径：打开dp2Installer,点击【dp2library】-【打开数据文件夹】-【选择需要删除client.cs的实例】进入【library_data】-【cfgs】-【client】，删除整个【client】子目录。

单机版服务器中client.cs文件路径：在【dp2Libraryxe单机】上点击【帮助】-【打开用户文件夹】-【library_data】-【cfgs】-【client】，删除整个【client】子目录。

原来的脚本程序和前端校验函数都失效后，在校验开关打开时，新配置的校验函数才能真正生效。

打开服务器端校验函数

在【功能】-【系统维护】-【系统管理】-【内核】-【Library.xml】配置文件中，root根元素下配置circulation元素，启动相关校验功能。verifyBarcode代表校验条码，verifyReaderType代表校验读者类型, verifyBookType代表校验册类型。

<circulation verifyBookType="true" verifyReaderType="true" verifyBarcode="true" />

Mar 12 '20 18:03 renyh

一、前端界面校验与服务器API校验概述

如上图所示，dp2的条码校验过程分为两个阶段：首先是内务前端界面里校验条码是否符合规则，界面校验通过后，前端把数据提交服务器，相应的服务器API再次对条码进行校验。

但dp2系统为了照顾到所有用户的情况，比如有的早期用户单位，条码规则比较乱，没法配置出条码规则来，这时就不能让系统对条码进行校验。所以dp2系统用不同的开关参数，决定是否执行前端界面校验和服务器端API校验，只有打开界面校验才执行界面校验，只有打开了服务器API开关，才执行服务器端API的校验。

例如在读者窗，新增/修改读者时，界面开关和服务器API的就有下表这4种组合。

内务界面开关	API开关	界面校验效果	服务器API校验效果
关	关	不校验	不校验
开	关	校验	不校验
关	开	不校验	校验
开	开	校验	校验

我们给用户服务时，最理想的情况是：指导用户把前端校验开关打开，同时我们也帮用户把服务器校验开关打开，这样一些功能就先在前端界面校验，如果不合规则，在前端界面校验就卡住了，不会提交到后台服务器端；如果前端校验通过，提交到服务器端，服务器端API再进行一遍校验，两保险肯定没有问题。

但实际情况，我们可能没法检查每个用户的前端电脑上内务是否打开界面校验参数，即使指导用户打开了界面校验，用户后面也可能自己修改了。所以最低情况下，要保证打开服务器API校验开关。

下面第2章节如何开关前端界面校验开关与服务器API校验开关。

Mar 13 '20 18:03 renyh

二、如何打开/关闭条码校验开关

2.1 打开/关闭服务器API校验开关

服务器API校验开关配置很简单，只在一处配置，即在dp2服务器的library.xml文件的circulation节点配置属性verifyBarcode="true" (注意B字母要大写)，打开服务器端API校验开关。例如<circulation verifyBarcode="true" />

如要关闭服务器API校验开关，将verifyBarcode设为false，即<circulation verifyBarcode="false" />

2.2 打开/关闭内务前端界面的校验开关

内务界面校验针对不同的功能，有3个界面校验开关，分别如下： 1）册登记操作，需在种册窗启用校验册条码，点击菜单【帮助】/【参数配置】，在【种册】属性页，勾中“校验输入的册条码号”； 2）借还书操作，需在快捷出纳窗启用校验条码，点击菜单【帮助】/【参数配置】，在【快捷出纳】属性页，勾中“校验输入的条码号”； 3）编辑读者信息，需在读者窗启用校验条码，点击菜单【帮助】/【参数配置】，在【读者】属性页，勾中“校验输入的条码号”。

如要关闭某项功能条码的界面校验开关，则在参数配置里对应的属性页，取消校验开关前面的勾号即可。

Mar 14 '20 08:03 renyh

三、各功能界面校验与服务器API校验的匹配依据

我们来看一个简单的校验规则配置，以此来说明各功能界面校验与服务器端API校验的匹配依据。注意打开各功能界面校验开关与服务器API校验开关。

<barcodeValidation>
    <validator location=",流通库,阅览室">
        <patron>
            <range value="P001-P999" />
        </patron>
        <entity>
            <range value="000001-999999" />
        </entity>
    </validator>
    <validator location="海淀分馆,海淀分馆/*">
        <patron>
            <range value="HD001-HD999" />
        </patron>
        <entity>
            <range value="HD000001-HD999999" />
        </entity>
    </validator>
</barcodeValidation>

条码规则中location 属性定义了馆藏地名称，一般是一个馆代码或者馆藏地名称。空字符串表示总馆，*号表示任意字符。location可以是以逗号分隔的多个值，表示指定的多个值都适应配置的条码规则。例如：location=',馆藏地1,馆藏地2' 表示在各功能进行条码校验时，传空字符串、传"流通库"、传"阅览室" 均能匹配上规则。 location='海淀分馆,海淀分馆/* 表示在各功能进行条码校验时，传"海淀分馆"和传"海淀分馆/任意字符"都能匹配上规则。

下面我们分别说明：读者窗编辑读者信息、种册窗一般和快速册登记、册登记窗册登记、快捷出纳窗借还的界面校验与服务器API校验时传递的匹配依据。

如果服务人员想用下面说的检测方式实验一下，需在本地配置下面环境： 1）在内务参数里配置“流通库”和“阅览室”，以便在左上角能选择馆藏地 2）配置“海淀分馆”分馆的读者库，为其创建一个“图书馆”馆藏地和设置排架体系。

3.1 读者窗，编辑读者信息

界面校验发生时机： 在读者窗，点新增/保存按钮时进行界面校验。新增时，界面校验不通过时，不会出现选择读者库对话框；界面校验通过了，才会出现选择读者库对话框，然后提交服务器。

界面校验匹配依据： 左上角选择的馆代码或者馆藏地信息，就是左上角选择什么就是用什么值去匹配校验规则。

服务器API匹配依据： 读者记录保存至读者库所属的馆代码。

小结： 读者编辑，界面校验与服务器API校验的匹配依据是不同的，配置xml校验规则时要小心，左上角的值和读者库所属分馆的值都要支持到，复杂情况时还可能需要重复写规则。在后面comment中的复杂示例中有介绍。

检测方式： 1）在读者窗，证条码输入"P0"（这是一个不合任何location规则的条码），左上角选择空，点“新增”按钮，报您输入的...号码'P0'(馆藏地属于'')...，看到提示报的馆藏地为空。左上角选择“流通库”，点“新增”按钮，报您输入的...号码'P0'(馆藏地属于'流通库')...，看到提示报的馆藏地为“流通库”。左上角选择“海淀分馆”，点“新增”按钮，报您输入的...号码'P0'(馆藏地属于'海淀分馆')...，看到提示报的馆藏地为“海淀分馆”。以上操作均报界面校验不通过，未到达选择读者库对话框。提示中的馆藏地值与左上角选择完全一致，由此判断界面校验的匹配依据是左上角选择的值。

2）在读者窗，证条码输入"P001"（这是一个任何总馆规则的条码），左上角选择[总馆]，点“新增”按钮，界面校验通过，到达选择读者库对话框。此时故意选择“星洲小学读者”，然后提交到服务器，服务器API校验失败，返回提示条码号...(号码'P001'(馆藏地属于'星洲小学')既不...)。由此提示可判断服务器保存读者API是匹配依据：保存的读者库所属的馆代码。

3.2 种册窗，一般册登记

界面校验发生时机： 在种册窗一般册登记打开的“册信息”对话框，点“确定”时进行界面校验，界面校验不成功，就弹出不通过提示。只有校验成功后，才能回到种册窗。点“全部保存”才提交服务器。

界面校验匹配依据： 册信息对话框中馆藏地输入框的完整值。比如选择的“流通库”则依据“流通库”匹配规则，选择的“海淀分馆/图书馆”则依据“海淀分馆/图书馆”匹配规则。

服务器API匹配依据： 册记录的馆藏地字段的完整值。比如册记录的馆藏地字段值为“流通库”则依据“流通库”匹配规则，馆藏地字段值为“海淀分馆/图书馆”则依据“海淀分馆/图书馆”匹配规则。

小结： 一般册登记时，因为册记录里的馆藏地字段就是“册信息”对话框中馆藏地输入中的值，两者完全一样。所以界面校验与服务器API校验的匹配依据可以认为是相同的。

检测方式： 1）左上角先选择[总馆]，在种册窗，一般册登记，在打开"册信息"对话框，册条码输入"P1"(不符合任何规则），馆藏地选择"流通库"，然后点"确定"，提示您输入的...(号码'P1'(馆藏地属于'流通库')即不是...)。请重新输入。，界面校验不通过无法回到种册窗，看到提示中的馆藏地为"流通库"，与馆藏地输入框的值一致，与左上角无关。然后在"册信息"对话框中，将馆藏地改为"海淀分馆/图书馆"，然后点"确定"，提示您输入的...(号码'P1'(馆藏地属于'海淀分馆/图书馆')即不是...)。请重新输入。，界面校验不通过无法回到种册窗，看到提示中的馆藏地为"海淀分馆/图书馆"，与馆藏地输入框的值一致，与左上角无关。

由此判断，种册窗一般册登记的界面校验是依据在"册信息"对话框馆藏地输入框的值，与左上角选择的值无关。

2）在打开"册信息"对话框，将册条码改为"HD000001"(符合海淀分馆/*规则），馆藏地选择"海淀分馆/图书馆"，然后点"确定"，界面校验通过，回到了种册窗，点"全部保存"按钮提交到服务器，服务器端API校验也通过，保存成功。服务器端API校验是依据册记录的馆藏地字段值。一般册登记无法造出前端校验匹配值与服务器匹配值不同的情况，因为在“册信息”对话框卡住了，不通过没法回到种册窗，而且界面校验也是依据馆藏地字段的值。

3.3 种册窗，快速册登记

界面校验发生时机： 种册窗，快速册登记，在种册窗下方的册条码Textbox输入框输入条码后，回车时进行界面校验，界面校验不成功的话，弹出不通过提示，不会加到册列表中。弹出不通过提示。只有校验成功后，才能加到册列表中，点“全部保存”才提交服务器。

界面校验匹配依据： 左上角选择的馆代码或者馆藏地信息，就是左上角选择什么就是用什么值去匹配校验规则。

服务器API匹配依据： 册记录的馆藏地字段的完整值。比如册记录的馆藏地字段值为“流通库”则依据“流通库”匹配规则，馆藏地字段值为“海淀分馆/图书馆”则依据“海淀分馆/图书馆”匹配规则。

小结： 快速册登记时，TextBox值界面校验是依据左上角选择的，服务器API校验是依据册记录的馆藏地字段值，两者匹配依据不同，配置xml规则时小心，应对左上角的值和册记录的馆藏地字段值都要支持到。所以location值没法向以前C#方式只配一个馆代码，对于单套系统，一般配置为location=",馆藏地1,馆藏地2"或location="*"；对于总分馆模式，一般是配置为location="馆代码,馆代码/*"。

检测方式： 1）在种册窗，快速册登记，左上角先选择[总馆]，在种册窗下方的Textbox输入"P1"(不符合任何规则），然后回车，提示您输入的...(号码'P1'(馆藏地属于'')即不是...)。请重新输入。，界面校验不通过无法加到册列表中，看到提示中的馆藏地为空，与左上角一致。然后切换左上角选择"流通库"，下方册条码框依然是P1，回车，提示您输入的...(号码'P1'(馆藏地属于'流通库')即不是...)。请重新输入。，看到提示中的馆藏地为"流通库"，与左上角一致。再切换左上角选择"海淀分馆/图书馆"，下方册条码框依然是P1，回车，提示您输入的...(号码'P1'(馆藏地属于'图书馆/')即不是...)。请重新输入。，看到提示中的馆藏地为"海淀分馆/图书馆"，与左上角一致。

由此判断，快速册登记的界面校验是依据左上角选择的值。

2）造一个左上角值，与提交册记录馆藏地不同的情况。在快速册登记缺省值中馆藏地设为"海淀分馆/图书馆"。在上角选择[总馆]，然后在种册窗下方的册条码框中输入"000009"(这是一个符合总馆校验规则，不符合"海淀分馆/图书馆"规则），在textbox回车，界面校验通过（依据左上角值匹配），加到册列表中，再点全部保存按钮提交到服务器。服务器校验不通过，返回提示条码为'000009'的事项在提交保存过程中错误--条码号...(号码'000002'(馆藏地属于'海淀分馆/图书馆')即不是...) 。由此判断，服务器API校验是依据册记录的馆藏地字段值，与左上角选择无关，有可能左上角通过了，但服务器不通过。

3.4 册登记窗，册登记

界面校验发生时机： 无界面校验。

服务器API匹配依据： 依据册记录的馆藏地字段的完整值。比如册记录的馆藏地字段值为“流通库”则依据“流通库”匹配规则，馆藏地字段值为“海淀分馆/图书馆”则依据“海淀分馆/图书馆”匹配规则，与左上角的选择无关。

小结： 在册登记窗进行册登记时，只有服务器API的校验，依据是册记录的馆藏地字段值，所以只要能匹配上馆藏地的条码规则即可。

检测方式： 左上角选择[总馆]，在册登记窗，检索一条本地记录装载到种和册界面，点+号新增一册，册条码输入"P2"(不符合任何规则） ,馆藏地选择"流通库"。再新增一册，册条码输入"P2"（不符合任何规则），馆藏地选择“海淀分馆/图书馆”，到此界面上一直没出现任何不通过提示，所以判断出册登记窗无界面校验。

然后点击左下角的"保存"按钮，提交到服务器，返回服务器API校验不通过的提示，其中第1条提示条码号"P1"经验证...(号码'P1'(馆藏地属于'流通库')即不是...)，这里看到提示的馆藏地为"流通库"第一条记录的馆藏地值相同。第2条提示条码号"P2"经验证...(号码'P2'(馆藏地属于'海淀分馆')即不是...)，这里看到提示的馆藏地为"海淀分馆/图书馆"与册记录的馆藏地一致。由此判断，服务器API校验依据册记录里的馆藏地值，与左上角选择无关。其实服务器API与种册窗新增册是同一个API。

3.5 快捷出纳窗，借还

界面校验发生时机： 在快捷出纳窗条码TextBox回车时进行校验。界面校验不通过，报不通过提示；校验通过，装载读者信息或者册信息。

界面校验匹配依据： 左上角选择的馆代码或者馆藏地信息，就是左上角选择什么就是用什么值去匹配校验规则。

服务器API匹配依据： 无服务器API校验

小结： 快捷出纳窗借还只有界面校验，界面校验依据左上角选择的值，所以只要让用户左上角选择的值匹配上对应规则即可。

检测方式： 1）在快速出纳窗，点借书，左上角先选“[总馆]”，条码框输入'P0'回车，报校验不通过提示，看到提示信息里的馆藏地值为''。不能装载读者。 2）左上角先选“馆藏地1”，条码框输入'P0'回车，报校验不通过提示，看到提示信息里的馆藏地值为'馆藏地1'。 3）左上角先选“海淀分馆”，条码框输入'P0'回车，报校验不通过提示，看到提示信息里的馆藏地值为'海淀分馆'。

3.6 读者查询窗，校验读者记录

不受界面校验开关和服务器API校验开关的影响（也就是说与这两个开关没有任何关系）。

校验匹配依据： 读者记录所属读者库的馆代码。

检测方式： 选中一条总馆记录一条分馆记录，执行右键命令“校验读者记录”，查看报错提示里的的馆藏地值，可以看到是本条读者记录所属读者库的馆代码。

3.7 实体查询窗，校验册记录

不受界面校验开关和服务器API校验开关的影响（也就是说与这两个开关没有任何关系）。

校验匹配依据： 册记录的馆藏地字段完整值。

检测方式： 在一条不合规则的记录上执行右键命令“校验册记录”，查看报错提示里的的馆藏地值，可以看到是该记录的馆藏地字段完整值。

Mar 14 '20 08:03 renyh

四、条码规则编写与应用案例

这里根据常见的4种图书馆条码规则要求，编写对应规则，并解释说明为什么这样编写。服务人员可以根据这些样例为图书馆具体配置，如果还有特殊情况，再补充样例。

4.1 单套系统，统一的条码规则

<barcodeValidation>
    <validator location=",流通库,阅览室,保存本库">
        <patron>
            <range value="001-999" />
        </patron>
        <entity>
            <range value="000001-999999" />
        </entity>
    </validator>
</barcodeValidation>

说明： 1）location中的第一个逗号前的空，表示匹配馆代码为空的情况，就是单套系统下左上角默认为[总馆]的值。对于单套系统，没有特别的情况，不会让用户在内务前端配置附加馆藏地，左上角馆代码就是一个空值。所以要支持空值的匹配。界面校验是依据左上角值匹配的地方有：读者窗，快捷出纳窗，种册窗的快速册登录。

2）另外读者保存服务器API是依据读者库馆代码，单套系统读者库的馆代码为空。由此看到服务器校验也要支持空值的匹配。

3）为什么不能写为location=''，是因为xml新规则，对于册记录条码的服务器API校验是依据册记录的馆藏地字段值校验了，location设为空，只能匹配馆代码空值，不能匹配上具体的馆藏地字段值。所以看到上面规则示例中location列举了对各个馆藏地的值。

4）如果一个系统的馆藏地很多，列举很麻烦，容易漏掉，能不能优化？可以优化为location=",*"，逗号前面的空表示馆代码，星号表示任意馆藏地。如果还希望再简化，可以优化为location="*",表示匹配任意馆代码和任意馆藏地。

4.2 单套系统，馆藏地条码规则不同

如果一套系统，但内部使用者有独立的划分，比如有东区和西区两个大的划分，两个区的册条码规则是不同的，读者证条码规则也是不同的，那么可以按下面方式来配置。

<barcodeValidation>
    <validator location="">
        <patron>
            <range value="D001-D999" />
            <range value="X001-X999" />
        </patron>
    </validator>
    <validator location="东区*">
        <patron>
            <range value="D001-D999" />
        </patron>
        <entity>
            <range value="D000001-D999999" />
        </entity>
    </validator>
    <validator location="西区*">
        <patron>
            <range value="X001-X999" />
        </patron>
        <entity>
            <range value="X000001-X999999" />
        </entity>
    </validator>
</barcodeValidation>

说明： 1）东区和西区是两个大的馆藏地划分，可以实际有"东区一层"、"东区二层"、"西区一层"等，所以分别定义了location="东区*"和location="西区*"，星号表示任意字符，属于东区或西区的馆藏地都会匹配上对应规则。

2）为什么除了"东区*"和"西区*"的定义，又定义了locaton="",重复书写了证条码的规则？这是因为读者保存服务器API是依据读者库所属馆代码来匹配规则，对于单套系统，读者库的馆代码为空。所以为了在服务器API校验时通过，需要配上location为空的情况。

3）上述规则配置比较严格，使用的时候，要指导用户在内务前端参数中配置上附加馆藏地"东区"和"西区"，并且指导东区和西区的用户在内务左上角选正确自己的区。如果左上角没选，按默认[总馆]，那么读者编辑界面校验和服务器API都能通过，但快捷出纳窗扫册条码时和种册窗下方册条码输入框回车均界面校验不通过，因这两处的界面校验是依据左上角选择的馆藏地。如果左上角选错了，本来是西区的用户选择了东区，那么各处的界面校验均不通过。所以上述xml对用户使用要求比较严格。

4）如果觉得上述配法规用户使用要求严格，服务没有精力的话，可以配置的笼统一些，这样在内务左上角不选择或者选错，都没有关系，能正常的通过前端界面校验和服务器API校验。可以改为下面写法，这种笼统写法的特点把总馆、东区、西区等全部看为一个范围，支持好几种条码形态。优点是配置简单，服务也简单，小缺点就是不能区分很细，比如册登记时、借还书时，东区也能认西区的条码，但线下管理上别搞弄了就行，如果希望东区不能借还西区的图，可以通过js脚本来配置。

<barcodeValidation>
    <validator location=",东区*,西区*">
        <patron>
            <range value="D001-D999" />
            <range value="X001-X999" />
        </patron>
        <entity>
            <range value="D000001-D999999" />
            <range value="X000001-X999999" />
        </entity>
    </validator>

其实上面location再简化，就是为location=",*"或location="*，与单套系统是一样，只是多支持几种条码形态而已。

4.3 总分馆系统，分馆内统一的条码规则

<barcodeValidation>
    <validator location="海淀分馆,海淀分馆/*">
        <patron>
            <range value="001-999" />
        </patron>
        <entity>
            <range value="000001-999999" />
        </entity>
    </validator>
    <validator location="西城分馆,西城分馆/*">
        <patron>
            <range value="001-999" />
        </patron>
        <entity>
            <range value="000001-999999" />
        </entity>
    </validator>
</barcodeValidation>

配置说明： 1）以前C#只写一个馆代码就可以了，为什么新xml规则配置location时，除了馆代码，还要加一个馆代码/*？例如 location="海淀分馆,海淀分馆/*"。新规则细化到对馆藏地校验，相比以前C#发生了很大的变化，所以就不用参考以前C#写法了。 location中增加'馆代码/*'，是因为册记录保存的服务器API是依据册记录的馆藏地字段去匹配校验的，分馆下的馆藏地写法是"馆代码/XXX",如果location只写馆代码没法匹配上册记录的馆藏地。

2）那么location只配置为location="馆代码/*" 可以吗？不可以，因为读者编辑时、快捷出纳窗借还时，界面校验是依据左上角选择馆代码，馆代码是不带/的。另外读者保存服务器API校验也是依据读者库的馆代码，所以location里要列上"馆代码"。

3）综合上面两条，location配置为location="馆代码*可以吗？不可以，不用列举号，直接用"馆代码*"这样写有漏洞，比如配置为locaton="海淀分馆*"，那么除了"海淀分馆"和下级馆藏地能匹配上，"海淀分馆1"类似这样前半段相同的分馆和下级馆藏地也都匹配上了。这显然违背了希望分馆条码区分开的目的。需要用列举法，列出馆代码和下级馆藏地，这样才能精确到是这一个分馆的规则，需配置为location="海淀分馆,海淀分馆/*"。

4.4 总分馆系统，分馆下馆藏地条码规则不同

类似4.2，单套系统内有可能馆藏地条码规则不同，分馆下馆藏地也可能会出现条码规则不同，例如“星洲学校/高中部”和“星洲学校/初中部”，是两个独立的管理单位，册条码规则不同，读者证条码规则不同。但高中部和初始化是属于同一个分馆。读者库所属馆代码是同一个分馆代码。

可以按下面方式配置，但指导用户使用工作量比较大，需要这个分馆的高中部用户在内务中配置附加馆藏地"星洲学校/高中部"，初中部用户配置附加馆藏地"星洲学校/初中部"，并且左上角一定要选择上 "星洲学校/高中部"或者"星洲学校/初中部"，不能按缺省值"星洲学校"或者选错了。按默认值或选项要校验不通过，具体参见4.2中第3条说明。

<barcodeValidation>
    <validator location="星洲学校">
        <patron>
            <range value="XZJ001-XZJ999" />
            <range value="XZH001-XZH999" />
        </patron>
    </validator>
    <validator location="星洲学校/初中部*">
        <patron>
            <range value="XZJ001-XZJ999" />
        </patron>
        <entity>
            <range value="XZJ000001-XZJ999999" />
        </entity>
    </validator>
    <validator location="星洲学校/高中部*">
        <patron>
            <range value="XZH001-XZH999" />
        </patron>
        <entity>
            <range value="XZH000001-XZH999999" />
        </entity>
    </validator>

</barcodeValidation>

如果要简化配置，服务指导或维护方便，可以改为下面列举法配置，这样在内务左上角按默认的分馆值，能正常的通过前端界面校验和服务器API校验。这种笼统写法的特点是一个分馆和其下级的馆藏地看为一个范围，支持多种条码形态。优点是配置简单，服务也简单，小缺点就是不能区分很细，比如册登记时、借还书时，高中部也能认初中部的条码，但线下管理上别搞弄了就行，如果希望高中部不能借还初中部的图书，可以通过js脚本来配置。

<barcodeValidation>
    <validator location="星洲学校,星洲学校/初中部*,星洲学校/高中部*">
        <patron>
            <range value="XZJ001-XZJ999" />
            <range value="XZH001-XZH999" />
        </patron>
        <entity>
            <range value="XZJ000001-XZJ999999" />
            <range value="XZH000001-XZH999999" />
        </entity>
    </validator>
</barcodeValidation>

理解了上面4种情况后，我们怎么配置规则就清楚了。后面章节介绍的条码转换不会改变和影响这4个情况的配置方式，只是增加了一个条码转换的功能。

Mar 14 '20 08:03 renyh

条码自动转换

条码转换主要用在快捷出纳窗。

下面是一个分馆下馆藏地册条码规则不同，且册条码有自动转换的示例：

    <validator location="分馆名称">
        <patron>
            <CMIS />
<!-- 此为注释：学籍号 -->
            <range value="XXP00001-XXP99999" />
        </patron> 
    </validator>
    <validator location="分馆名称/馆藏1">
        <entity>
            <range value="00001-27067" transform="result= 'XXY' + barcode ;" />
<!-- 当条码为 00001-27067区间时，借还扫入时要加上XXY前缀-->
            <range value="XXY00001-XXY27067" />
            <range value="XXY0000001-XXY9999999" />
        </entity>
    </validator>
    <validator location="分馆名称/馆藏2">
        <entity>
            <range value="27068-31284" transform="result= 'XXW' + barcode ;" />
            <range value="XXW27068-XXW31284" />
            <range value="XXW0000001-XXW9999999" />
        </entity>
    </validator>

上面这个示例，对用户使用要求严格，需要在用户在内务前端配置上对应的附加馆藏地，然后在内务左上角选择正确的馆藏地，才能进行转换和校验条码，左上角不能直接用馆代码。指导用户使用工作量比较大。

如果希望简化配置，服务指导或维护方便，可以把几种条码格式看作在一个大范围，location用列举法配置，这样就不用在用户前端电脑配置附加馆藏地了。配置举例如下：

  <validator location="分馆名称,分馆名称/馆藏1,分馆名称/馆藏2">
        <patron>
            <CMIS />
            <range value="XXP00001-XXP99999" />
        </patron>
        <entity>
            <range value="00001-27067" transform="result= 'XXY' + barcode ;" />
            <range value="27068-31284" transform="result= 'XXW' + barcode ;" />
            <range value="XXY00001-XXY27067" />
            <range value="XXW27068-XXW31284" />
            <range value="XXY0000001-XXY9999999" />
            <range value="XXW0000001-XXY9999999" />
        </entity>
    </validator>

Mar 15 '20 15:03 renyh

dp2installer dp2libraryxe 和 dp2circulation 都已经更新了。兑现了新的默认匹配规则，即每一位字符的取值范围为对应位置首尾字符的范围。例如range='001-999'，则需要满足前两位每位字符为0-9，最后一位字符为1-9。 range 元素中的 pattern 属性也实现了，pattern 属性存在的时候 range 属性只参与比较首尾范围、不进行逐字符范围比较。

注意：默认匹配规则也有坑，例如range='0000001-7777777' 这样的定义，需要每一个字符都只允许 7 和以下的数字，例如0009999则不符合，和直觉相违背，使用时候要格外注意。

下面的是一些测试样例：

条码规则定义：range='000001-999999' 条码测试样例：

000001  符合
012345  符合
700009  符合
999999  符合
000000  不符合
00000A  不符合
0A0001  不符合
A00001 不符合
12345  不符合
01234中  不符合
1234567  不符合

条码规则定义：range='A00001-A99999' 条码测试样例：

A00001  符合
A12345  符合
A77777  符合
A99999  符合
AB0000  不符合
A0000A  不符合
A0001 不符合
12345  不符合
B12345  不符合
A123456  不符合

条码规则定义：range='000001-A99999' 条码测试样例：

000001  符合
123456  符合
999999  符合
A00001  符合
A12345  符合
A77777  符合
A99999  符合
AB0000  不符合
A0000A  不符合
A0001 不符合
12345  不符合
B12345  不符合
A123456  不符合

条码规则定义：range='000001-555555' 条码测试样例：

000001  符合
012345  符合
123455  符合
444449  不符合
060000  不符合
123456  不符合
A00001  不符合
000060  不符合
001  不符合
0000001 不符合

条码规则定义：range='ABC00001-ABC99999' 条码测试样例：

ABC00001 符合
ABC99999 符合
ABC12345 符合
ABCD0001 不符合
ABC0000A 不符合
A0000001  不符合
AB000001  不符合
0BC00001  不符合
ABC9999A  不符合

Jul 24 '20 10:07 renyh

新的条码校验规则应用

目录

删除原有的C#脚本程序和client.cs前端校验函数

删除c#脚本函数

删除client.cs前端校验函数

打开服务器端校验函数

一、前端界面校验 与 服务器API校验 概述

二、如何打开/关闭条码校验开关

2.1 打开/关闭服务器API校验开关

2.2 打开/关闭内务前端界面的校验开关

三、各功能界面校验与服务器API校验的匹配依据

3.1 读者窗，编辑读者信息

3.2 种册窗，一般册登记

3.3 种册窗，快速册登记

3.4 册登记窗，册登记

3.5 快捷出纳窗，借还

3.6 读者查询窗，校验读者记录

3.7 实体查询窗，校验册记录

四、条码规则编写与应用案例

4.1 单套系统，统一的条码规则

4.2 单套系统，馆藏地条码规则不同

4.3 总分馆系统，分馆内统一的条码规则

4.4 总分馆系统，分馆下馆藏地条码规则不同

条码自动转换

一、前端界面校验与服务器API校验概述