ios - 在 PDFKitten 中无法进行特殊字符搜索

Question

我正在使用 PDFKitten 搜索功能，发现在此特殊字符无法搜索(例如，在 PDF 中说有一个单词 RAVI's，如果我搜索该单词，它将返回 NULL 值。请建议我如何做我解决了这个问题。

谢谢

在scanner.m中有一个函数didScanString

void didScanString(CGPDFStringRef pdfString, Scanner *scanner)
{
     NSString *tempStr = (NSString *)CGPDFStringCopyTextString(pdfString);
     NSLog(@"ScanString==%@",tempStr);

NSString *string = [[scanner stringDetector] appendPDFString:pdfString withFont:[scanner currentFont]];
    NSLog(@"didScanString====>>>%@",string);
    [ss appendString:string];
    [[scanner content] appendString: string];
    //NSLog(@"TOTAL: %@",[scanner content]);

}

例如搜索 PDF 字符串是 MGR KL445 的在上面的函数中，两个 NSLog 输出第一个显示 ScanString==MGR KL445™s第二个什么也不会显示。

Answer 1

您的搜索文本 RAVI's 包含一个垂直撇号；您是否检查过 PDF 是否不包含该字符的向前或向后倾斜版本？那些不同的版本毕竟有不同的字符代码。

在问题的上下文中 PDFKitten is highlighting on wrong position ，看起来该库将连字返回为单个连字字符而不是“去连字”字符组。如果您的文本包含连字，这可能就是原因。

在同一个问题的上下文中，PDFKitten 字体数据解析结果在某些方面存在缺陷。针对这个问题，针对此类缺陷的解决方法已添加到代码中，在我看来，它并没有解决一般情况，只是解决了一些特殊情况，请参见。我在那里的回答中的建议。

此外，一些字体根本不包含将其字形映射回 unicode 字符的信息。你说特殊字符无法搜索 --- 也许这些特殊字符取自不支持解析的不同字体。

理论上，撇号甚至可能是使用图形、非文本运算符绘制的。在这种情况下，文本解析将找不到它。

如果这些想法都不能解释您的情况(或者您无法检查它们是否能解释)，请提供示例 PDF 以供检查。

编辑(考虑到您的 Brivo MR355 copy.pdf 示例文件)

我认为撇号又是个麻烦事，这次是在 MR355 中。原始页面内容有两个准确度，

/TT1 1 Tf
0.559 0 Td
(Brivo MR355\222s Ready Bar technology replaces 30 complex inputs with a single control, simplifying scan optimization )Tj

和

/TT1 1 Tf
0.559 0 Td
(Brivo MR355\222s Ready Interface)Tj

两次都使用了字体资源/TT1，两次都将撇号编码为\222，它是十进制 146 的八进制，quoteright 在 WinAnsiEncoding 中，trademark PDF文档编码。

/TT1是

/LastChar   146
/BaseFont   /REEDOQ+GEInspira
/Type   /Font
/Subtype    /TrueType
/Encoding   /WinAnsiEncoding
/Widths [232, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 198, 0, 0, 0, 530, 0, 0, 530, 0, 530, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 570, 0, 0, 0, 0, 0, 0, 243, 0, 0, 0, 764, 0, 0, 0, 0, 556, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 545, 545, 482, 545, 509, 297, 545, 544, 210, 0, 0, 210, 836, 544, 537, 545, 545, 341, 437, 317, 544, 474, 736, 471, 474, 427, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 190]
/FontDescriptor 32 0 R
/FirstChar  32

/LastChar 是 146 和/Encoding 是/WinAnsiEncoding 应该使 PDFKitten 很容易将\222 识别为 quoteright 字符。

由于您的一条评论表明您没有使用最新的 PDFKitten 版本，我也会根据旧版本进行代码分析。

PDFKitten 在解析该字体字典(Font.m 中的 setEncodingNamed)时识别字符串“WinAnsiEncoding”，并将枚举 CharacterEncoding (Font.h) 中的 WinAnsiEncoding (3) 存储在 self.encoding 中；稍后，当将原始 PDF 数据转换为 unicode(SimpleFont.m 中的 stringWithPDFString)时，它会调用并返回

NSString *string = [[NSString alloc] initWithData:rawBytes encoding:self.encoding]; 

但是nsstring.h映射中的编码常量

NSJapaneseEUCStringEncoding     = 3,

因此，这里的 PDFKitten 尝试将原始数据解码为 EUC-JP字节值 >127 的编码应该会失败，而字节值 <= 127 被解释为 ASCII 字符。

NSString initWithData returns nil if the initialization fails for some reason (for example if data does not represent valid data for encoding) .因此，PDFKitten 在处理 PDF 数据时丢弃了整个片段。

乍一看相关代码部分在当前代码库中仍然是相同的。因此，您可能想在 PDFKitten 网站上报告有关 /Encoding/WinAnsiEncoding 字体的字符代码 > 127 的问题，并且很可能还有 `/Mac*Encoding'