Question

我在Windows上使用非美国英语语言环境遇到了c()与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）。我也是坚持the behavior of dplyr's select() function的人。

我不太确定这种行为是错误还是设计错误。我应该向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。这也将启用安全查找。

Language symbols（在dplyr＆＃39; s group_by()中使用）是一个完全不同的问题。出于某种原因，它们始终以本机编码进行解释。（尝试as.name(names(c(x)))。）但是，最好将它们放在UTF-8中，并在调用as.name()之前转换为原生。这就是dplyr应该做的事情，我们还没有到那里去。

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

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

1 个答案: