聚会很晚...所以我想就我的发现提供一些意见,每个都与
使用$("#sigDiv").jSignature('getData', 'putSomethignInHere') 函数来验证签名是否存在。
以下是我为传递给 jSignature 函数的第二个属性检查过的选项:
native 在 sig 框为空时返回对象 .length == 0 的对象,但在 sig 框中有东西时返回 .length > 0。如果您想知道有多少笔画,只需使用此对象的长度即可。
注意:根据 jSignature 文档:
“Stroke = mousedown + mousemoved * n (+ mouseup 但我们没有记录,因为那是“结束/缺乏移动”指示器)”
base30 也返回一个对象。这里我查看了这个对象的第二个索引位置的信息。
x = $("#sigDiv").jSignature('getData', 'base30')[1].length > 0 ? TRUE : FALSE 此处 x 如果该框已签名,则为 TRUE,而当 jSig 框保持不变时,则为 FALSE。
在我的例子中,我使用base30 属性来验证签名复杂性,而不仅仅是“最终用户是否画了一些东西?”。
x = $("#sigDiv").jSignature('getData', 'base30')[1].length > {insertValueHere} ? TRUE : FALSE。为了验证最终用户实际在框中签名并给出的不仅仅是一个简单的“。”小'x'。从base30 产生的第二个索引的返回值随着复杂度的增加而变大。因此,如果用户确实只输入了一个点,
x = $("#sigDiv").jSignature('getData', 'base30')[1].length 大约是 5。最终用户在框中绘制的越多,产生的值就会变得越来越大。我在测试期间记录的最长长度是 2272。我在盒子里乱涂乱画了 15 秒。
根据 jSig 文档:
base30 (alias image/jSignature;base30) (EXPORT AND IMPORT) (VECTOR) 数据格式是一种基于 Base64 的压缩格式,针对荒谬的紧凑性和原生 url 兼容性进行了调整。它是将“原生”数据结构压缩成所有向量的紧凑字符串表示形式。
image- 这是我在验证时会避免的选择。它在第二个索引位置生成一个带有长字符串的对象。我测量的最后一个是 672 个字符长。使用 image 会生成一个字符串,无论 sig 框是空白还是已使用。为了让事情变得更无用,Chrome verse 中的空白签名框与 FF Developer 中的空白签名框生成的字符串是不同的。我确定 image 值有用,但不能验证。
svgbase64 - 这类似于image,但有例外。与image 不同,使用svgbase64 在第二个位置会产生一个长而短的字符串。此外,当我执行 Chrome verse FF Developer 检查时,这个字符串是相同的。这是我停止测试的地方。所以我假设你可以使用svgbase64 进行验证。
这些是我的结论,你的可能会有所不同。请不要以我的低劣名声反对我。