R里面的字符数据保存在 CHARSXP 里面。在
R 2.1.0 之前，它假定平台上的数据都是8-位编码，
而且它还常常假定编码是ISO Latin-1或是它的超集
（如微软的 CP1252 或
Latin-9）。
从 R 2.1.0开始，其它编码方式也被支持，特别是UTF-8和Windows里面为CJK
语言1采用的多字节编码方式。但是，没有任何办法显示何种编码方式真正被使用，
即使是已知的编码方式（例如，scan就可能不知道它正在读的文件的编码方式）。
这导致一个包里面含有Latin-1 编码的法语数据 .rda 文件可能
在其它本地化的系统里面打不开（它们可能在
一个法国UTF-8的本地化系统打开，但在大多数日本的本地化系统里面打不开）。
R 2.5.0 引入一个部分解决的方案来提示
CHARSXP 的编码。它通过设置一个`一般目的'（general purpose）的二进制位
来声明编码方式是 Latin-1 还是 UTF-8。（注意，字符向量里面可以同时包括不同编码的
元素。）无论打印还是画图都需要注意该声明然后把字符串
转换成本地系统格式（可能使用 <xx> 显示
本地系统不支持的字节）。许多（但不是所有的）字符操作函数
要么保护该声明要么对字符串重新编码。
最后，和操作系统相关的字符串，如文件名，在一些操作系统（比如，Windows） 上需要通过 一个宽-字符（wide-character）接口，但是现在它们仅仅重新编码 到当前的本地系统。
什么时候字符串需要声明为已知的编码呢？一种方法是直接用
Encoding。如果是已知编码方式，剖析器会通过encoding参数
去解析（parse）或通过本地系统在R命令行解析。
函数 scan，read.table，
readLines 和 source 有一个 encoding 参数，但他们
它们没有对来自本地系统的文件进行任何前提假设。
同杨，iconv给字符串做标记让它转换成Latin-1或UTF-8。
没有必要声明ASCII字符串的编码，因为它们可以在任何本地环境工作。 但这样做影响不大，因为它们从来都不会传递给 iconv 以翻译。
仅仅考虑UTF-8和Latin-1的初衷是因为大部分系统都支持UTF-8字符串，而且
这是我们所拥有的最接近通用格式的方案。
对于那些不支持的系统（例如，
那些缺乏足够强大的iconv函数），它们就只能
采用Latin-1，这也是旧的R版本所假设的。