R 中的 Base64 解码：完整指南

一条字符串落进了你的 R 会话。它看起来像一碗洗得乱七八糟的字母汤：字母、数字，偶尔冒出一个加号或斜杠，尾巴上还挂着一对等号。发它给你的人信誓旦旦地说，它曾经是一句再普通不过的话、一张 JPEG，或是一份 JSON 文档。这条字符串就是 Base64，而这一页就是把它变回原样的配方。

先来快速温习一下，因为本站首页已经把这种格式讲得面面俱到：Base64 把三个输入字节写成从 64 符号字母表中挑出的四个字符，末尾一个或两个 = 字符标记着真实数据在哪里结束。正是这种四换三的交换，让编码后的文本比原文大约多出三分之一，而解码只是把这笔交换反过来做。记住问题的形状，让我们拆开几个信封吧。

这里有个转折，让 R 和许多其他语言有点不一样：base R 根本没有 Base64。基础包里并没有藏着 base64_decode()，也没有一行就能搞定的内置函数。你得自己带包来。好消息是生态里提供了好几个，各有各的性格，读完这篇文章，你会清楚地知道该伸手拿哪一个、该提防哪一个。

解码器一览

五个包干着重活，它们分成两大阵营：宽松派，对脏输入一耸肩就放行；严格派，把 RFC 当作合同来执行。下面是这套阵容，截至 2026 年：

三个亚军值得一提。jsonlite 包导出自己的助手函数 base64_enc、base64_dec 和 URL 安全的那一对，所以如果你已经在解析 JSON，手里可能已经有一个解码器了。jose 包为 JWT 工作附带了 base64url_decode()。而古老的 RCurl 包还背着一个封装 libcurl 的 base64() 函数：它能用，它面向字符，它给人的感觉是一位忠实的长辈，而不是新代码该用的工具。

把阵容装好

如果机器上还没有 R，你的操作系统会自带：Debian 和 Ubuntu 上是 r-base，Fedora 上是 R，macOS 和 Windows 上是软件包或安装器。然后是这些包，直接从 CRAN 装：

install.packages("base64enc")
install.packages("openssl")
install.packages("b64")
install.packages("base64url")

两条构建提醒，因为安装翻车就翻在这两处。openssl 包会针对你系统的 OpenSSL 编译，所以一台光板 Linux 机器可能要先装上开发头文件：

sudo apt install libssl-dev

b64 包是一个用 extendr 封装的 Rust 引擎，所以从源码构建它需要 Rust 工具链（sudo apt install cargo 会连 rustc 一起拉进来）。在 Windows 和 macOS 上，你从 CRAN 拿到的是预编译二进制，以上这些都不适用。如果你更喜欢用包管理器，pak::pkg("base64enc") 或 remotes::install_cran("b64") 能干同样的活，而且对仓库的执念更少。

你的第一次解码：三行仪式

解码生涯的百分之九十，都装得进三行。这是标准的冒烟测试，用那个著名的 TWFu 字符串：

library(base64enc)
packed <- "TWFu"
bytes <- base64decode(packed)
bytes
#> [1] 4d 61 6e
rawToChar(bytes)
#> [1] "Man"

那场小小的仪式里，有三件事值得留意。第一，base64decode() 交给你的永远是一个原始向量，绝不是字符串。这是设计特性，不是意外：Base64 能装一句话、一张 JPEG，或一张证书，在你搞清楚手里是什么之前，它们都不该被区别对待。第二，从字节跳回文本是另一个独立的、有意的步骤，要经过 rawToChar()，而字符集的决策就住在那一步里（后面细说）。第三，TWFu 解码出来是单词 "Man"：三个字母，零剧情。把这个字符串揣在口袋里。如果一段解码代码能把 TWFu 变成 Man，那这台机器就是诚实的。

因为你总归有一天要解码自己编码过的东西，这是证明两个方向互相吻合的完整往返：

text <- "Hello, world!"
packed <- base64encode(charToRaw(text))
packed
#> [1] "SGVsbG8sIHdvcmxkIQ=="
identical(text, rawToChar(base64decode(packed)))
#> [1] TRUE

原始向量的边界

