1

我正在使用 PDFKitten 搜索功能，发现在此特殊字符无法搜索（例如，假设在 PDF 中有一个单词 RAVI，如果我搜索该单词，它将返回 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's 在上述函数中，两个 NSLog 输出第一个显示 ScanString==MGR KL445™s，第二个什么都不会显示。

4

1 回答 1

1

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

在PDFKitten 突出显示错误位置的问题的上下文中，该库将连字作为单个连字字符而不是“去连字”字符组返回似乎很明显。如果您的文本包含连字，这可能就是原因。

在同一个问题的上下文中，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的八进制，WinAnsiEncoding中的quoteright， PDFDocEncoding中的商标。

/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 在解析字体字典（setEncodingNamed在 Font.m 中）时识别字符串“WinAnsiEncoding”并将 WinAnsiEncoding（3）从枚举 CharacterEncoding（Font.h）中存储在 self.encoding 中；稍后，当将原始 PDF 数据转换为 unicode（stringWithPDFString在 SimpleFont.m 中）时，它调用并返回

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

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

NSJapaneseEUCStringEncoding     = 3,

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

如果由于某种原因初始化失败（例如，如果数据不代表用于编码的有效数据），则NSString initWithData返回 nil 。因此，PDFKitten 在处理 PDF 数据时会丢弃整个片段。

乍一看，当前代码库中的相关代码部分仍然相同。因此，您可能希望在 PDFKitten 站点上报告一个关于字符代码 > 127 的问题，该问题也适用于带有/Encoding /WinAnsiEncoding和最有可能带有 `/Mac*Encoding' 的字体。

于 2013-01-21T12:09:05.347 回答