在R语言网络爬虫中，有时会遇到一种奇怪的现象：使用rvest或httr抓取网页源码后，明明看到了内容区域，但提取出的文字却显示为一个个方块或无法识别的乱码。查看源码对应位置，发现拿到的是一串Unicode私用区字符，例如U+E001、U+E002等。此时再去查看页面样式，通常会看到@font-face规则，字体文件指向一个.svg结尾的地址。也就是说，网站用自定义SVG字体把真实字符替换成了私用区码点，浏览器加载字体后将码点渲染成对应字形，而爬虫没有加载字体，自然无法直接得到真实文本。要解决这个问题，需要把SVG字体文件下载下来，解析其中的glyph元素，还原私用区码点与真实字符之间的映射关系。
下面会从SVG字体反爬的原理、R语言解析字体文件的关键代码、构建映射表并还原文本、以及实战中的注意事项几个方面展开。整个过程不依赖浏览器自动化，只需要R脚本配合几个常用的包就能完成。
一、SVG动态字体为什么会让爬虫看到乱码
站点使用动态字体做反爬，通常利用的是Unicode私用区。私用区的码位范围大致是U+E000到U+F8FF，Unicode标准中这些码位没有定义统一字符，由应用程序自行解释。网站可以把真实字符A的对应码位设置成U+E001，把B设置成U+E002，然后把网页文本中的真实字符全部替换成这些私用区码位。浏览器加载页面后，会根据CSS里的@font-face规则下载字体文件，再用字体文件里定义的glyph把U+E001绘制成A的字形，于是用户看到的还是正常文字。
对于爬虫来说，只读取HTML源码时，得到的自然是一堆私用区码点。就算用rvest的html_text把文本节点提取出来，也无法自动还原成原始字符。更麻烦的是，有些站点还会对字体文件做动态处理，每次请求生成的字体文件内容不同，私用区映射关系也会变化。因此不能只靠一份静态映射表解决所有页面，需要每次请求时动态解析字体文件。
SVG字体与其他字体格式相比，有一个对爬虫明显有利的特点：它是XML文本，不是二进制。一个典型的SVG字体文件里，每个字形由<glyph>元素描述，包含unicode属性和d路径。unicode属性记录该字形对应的码点，d属性则保存矢量路径的数据。比如某个<glyph>的unicode属性可能是这样的十六进制实体，表示U+E001码位，其d属性则是一长串M、L、C等路径命令，用来描述真实字符的字形轮廓。只要把这些元素提取出来，就能得到私用区码位与矢量路径之间的对应关系。
但这里有一个关键点：仅仅从SVG字体里解析出U+E001对应某条路径，还无法直接知道它就是字符A。因为字体文件不会明确写出A这个字符，它只提供码位和轮廓。要还原真实字符，需要进一步把轮廓识别出来，或者与已知字符集做匹配。这个识别过程会在第三部分详细说明。
二、R语言解析SVG字体文件的核心代码
解析SVG字体的第一步是把字体文件下载下来。R中可以用httr包发送请求，注意设置User-Agent，否则有些站点会拒绝默认的R请求头。下载后使用xml2包读取XML结构。SVG字体虽然根节点是<svg>，但字形通常位于<defs>下的<font>元素中，或者直接以<font>作为根节点。为了兼容不同写法，使用local-name匹配标签名更为稳妥，这样可以忽略命名空间带来的影响。
library(httr)
library(xml2)
font_url <- "https://bbccb.com/fonts/custom.svg"
resp <- GET(font_url, user_agent("Mozilla/5.0"))
font_content <- content(resp, as = "text", encoding = "UTF-8")
svg_font <- read_xml(font_content)
# 使用local-name匹配所有glyph元素
glyphs <- xml_find_all(svg_font, "//*[local-name()='glyph']")
# 提取unicode、glyph-name和d属性
glyph_data <- data.frame(
unicode = xml_attr(glyphs, "unicode"),
glyph_name = xml_attr(glyphs, "glyph-name"),
d = xml_attr(glyphs, "d"),
stringsAsFactors = FALSE
)
head(glyph_data)
这段代码先把字体内容读入为字符串，再用read_xml解析。xml_find_all中的XPath表达式使用local-name，这样即使字体文件声明了命名空间，也能正确找到<glyph>元素。提取属性时，xml_attr会自动返回字符向量，其中unicode属性可能以十六进制实体的形式存在，比如或者，也可能直接是单个Unicode字符。glyph-name属性是字形的名称，有些字体用A、B这样的名称，但很多动态字体只使用uniE001这种名称，甚至直接省略。d属性是SVG路径数据，表示字形的轮廓。
得到原始属性后，需要解析unicode属性为整数码点。如果属性值是十进制实体或十六进制实体，可以用正则提取数字部分，再按对应进制转换。如果属性值本身就是一个字符，则直接用utf8ToInt转成码点。下面是解析函数和筛选私用区字符的示例。
parse_unicode <- function(value) {
if (is.na(value)) return(NA_integer_)
if (grepl("^&#x", value, ignore.case = TRUE)) {
hex_part <- gsub("^&#x|;$", "", value, ignore.case = TRUE)
return(strtoi(hex_part, base = 16L))
} else if (grepl("^&#", value)) {
dec_part <- gsub("^&#|;$", "", value)
return(as.integer(dec_part))
} else {
chars <- utf8ToInt(value)
if (length(chars) == 1) return(chars) else return(NA_integer_)
}
}
glyph_data$code_point <- vapply(glyph_data$unicode, parse_unicode, integer(1))
private_glyphs <- subset(glyph_data, code_point >= 0xE000 & code_point <= 0xF8FF)
解析时需要注意，xml_attr读到的unicode属性可能是HTML实体形式，也可能已经被xml2自动解码。grepl中的正则模式^&#x需要匹配字符串开头的&#x，因此不能直接写成^，否则会被R解释为含义不同的字符。用gsub去掉前缀和结尾分号后，再调用strtoi转换进制。这样得到整数码点后，就可以通过subset筛选出私用区范围的glyph。
有些SVG字体并不给每个glyph都写unicode属性，而是只有glyph-name和d路径。这种情况多出现在通过字体工具导出的文件中，它们会用一个单独的cmap表来建立码位与字形名称的对应。如果遇到这种结构，可以先提取所有glyph的d路径和glyph-name，再根据标准字体的cmap规则猜测映射。不过在反爬场景中，大多数动态字体为了浏览器能够正确渲染，还是会把unicode属性直接写在glyph上，因此上述代码可以覆盖大部分情况。
三、从字形轮廓到真实字符：构建映射表
解析出私用区码位与d路径之后，就得到了一个关键映射：U+E001对应某条路径，U+E002对应另一条路径。但要还原成真实字符，还需要知道每条路径画出来像什么。一种可行思路是把每条路径渲染成小图片，然后用OCR识别。R中可以用magick包把SVG路径转换成图像，再调用tesseract包进行OCR。为了避免OCR识别出无关字符，可以设置白名单，只允许它输出字母和数字等候选字符。
library(magick)
library(tesseract)
# 将私用区字形渲染为图片并OCR识别
render_and_ocr <- function(d_path, size = 64) {
svg_text <- sprintf(
'<svg xmlns="http://www.w3.org/2000/svg" width="%d" height="%d"><path d="%s" transform="translate(8,56) scale(0.08)"/></svg>',
size, size, d_path
)
img <- image_read_svg(svg_text) %>%
image_convert(format = "png", colorspace = "gray")
eng <- tesseract(options = list(tessedit_char_whitelist = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"))
ocr_text <- ocr(img, engine = eng)
return(trimws(ocr_text))
}
# 示例：对第一条私用区路径进行识别
recognized <- render_and_ocr(private_glyphs$d[1])
print(recognized)
这段代码中，sprintf会把d路径嵌入到一个完整的SVG字符串里。由于SVG标签必须写在字符串中，所以在R代码里需要把<svg>、<path>这些标签字符转义为<svg>和<path>，否则R语言本身会把它们当作比较运算符处理。image_read_svg可以把SVG文本渲染成位图，再用image_convert转换成灰度PNG，这样OCR识别时干扰更少。tesseract的白名单设置为字母和数字，能有效减少把字体轮廓识别成标点或空格的错误。不过OCR对单字符的识别精度并不总是稳定，尤其是当字形带有装饰性笔画、旋转或极窄字重时，很容易认错。
因此，如果OCR准确率不够，可以采用模板匹配的方式。先人工确认一部分私用区字符对应的真实字符，比如从页面中已知的固定文本推断出U+E001是A、U+E002是B，然后把这些已知字符渲染成标准字体的图像，再与SVG字体渲染出的图像计算像素相似度。R中可以用magick的image_compare或者自己把图像转成矩阵后计算余弦相似度。模板匹配虽然需要一些前期人工标注，但一旦建立了一批基础模板，后续就可以自动化扩展，尤其适合同一站点反复抓取的情况。
拿到私用区码位与真实字符的映射表后，就可以对网页文本做还原。还原时要注意文本中私用区字符的编码形式。如果rvest已经将HTML实体解码成了真实的Unicode字符，可以直接用intToUtf8生成对应字符后替换；如果文本还保留着这样的实体字符串，则需要先统一解码。下面是一个简单的替换函数示例。
mapping <- data.frame(
code_point = c(0xE001, 0xE002),
real_char = c("A", "B"),
stringsAsFactors = FALSE
)
restore_text <- function(text, mapping) {
for (i in seq_len(nrow(mapping))) {
private_char <- intToUtf8(mapping$code_point[i])
text <- gsub(private_char, mapping$real_char[i], text, fixed = TRUE)
}
return(text)
}
raw_line <- "BC"
restored_line <- restore_text(raw_line, mapping)
print(restored_line)
这里raw_line中的是未解码的HTML实体，实际抓取时如果已经被xml2解码，则会变成对应的私用区字符，替换逻辑同样适用。需要注意的是，如果私用区字符在网页中大量出现，逐字符gsub在长文本上可能较慢。此时可以用stringi包进行批量替换，或者先把文本转换为UTF-32码点向量，再一次性映射，效率会高很多。
四、实战中的注意事项与优化建议
实际爬取中，动态字体反爬往往比单个SVG文件复杂。有的站点会同时加载多个字体文件，每个文件负责不同字符集；有的站点每次请求返回的字体文件都会变化，甚至同一个页面中不同部分使用不同映射。因此，在解析字体时不能只下载一次就写死映射表，而应该把字体解析做成一个可复用的函数，每次抓取页面时自动从CSS中提取字体URL，下载对应文件并完成解析。CSS中字体URL可能以相对路径、绝对路径或base64内联形式存在，提取时可以用正则匹配@font-face规则中的src属性。
解析SVG字体时，还要注意XML的命名空间问题。某些服务器返回的SVG字体带有默认命名空间，比如xmlns属性指向http://www.w3.org/2000/svg，如果直接用XPath写//glyph可能匹配不到，必须使用local-name。前面代码已经使用了这种写法，可以避免因为命名空间不同而解析失败。另一个常见问题是码点进制不统一，有些字体用十六进制实体，有些用十进制实体，还有一些直接把Unicode字符写在属性里，解析函数需要兼容这些格式。
从性能角度考虑，OCR识别每个私用区字形是最耗时的环节。如果同一个站点频繁抓取，可以把解析出的字形路径做一次哈希，把路径哈希与识别结果存储到本地RDS文件。下次解析时先对比路径哈希，如果命中缓存就直接使用已有映射，只有新出现的字形才需要OCR或匹配。这样做可以把重复页面的还原时间从几秒降到几十毫秒。此外，如果字体文件没有变化，整个映射表也可以直接缓存，避免重复下载和解析。
最后，虽然本文聚焦SVG字体，但类似的思路同样可以扩展到WOFF、TTF等格式。只是这些二进制字体需要借助fonttools或系统字体库来解析，R中可以通过reticulate调用Python的fontTools来完成。SVG字体因为结构透明、文本可读，在R环境下的处理成本最低，也最适合作为动态字体反爬的入门案例。掌握解析与映射的完整流程后，再遇到复杂格式的字体反爬，就能根据同样思路选择合适工具还原文字。