R 靠两个小函数跨越字节与文本的边界，一旦认识了它们，这篇文章的其余部分看起来就会理所当然。charToRaw() 把字符串变成它的字节，rawToChar() 做相反的事，两者之间摆着整套 raw 工具箱：length() 用来数字节，head() 用来偷看一眼，writeBin() 和 readBin() 负责把字节搬进文件和搬出文件。本文里的每一个解码器都故意停在那条边界上。

bytes <- base64decode("SGVsbG8s")
length(bytes)
#> [1] 6
head(bytes)
#> [1] 48 65 6c 6c 6f 2c
rawToChar(bytes)
#> [1] "Hello,"

所以当你看到 [1] 48 这样的结果，把它读作"一个字节，值 72，字母 H"，然后停在那儿，直到你弄清这些字节穿的是哪个字符集。这一停顿，就是解码的全部纪律。

脏输入：解码器们如何各执一词

这一节会在凌晨两点救你一命，因为解码器们对"输入有点脏时会发生什么"各有各的说法。现实世界的 Base64 经常带着内部空格、被紧张的复制粘贴弄丢的填充、被剪贴板吞掉后残留的杂字符，或者尾巴上拖着一堆垃圾。面对同一批"惯犯"，每个解码器这样作答：

把那张表读两遍，因为它装下了整个故事。默认的 base64decode() 是一位和善的海关官员：它跳过字母表之外的字符，容忍缺失的填充，忽略尾部内容，所以邮件形状和剪贴板形状的字符串都能直接过关。strict = TRUE 模式在漫长的沉默之后，随着 2026 年 2 月的 0.1-5 版本姗姗来迟，它是一位法医鉴定师：它校验整个字符串，点出违规者的确切位置，拒绝一切不像教科书的内容。b64 默认严格，从不只成功一半。而 openssl 坐在尴尬的中间地带：它乐意跳过空白，面对缺失的填充也会正确地报错，但一旦遇到真正非法的字符或尾部垃圾，它就返回一个空的原始向量，并且什么都不说。这个沉默的空白结果，是整篇文章里最危险的行为，所以让我们看着它发生：

dirty <- "SGVsbG8s!IHdvcmxkIQ=="
openssl::base64_decode(dirty)
#> raw(0)   # 空的。没有错误。没有警告。没有任何提示。

如果你针对 openssl 写代码，先检查拿到结果的长度，再决定信不信。这是个小习惯，却能避免一整类"我的数据去哪了"的神秘事件。

对严格派这边，这是 base64enc 展现精确一面的样子，附带你在自己控制台里会看到的原样错误信息：

base64enc::base64decode("TWF u", strict = TRUE)
#> v=30000, pad=0, org='u'
#> Error: Invalid character (' ') at position 4 in base64 string (not allowed in strict mode)
base64enc::base64decode("TWF", strict = TRUE)
#> v=10000, pad=3, org=''
#> Error: Missing padding (1 characters) at the end of the base64 string (not allowed in strict mode)
base64enc::base64decode("TWF=xx", strict = TRUE)
#> v=20000, pad=0, org='xx'
#> Error: Trailing content 'xx' after padding at position 4 in base64 string (not allowed in strict mode)

有一个怪癖要有心理准备：每一次严格模式的调用，无论成功还是失败，都会往控制台嘟囔一行 C 层面的状态信息，类似 v=30000, pad=0, org='u'。它是编译后的代码直接写出来的，不是 R 警告，所以 suppressWarnings() 对它无能为力。它无害，但如果你用测试去比对控制台输出，现在你知道为什么多出一行了。

R 的脾气：NA、向量和静默拼接

Base64 有自己的怪癖，R 再添上自己的。第一个从 NA 这里咬人。当你把 NA_character_ 传给解码器时，R 会悄悄地把它强制转换成字符串 "NA"，然后解码器才见到它，而 "NA" 是一个完全合法的 Base64 分组。结果既不是错误，也不是空向量。它是字节 0x34，字母 "4"：

base64decode(NA_character_)
#> [1] 34
rawToChar(base64decode(NA_character_))
#> [1] "4"

所以一列缺失值不会解码成一列缺失值。它会解码成一列字母 4，而你的下游代码会开开心心地继续处理。如果输入里可能含有 NA，先过滤掉：

