R、 utf-8字符在slitify中似乎失败了

Question

更新3:我似乎已经通过密切协调设置文件编码参数和使用函数slidify(file.Rmd, encoding="UTF-8")解决了这个问题，上面的链接会有所帮助，因为除了使用install_github('ramnathv/slidify@fix_encode')的slitify之外，还需要包括slitify的fix-encode分支，但它可能很快就会被包含在主集合中。我会把这个放在这里存档。无法说出修复它的确切原因，但问题可能是由于输入文件的编码与脚本文件不同，因为默认编码似乎会导致一些问题。我仍然有点不确定到底发生了什么，但我对slidify的维护者Ramnathv积极参与所有这些讨论感到感激和惊讶。这个修复的故事也在上面的链接中。

我会把这篇文章放在网上只是为了存档，也许其他人最终会遇到和我当时非常相似的情况。

更新2:以前使用slitify编码时出现过问题，其中一些问题已经解决，更多信息请访问以下链接：https://github.com/ramnathv/slidify/issues/377，http://kohske.github.io/ESTRELA/201412/index.html，https://github.com/ramnathv/slidify/issues/373，https://github.com/Koalha/landslide/blob/master/index.Rmd

更新：打开包含utf-8字符的文件时，似乎会出现此问题。在文本中的代码括号中写入r "õ,ä,ü"似乎很好，但当打开一个包含utf-8字符的变量的文件时，会导致脚本出现问题。使用knitr编译到html5时不会出现这些问题。有人知道两者之间的区别吗？

key <- read.csv("key1.csv", header = TRUE, sep = ";", 
        quote = """, dec = ".", fill = TRUE, comment.char = "")
print(key)

添加和编码参数或fileEncoding似乎没有帮助，html编织器似乎不需要它

编辑：仍然没有解决，但我可能更接近这种情况的原因。事实证明，虽然Rmd本身被保存为UTF-8，但许多使用的数据集在存储中仍然恢复为ANSI。可能是混合文件类型的问题。在最好的情况下，slidify(file.Rmd, encoding="UTF-8")似乎用正确编码的字符编译了.md，但在数据处理过程中，由于编码不匹配已经发生了错误。这些问题并没有发生在常规的编织器Rmd到html的转换中。

我正在将一个html的Rmarkdown文档转换为ioslides类型的Rmarkdown文档，我偶然发现了一个意外的问题。该文档在常规编织器构造方面没有问题，但在slitify中使用完全相同的代码、环境和目录时似乎遇到了字符编码问题。

也就是说，当遇到包含非拉丁字符（如ä，ü，ö）的变量时，该编织器似乎会崩溃，当它输出的文本包含这些字符时，它们会被"？"矩形取代。

我使用的设置基于Claas Thido Pfaff的示例：http://cpfaff.github.io/reproducibility/.我还没有找到一个可以指定或更改区域设置的地方（因为完全相同的文档可以很好地处理html输出

---
title       : Reproducible Reports
subtitle    : With R, Knitr, LaTeX and Markdown 
author      : Claas-Thido Pfaff 
job         : http://cpfaff.github.io/reproducibility
framework   : io2012        # {io2012, html5slides, shower, dzslides, ...}
highlighter : highlight.js  # {highlight.js, prettify, highlight}
hitheme     : tomorrow      # 
widgets     : [mathjax, bootstrap]            # {mathjax, quiz, bootstrap}
mode        : selfcontained # {standalone, draft}
knit        : slidify::knit2slides
github      :
  author    : changed
  repo      : reproducibility
---
```{r echo = FALSE, include = F, eval = T}
require(knitr)
hook_source_def = knit_hooks$get('source')
knit_hooks$set(source = function(x, options){
  if (!is.null(options$verbatim) && options$verbatim){
    opts = gsub(",\s*verbatim\s*=\s*TRUE\s*", "", options$params.src)
    bef = sprintf('nn    ```{r %s}n', opts, "n")
    stringr::str_c(bef, paste(knitr:::indent_block(x, "    "), collapse = 'n'), "n    ```n")
  } else {
     hook_source_def(x, options)
  }
})
require(ggplot2)
```

有什么想法吗？谢谢

Answer 1

根据@Nisse Engström的建议，我发布了最终解决方案作为答案，而不是原始问题的更新。我认为现在应该将修复编码集成到主要的slitify包中。

我似乎已经通过密切协调设置fileEncoding参数和使用函数slidify(file.Rmd, encoding="UTF-8")解决了这个问题，上面的链接会有所帮助，因为除了使用install_github('ramnathv/slidify@fix_encode')的slitify之外，还需要包括slitify的fix-encode分支，但它可能很快就会被包含在主集合中。我会把这个放在这里存档。无法说出修复它的确切原因，但问题可能是由于输入文件的编码与脚本文件不同，因为默认编码似乎会导致一些问题。我仍然有点不确定到底发生了什么，但我对slidify的维护者Ramnathv积极参与所有这些讨论感到感激和惊讶。这个修复的故事也在上面的链接中。