好的，在我的商务平台上，购物车数据作为序列化数组存储在会话中。今天出现了一个问题，其中一个项目的尺寸选项具有 1/4 和 1/2 尺寸的特殊字符，例如；7¼、7½ 等，但是在查看客户为此商品下的订单时，尺寸值显示如下：7½
对 101 进行故障排除后，我前往该站点并下达了与客户完全相同的订单……奇怪的是，一切都按预期工作，并且问题没有重现。然后我注意到订单是通过“电话订单”下达的，这是一个后端脚本，允许商店工作人员编译新订单并在一个屏幕上进行收费/最终确定。系统通过使用 jquery 和 ajax 来实现这一点，以将所有内容都保留在屏幕上，而不必拥有多个“结帐页面”。
无论如何，通过电话订单脚本下了相同的订单，问题重现得很好。深入研究后，我注意到在客户下订单的“站点”端，购物车数据使用 PHP 函数进行序列化，然后 base64_encoded 并将“COMPRESSED”与订单一起存储在数据库中。
在电话订单方面，序列化是通过 php.js 序列化函数完成的，该函数假设同样模拟 php 序列化函数。然后将序列化的数据连同客户信息等一起发布到处理程序。向 CC 收费，并将订单保存到数据库中，就像在站点端一样。
进一步研究它，我比较了双方的两个“序列化”字符串的相同顺序，并且存在差异。在 php 方面，值 7½ 显示为“s:2:7½”，Javascript 版本显示为“s:3:7½”...
我已在此过程中涉及的所有页面上验证了我网站的字符编码为西方 (iso-8859-1)。
我能够解决这个问题......一旦将“坏”序列化对象传递给 php 以保存订单，然后我取消序列化它，然后将生成的数组/对象传递给运行转换器函数的递归函数（ char2html) 在每个值上，它将任何特殊字符转换为其实体名称代码，本质上 ½ 变为 ½ 并且  变成 Â。然后我使用 str_replace 删除任何“” 字符串，然后通过我的另一个函数（html2char）运行它，它覆盖了任何 &entityNames; 回到他们的实际性格。
一旦该函数完成运行，然后使用 php 的序列化函数重新序列化对象/数组，一切正常，电话订单脚本上的订单不再显示 Acric 字符。
因此，特别是我想弄清楚是否有某种方法可以在通过之前将javascript中½字符的UTF8版本强制转换为1字节版本（而不是javascript看到的两字节UTF8版本）到序列化函数，希望序列化函数将返回正确的字符串，不存在 UTF8 字符。
也有人说 php.js 序列化函数中有一些 UTF8ness 发生，但我的 JS 编码不够先进，无法确定序列化函数内部是否有某些东西在执行此操作......或者如何更改它如果有。
函数参考： http ://phpjs.org/functions/serialize:508
想法？