values <- c("TWFu", NA_character_, "TQ==")
clean <- values[!is.na(values)]
out <- vapply(clean, function(x) rawToChar(base64decode(x)), character(1))
unname(out)
#> [1] "Man" "M"

第二个怪癖是向量输入，而解码器们在这里拐了完全不同的弯。base64decode() 把一个字符向量当作同一个字符串的几段来拼接，所以两个元素会合并成一个原始向量返回。openssl::base64_decode() 连那一步都走不到：它先把参数压缩成一团，然后撞上一个两元素的逻辑判断，产出了 R 里最诚实的错误信息之一。而 b64::decode() 是唯一真正向量化的，每个输入返回一个解码后的数据块：

base64decode(c("TWFu", "TQ=="))
#> [1] 4d 61 6e 4d
openssl::base64_decode(c("TWFu", "TQ=="))
#> Error in if (is.na(text)) : the condition has length > 1
out <- b64::decode(c("TWFu", "TQ=="))
rawToChar(out[[1]])
#> [1] "Man"
rawToChar(out[[2]])
#> [1] "M"

记住这一点：要么有意识地写循环，要么有意识地向量化，并且永远不要假设输入的向量会换来输出的向量。

URL 安全字母表

标准 Base64 把字母表的最后两个位置给了 + 和 /，而这两个字符正是 URL 不喜欢的。加号变成 %2B，斜杠变成 %2F，填充变成 %3D，于是本该随处粘贴的令牌开始披上百分号。URL 安全变体（RFC 4648 第 5 节定义）把这两个字符换成 - 和 _，通常还会把填充也丢掉。R 有三扇门通向那个世界。

第一扇门是 b64 的引擎。所谓引擎，就是一套配置好的字母表加填充策略，这个包自带的四个正是你需要的：

library(b64)
std <- encode(as.raw(c(0xfb, 0xef, 0xbe)))
std
#> [1] "++++"
url <- encode(as.raw(c(0xfb, 0xef, 0xbe)), engine("url_safe"))
url
#> [1] "----"
decoded <- decode(url, engine("url_safe"))[[1]]
toString(decoded)
#> [1] "fb, ef, be"

四个引擎分别是 "standard"（默认）、"standard_no_pad"、"url_safe" 和 "url_safe_no_pad"，同一个引擎对象两个方向都能用，这让你的代码保持对称。它们对自己的字母表也很严格：把 "----" 喂给标准引擎，它会回答 "Invalid byte 45, offset 0."，这让人松了口气。

第二扇门是专门的 base64url 包，小而单一用途：URL 安全字母表，永远不填充。一个注意点：它的解码器很宽容，会心甘情愿地解码一个损坏字符串里有效的前缀，然后停下，一声不吭。如果 URL 安全的值来自不可信的来源，优先用 b64。

base64url::base64_urlencode("hello world")
#> [1] "aGVsbG8gd29ybGQ"
base64url::base64_urldecode("aGVsbG8g!!!")
#> [1] "hello "   # 其余部分被悄悄丢弃了

第三扇门是 jose，它为 JWT 工作导出 base64url_encode() 和 base64url_decode()，并且按你期望的那样返回原始向量。

而当你只是偶尔需要一次性的操作，又想留在 base64enc 里时，字符串手术加一点填充修补就够了：

url <- "----"
fixed <- gsub("_", "/", gsub("-", "+", url), fixed = TRUE)
padded <- switch(as.character(nchar(fixed) %% 4L),
  "0" = fixed,
  "2" = paste0(fixed, "=="),
  "3" = paste0(fixed, "="))
rawToChar(base64decode(padded))
#> [1] "\xfb\xef\xbe"

JWT：偷看与信任

大多数人第一次见到 URL 安全 Base64，是因为 JSON Web Token。JWT 是三段用点号连起来的 base64url：一段描述签名方式的头、一段装声明（claims）的负载，还有一段让整个东西值得信任的签名。在 R 里解码前两段，五行就够。注意 strsplit() 里的 fixed = TRUE：点号是正则通配符，少了这个标志，R 会开开心心地把你的令牌拆成单个字符，这是野外 R 代码里最常见的 Base64 bug。

