R - c()意外地将命名向量的名称转换为UTF-8.这是一个错误吗？

Question

c()在Windows上使用非美国英语语言环境时,我遇到了R 3.3.2 的奇怪行为.它将命名向量的名称转换为UTF-8.

x <- "?"
names(x) <- "?"

Encoding(names(x))
#> [1] "unknown"

Encoding(names(c(x)))
#> [1] "UTF-8"

认为这个问题对大多数人来说没有问题,对于那些使用命名向量作为查找表的人来说这是至关重要的(例如:http://adv-r.had.co.nz/Subsetting.html#applications).我也是那个坚持dplyr的select()函数行为的人.

我不太确定这种行为是错误还是设计.我应该向R核心提交错误报告吗？

这是关于我的R环境的信息:

sessionInfo()
#> R version 3.3.2 (2016-10-31)
#> Platform: x86_64-w64-mingw32/x64 (64-bit)
#> Running under: Windows >= 8 x64 (build 9200)
#> 
#> locale:
#> [1] LC_COLLATE=Japanese_Japan.932  LC_CTYPE=Japanese_Japan.932    LC_MONETARY=Japanese_Japan.932
#> [4] LC_NUMERIC=C                   LC_TIME=Japanese_Japan.932    
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> loaded via a namespace (and not attached):
#> [1] tools_3.3.2

Answer 1

您应该仍然可以names(c(x)) == names(x)在您的系统上看到。编码更改c()可能是无意的，但在大多数情况下不应影响您的代码。

在没有 UTF-8 区域设置的 Windows 上，最安全的选择是首先通过将所有enc2utf8()字符串转换为 UTF-8 ，然后保留为 UTF-8。这也将实现安全查找。

语言符号（如 dplyr 中使用的group_by()）是一个完全不同的问题。由于某种原因，它们总是以本机编码进行解释。（尝试一下as.name(names(c(x)))。）但是，最好还是将它们采用 UTF-8 格式，并在调用之前转换为本机as.name()。这就是 dplyr 应该做的事情，我们只是还没有完全做到这一点。

我的建议是在 Windows 上使用 dplyr 时使用纯 ASCII 字符作为列名称。如果您依赖tidyr::spread()非 ASCII 列内容，这需要一些纪律。您还可以考虑切换到原生支持 UTF-8 的系统（OS X 或 Linux）。