NI Vision OCR Verify Text验证文本函数中文不兼容
验证文本 上面的效果就是验证文本后的效果。但是因为在shi.abc的字符集中，我们并没有指定参考字符，所以这里的验证分数都是0。 这个验证文本函数，可能还存在了一个问题，即中文等双字节的字符在验证时，无法正常处理。期望字符中输入双字节的中文时，会被当作是2个字符，而识别的字符，一个中文则只有一个字符，这时如果按照识别到的中文数输入期望字符，则会出现数量不匹配的错误：中文字符的验证文本功能有问题 上面的ROI中，如果做图像处理，则是“石鑫华视觉网”6个中文字符。但是，在期望字符中输入“石鑫华视觉网”时，则被认为是12个字符，所以这里就出现了“找到的目标数量与要验证的期望字符或模式数量不匹配”的错误。假如说，我们将上面的期望字符改为“石鑫华”之类的3个中文字符，则会被计算为6个字符长度，则其长度是匹配的：期望字符“石鑫华”3个中文字符长度是6个字符与识别的字符数量匹配 所以，这里的验证文本的使用，可能还有些问题。如果真要使用该函数，可能无法作用于双字节的中文字符识别。期望字符123456共6个数字字符可以做验证文本的功能期望字符abcdef共6个英文字符可以做验证文本的功能 所以，双字节的中文、日文、韩文等，做字符验证时，会存在问题，请小心使用。但是这个字符验证，在OCR训练接口中，对于中文等，又是可以正常使用的：中文的“石鑫华视觉网”验证分数都是1000分或接近1000分 如上面的OCR训练接口中，训练了“石鑫华视觉网”6个中文字符，并且设置了参考字符，则其验证分数都有近1000的满分值，也就是说可以正常的验证。所以，对于这里的实现功能，在LabVIEW中如何去实现，还得研发人员再考虑考虑：使用期望模式验证中文字符 在这里，视觉论坛使用了一种方法，就是期望字符置空，但是在期望模式中，设置相应的中文期望数组，这样再做文本验证时，就可以正常使用了，如上图是正常的验证文本，下面的则是数量不匹配的验证文本：数量不匹配的验证文本 所以，视觉论坛推断，在OCR训练接口中的验证文本功能，应该是使用了期望模式的输入端，而非使用了期望字符。当然了，如果非要使用期望字符，在仅有有限的几个中文字符时，也是有办法可想的，如本节的示例中，“石鑫华视觉网”6个中文，那么可以将其映射为单字符的数字或字母进行验证，就如上面的123456或abcdef之类的。但是这样做，验证分数可能也是不会高的，因为字符集，可能并没有对应的123456/abcdef的字符类。所以，最终还是得将中文字符当作是一个字符模式来处理验证功能。
页:
[1]