jwt <- jose::jwt_encode_hmac(jose::jwt_claim(sub = "1234567890", iat = 1516239022, name = "John Doe"), "0123456789abcdef")
parts <- strsplit(jwt, ".", fixed = TRUE)[[1]]
header <- base64url::base64_urldecode(parts[1])
header
#> [1] "{\"typ\":\"JWT\",\"alg\":\"HS256\"}"
payload <- jsonlite::fromJSON(base64url::base64_urldecode(parts[2]))
payload$name
#> [1] "John Doe"

两条诚实的免责声明。第一，解码 JWT 只是偷看，不是信任：第三部分是签名，只有拿发行方的密钥去校验时，它才有意义。这件事 jose 包全家都管。它的 2.0 版本（2026 年 4 月）新增了 ED25519 支持，并让 typ 头变为可选；展示 1.x jwk_read()/jwk_write() 助手（或其 read_jwk()/write_jwk() 别名）的旧教程依然有效，因为 2.0 仍然附带那些同样的 JWK 读写助手：

library(jose)
claims <- jwt_decode_hmac(jwt, "0123456789abcdef")
claims$name
#> [1] "John Doe"
claims$sub
#> [1] "1234567890"
sp <- jwt_split(jwt)
sp$header
#> $alg
#> [1] "HS256"
#>
#> $typ
#> [1] "JWT"
sp$payload$name
#> [1] "John Doe"

jwt_decode_hmac() 会校验签名，同时强制执行 exp 和 nbf 声明，令牌过期就抛错。第二，base64url::base64_urldecode() 及其同族解码头和负载都没问题，但签名部分是二进制的，所以要用返回 raw 的函数来解码它（比如用 "url_safe_no_pad" 引擎的 b64::decode()），而不是解成字符串。

字符集：那些字节是什么文本？

本文里的每一个解码器都故意停在原始向量的边界上，因为"那到底是什么文本"的答案，取决于这些字节被打包时用的字符集。先说好消息：如果发送方用的是 UTF-8 - 现代网络的大多数都是 - 你的日子又短又愉快。base64enc 甚至自带一道关卡：

packed <- base64encode(charToRaw("caf\u00e9"))
bytes <- base64decode(packed)
checkUTF8(bytes, quiet = TRUE)
#> [1] TRUE
rawToChar(bytes)
#> [1] "café"

checkUTF8() 会问"这些字节能按 UTF-8 读吗？"，但不会当场下结论。加上 quiet = TRUE，它返回 TRUE 或 FALSE；默认情况下它更直接，遇到无效字节就抛错，并点名违规者，例如 INVALID byte 0xff at 0x0 (0, line 1): invalid start byte (FE/FF)。对含有 NUL 字节的字符串，它也报 FALSE，因为 NUL 字节永远不可能是合法 UTF-8 R 字符串的一部分。把它当关卡用，剩下的水到渠成。

这里就是关卡重要的原因。在 UTF-8 locale 下，字节不是合法 UTF-8 时，rawToChar() 不会抛错。它交给你一个 R 标记为 Encoding() == "unknown" 的字符串，而根据 locale 和 R 构建版本的不同，同样的调用也可能以 "invalid multibyte sequence" 错误告终，这至少还算诚实。无论如何，对来路不明的字节不加防护地调用 rawToChar()，就是乱码的出生方式：

broken <- as.raw(c(0xc3, 0x28))   # 一个被截断的 UTF-8 字节对
checkUTF8(broken, quiet = TRUE)
#> [1] FALSE
rawToChar(broken)                  # 没有报错。问题就在这里。
#> [1] "\xc3("

而当发送方用的完全是别的东西，Latin-1、Windows-1252 或 Shift-JIS，配方就是先解码到 raw，再用 iconv() 转码，它认得那些有名字的字符集：

latin1_bytes <- as.raw(c(0x63, 0x61, 0x66, 0xe9))   # Latin-1 里的 "café"
iconv(rawToChar(latin1_bytes), from = "latin1", to = "UTF-8")
#> [1] "café"

表情符号值得一谈，因为 R 在这里有故事。现代 R 把 U+FFFF 以上的码位 - 表情符号就住在那里 - 存成真正的 UTF-8，所以往返是可行的，字节数也和每种语言预期的对上。老版本的 R 把同样的字符存成代理对，这种方案常被称为 CESU-8，所以一个表情符号过界时是六个字节的非法 UTF-8。如果你接手的老 R 代码里，表情符号在传输中碎掉了，首要嫌疑人就是它：检查 nchar(x, type = "bytes")，和发送方语言会产生的值对比一下。

