Express接收EUC-KR编码POST表单乱码，如何用iconv-lite正确转成UTF-8

你之前用iconv-lite转码失败的根本原因是转码时机完全错误：
Express 全局挂载的bodyParser.urlencoded中间件默认使用UTF-8编码解码原始请求体。但你收到的表单请求，实际是前端EUC-KR页面生成的CP949编码字节流，中间件在解析阶段就已经把原始的CP949字节按UTF-8规则错误解码为乱码字符串，后续拿到的req.body.address已经是被损坏的字符串——此时不管用什么转码工具处理，都无法恢复原始的正确内容。
之所以zipCode字段能正常显示，是因为纯数字属于ASCII字符，在UTF-8和CP949两种编码下的字节值完全一致，哪怕解码规则错了也不会出现乱码；而韩文是双字节字符，解码规则不匹配就会直接变成日志里看到的问号、特殊符号。

错误流程直观演示：

1. 前端提交的"제주"两个韩文字，对应的CP949原始字节为0xBE 0xC6 0xC1 0xBC
2. 默认配置的body-parser拿到这4个字节，直接按UTF-8规则解码，因为这几个字节不符合UTF-8的多字节字符校验规则，会被替换成乱码的替换字符，此时原始字节信息已经完全丢失
3. 你拿到这个错误乱码字符串，再用iconv-lite做CP949到UTF-8的转换，相当于在损坏的字符串上做二次编码，自然永远得不到正确结果。

方案1：给目标接口单独配置可指定编码的urlencoded解析中间件（最简便） #

不需要手动收集请求流，直接利用bodyParser本身支持的自定义编码配置，让中间件在解析阶段就用正确的CP949编码解码请求体，步骤如下：

• 移除全局挂载的默认urlencoded中间件，避免它提前用UTF-8错误解码目标接口的请求
• 给/这个接收EUC-KR表单的POST接口，单独挂一个指定了解码编码为CP949的urlencoded中间件
• 其他接口的逻辑保持不变

示例代码：

const server = express();
// 保留全局的json解析逻辑
server.use(bodyParser.json());

// 针对根路径的POST请求，单独配置urlencoded解析规则
const koreanFormParser = bodyParser.urlencoded({
  extended: false,
  encoding: 'cp949' // 这里直接指定解析时使用的编码，替代默认的UTF-8
});

// 目标接口绑定自定义的解析中间件
server.post('/', koreanFormParser, (req, res) => {
  console.log(req.body); // 此时req.body里的address字段已经是正确的韩文地址，不需要手动转码
  app.render(req, res, '/');
});

方案2：手动收集原始请求Buffer，用iconv-lite手动解码（更灵活） #

如果需要更细的控制，可以绕过body-parser对目标接口的处理，直接收集原始请求的字节流，手动完成解码和url参数解析：

• 调整全局bodyParser的配置，让它跳过/接口的urlencoded请求解析，保留原始请求流
• 在接口处理逻辑里，手动收集所有请求字节，等接收完成后，用iconv-lite按CP949规则把Buffer解码为正确的字符串
• 用Node内置的querystring工具把解码后的字符串解析为表单字段对象

示例代码：

const iconv = require('iconv-lite');
const querystring = require('querystring'); // Node内置模块，不需要额外安装

// 调整全局urlencoded中间件的拦截规则，跳过/路径的请求
server.use(bodyParser.urlencoded({
  extended: false,
  type: (req) => {
    // 如果是/路径的application/x-www-form-urlencoded请求，就不让bodyParser处理
    if (req.originalUrl === '/' && req.headers['content-type']?.includes('application/x-www-form-urlencoded')) {
      return false;
    }
    return true;
  }
}));
server.use(bodyParser.json());

server.post('/', (req, res) => {
  // 收集原始请求的所有字节块
  const chunks = [];
  req.on('data', (chunk) => chunks.push(chunk));
  req.on('end', () => {
    const rawBuffer = Buffer.concat(chunks);
    // 用CP949编码把原始字节解码为正确的字符串，和EUC-KR完全兼容
    const decodedStr = iconv.decode(rawBuffer, 'cp949');
    // 按urlencoded格式解析为字段对象
    const reqBody = querystring.parse(decodedStr);

    console.log(reqBody); // 可直接拿到正确的韩文地址内容
    app.render(req, res, '/');
  });
});

• 不要在body-parser解析完成、拿到req.body之后再做转码操作，此时原始的CP949字节已经被消费、覆盖，转码没有任何意义
• iconv-lite内置的cp949编码完全兼容EUC-KR页面的内容，不需要额外引入其他韩国编码规则
• 不要尝试把已经拿到的乱码字符串转回Buffer再做编码转换，这种操作本质是在损坏的字符串上做二次编码，无法恢复原始数据

内容的提问来源于stack exchange，提问作者Changdae Park