目录
(4) 我公司HeroGod（亥个）“终端”1:n软件与api的用法
(4) 门禁“人脸识别”终端机能否用于“检票”与“访客”系统？
闸机WEB API 与终端macse 二次开发 说明书
l 如下图所示，譬如，顾客在闸机上刷二维码检票
l 二维码内容是:”123456789”
l 服务器api url：http://192.168.31.139:5103/api/MacGetedQr6Api
l 此时，闸机等价于浏览器（相当于闸机模拟器）向服务器url post 提交“二维码”JSON数据
l 服务器上会收到JSON
![文本框: {
"head": {
"uirst": {
"exebtn": {
"idx": 0
},
"cbxs": [
{
"v": 0,
"idx": 0
}
]
},
"pams": {
"mid": "12345678901234567890123456789012",
"tid": 0,
"swmode": 0
}
},
"rst": 0,
"tp": 0,
"qrb64": "MQAyADMANAA1ADYANwA4ADkA",
"idx": 0
}](2023.10.30.web.api.files/image003.gif)
(3) JOSN中关键项的意义
l “mid”为闸机的id号，用于区分不同的闸机
u 注意闸机的id号也相当于登陆密码
l “qrb64”为二维码的base64编码
l JSON中还有其它文本是关于界面DIY元素的，不影响控制逻辑，为了快速对接，后面会再说明
l 模拟闸机提交的全部数据与格式如下图所示
(5) JOSN中关键项的意义
l “ctrmac”如果不为null，则闸机控制动作有效
l “tp”为1表示“开门一次”；如果为0，表示不执行闸机控制
l JSON中还有其它文本是关于界面DIY元素，以及更多控制参数，为了快速对接，后面会再说明
l 服务器返回的“headers”格式为content-type: application/json; charset=utf-8
l 至此，就完成了“主动模式下”闸机“二维码检票”的对接
(1) 1:n与1:1的关系
l 1:n调用是1:1函数，在海量人脸中找到达到阈值的记录
l 当采集到了与设备相关的人脸图片与特征值，只是完成了人脸识别开发的一小部分，之后1:n是多线程并发开发，如果数据达到百万，则10个并发查询就相当于千万级别，效率是重点
l 我们发现，很多百元的脱机门禁机配置CPU 1G都不到，人脸识别的查询的速度并不慢，是因为门禁数据一般很少，而且脱机时无并发，如果真存满10万条，速度马上就不行了，脱机门禁机动态增删改性能低，所以满足不了检票、访客行业需求
l x86服务器一般可以做到大于CPU 16核、2.5G，RAM 128G，适合做人脸识别1:n服务器，配合多线程合理编程与内存版数据库，可以做到1亿条数据500毫秒内匹配；由于主要是内存表操作，对硬盘速度要求低，硬盘中的数据库一般存储人脸识别额外信息，比如人员图片，资料等，这些信息是1:n出结果后，用主键从数据库中提出
l 内存查找是关键，要将所有数据从数据库一次性提到内存表，之后增删改都在内存中进行，文件数据库可以延迟更新，否则，硬盘是最大瓶颈，要注意的是，云主机有虚拟层，会导致速度大打折扣，数据量要控制在千万级别
l 1:1算法如果是内积算法的话，就是将两个数组的元素一一计算，最后得出一个数字结果，代表相似度
l 特征值与设备的算法与参数设置相关，通用性稍差，可以将采集设备整体当成“黑盒”，如果要替换，可以整体替换；但特征值比较与平台与设备无关，一套软件可以不加修改直接用于其它特征比较
l C#代码
![文本框: /// <summary>
/// C#的 人脸识别1:1比对函数
/// 要求人脸识别特征值是采用同类设备采集的
/// </summary>
/// <param name="fu1">特征值数组1</param>
/// <param name="fu2">特征值数组2</param>
/// <returns>返回(0-1)，越大越相似，一般应用达到0.6认为是同一个人</returns>
public static float match(float[] fu1, float[] fu2)
{
float rst = 0;
if (fu1 != null && fu2 != null)
{
int minlength = Math.Min(fu1.Length, fu2.Length);
for (int i = 0; i < minlength; ++i)
{
rst += fu1[i] * fu2[i];
}
}
return rst;
}](2023.10.30.web.api.files/image006.gif)
l 可以看出，就是简单的乘法与加法，如果只有几千人的话，用单片机单线程1:n下来，也能做到1秒返回；所以，脱机门禁机由于可以不考虑并发，用STM32精心设计的话，成本可以做到50元以内
(4) 我公司HeroGod（亥个）“终端”1:n软件与api的用法
l 1:n是指服务器软件的api，是脱离硬件终端的，api需要user只是“权限id”
l 服务器软件数据库用的是sqllite，sqllite比大型数据库效率低，但其只是存取，软件实际是内存数据库工作，本地存取无关紧要；我们选用sqllite另一个原因是，sqllite是文件型，好复制，能做成“绿色软件”，且移到ubuntu上运行
l 打开服务器软件
l 人脸识别“1:n”api是 服务器ip /api/DemoFace301Api/findfaces1n
l JSON如下
{
"user": "string",
"gpidx": 0,
"fus": [
0
],
"timeout":2000
}
“user”在“appsettings.json”中配置，是本api的访问权限
“fus”是获取人脸识别时得到的特征值数组
l 返回结果如下
{
"rst": 0,
"keyid": null,
"sim": null,
"ms": 0
}
“keyid”是匹配到的数据库记录的主键，用此主键可进一步提取图片与其它信息
“sim”是相似度
“ms”是1:n的总耗时
l 人脸库的建立可以用H5端demo api
l “获取”按钮能查看所有库中记录
l 为了测试性能，可以将待匹配的记录放到数据库的最后
l CPU与线程的配置，可以打开数据库“facegp”表
l
l “gpidx”是分组，每个组之间的人脸库是隔离的，比如A店与B店人员不互通，就要分在两个不同组
l “taskcount”是指本组并发启动的任务数，同一时刻，超过此数量将会排队处理
l “thdcount”是指每个任务的线程数，一般总线程是cpu物理线程的10~100倍，也不太多，太多的话，线程本身的调度信号，也会浪费资源
l 主要涵盖HeroGod（亥个）牌“检票闸机”与“前台终端”的二次开发,由于API全部是标准的REST风格,通信内容为纯JSON，因此，也可以扩展到我公司（北京顺极）或友商同类产品的对接
l 我公司传统旧版非JSON接口闸机，如串口、IO电平接口设备，一般可以采用我司专门的“canZhuang转接板”转换，该转接板是将旧接口统一转为“CAN总线接口”接入现有总线，从而进一步实现WEB API接口
l 如今产品接口，一般都是以WEB API为主，JSON格式交换，上位机服务器语言多用”java”、“c#”，所以，本说明书没有 “新技术”，本质上是介绍闸机二次开发时JSON各成员的意义
l 另一部分内容介绍“人脸识别”比对、“身份证”人证合一、“IC卡”读写、“二维码”读取、“闸机控制”、“打印图文报表”，这些 “硬件”都是常见的，一般“管理系统”与“售（检）票系统”都需要与之打交道；我公司尽可能将这些硬件模块集中起来，做成WEB API接口统一控制，便于纯WEB方式控制，如浏览器无插件控制、手机H5控制、微信小程序控制等，一般用“WIFI”连接，简单高效
l “人脸识别系统”有不少开源系统，大多与openCv有关，商用产品，几乎无真正核心的“原创算法”，是“低门槛”技术
l 作为应用，“人脸识别”开发工作集中在“服务端1:n比对”与“终端采集”， “服务端1:n比对”是多线程开发的重点，也是大部分“云上系统”的服务内容，“服务端1:n比对”可以自架服务器，普通代码不够“巧妙”的话，可堆硬件解决，一般用i5处理器+16G内存的小服务器，轻松应对5000万条人脸库的应用，一般100ms~1000ms得到结果的话，都不影响用户体验
l 当前仍有一些公司提供在线1:n服务，并且按次收费，就像上网刷新一次，也可以说成是获得了一次网页服务，就要按次收费，明显让人不安
l 由于几个大公司的宣传加持，好像任何管理软件都需要人脸识别，鲜有领导会考虑其必要性，所以，正确做法是，人脸识别都要有，但不一定要使用
l 为了适应，我公司将终端上的人脸识别功能，设置为几种开启状态，可以通过WEB API配置
l 开机运行人脸识别，并且开启热成像；一般用于访客系统
l 开机关闭人脸识别，顾客可以用“按钮”选择开启人脸识别功能；一般用于检票系统；因为检票系统主要是二维码、手动输入验证码、IC储值卡为主，人脸识别可以用于老年票、儿童票等半价票的自动化检票，做法如下
l 顾客购票以后，自主上传人脸相片与证明文件，商家收到订单以后，查看正确，则允许生效；
l 以上步骤如果是现场售票，商家前台可以直接确定属于优惠人群，直接采集人脸
l 顾客用人脸识别检票通过；如果顾客刷二维码，后台获知是优惠票，则应启动人脸识别，提示人脸识别二次验证
l 当然，老年票购买时，可以在订单中填写身份证号，然后刷身份证检票，身份证上的生日与有效期可以判断年龄是否相符
l 开机关闭人脸识别，隐藏人脸识别按钮，用于“进出”“封闭管理”的系统；这类系统一般进“入场”刷二维码扣费一次，出场则不能再进，但是期间顾客要临时“出场”，则顾客可以在手机上开启“临时出场”，然后再检票出场时，闸机终端自动开启人脸识别，这样就用“手机二维码+人脸识别”解决了重复入场的问题
l HeroGod（亥个）终端上的人脸识别只提取人脸识别最小区域，人体其它部分不拍照，不是人脸不提取
l 人脸识别热成像防伪拍照为单独流程，拍照流程屏幕可见，热成像用于本轮防伪，不会发到接口
l 当安装到更衣柜时，会安装到固定斜度，不可以调角度，保证了物理角度上只拍到人脸区域
l 一般在隐私在意场所，可另外张贴“隐私模式已开启”与原理说明，以消除担忧
l 如果产品需要与欧盟打交道，这一点尤为重要，从发展来说，我国以后也会出台相应隐私政策
(4) 门禁“人脸识别”终端机能否用于“检票”与“访客”系统？
l 门禁“人脸识别”终端机一般是脱机比对，受硬件限制，其速度与阈值设置的很低，一般存储不会超过100万，而如今小区门禁系统基本不要求安全性，连IC阅读器很多都是使用简单的序号，形成了一种行业惯例，所以看起来，很多小区安装了人脸识别，但却很少实际投入使用，技术上原因是门禁“人脸识别”终端机不能频繁增删用户，用户量也一般也不要超过20万，否则速度马上降到无法忍受的地步
l “检票” 与“访客”系统如果采用人脸识别，会有一半性能用于“增删改人脸库”；另外，多终端同步计算要求数据集中在数据库中，而不是脱机在“终端机”中，比如访客系统，可能人员是从网上登记的，访客的进与出也不一定是同一组闸机，所以，门禁“人脸识别”终端机只是看起来有用，认真起来则无用
l 民间身份证采集，其实只有公安部模块脱机解码才是合法的，所谓网络版身份证阅读器是商家搭“私服”，将公安解码模块放在远程，从而节省了模块费，也就节省了成本，但公安部未授权这种做法，网络版商家号称稳定用于某大型国家项目并不可信
l 网络版身份证阅读器有时比正规脱机的还快的原因是，商家“私服”上违规记录了上次采集过的身份证序号，从而跳过解码步骤，直接从库中返回了身份证信息
l 现在云系统居多，反正都要联网，使得用户无法区分所刷的身份证是“脱机”还是“上网” 解码的，让“网络解码”有了生存空间；网络版身份证阅读器最大问题是不稳定，但使用上也分行业，比如宾馆登记这种客流量小，又不太要求稳定速度的场合则可以；而检票闸机要求马上出结果则不能用，否则，客流量大的节假日会翻车
(6) IC卡读写的应用现状
l 一般的门禁系统、小型会员管理系统，很多用的是IC卡序号，也就是当成ID卡使用，只读序号的阅读器更便宜
l IC卡写入次数是10万，所以也不适合频繁计数，最安全可靠的做法是，发（制）卡时，由应用软件将A、B密钥都加密，生成16字节“唯一识别码”写在数据区，而后只读使用；加密后的数据有了安全屏障，至少十块钱无法复制了，顾客消费数据仍然在服务器，结合消费提醒推送给顾客，即可保证资金安全
l 特别提醒，复旦M1 IC卡出厂控制字是FF078069，表示A钥与B钥作用相同，所以都要同时加密（为了简化，可以相同密码），市面上有相当一部分错误认地认为B钥无效，可以不管，只对A钥加密，造成用B钥出厂密码就可以随便读写
l 管理系统软件采用的技术现状
l 如今随处可见的关键字是：云、JSON、H5、VUE、微信小程序，纠其原因，还是当前大部分应用属于“记录数据的软件”，适合在web框架上积木开发，尤其是被要求限期上线，兼容微信时，选择H5有时成为唯一选择
l 用上述技术做管理软件使人愉快，但也会遭遇到旧技术负担，比如硬件接口是浏览器插件，动态库等，这些负担破坏了WEB系统的“纯粹”性，而且明知后期很难扩展与替换，加剧了痛苦指数；于是，我公司单独成立接口部门，将这些管理软件的硬件外设，都做成了web api接口；不过也有例外，目前性价比高的小票打印机的驱动较为封闭，暂时这类小票打印机只能接在windows电脑上，好在一般前台电脑大多还是windows系统商用机，如此就可以用同一套web api打印图文并茂的小票，而不是简单的文字小票，使软件彻底解放依赖；比如，某简单的系统，可以用智能电视的浏览器打开网页，通过遥控器就能控制设备工作，美哉
l 简易“组态”显示屏，尤其是顾客显示屏的需求一直存在，目前现有的“组态屏”、“串口屏”由于性能低下，显示图文混排能力实在太弱
l HeroGod（亥个）闸机屏与前台终端屏支持JSON格式自定义界面、自定义声音与LED彩色提示、自定义“按钮”与“复选框”，考虑到触摸屏设备的性能与稳定，HTML文本支持简单的颜色与大小控制，并不支持JavaScript与复杂的CSS；可以做如“发送扫码提示”、“银行签名板”、“评价界面”等应用
l 检票与门禁的区别是，检票要求准确无误，因此，检票一般是服务器端计算，闸机端为采集端
l 对于国家级应用，不缺安保系统，一般任何种类闸机都可以；但是民间应用，尤其是客流量稍大的景区，一般只有三棍闸一个选择，因为摆闸、翼闸都存在不安全因素，比如闯闸绊倒，拥挤卡住摆门等很难避免，而三棍闸从物理上保证了只能120度通过一人
l 三棍闸刚泊来时就是自动三棍闸，也就是有电机带动自动转，驱动系统监测转杆0度位置，如果偏移就会自动回转归零；如今，为了节省电机与驱动器，八成三棍闸用电磁铁+机械卡盘代替，改名为“电控（半自动）” 三棍闸，混淆替代“自动”三棍闸，“电控”三棍闸的缺点是电磁铁本身物理效率低，故障高
l 更麻烦的是，卡盘是钢性连接结构，一旦被挤压（防撞相关测试），就无法解锁，而“自动”三棍闸可以转动缓冲撞击；另外，“电控”三棍闸断电时，电磁铁会锁住卡盘，为了解决此问题，又冗余增加了一个电磁铁吸住转杆，叫做断电落杆功能，目的是让人能通过，而“自动”三棍闸是电机驱动，断电时能自由转动；断电落杆的缺点是不安全，杆子虽然细，但末端力量仍然可以夹断手指；这就注定了杆子无法像自动三棍闸那样做粗，粗杆明显过人体验更好
l 而自动三棍闸，露在壳外的的转杆没有活页结构，消除了所有安全隐患
l 实际上，电控三棍闸与自动三棍闸成本相差不多，电控三棍闸目前更便宜一点的原因是制造规模更大
l 另外，电控三棍闸机肚开孔很大，无法做到防雨，就更缩短了其使用时长；所以，能看到的室外电控三棍闸，大都是故障停用状态
l 识别自动三棍闸的方法是，两边强制推动转杆（防撞功能）使其偏移一定角度，如果能马上感应到并恢复到正位，就是自动的
l 一般情况下，顾客在闸机上检票后，闸机主动向服务器发数据，所以是“主动”模式，特点是检票事件随时会发生
l “前台”售票时，从“前台电脑”向“前台终端”发送“付款提示”，然后顾客刷二维码付款，对于“前台终端”来说，是被动受控，所以是“被动模式”
l 另外如果是“前台”向闸机发送“临时开门”命令，闸机被动接收，此时闸机是“被动”模式，也就是说，设备有两种模式，可以随时切换
l 如下图，“打印机”是“被动模式”
l HeroGod（亥个）设备的“主被动”是由数值标识的，在设备端，可以设置两个模式对应不同的url，比如：
l 将闸机的“主动”模式用于平时人脸识别检票，指向一个大数据服务器，开发主要业务逻辑；
l 当前台手机用H5遥控闸机时，指向另一个服务器地址，该服务器上放置我公司通用的服务器软件，将这一部分不重要的开发省去
5. BASE64编码转换工具
l 在测试时，如果需要将文本、图片转为BASE64编码，可以使用我们H5页面生成，其内部为纯JS转换
l 网上的一些工具未考虑UTF-16中文的情况，经常转换出来的不能用
l JAVA与C#转换时，编码为UTF-16,小端
l 第一个示例是闸机主动向服务器提交二维码数据，服务器回复中含有闸机的控制命令，只需要一次http连接即可
l “被动模式”是指“前台电脑”向目标设备发送命令，两者都是REST风格的“客户端”，需要服务器中转，为了减少工作量，我公司将终端（闸机或者前台采集设备）的“被动模式”API做了转发，并做了手机端H5控制示例，如此一来，开发者将我公司提供的“服务器端API软件”在远程服务器（或局域内主机，又或本机127.0.0.1）启动，就可以省去步骤，仍然使用“主动模式”一样方式，只要一次http通信
l 如下图所示，“前台” 电脑与采集“终端”在一起，“终端”是“顾客屏”角色，“前台”电脑是商家收银软件角色，两者放在一起，由电脑控制终端，实际是由服务器转发的；优点是，所有设备都在“客户端”，部署方便，如果您的系统需要挣欧元的话，则已经有了天然客端安全性
l 使用的是API是
l 前台电脑H5发出的 “可视化JSON”如下图所示
l “等待结果阻塞时间”是指本次H5等待终端上刷二维码的时间，如果超过此时间未收到，会返回“未获取”；
l “head”是头部JSON，可以DIY界面，声音，提示，LED灯光提示，人脸识别开关，所有API都有；
l “uis”是界面DIY定制，包含在“head”中；
l “图片”是指发给界面的外部图片，“添加图片（可多选）”可以添加更多图片，x，y座标是指图片的左上角座标；
l “内置图片”是指“终端设备”中已经存在的图片，只需要编号就可以，这样就可以不用“外置图片”，提高效率；内置图片与外置图片其它参数一样,也可以添加多个；
l “文本”是指界面上显示的文本，支持简单的html样式，文本显示的位置与矩形区域范围也需要设置；文本可以添加多个；
l “复选框”与“按钮”，是指自定义界面控件，由于获取二维码一般不需要自定义控件，这部分介绍留到后面再讲；
l “ui界面显示时间（毫秒）”是指本命令的自定义界面显示的时间，超过此时间将回到终端内部“默认界面”；“默认界面”也可以设置；
l “opt”是指界面的显示方式，一般是“1”，先清屏后再添加，这样界面就是全新的；
l “face（人脸识别开关）”是控制人脸识别开关的，在此保持为“0”， 这部分介绍留到后面再讲；
l “pams（参数）”中；“mid”填写要控制的终端设备的mid；“swmode”填写“2”代表“被动模式”，我公司的“服务器API软件”使用了此值，如果是“被动模式”才会转发，如果您自己开发这一块，则可以自定义意义；“tid”发多少，终端就多少，所以可以模拟“会话”，但也可以不使用，可以填任意值；
l “保存全局配置”是将“pams（参数）”保存，这样打开其它API也会是此参数；
l “消息提醒”中的文本在屏上闪现几秒后消失，用于提醒，如果不要，就置空；
l “led”让终端的侧面LED显示提配置，1=主要是绿，2=主要是蓝，3=主要是红，可以分别表示“OK”，“提示”，“拒绝“；
l “sud”让终端发出提示声，提示声是终端设备内置的，内置声音也可以自己提前制作好添加进去；
l 点击“确认执行”后，会向服务器POST提交JOSN，并显示在文本框中，形成的JOSN如下图所示
l 注意：JOSN中含“b64”的字段，需要格式化成BASE64发送
l 终端设备收到后，显示的界面如下图所示
l 当在终端上扫描一个二维码“6921734968814”时，返回JOSN如下图所示
l 如果超时，返回JSON如下图所示
l 使用的是API是
l 获取身份证与以上所述获取二维码head部分格式是一样的，此示例使用了“内置图片”，iimg为5；
l “getfu“是指是否提取人脸识别特征值，如果填“0”则使用终端内的默认值，默认值是“是”还是“否”可以设置；提取人脸识别特征值，大约需要多耗时500ms；譬如下一步执行的是人证合一比对，则需要提取特征值；
l “pix”是指提取人脸识别特征值的最小像素（最小识别粒度），此值一般是18，如果太小，则提取的慢，太大会提取不到；
l “save”如果为1，则将以上两个值保存为默认值；比如，要设置闸机为人证合一专用，则设置默认值getfu=1,pix=18
l 点击“确认执行”后，终端上显示如下图所示
l 当在终端上刷身份证后，返回身份证上的全部信息，可以在H5页面上找到字段对应关系
l 注意，相片与大部分字段都需要用BASE64解码
l “fus”，如果不为null，则说明有人脸识别特征值数组，特征值可以用于”相似度比较“API
l 由于身份证中的相片精度低，如果用于人证合一的话，相片特征值与实际人脸比较超过0.4就可以认为是同一人
l 要注意的是，人证合一验证时，一般为了速度，不会进行热成像防伪（活体）检测，这种情况下，用身份证+相片就可以通过；所以，对于高要求的实名制系统，可以开启热成像二次检测
l 使用的是API是
l 上面两个示例已经介绍了结构，此示例并无特殊之处，以下简化说明
l 发送
l 提示：发送图片需要BASE64编码，做成JSON
l 此处传了一个外置背景图片，如果图片适合并且不常改变，可以设置成内置图片，以后就可以用编码显示，节省性能；
l 如上图所示，是签名板的样式，一般将”pencolor”需要设置透明度，就会有一些笔峰“效果；
l 发送后，终端显示界面如下图所示
l 终端上签名，可以使用“电容屏签名笔”，比手写更方便；
l 前台电脑H5收到
l 收到的图片是透明PNG，用于合成处理；譬如，有些高保密单位的访客机，第一道关过闸机，需要人证合一，提取相片，访客到前台，还要人脸识别调出进场记录人工核验，然后签名，最后将相片、签名、身份证信息，访客事由授权记录合成到一起，打印出小票；
l 有些电商后台核销没有接口，只能是手动输入验证码的方式，就可以使用此功能做“核销码”换“本地票”功能
l 使用的是API是
l 发送
l “showpwd”输入时显示是否为密码显示；
l “defvalb64”是指默认填写的值，譬如，所有号码都是“13“开头，则可以设置默认就填充；
l “btn64”设置按钮的文本，按钮可以主动弹出数字键盘，这项在“主动”模式时有用，假如检票闸机支持功能机，功能机无二维码，就可以在购票后，发送数字验证码，然后用户手动输入验证码检票，为了醒目，可以将按钮默认显示为“输入短信码检票”；
l “save”如果是“1”，则会将这些值保存为默认值，下次开机后，按钮弹出数字键盘的行为就被设置了；
l 注意，按钮弹出数字键盘时，还可设置更多功能，比如声音提示，LED提示；
l 收到
l 使用的是API是
l 发送
l “复选框”与“按钮”可以添加多个，用户操作后，将会收到以“idx”为键值的数组，多个“按钮”只会收到被按下引起提交的“idx”；
l 终端界面上会显示：
l 按钮下“是”，会收到
l 按钮下“否”，会收到
l 结果的JSON中，“cbxs”是“复选框“的数组，与输入的一一对应；”exebtn”是被按下引起提交的“按钮”；
l API
l 发送
l 终端显示
l 电脑收到结果
l 获取人脸识别在“head”中，到终端设备的API都可以同时控制人脸识别；人脸识别容易被误触，而其它的如刷二维码等都是用户“自愿”行为，不会误触；譬如终端用于超时前台收银时，当结账时，软件向终端发送收款二维码图片，并提示“请用支付宝扫此码100元”，这时，应明确关闭人脸识别，否则会干扰流程；
l API
l 发送JSON
l “文本”项，一般用于人脸识别涉及的隐私提醒；
l “face”项中，
l ”opt”：1=明确打开人脸识别；2=明确关闭人脸识别；0=保持当前打开或关闭状态不变；此示例要采集人脸识别，所以为“1”；
l “hw”：如果为1，则会开启防伪二次验证；
l “cl”与”po”是关于采集质量的，一般在前台人工采集时，设置为最高“3”，高质量的相片有利于后期1:n查找；而在闸机上时，设置为“1”，质量越低，识别的越快，但1:n时可能匹配不上；
l API
l 人脸的特征值是小数数组，比较人脸特征值是纯数学计算，实际上，一般指纹比较，虹膜比较等相似度比较也是相同算法
l 发送
，
l 注意：此API并不需要真实的终端存在，“mid”只需要在服务器上核对，可以认为是个虚拟的权限号码；
l 由于1:1计算比较简单，此API会立即返回；
l “fu1”与”fu2”是采集人脸识别或身份证时得到的，如："fus":[0.06660951,0,0.01110601,0,0,0.01594588,0,0.022664187,0.05368002.……]这样的小数数组；
l M1 IC卡有16个扇区，每个区4个块；密码在每个扇区的最后一行；比如0扇区，0块是序号；1、2块是数据区；3块是密码；数据与密码都可以写
l IC卡的序号UID总是可读，为4字节，如果完整读第0块，UID处于16字节的前4字节
l HeroGod（亥个）终端读写API操作直接映射到IC卡本身的底层操作，要注意的是，写密码区如果写错，可能卡会无解而作废
l 一般联机应用会选择一个固定的块，用固定密码写入一串16字节数据作为识别号，后期只读使用此识别号
l API与发送
l “opt”：3=读1次，
l “block”：块，101表示使用内置的块号，内置的块号可以设置；譬如，块是10，则其密码在(10/4)*4+3，读写数据时，密码所在块无需指定；
l 其它值为空，则表示保持默认值；
l 刷卡后收到返回
l {"head":{"uirst":null,"pams":{"mid":"12345678901234567890123456789012","tid":0,"swmode":2}},"rst":2,"uidhex":"127e8d10","cdhex":"00000000684c0020a5a5a5a5a5a5a5a5","idx":0}
l “uidhex”是序号，总是会存在；
l “cdhex”是数据，只有密码对了，才有效；
l 修改终端设备读IC的默认密码为1213141516：”pwdhex”=” 1213141516”；”save”=”2”；
l 给空IC第2块写入数据并用默认密码加密：”opt”=”4”； ”block”=”2”;”datahex”=”数据”；
l 修改IC卡密码：”opt”=”4”；”block”=”需要计算密码所在的块”;”datahex”=”需要拼成新的密码”，这部分知识，可以找一些M1 IC说明，也可以向我技术人员咨询
l API与发送
l “opthead”：主要是定制界面元素、声光行为，与以上的API结构相似；
l “objs”：主要是设置参数，可以添加多个同时设置；
l
此api要从“选择JSON模板”
，开始，结合数值与意义表进行设置，模板如下图所示
l 上图中的“执行”可以测试各API的功能，进入不同API后，选择对应的json，可提高效率