这次参加R会议的talk还挺有收获，一是吐槽了下字符编码(Encoding)的各种恶心事，二是勾起了我学习下Python的兴趣。

最近几日都在鼓捣Python，的确有很多好用的地方，目前粗略地总结了下：

  1. 语言自身工程性强：语言自带的基础类型（如dict、set和tuple）更丰富，偏软件工程的标准库也更丰富得多，对于工程支持是原生的
  2. 用户基数大：带来更多大厂的支持，如大量机器学习的库、详实的文档还有更多的“同行”
  3. 原生Unicode字符：爱了爱了

当然R也有很多自己的优点，比如对于数据框的支持、作图、meta programming、更为方便的帮助系统等，以后我再熟悉些了，写个总结吧。语言这东西真就像小马过河，只有自己试了才知道。

~偏题了

本来是冲着好奇，想去了解下为什么Python3和Python2如此地泾渭分明，而不是循序渐进的过渡。《Why Python3 exists》这篇文章着实让我有些惊讶，原来Python3和Python2无法缓慢过渡的最重要的原因之一，就是因为Python2里面的字符串存在多种选择，str, bytes和unicode，导致了无数的bug和问题。

文章也提到，虽然Python2.0提供了unicode的类型，但是开发者可能因为“没注意”“懒”“要追求极致计算效率”等各种原因不去使用它，进而导致无止境的复杂…

这不就和我之前遇到的经历一样吗？ 哈哈。幸运的是，随着R4.2.0对于Win10原生UTF-8的支持，也许R的世界里能有朝一日看到这只奇异生物的灭绝。

win10中文系统，之前r升级到4.2 后，就发现用data.table的fread读取csv中文乱码，搜了一圈发现没有解决方案，就先苟回4.1.3了 （捂脸）

    darkknight 嗯，R4.2.0改成了UTF8默认编码，而data.table::fread()不支持重编码…如果不考虑效率倒是可以自己按下面转一下…

    方法1，效率高点

    reencode_dt = function(dt, dt_enc = "CP936") {
  reencode = \(v) iconv(v, dt_enc, "UTF-8")
  data.table::setnames(dt, reencode)
  cols = names(dt)[dt |> vapply(is.character, FUN.VALUE = logical(1L))]
  if (length(cols)) {
    dt[, c(cols) := lapply(.SD, reencode), .SDcols = c(cols)] 
  }
  invisible(dt[])
}
x = r"{your file path}" |> data.table::fread() |> reencode_dt()
x

    方法2，低效点，但简单

    r"{your-csv-path}" |> 
  readLines(encoding = "CP936") |> 
  iconv("CP936", "UTF-8") |> 
  data.table::fread(text = _)