emoji <- "\U0001F600"
nchar(emoji, type = "bytes")
#> [1] 4
round_trip <- base64decode(base64encode(charToRaw(emoji)))
identical(emoji, rawToChar(round_trip))
#> [1] TRUE

经验法则：假定 UTF-8，用 checkUTF8() 验证，只有确知另一种字符集时才动用 iconv()。永远不要猜。

文件：从包裹的文本到真实字节

字符串好办；文件才是 Base64 挣回工钱的地方。先用一套任何包都能跑的流水线：读入编码文本、解码、写出字节。

cat("SGVsbG8sIHdvcmxkIQ==", file = "hello.b64")
bytes <- base64decode(paste(readLines("hello.b64"), collapse = ""))
writeBin(bytes, "hello.txt")
readLines("hello.txt")
#> [1] "Hello, world!"

然后是便捷层。base64enc 能替你读写：file 参数指向装着 Base64 文本的文件，output 指向解码后的字节该落脚的地方。返回值是写入的字节数，一个美滋滋的免费健全性检查：

n <- base64decode(file = "hello.b64", output = "hello.txt")
n
#> [1] 13
readLines("hello.txt")
#> [1] "Hello, world!"

被折行的输入 - 那种扛过邮件或 PEM 铠甲的 - 对宽松解码器不成问题：只要剩下的东西是合法 Base64，换行落在哪里它们都直接看穿。MIME 按每行 76 字符折行，行间用 CRLF；PEM 块按 64 字符折行。严格引擎当然一口回绝折行。

wrapped <- paste0("VGhlIHF1aWNrIGJ", "\r\n",
  "yb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZw==")
rawToChar(base64decode(wrapped))
#> [1] "The quick brown fox jumps over the lazy dog"
rawToChar(openssl::base64_decode(wrapped))
#> [1] "The quick brown fox jumps over the lazy dog"
b64::decode(wrapped)
#> Error: Invalid byte 13, offset 15.

b64 包有一对文件函数，名字最清楚，而且它快如 Rust，文件大的时候就该伸手拿它。不过有一处锋利的边缘：decode_file() 逐字节地读文件，毫不留情。一个尾部换行 - writeLines() 会加、而 cat() 从不加的那种 - 会让 Rust 引擎 panic，冒出来变成形如 User function panicked: decode_file_ 的可捕获错误。用 cat() 或 writeBin(charToRaw(enc), path) 写编码文本，这条边缘就保持钝的。

writeBin(charToRaw("file payload bytes"), "payload.bin")
enc <- b64::encode_file("payload.bin")
cat(enc, file = "payload.b64")
bytes <- b64::decode_file("payload.b64")
rawToChar(bytes)
#> [1] "file payload bytes"

base64 包是第三条进路：纯粹面向文件，一对相匹配的函数：

base64::encode("payload.bin", "payload.b64")
base64::decode("payload.b64", "payload.out")
readLines("payload.out")
#> [1] "file payload bytes"

实践中还会遇到另一种文件形状：数据框里一整列编码数据块，在 API 导出的数据里非常常见。几百行的话，一个简简单单的向量化调用就够了：

df <- data.frame(content = c(b64::encode("alpha"), b64::encode("beta"),
  b64::encode("gamma")))
decoded <- b64::decode(df$content)
df$decoded <- vapply(decoded, function(x) rawToChar(x), character(1))
df$decoded
#> [1] "alpha" "beta"  "gamma"

API 与 Web 响应

JSON API 喜欢把二进制塞进文本里，而 Base64 是它们最钟爱的行李箱。R 里的套路每次都一样：取回、解析、解码，然后决定这些字节是什么。现代的 HTTP 客户端是 httr2，JSON 那边是 jsonlite：

library(httr2)
library(jsonlite)
res <- req_perform(request("https://httpbin.org/get?attachment=TWFuIGlzIGhlcmU%3D&name=man.txt"))
data <- fromJSON(rawToChar(res$body))
bytes <- base64decode(data$args$attachment)
writeBin(bytes, data$args$name)
length(bytes)
#> [1] 11

三句上路前的提醒。请求构造函数叫 request()，从 httr2 第一次发布起就是这个名字。响应体以原始向量形式到达，所以先 rawToChar()，再把它当 JSON 解析。API 可能说的是方言：在喂给期望教科书版本的解码器之前，先查清它的 Base64 是不是 URL 安全的，或者是不是剥掉了填充。有些 API 甚至双重编码，Base64 里套 Base64，一次解码得到的是更多 Base64 而不是预期的字节，那时你就认出它了。

Data URI 与自包含文档

data: URI 方案（RFC 2397）让文档可以携带自己的内容：一个 MIME 类型、负载被编码时加上 "base64" 这个词，再加上负载本身。你在爬取的 HTML 里会不断遇到它们，解码一个就是两步字符串操作，再跟一次普通解码：

img_tag <- "<img src=\"data:image/png;base64,iVBORw0KGgoAAA\" />"
uri <- regmatches(img_tag, regexec("src=\"([^\"]*)\"", img_tag))[[1]][2]
uri
#> [1] "data:image/png;base64,iVBORw0KGgoAAA"
payload <- sub("^data:[^,]*,", "", uri)
bytes <- base64decode(payload)
length(bytes)
#> [1] 10

同样的形状也出现在 CSS、PDF 注释和自包含的 R Markdown 报告里，那里一张图被压扁成一个 <img> 标签，让 HTML 不带任何附属文件就能出行。如果你在渲染这类文档并想提取嵌入的图片，技巧全部在这里：找到 data: 字符串，在第一个逗号处切开，解码。

数据库、邮件与配置

每当有人想把二进制塞进文本列，Base64 就会出现在数据库里，而解码端就是一列字符串变回字节。这是通过 DBI 和 RSQLite 对 SQLite 的往返：存入编码值，查询回来，解码，字节就到手了：

library(DBI)
library(RSQLite)
db <- dbConnect(SQLite(), ":memory:")
dbExecute(db, "CREATE TABLE files (name TEXT, payload TEXT)")
stored <- base64encode(charToRaw("stored in a database"))
dbExecute(db, paste0("INSERT INTO files VALUES ('note.txt', '", stored, "')"))
row <- dbGetQuery(db, "SELECT * FROM files")
rawToChar(base64decode(row$payload))
#> [1] "stored in a database"

SQLite 也能原生地把二进制存成 BLOB，那就完全不需要 Base64，该列回到 R 时是一个原始向量，例如 class(dbGetQuery(db, "SELECT payload FROM blobs")$payload[[1]]) == "raw"。把 Base64 装进 TEXT 的变体存在的理由是可移植性：你能用文本编辑器查看它，每种语言都不需要二进制驱动就能读它。

邮件是折行 Base64 的老家。MIME 部分按每行 76 字符折行，行间用 CRLF，你读过的任何邮件系统都这样携带附件。R 没有一等公民级的邮件客户端，但当你确实收到一个 .eml 文件时，附件的 base64 部分就是折行文本：宽松解码器会在解码的同时替你拆行。mime 包能帮你辨认手里拿的是什么：

mime::guess_type("photo.jpg")
#> [1] "image/jpeg"
part <- "SGVsbG8s\r\nCnRoaXMgaXMgYW4g\r\nZW1haWwgYXR0YWNobWVudA=="
rawToChar(base64decode(part))
#> [1] "Hello,\nthis is an email attachment"

配置文件给这趟巡游画上句号。当证书或数据块以 Base64 编码的形式存在 YAML 或 JSON 配置里，或存在环境变量里，R 把它当普通字符串读入，你随需解码：

config_line <- "api_cert: TFRTU0VDUkVU"
cert_b64 <- sub("^api_cert: ", "", config_line)
raws <- base64decode(cert_b64)
rawToChar(raws)
#> [1] "LTSSECRET"

大负载

R 字符串有 2^31 - 1 字节的硬上限，足够大的 Base64 字符串会撞上它，因为编码形式比原文大约大三分之一。base64enc 包从 2022 年的版本起就处理了这一点：给 base64encode() 一个行宽，它返回的是一行行的向量，而不是一根巨大的字符串；解码端，file = 参数按行读文件并解码，不逼你把一个巨型字符串抱在变量里。

