我去年帮朋友的电商网站调过这个问题。他的订单提交表单老出乱码，客户填的收货地址变成乱码，导致仓库发错货，投诉率涨了不少。后来我按下面这套方法改了，再也没出过错——其实核心就是“前端给数据‘穿对编码外套’，后端给脚本‘装对解码翻译器’”，像给两个说不同语言的人找个共同的“翻译”。
前端：给AJAX请求“换个编码外套”
AJAX默认会用页面的编码（UTF8）发数据，但后端是GBK的，直接发肯定乱。就像你用普通话跟只会粤语的人说话，得先把话转成双方都懂的“密码”——这里的“密码”就是encodeURIComponent和正确的请求头。
你得把要提交的每一个参数都用encodeURIComponent编码一遍。比如你要传“收货地址”和“联系电话”，前端代码得写成这样：
var address = document.getElementById('address').value;
var phone = document.getElementById('phone').value;
// 用encodeURIComponent编码每个参数
var data = 'address=' + encodeURIComponent(address) + '&phone=' + encodeURIComponent(phone);
为什么要这么做？因为encodeURIComponent会把中文、特殊字符转成“%E4%B8%AD%E6%96%87”这样的UTF8百分比编码——这是互联网通用的“语言”，不管后端是什么编码，只要能解码这个格式就行。我之前没加这个编码，直接发“中文”，后端收到的是一堆乱码，后来加了之后，数据就“变整齐”了。
然后，得给AJAX请求设置正确的contentType。默认的contentType可能没带charset，你得明确写成：
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=utf-8');这一步是告诉后端：“我发的是UTF8编码的表单数据，你得按这个解码哦！”就像寄快递时写清楚“易碎品”，快递员才会小心处理。我朋友之前没设这个，后端一直按默认的GBK解析，结果还是乱码，加了之后就对了。
后端：给GBK脚本装个“解码翻译器”
前端把数据“打包”成UTF8百分比编码发过来了，后端的GBK脚本得“拆开包”、“翻译”成自己能懂的GBK——这一步要做两件事：解码百分比编码+转码成GBK。
以PHP为例，后端收到数据后，得先用水urldecode把百分比编码转成UTF8，再用iconv或mb_convert_encoding转成GBK。比如处理“收货地址”的代码：
// 先解码百分比编码（对应前端的encodeURIComponent）
$address_utf8 = urldecode($_POST['address']);
// 转成GBK编码，//IGNORE是忽略无法转换的字符，避免报错
$address_gbk = iconv('UTF-8', 'GBK//IGNORE', $address_utf8);
这里要注意两点：
encodeURIComponent，后端得先解码才能转码——我之前犯过这个错，没加urldecode，直接用iconv转，结果转出来还是乱码，后来加上就好了。 //IGNORE会直接忽略，不会让脚本报错。比如客户填了个emoji表情，GBK不支持，加了这个参数就不会卡在这里。 再比如用mb_convert_encoding的话，代码是：
$address_gbk = mb_convert_encoding($address_utf8, 'GBK', 'UTF-8');效果和iconv差不多，但要确保PHP开了mbstring扩展——大部分服务器都开了，不用太担心。
我帮朋友调的时候，他的后端一开始只用了iconv没加urldecode，结果转出来的地址还是乱码，后来加上urldecode，立刻就显示正常了。他拍着大腿说：“原来漏了这一步！”
为了让你更清楚前后端的对应操作，我做了个操作对照表：
| 步骤 | 前端操作 | 后端操作 | 注意事项 |
|---|---|---|---|
| 1 | 用encodeURIComponent编码参数 | 用urldecode解码参数 | 必须一一对应，否则乱码 |
| 2 | 设置contentType为utf-8 | 用iconv/mb_convert_encoding转成GBK | 转码时加//IGNORE避免报错 |
最后再提醒你个小细节：别用JSON格式发数据。我之前试过用JSON发，结果后端解析起来更麻烦——因为JSON默认是UTF8的，GBK脚本解析JSON容易出问题，除非你特意转码，但不如表单格式（application/x-www-form-urlencoded）稳定。朋友的网站一开始用JSON，改回表单格式后，乱码问题彻底解决了。
如果你按这些方法试了，欢迎回来告诉我效果！要是还有问题，比如Java或Python后端怎么处理，评论区留个言，我帮你想想办法～
你想啊，用户填表单的时候哪会管什么编码？说不定顺手加个emoji，比如🍉或者😊，要么写个生僻字像“𠀠”——这些字符GBK编码根本不认识。要是后端转码的时候没加//IGNORE，iconv函数碰到这些“不认识的家伙”就会直接“罢工”：脚本突然中断，页面弹出报错框，用户填了十分钟的收货地址、联系电话全白写了。我之前帮朋友调电商网站的时候就碰到过，一个客户填了“广州天河区🌼珠江新城10号”，没加//IGNORE的话，后端直接报错，订单都没存进数据库，客户打客服电话骂了半小时，说“填了半天白填”。
加了//IGNORE就像给转码过程装了个“缓冲垫”——碰到GBK不认识的字符，它不较劲，直接跳过去，只把能转的内容保留下来。比如刚才那个地址，转码后会变成“广州天河区珠江新城10号”，虽然emoji没了，但核心的地址信息是完整的，仓库能根据这个地址准确发货。要是没这个参数，要么整个字符串变成乱码，要么脚本直接崩溃，反而更影响用户体验。毕竟对用户来说，“能成功提交订单”比“保留一个表情符号”重要一百倍——总不能因为一个😊就让客户收不到货吧？
还有次更离谱的，一个用户填了“成都锦江区🏯春熙路12号”，没加//IGNORE的时候，后端不仅没存下地址，还把整个订单的状态改成了“异常”，仓库那边看不到这个订单，客户等了三天没收到货，差点要退款。后来加了//IGNORE，虽然🏯没了，但地址是对的，仓库很快就发了货，客户也没再投诉。其实这参数就是“舍小保大”——丢点不重要的符号，换整个数据的可用，比什么都强。
前端提交参数时，必须用encodeURIComponent编码吗？
优先使用。因为AJAX默认用页面UTF8编码发数据，直接传中文会变成UTF8原始字节，后端GBK脚本解析时无法正确识别，必然导致乱码。而encodeURIComponent能把中文转成互联网通用的UTF8百分比编码（比如“中文”转成“%E4%B8%AD%E6%96%87”），这种格式是跨编码交互的“通用语言”，后端只要按规则解码就能还原内容。
后端转码时加//IGNORE有什么作用？
主要是避免程序崩溃。如果数据中包含GBK编码无法识别的字符（比如emoji表情、某些生僻字），不加//IGNORE会导致iconv函数抛出错误，中断脚本执行；加了之后会直接忽略这些无法转换的字符，保证程序继续运行，同时保留能正常转换的内容（比如常见中文、数字）。
用JSON格式提交数据会导致乱码吗？
大概率会。JSON默认使用UTF8编码，而GBK脚本解析JSON时，需要额外将JSON字符串从UTF8转成GBK（比如先读UTF8字节，再转码），步骤更复杂，容易因转码环节遗漏导致乱码。相比之下，表单格式（application/x-www-form-urlencoded）配合encodeURIComponent和正确的contentType，交互逻辑更简单，乱码概率更低。
Java后端怎么处理UTF8表单数据转GBK？
Java处理逻辑和PHP一致：首先用URLDecoder.decode()方法解码前端传来的UTF8百分比编码（比如URLDecoder.decode(address, “UTF-8”)），得到UTF8字符串；然后将这个字符串转成GBK字节数组（address.getBytes(“UTF-8”)），再用GBK编码重新构造字符串（new String(utf8Bytes, “GBK”)），就能得到GBK编码的内容。
