本文深入解析前端开发中常见的数据传输难题：当使用 XMLHttpRequest 配合 FormData 发送包含 HTML 片段（例如标签）的 JSON 字符串时，为何服务端接收到的数据会出现标签丢失、字符串被意外截断的现象，并为您提供一套安全、规范且一劳永逸的解决方案。
彻底解决：使用 FormData 发送含 HTML 的 JSON 数据时标签丢失与截断问题
许多开发者在实际项目中都曾遇到这个令人困惑的场景：前端明明已将一段包含完整 HTML 标签（如 ``）的 JSON 字符串通过 FormData 提交，但服务器端解析后却发现标签神秘消失，只留下诸如“testStarttestEnd”的残缺文本。问题根源究竟何在？事实上，这并非服务器主动“过滤”了你的标签，而往往是由于字符编码处理不当与数据传输协议语义混淆所引发的典型“误会”。
问题根源剖析：未受保护的 JSON 字符串遭遇 HTML 特殊字符
当你尝试通过 FormData 提交一个内嵌了 HTML 代码片段的 JSON 字符串时，如果该 HTML 片段中的尖括号（`<`、`>`）、引号（`‘`、`“`）等特殊字符未被正确转义，问题便会随之产生。一个常见的误解是：FormData 会自动处理这些细节。然而事实是：它并不会。`FormData.append()` 方法仅仅将你提供的字符串作为一个普通的文本字段值进行发送，它不会自动执行 JSON 序列化或 URL 编码。
于是，这个携带“原生”特殊字符的字符串会被原样发送至服务器。在某些服务器环境（尤其是一些特定的 PHP 配置或中间件）中，出于安全防护机制或默认的协议解析规则，这些尖括号可能被误判为实际的 HTML 标签起始符从而遭到过滤或转义处理。更严重的情况是，未转义的引号可能会错误地界定 `multipart/form-data` 格式中字段值的边界，直接导致后续数据被截断。最终，你得到的就是一个不完整的字符串。
标准解决方案：严格遵守 JSON 数据传输协议
破解这一困境的核心在于坚守一个基本原则：确保通过网络传输的是一个完全合法、格式自洽的 JSON 字符串，并明确告知服务端应严格按照 JSON 协议来解析它。任何试图绕过此原则的“技巧性”方案，都可能为系统埋下隐患。
具体实施可分为以下三个清晰、可操作的步骤：
第一步：前端发送前，强制执行 JSON 标准化与序列化
即便你确信从 `FileReader` 读取的 `e.target.result` 已经是字符串格式，也强烈建议进行一次“验明正身”的标准化处理。先解析再序列化的过程，能强制性地将所有特殊字符进行符合 JSON 规范的转义。
reader.onload = (e) => {
try {
const rawJson = e.target.result;
// 关键步骤：验证并标准化JSON（虽为可选但强烈推荐）
const parsed = JSON.parse(rawJson);
const safeJsonString = JSON.stringify(parsed); // 此时，字符串内的引号、反斜杠、尖括号等均已正确转义
const fdata = new FormData();
fdata.append("json", safeJsonString); // ✅ 传入这份“格式合格”的JSON字符串
const request = new XMLHttpRequest();
request.addEventListener("load", () => {
console.log("Server response:", request.response);
});
request.open("POST", "import_export_quiz.php");
request.send(fdata);
} catch (err) {
console.error("Invalid JSON in file:", err);
}
};
第二步：后端接收时，从原始输入流读取并正确解析 JSON
在服务端，务必避开一个常见陷阱——避免直接使用 `$_POST[“json”]` 来获取数据。PHP 的 `$_POST` 超全局数组主要设计用于处理 `application/x-www-form-urlencoded` 格式的数据，对于 `multipart/form-data` 中包含复杂 JSON 结构的字段，其支持并不可靠。标准做法是从 PHP 的原始输入流中获取数据。
// import_export_quiz.php
$jsonInput = file_get_contents(‘php://input’); // 首选方案：获取原始POST数据流
// 或者，如果明确是FormData中的特定字段，也可谨慎尝试：
// $jsonInput = $_POST[‘json’] ?? ‘’;
$data = json_decode($jsonInput, true);
if (json_last_error() !== JSON_ERROR_NONE) {
http_response_code(400);
echo json_encode([‘error’ => ‘Invalid JSON’]);
exit;
}
// ✅ 至此，$data 已是完整无误的PHP关联数组，所有HTML标签均被完整保留
第三步：响应返回前端，保持 JSON 数据格式的统一性
数据处理完毕后，返回给前端的响应也应保持规范。直接使用 `echo` 输出未经处理的字符串可能引发 XSS 跨站脚本攻击或字符编码问题。正确的做法是重新将数据编码为 JSON 格式后输出。
header(‘Content-Type: application/json; charset=utf-8’); echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
常见误区澄清与补充要点
在寻求解决方案的过程中，你可能会接触到一些替代方案，在此有必要进行厘清：
- Base64 编码并非最佳实践：诚然，将整个 JSON 字符串进行 Base64 编码后再传输，可以规避特殊字符问题。但这会引入额外的编码与解码开销，增加数据传输量。更重要的是，它掩盖了数据传输协议本身应被正确使用的核心问题，属于“治标不治本”的方案。除非是为了兼容极其古老的系统，否则不推荐采用。
- 切勿依赖 $_POST 直接获取 JSON 字符串：这一点值得再次强调。对于 `multipart/form-data` 格式中的非标准字段（如完整的 JSON 字符串），`$_POST` 数组的行为具有不确定性，是导致数据损坏的主要风险点之一。
- HTML 标签无需额外进行 HTML 实体编码：你不需要手动将 `<` 转换为 `<`。因为 `JSON.stringify()` 方法已经为我们妥善处理了字符串中的所有特殊字符，确保它们在 JSON 字符串的语境下是安全且语义正确的。
归根结底，整个问题的本质，是混淆了“表单字段值”和“结构化 JSON 数据”这两层不同的语义边界。表单（FormData）负责数据的封装与传输，而 JSON 负责描述复杂的数据结构，二者应各司其职。只要前端坚持使用 `JSON.stringify()` 生成标准化的数据载荷，后端坚持使用 `json_decode(file_get_contents(‘php://input’))` 这套组合来解析，就能构建起一个坚固、可靠的数据传输通道。无论是包含 HTML 标签的富文本、复杂的多层嵌套数组，还是各种特殊符号，都能被 100% 完整无误地传递。这套经过实践检验的“黄金组合”，才是值得信赖的标准解决方案。
