根本原因是Excel不读UTF-8 BOM而误判编码，需用utf-8-sig（Python）或手动加ufeff（Node.js）；HEX用于无损保留二进制字段，非整文件转换，导入时须用decode()/UNHEX()还原。
导出 CSV 时中文/emoji 出现乱码或问号
根本原因不是编码选错了，而是 excel 默认用 gbk（windows）或 iso-8859-1（旧版 macos）打开 utf-8 文件，且不读 bom。直接写 utf-8 没用，得加 bom 才能被 excel 正确识别。
- Python 用
open(..., encoding='utf-8-sig')——utf-8-sig会自动在开头写 BOM - Node.js 用
Buffer.from('ufeff' + csvContent, 'utf16le')或第三方库如papaparse配置encoding: 'UTF-8'+ 手动 prependufeff - 别用
utf-8直接写文件再双击打开，Excel 看不到 BOM 就当 ANSI 处理，中文全变乱码
需要保留原始字节（比如调试协议、日志分析）时用 HEX 输出
HEX 不是为“好看”或“兼容”，而是为了无损还原二进制内容。比如某字段存的是加密后的 bytes、设备返回的原始报文、或含控制字符（ 、 ）的字段，直接转字符串会截断或报错。
- Python：用
binascii.hexlify(data).decode('ascii')，注意data必须是bytes；如果是str先用.encode('utf-8') - JavaScript：用
Array.from(new Uint8Array(buffer)).map(b => b.toString(16).padStart(2,'0')).join('') - 别对整个 CSV 文件做 HEX —— 那只是把逗号、换行也转成
2c、0a，后续根本没法当表格用 - 只对真正需要保真字节的字段做 HEX，其他字段保持原样
PostgreSQL / MySQL 导出含特殊字符字段的 HEX 值
数据库里存了 bytea 或 BLOB，想导出可读 HEX 字符串，不是导出原始二进制文件。
- PostgreSQL：
SELECT encode(your_column, 'hex') FROM table——encode()是关键，别用to_hex()（只支持整数） - MySQL：
SELECT HEX(your_column) FROM table—— 注意大小写敏感，hex()小写才有效 - 如果字段是文本但含不可见字符（比如粘贴进来的零宽空格
u200b），先用REGEXP_REPLACE(col, '[^[:print:]]', '?')或CONV(HEX(col), 16, 10)辅助定位 - 导出到 CSV 时，HEX 字段本身是纯 ASCII，不用加 BOM，但整行仍需按第一部分处理编码问题
HEX 字符串导入回数据库时容易漏掉的一步
导出时用了 encode() 或 HEX()，导入时不能直接插回去 —— 那只是插入一串字母数字，不是原始 bytes。
- PostgreSQL 导入 HEX 字符串：用
decode('a1b2c3', 'hex')转回bytea，否则字段类型不匹配 - MySQL 导入：用
UNHEX('a1b2c3')，不是HEX()的逆操作 - CSV 中 HEX 字段若含前缀
\x或0x，导入前必须先去掉，decode()和UNHEX()只认纯十六进制字符 - 别在应用层手动拼 SQL 插入 HEX 字符串，容易被单引号、反斜杠破坏，用参数化查询 +
decode函数更稳