对几百 MB 的文件，实用的模式是按对齐的块来读。Base64 分组彼此独立，所以任何长度是 4 的字符倍数的块都能单独解码；你只需要一个小缓冲来兜住参差不齐的尾巴：

chunk <- 65536L
con <- file("huge.b64", "rb")
on.exit(close(con))
leftover <- ""
out <- raw(0)
while (TRUE) {
  piece <- readChar(con, chunk, useBytes = TRUE)
  if (length(piece) == 0) break
  piece <- gsub("[\r\n]", "", piece)
  ready <- paste0(leftover, piece)
  take <- floor(nchar(ready) / 4) * 4
  if (take > 0) {
    out <- c(out, base64decode(substr(ready, 1, take)))
    leftover <- substr(ready, take + 1, nchar(ready))
  } else {
    leftover <- ready
  }
}
if (nchar(leftover) > 0) out <- c(out, base64decode(leftover))
length(out)

b64 包是这个地界的速度冠军：它的 Rust 引擎解码 50 MB 的文件只花一秒钟的一小部分，它的向量化 decode() 一次调用就能处理一整列编码值，这和逐行循环差距悬殊。如果你有很多字符串，自己跑一个快速的 system.time() 对比；逐行循环和一次向量化调用之间的差距，通常大到足以影响性能。

命令行

不是什么都需要完整的 R 会话。经典 Unix 工具天生会说 Base64，R 可以把活交给它们，也可以从它们那里取活。在 Linux 上，base64 -d 做解码（macOS 和其他 BSD 系统用 -D）：

echo "SGVsbG8sIHdvcmxkIQ==" | base64 -d
#> Hello, world!

一行 Rscript 也能用你脚本里同样的包干同样的活：

Rscript -e 'library(base64enc); writeLines(rawToChar(base64decode("TWFu")))'
#> Man

快速检查和管道交给 shell；结果需要住进数据框、文件或报告时，用 R。一句提醒：命令行参数有大小上限（ARG_MAX），所以别把几 MB 的字符串粘进终端。改用文件管道传过去。

值得知道的坑

这是份简短清单，列出它咬 R 开发者的方式，全部是这个生态的原生问题，而不是 Base64 本身的问题：

• openssl 会沉默地失败。遇到字母表之外的字符或尾部垃圾时，base64_decode() 返回一个空的原始向量，没有错误，没有警告。相信你之前，永远先检查结果的 length()。
• NA 在解码器眼里不是缺失值。NA_character_ 会被强转成字符串 "NA"，它解码成字节 0x34。解码前先过滤掉 NA。
• 向量的行为不符合你的预期。base64decode() 把输入拼成一个原始向量；openssl::base64_decode() 遇到多元素输入会死在 the condition has length > 1 上；只有 b64::decode() 是真正向量化的。
• rawToChar 是静默的破坏者。无效 UTF-8 字节在 UTF-8 locale 下不会抛错；它们变成被标记为 "unknown" 的字符串。先用 checkUTF8() 把关。
• JWT 里的点是正则通配符。不带 fixed = TRUE 的 strsplit(jwt, ".") 会在每个字符处拆分。这是 R 代码里最常见的 Base64 bug。
• b64 的文件处理不留情面。编码文件里一个尾部换行会让 b64::decode_file() panic。用 cat() 写，别用 writeLines()。
• 宽容不足以用于信任。base64decode() 的默认模式会跳过任何位置的坏字符，所以损坏的字符串可能解码出一堆看起来很合理的垃圾，而没有错误。在信任边界上用 strict = TRUE。
• b64 的错误信息说的是 Rust。当你传给它一种它不想要的类型时，预期会看到 Both cases of Either errored 这样的句子。这句话故意不实用；那是 Rust 类型系统在耸肩。

最佳实践

