1. 这不是教科书里的“编码概述”而是一线工程师每天在调试日志、解析API响应、处理文件上传时反复踩坑后理出来的实战脉络“Overview of Encoding Methodologies”——光看这个标题很多人第一反应是又一篇泛泛而谈的综述讲ASCII、Unicode、UTF-8、Base64再配张字符映射表最后加一句“UTF-8是目前最主流的编码方式”就收工我干这行十二年从嵌入式固件刷写失败到Web接口返回乱码被客户凌晨三点电话轰炸再到爬虫抓回来的中文标题全变成再到数据库里存进去的是“张三”查出来显示成“å¼ ä¸‰”……所有这些没一个是因为“没学过Unicode原理”——而是因为我们总在错误的时间、用错误的工具、对错误的数据施加了错误的编码操作。这篇内容不讲定义不列年表不堆术语。它只回答四个问题第一为什么同一串字节在终端里显示正常在Excel里打开就是乱码第二为什么Python里encode(utf-8)之后再decode(gbk)结果既不是原文也不是乱码而是一串完全不可预测的汉字第三为什么Node.js的Buffer.from(str, utf8)和Go的[]byte(str)看似等价但在HTTP header里传出去就被Nginx截断第四当你的日志系统突然开始记录大量UnicodeEncodeError: charmap codec cant encode character \u2026你该先改代码、换终端还是重装系统字体我把这十二年拆解成四类真实战场字符表示层Character Representation、字节序列化层Byte Serialization、传输封装层Transport Wrapping、存储持久化层Storage Persistence。每一层都对应一套独立的编码逻辑、一套默认假设、一套隐式转换规则。你不是在学“编码方法”你是在学习如何识别当前数据所处的层级并在该层级上做唯一合法的操作。适合谁后端API开发者、前端跨域调试者、数据ETL工程师、运维日志分析员、甚至只是经常用Excel打开CSV、用Notepad改配置文件的普通用户——只要你曾被“编码问题”卡住超过5分钟这篇就是为你写的。2. 四层编码战场为什么你总在“正确”操作后得到“错误”结果2.1 字符表示层你以为你在处理“文字”其实你只在处理“编号”这是所有混乱的起点。很多人以为“编码”就是把汉字变成字节但真相是在计算机内存里根本不存在“汉字”这个东西。存在的只有整数——Unicode码点Code Point。比如“中”字在Unicode标准里被分配了U4E2D这个编号“文”是U6587“编”是U7F16。它们本质和42、100、255没有区别只是人类给它们赋予了视觉意义。操作系统、编程语言、编辑器都通过一张巨大的“码点→字形”映射表即字体文件把U4E2D渲染成你屏幕上看到的那个方块字。所以当你在Python里写ch 中变量ch里存的不是字形也不是字节而是一个抽象的Unicode码点对象Python 3中为str类型。关键来了这个抽象层本身不涉及任何字节。它不关心你是用UTF-8、UTF-16还是GB18030来存储它——那是下一层的事。但问题就出在这里几乎所有开发工具都在悄悄越界。比如你在VS Code里新建一个空文件输入“中文”保存时默认用UTF-8编码但如果你用Windows自带的记事本同样输入“中文”保存时默认用ANSI即当前系统区域设置下的本地编码简体中文Windows通常是GBK。两个文件内容看起来一模一样但底层字节序列完全不同UTF-8下“中”是三个字节e4 b8 adGBK下“中”是两个字节d6 d0。可当你双击打开这两个文件时记事本和VS Code都“猜对了”编码方式于是都正确显示为“中文”。这种“自动猜测”机制BOM检测、字节频率分析、上下文启发式让开发者产生幻觉编码是透明的、自动的、无需干预的。直到某天你把记事本保存的GBK文件用Python以UTF-8打开open(file.txt, r, encodingutf-8)程序立刻报错UnicodeDecodeError: utf-8 codec cant decode byte 0xd6 in position 0。这不是Python错了是它严格遵守了你的指令你明确说“请用UTF-8规则解读这串字节”而字节0xd6在UTF-8里根本不是一个合法起始字节。此时正确的操作不是骂Python太死板而是问自己这串字节到底是谁、在哪个环节、用什么规则生成的答案必须回到源头——字符表示层从未参与字节生成它只负责提供码点。所以当你拿到一串未知来源的字节流比如HTTP响应体、二进制文件读取结果第一步永远不是尝试decode()而是确认它的编码身份。方法有三一是看协议规范HTTP头里的Content-Type: text/html; charsetutf-8二是看文件签名UTF-8无BOMUTF-16 LE以ff fe开头UTF-16 BE以fe ff开头三是用chardet库实测注意chardet是概率模型对短文本准确率低于70%仅作辅助。我见过太多人在没确认编码前就盲目decode(utf-8)结果把原本是GBK的0xd6d0强行按UTF-8解释得到一个非法序列再encode(utf-8)存回去原始信息彻底损坏。记住字符表示层是纯逻辑层它不生产字节只消费字节。你的责任是确保送进来的字节和你声明的解码方式严格匹配。2.2 字节序列化层UTF-8、UTF-16、GBK不是“选项”而是“契约”一旦你拥有了Unicode码点比如Python的str下一步就是把它变成字节流——这就是字节序列化层。这里没有“最好”的编码只有“最适合场景”的契约。UTF-8、UTF-16、UTF-32、GBK、Big5、Shift-JIS它们本质都是同一套数学映射把0到0x10FFFF范围内的码点压缩成1~4个字节的序列。区别在于压缩策略和兼容性设计。UTF-8是Web事实标准因为它完美兼容ASCII所有ASCII字符U0000~U007F在UTF-8里就是单字节值完全相同。这意味着一个纯英文的HTML文件用ASCII、ISO-8859-1、UTF-8打开效果一模一样。但中文呢U4E2D中在UTF-8里是e4 b8 ad3字节在UTF-16 LE里是2d 4e2字节在GBK里是d6 d02字节。表面看UTF-16和GBK更省空间但陷阱在于字节序Endianness。UTF-16必须明确是LE小端还是BE大端否则2d 4e可能被误读为U4E2D正确或U2D4E一个不存在的字符。而UTF-8天生无字节序问题因为它的多字节结构由首字节高位模式唯一确定110xxxxx表示2字节序列1110xxxx表示3字节序列。这就是为什么HTTP、JSON、XML等网络协议强制要求UTF-8它消除了跨平台解析歧义。GBK则完全不同——它是国家标准只为中文设计不兼容Unicode。一个GBK编码的“中”d6 d0在UTF-8里解码会得到ÖÐ两个拉丁扩展字符反之亦然。更危险的是混合使用比如你用Python读取一个GBK文件content open(gbk.txt, r, encodinggbk).read()得到str对象然后你把它发给一个只认UTF-8的APIrequests.post(url, datacontent.encode(utf-8))。这步encode(utf-8)是安全的因为str对象内部就是Unicode码点encode()只是按规则转字节。但如果中间有人插了一步content_gbk content.encode(gbk)然后再content_gbk.decode(utf-8)那就完蛋了——你把合法的GBK字节当成UTF-8去解必然出错。我在线上环境见过最离谱的案例一个Java服务用new String(bytes, GBK)读取数据库字段再用getBytes(UTF-8)写回结果数据库里存的GBK字节被两次错误转换最终变成无法还原的乱码雪球。解决方案在字节序列化层坚持单一编码契约并在所有接口边界显式声明。例如公司内部服务间通信统一规定所有HTTP请求体必须是UTF-8编码的JSON所有数据库TEXT字段必须用UTF8MB4字符集所有配置文件必须带UTF-8 BOM避免Windows记事本误判。不要依赖“系统默认”Windows默认是GBKLinux默认是UTF-8macOS默认是UTF-8你的程序不能随系统摇摆。我在部署一个跨国SaaS产品时强制所有微服务启动时检查locale.getpreferredencoding()如果不是UTF-8则panic退出并打印明确错误“System locale is GBK, but service requires UTF-8. Please set LANGen_US.UTF-8 before starting.”——宁可启动失败也不留隐患。2.3 传输封装层Base64、Hex、URL Encoding不是“编码”而是“包装”很多开发者混淆了“编码”Encoding和“编码格式”Encoding Format。UTF-8是一种编码格式它定义了码点到字节的映射而Base64、Hex、URL Encoding是传输封装层的工具它们解决的是“如何把任意字节安全地塞进一个只接受特定字符集的通道”。比如HTTP URL路径只能包含ASCII可见字符a-z, A-Z, 0-9,-,_,.,~但你的API需要传一个二进制图片ID比如UUIDb1f2a3c4-d5e6-7890-f1a2-b3c4d5e6f789直接拼在URL里会出错。这时你用URL Encoding也叫Percent-Encoding把非安全字符替换成%加两位十六进制b1f2a3c4-d5e6-7890-f1a2-b3c4d5e6f789变成b1f2a3c4%2Dd5e6%2D7890%2Df1a2%2Db3c4d5e6f789。注意URL Encoding操作对象是字节不是字符串。中.encode(utf-8)是b\xe4\xb8\xadURL Encoding后是%E4%B8%AD三个%xx组。Base64同理它把每3个字节24位拆成4组6位映射到A-Z a-z 0-9 /共64个字符末尾用补位。b\xe4\xb8\xadBase64后是5LiN。关键点Base64/Hex/URL Encoding不改变原始语义只是改变了字节的表示形式且可逆。它们和UTF-8是正交关系你可以先用UTF-8把“中”变成e4 b8 ad再用Base64把它变成5LiN也可以先用GBK变成d6 d0再Base64成1tAK。两者结果不同但各自合法。混乱常发生在“重复封装”。比如前端JavaScript用btoa(unescape(encodeURIComponent(中)))生成Base64这是老式兼容写法后端Python收到后先base64.b64decode()得到字节再decode(utf-8)——这没问题。但如果后端误以为前端传的是URL Encoded字符串先urllib.parse.unquote()再base64.b64decode()就会失败因为%E4%B8%AD不是合法Base64。另一个经典坑邮件附件。MIME标准规定二进制附件必须用Base64或QPQuoted-Printable编码后作为纯文本传输。但有些老旧邮件客户端会把Base64字符串里的换行符\nRFC规定每76字符插入一个\r\n当成邮件正文分隔导致解码时少掉几个字节。我的解决方案是在发送端Base64编码后用正则re.sub(r[\r\n], , base64_str)移除所有换行在接收端Base64解码前先base64_str.replace(\r, ).replace(\n, )。简单粗暴但100%有效。传输封装层的核心原则是明确通道约束选择唯一封装方式并在两端严格对称实现。不要在一个地方用URL Encoding另一个地方用Base64不要在HTTP Header里用Percent-Encoding在Query String里又用Base64。统一是避免混乱的唯一捷径。2.4 存储持久化层数据库、文件系统、缓存的“默认编码”都是定时炸弹最后一层也是最容易被忽视的一层数据落盘后的编码固化。你以为INSERT INTO users(name) VALUES(张三)执行成功数据就安全了错。安全与否取决于四个要素客户端连接编码、服务器默认编码、表字段字符集、列排序规则Collation。以MySQL为例一个典型的灾难链是应用用utf8mb4连接建表时却用CHARSETutf8注意MySQL的utf8是阉割版只支持3字节UTF-8不支持emoji插入“‍”U1F4BB U200D U1F4BC时MySQL silently truncate为?或者表是utf8mb4但连接时没设charsetutf8mb4客户端以为自己在发GBK服务器按utf8mb4存结果存进去的就是乱码。PostgreSQL稍好它强制要求客户端声明client_encoding不匹配直接报错。但文件系统呢Linux ext4不存储文件名编码它只存字节序列。你用UTF-8终端创建文件touch 中文.txt文件名就是e4 b8 ad e6 96 87 2e 74 78 74但如果你用GBK终端如某些国产Linux发行版创建同名文件字节就是d6 d0 ce c4 2e 74 78 74。两个文件在ls里都显示“中文.txt”但它们是完全不同的inode。更糟的是当你用mv重命名或用find搜索工具底层调用的是readdir()返回的原始字节如果终端编码和文件名编码不一致ls可能显示乱码find可能根本找不到。我维护过一个日志归档系统它用Python遍历目录os.listdir()返回的文件名是bytes类型Python 2或strPython 3但依赖sys.getfilesystemencoding()。在CentOS 7上默认是utf-8一切正常但迁移到一个定制版国产OS时sys.getfilesystemencoding()返回gbk导致所有含中文的文件名被错误解码脚本崩溃。解决方案在存储层放弃“默认”拥抱“显式”。数据库连接字符串里强制加?charsetutf8mb4文件操作前用locale.getpreferredencoding()校验不匹配则用os.fsencode()/os.fsdecode()显式转换缓存如Redisvalue一律用json.dumps(obj, ensure_asciiFalse).encode(utf-8)存取出来decode(utf-8)再json.loads()。不要相信任何“自动适配”。我见过最惨的案例一个金融系统交易流水号含中文备注存进Oracle时用了AL32UTF8字符集但报表导出用的JDBC驱动版本太老不支持setCharacterStream()导致导出CSV时中文全变?审计时发现三个月数据丢失被迫人工核对。教训是存储层的编码契约必须写进架构设计文档作为上线Checklist的第一条。3. 实操手册从乱码现场到根因定位的七步诊断法3.1 第一步冻结现场获取原始字节不是字符串所有诊断的起点是看到真实的字节序列。很多人一遇到乱码第一反应是“换个编辑器打开”这是最危险的。因为编辑器会自动猜测编码并渲染你看到的“显示结果”已经经过至少一次隐式转换。正确做法用十六进制查看器直面原始字节。Linux/macOS用xxdecho 中文 | xxd -g1 # 输出00000000: e4 b8 ad e6 96 87 0a .......Windows用CertUtil -encodehex file.txt或下载HxD。重点看字节长度是否符合预期“中”在UTF-8是3字节在GBK是2字节是否有BOMef bb bf是UTF-8 BOMff fe是UTF-16 LE BOM是否存在非法字节UTF-8中0xc0、0xc1、0xf5~0xff是禁止使用的起始字节。我习惯在Python里写一个快速诊断函数def hexdump(data): if isinstance(data, str): data data.encode(utf-8) # 先转字节避免str干扰 print( .join(f{b:02x} for b in data)) # 使用hexdump(中文) → e4 b8 ad e6 96 87这比任何GUI工具都快且绝对真实。3.2 第二步反向推演构建“编码路径图”拿到字节后问自己这串字节从诞生到你眼前经历了哪些环节画一个简单的流程图。例如一个Web表单提交浏览器输入框UTF-16 → HTML表单meta charsetutf-8 → HTTP POST bodyUTF-8字节 → Nginx可能做gzip → Python Flaskrequest.get_data() → 数据库存储utf8mb4。每个箭头都代表一次编码/解码操作。现在从你看到的乱码字节出发逆向检查每个环节如果xxd显示d6 d0而你期望UTF-8的e4 b8 ad说明问题出在“浏览器→HTTP body”之间浏览器没按UTF-8提交如果xxd显示e4 b8 ad但Python里request.form.get(name)是ÖÐ说明Flask解码时用了GBK可能是app.config[JSON_AS_ASCII] False没生效或Nginx转发时header丢失如果Python里name是中文但数据库里查出来是??说明数据库连接或表字符集不对。我用一个物理白板贴满便签纸每个环节写一行用红笔标出“已验证OK”绿笔标出“待验证”。这样问题范围会迅速收敛到1~2个节点。3.3 第三步隔离验证用最小可运行代码复现一旦锁定可疑环节立即写最小代码验证。不要在生产代码里调试。例如怀疑是Python读文件编码问题# test_encoding.py with open(test.txt, rb) as f: # 先用二进制模式读看原始字节 raw f.read() print(Raw bytes:, raw.hex()) # e4b8ad # 尝试不同解码 for enc in [utf-8, gbk, latin-1]: try: s raw.decode(enc) print(fDecoded with {enc}: {repr(s)}) except UnicodeDecodeError: print(fFailed with {enc}) # 输出Failed with utf-8, Failed with gbk, Decoded with latin-1: \xe4\xb8\xadlatin-1即ISO-8859-1是万能兜底它把每个字节直接映射到U0000~U00FF永不报错。如果latin-1能解说明字节本身是合法的只是你用错了编码。这时用chardet.detect(raw)看它猜什么import chardet print(chardet.detect(raw)) # {encoding: utf-8, confidence: 0.99}如果confidence 0.7别信它。我的经验是对短文本100字chardet基本不准对长文本它准但你要验证。验证方法用它猜的编码解码再用UTF-8编码回去和原始字节对比是否一致。不一致说明猜错了。3.4 第四步协议层检查抓包确认HTTP/DB实际传输内容如果Web场景Wireshark或Chrome DevTools Network面板是终极武器。在Chrome里打开Network → 找到请求 → Headers → 查看Request Headers里的Content-Type确认是否有charsetutf-8点开Preview或Response看是否显示正常如果不正常点Response → 右键“Save as”存为文件用xxd看字节。如果是数据库用MySQL命令行SHOW VARIABLES LIKE character_set%; -- 查看服务器、客户端、连接编码 SHOW CREATE TABLE users; -- 查看表字符集 SELECT HEX(name) FROM users LIMIT 1; -- 直接看字段存储的十六进制HEX()函数返回的是存储在磁盘上的原始字节这才是真相。我曾经帮一个团队排查他们坚称“数据库存的是UTF-8”但HEX(name)返回d6d0铁证如山——表字符集是GBK。他们之前一直用SELECT name FROM users看MySQL客户端自动做了转换掩盖了问题。3.5 第五步环境层扫描确认系统/终端/IDE的默认编码很多问题根源在环境。检查Linux/macOSlocale命令看LANG和LC_ALLWindowschcp命令看当前代码页936GBK65001UTF-8Pythonpython -c import sys; print(sys.getdefaultencoding(), sys.getfilesystemencoding())IDEVS Code右下角状态栏点击编码名称可切换PyCharm在File → Settings → Editor → File Encodings。特别注意Windows PowerShell默认代码页是936GBK但Windows Terminal可以设为UTF-8。我强制所有新服务器执行# PowerShell chcp 65001 # 切换到UTF-8 $env:PYTHONIOENCODINGutf-8 # 设置Python环境变量并在.bashrc或.zshrc里加export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8环境统一能消灭80%的“本地跑通线上报错”。3.6 第六步修复与加固不只是改一行代码定位到根因后修复要分两层临时修复快速止损。比如数据库存错了用CONVERT()函数修正UPDATE users SET name CONVERT(CAST(CONVERT(name USING latin1) AS BINARY) USING utf8mb4);先用latin1读出原始字节再当UTF-8重新解释永久加固防止复发。在代码里加防御性检查def safe_decode(data: bytes, encodings: list [utf-8, gbk]) - str: for enc in encodings: try: return data.decode(enc) except UnicodeDecodeError: continue raise ValueError(fCannot decode {data[:20]!r} with any of {encodings}) # 在所有文件读取、网络响应解析处用这个函数替代裸decode()在CI/CD流水线里加检查# .gitlab-ci.yml - python -c import locale; assert locale.getpreferredencoding() UTF-8 - find . -name *.py -exec grep -l open([^)]*encoding {} \; | xargs grep -L encodingutf-8确保所有open()都显式指定encoding。3.7 第七步建立编码健康度仪表盘让问题浮出水面最后一步是把经验沉淀为自动化。我给团队做的编码健康度检查脚本每天凌晨运行扫描所有CSV/LOG/TXT文件用chardet统计编码分布报警“非UTF-8文件占比5%”检查数据库所有TEXT字段SHOW FULL COLUMNS FROM table报警“字符集非utf8mb4的字段”抓取最近1000条Nginx错误日志正则匹配UnicodeDecodeError报警频次10次/小时。数据可视化在Grafana一目了然。编码问题不再是“偶发事故”而是可度量、可追踪、可优化的工程指标。4. 常见问题速查表与独家避坑指南4.1 “Python读CSV中文全是乱码pandas.read_csv()怎么设encoding”这是最高频问题。根本原因pandas.read_csv()默认用locale.getpreferredencoding()在Windows上是GBK在Linux上是UTF-8。解决方案分三步先确认CSV真实编码用xxd file.csv | head -n 5看前几行字节。如果第一行是ef bb bf就是UTF-8 BOM如果是d6 d0开头就是GBK。显式指定encoding# 有BOM的UTF-8 df pd.read_csv(file.csv, encodingutf-8-sig) # -sig自动strip BOM # 无BOM的UTF-8 df pd.read_csv(file.csv, encodingutf-8) # GBK df pd.read_csv(file.csv, encodinggbk)注意utf-8-sig是关键很多“UTF-8 CSV”其实是带BOM的不用-sig会把BOM当字符读入第一列列名导致df.columns[0]是\ufeff姓名。终极保险用csv模块先探测import csv with open(file.csv, rb) as f: raw f.read(1000) # 读前1000字节 encoding chardet.detect(raw)[encoding] df pd.read_csv(file.csv, encodingencoding)我的实操心得在数据管道里所有CSV输入强制要求上游提供encoding元数据写在同目录的file.csv.meta里内容为{encoding: utf-8, delimiter: ,}。下游先读meta再读CSV彻底杜绝猜测。4.2 “Vue项目里axios请求后端API中文响应体显示为乱码但Postman里正常”Postman正常说明后端API本身没问题问题在前端解析。常见原因Axios未设置responseType默认responseType: json但JSON规范要求字符串必须是UTF-8如果后端返回Content-Type: application/json;charsetgbkAxios会忽略charset按UTF-8解析导致乱码。解决方案// 全局设置 axios.defaults.responseType text; // 让Axios返回原始字符串 // 或在单个请求里 axios.get(/api/data, { responseType: text }) .then(res { const data JSON.parse(res.data); // 手动parse此时res.data是已按HTTP header charset解码的字符串 });Vue模板里v-html渲染如果后端返回的HTML片段含中文v-html会直接插入DOM但若HTML里没meta charsetutf-8浏览器可能用GBK解析导致乱码。解决方案后端返回的HTML必须带meta charsetutf-8或前端用DOMParserconst parser new DOMParser(); const doc parser.parseFromString(htmlString, text/html); const text doc.body.textContent; // 安全提取文本我的避坑技巧在Axios拦截器里加日志axios.interceptors.response.use( response { console.log(Response charset:, response.headers[content-type]); return response; } );一眼看出后端是否按约定返回了charset。4.3 “Linux服务器上crontab执行Python脚本中文日志变乱码但手动执行正常”手动执行正常crontab异常99%是环境变量差异。crontab默认PATH/usr/bin:/bin且不加载~/.bashrc所以locale是C localeASCII。解决方案在crontab里显式设置环境# 编辑crontab crontab -e # 添加 SHELL/bin/bash PATH/usr/local/bin:/usr/bin:/bin LANGen_US.UTF-8 LC_ALLen_US.UTF-8 0 * * * * /usr/bin/python3 /path/to/script.py在Python脚本开头强制设置import locale locale.setlocale(locale.LC_ALL, en_US.UTF-8)提示locale.setlocale()需要系统已安装该locale。用locale -a | grep en_US.utf8确认没有则sudo locale-gen en_US.UTF-8。我的实操心得所有部署到服务器的Python脚本第一行必须是#!/usr/bin/env python3 # -*- coding: utf-8 -*- import locale, sys locale.setlocale(locale.LC_ALL, C.UTF-8) # C.UTF-8是glibc提供的可靠UTF-8 localeC.UTF-8比en_US.UTF-8更轻量且在所有现代Linux发行版中都预装。4.4 “Git提交含中文的文件名Windows和Mac上显示不一致”Git本身不存储文件名编码它只存字节。Windows Git默认用GBKMac Git默认用UTF-8导致同一个commit在不同系统git status显示不同文件名。解决方案全局设置Git对文件名使用UTF-8git config --global core.precomposeunicode false git config --global core.quotePath false # 关键一步告诉Git文件名是UTF-8 git config --global core.autocrlf input重写历史如果已污染# 用git-filter-repo推荐替代旧的filter-branch pip install git-filter-repo git filter-repo --mailmap .mailmap --force注意重写历史会影响所有协作者需同步通知。我的独家技巧在团队初始化仓库时就加一个pre-commit钩子# .githooks/pre-commit #!/bin/sh if git status --porcelain | grep -q ^[AM]; then if git status --porcelain | grep -q [^[:ascii:]]; then echo Error: Commit contains non-ASCII filenames. Please rename to ASCII or ensure UTF-8. exit 1 fi fi强制文件名用ASCII从源头杜绝问题。4.5 “Excel打开UTF-8 CSV中文全变乱码怎么救”Excel尤其是Windows版打开CSV默认用系统ANSI编码GBK不会识别UTF-8 BOM。解决方案方法一推荐用Excel的“数据导入”功能数据→从文本/CSV→ 选择文件 → 在导入向导中编码选UTF-8→ 加载。方法二手动加BOM用Python给CSV加BOMwith open(data.csv, r, encoding