• 日常工作的默认选项是 base64enc::base64decode()，凡输入跨越信任边界的地方都打开 strict = TRUE：不可信的 API、用户上传、任何签过名的东西。
• 需要速度、真正的向量化，或 URL 安全和无填充引擎时，伸手拿 b64，并接受它天生严格。
• 如果 openssl 已经在你的项目里，就用它，但在检查长度之前，把每个结果都当嫌疑犯。
• 有意识地决定字符集：假定 UTF-8，用 checkUTF8() 验证，只有发送方明确告知另一种字符集时才用 iconv()。
• 对 JWT，用 strsplit() 加 fixed = TRUE 偷看，但只有在 jose 验证过签名之后才信任。
• 把 TWFu 留在你的测试里：它是你写的任何解码路径的三字节冒烟测试。
• 记住 Base64 不是什么：它不是加密，也不是压缩。它是打包胶带，任何拿到这篇文章的人都能把它做的一切反过来。尽管解码，有选择地信任。

R 中 Base64 的简史

这个格式很老。1987 年它为隐私增强邮件（Privacy-Enhanced Mail）协议标准化（RFC 989），1993 年被 MIME 采用（RFC 1521，之后是 1996 年定稿的 RFC 2045），2003 年在 RFC 3548 里被整理过，2006 年 RFC 4648 赋予它现代形态，包括 URL 安全字母表。R 的故事要短得多，也快得多。base64enc 包由 Simon Urbanek 编写，2012 年 9 月首次登上 CRAN，从此一直是主力，2015 年新增 checkUTF8()，2022 年支持长向量。2024 年 10 月，老 base64 包被明确地以兼容封装的名义重新发行，它自己的描述如今把新应用引向 base64enc、openssl 或 jsonlite。然后是 2024 年初的 b64（当前版本 0.1.7，2025 年 7 月），一个用 extendr 构建的 Rust 引擎，带来了真正的向量化和一整队字母表。2026 年 2 月，base64enc 发布了盼星星盼月亮的严格模式，2026 年 4 月 jose 包围绕 jwt_* 函数重新设计了自己。别的语言一个库就交付的东西，这里花了十年，但结果是一个工具箱，每个解码器都有清楚的职责和清楚的个性。

趣味事实

因为一本完整的指南应该以微笑收尾：

• base64decode(NA_character_) 返回字母 "4"，因为 NA_character_ 以字符串 "NA" 的身份抵达解码器，而 "NA" 是一个合法的 Base64 分组。这门语言里最 R 专属的一字节惊喜。
• 给 openssl::base64_decode() 喂一个带单个非法字符的字符串，它返回 raw(0)，全程一片死寂。生态里最危险的安静。
• 每一次对 base64decode() 的严格调用，都会嘟囔一行 C 层面的状态信息，像 v=30000, pad=0, org='u'。那不是警告。那是 C 代码在清嗓子。
• b64 能解码你从未见过的字母表：BinHex、IMAP 修改版 UTF-7，还有 bcrypt 和 crypt 的自定义字母表。R 可以用同一个引擎读 1980 年代的 Macintosh 附件，也能读现代密码哈希。
• R 字符串在 2^31 - 1 字节处止步，所以 base64enc 学会了为长输入返回一行行的向量。格式撞上了语言的墙，包就长出了一架梯子。
• 单词 "base64" 编码后是 YmFzZTY0。一个能描述自己本身的格式，相当于技术界一面会说莫尔斯电码的镜子。
• 一个 NUL 字节仍然要花四个字符："AA=="。在 Base64 里，无总是有。
• 你的 R 构建有个昵称。R 4.5.0 叫 "How About a Twenty-Six"，因为 R 的版本名取自花生漫画（Peanuts）和电影，而它们借名的漫画条比它们命名的发布早了几十年。连你正在用来解码的这个版本，都有幽默感。

总结

按你交什么样的朋友来挑解码器：日常工作用 base64enc，在边界上打开 strict = TRUE；openssl 如果已经在你的项目里，前提是你会检查结果；想要速度、向量和 URL 安全引擎时用 b64；文件杂活和 URL 安全字符串交给小专家 base64 和 base64url。在把字节称为文本之前，先用 checkUTF8() 守住它们；当确知字符集是别的东西时，用 iconv()；记住中间的原始向量是个特性：它逼你自己决定字节意味着什么，而不是让某个库去猜。解码一切，只信任能验证的东西。而当你需要朝反方向走时 - 不是拆开一个字符串，而是把自己的字节打包成字符串上路 - 姊妹篇会详细讲解 R 中的 Base64 编码。

最后更新： 2026-09-08

相关文章： R 中的 Base64 编码：完整指南