PHP执行SQL查询如何格式化输出-php教程-PHP中文网

安全调试应按场景选择输出方式：开发用+print_r；防xss用htmlspecialchars(var_export($result, true))；api用json_encode($data, json_unescaped_unicode | json_pretty_print)；后台展示用带htmlspecialchars的表格函数，并统一数据提取模式。

php执行sql查询如何格式化输出

直接输出数据库查询结果到页面，不加处理容易导致 HTML 解析错乱、XSS 漏洞或结构不可读——print_r 和 var_dump 能看，但不能用；echo 循环拼接易出安全问题；json_encode 又不适合前端调试。关键不在“能不能输出”，而在“以什么形式、在什么场景下安全又清晰地输出”。

用 `print_r` + `<pre class="brush:php;toolbar:false;"></pre>` 快速调试数组结构

这是开发阶段最轻量、最常用的组合，适合本地或测试环境查看原始数据形状。

print_r 本身不转义 HTML 字符，如果字段值含 <script></script> 或引号，可能破坏页面结构——必须包裹在 <pre class="brush:php;toolbar:false;"></pre> 内，并确保输出前没被浏览器误解析
正确写法是：echo "<pre class="brush:php;toolbar:false;">"; print_r($result); echo "</pre>";，不能写成 print_r("<pre class="brush:php;toolbar:false;">" . $result . "</pre>")（print_r 不接受字符串拼接）
若 $result 是 PDOStatement 对象或 mysqli_result 资源，得先调用 fetchAll() 或 mysqli_fetch_all() 转成数组，否则 print_r 只显示资源 ID

用 `var_export` + `htmlspecialchars` 防 XSS 并保留类型信息

比 print_r 更严谨，能体现 null、bool、字符串引号等细节，且经 htmlspecialchars 处理后可安全输出到 HTML 页面。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

不要用 var_dump 直接套 htmlspecialchars：因为 var_dump 输出含 HTML 标签（如 <small></small>），转义后反而更难读
推荐写法：echo "<pre class="brush:php;toolbar:false;">" . htmlspecialchars(var_export($result, true)) . "</pre>";
var_export($result, true) 返回的是可执行的 PHP 代码字符串，true 参数表示返回而非直接输出，这是关键
注意：如果 $result 含资源（如文件句柄、数据库连接），var_export 会报错，务必确认是纯数组或对象

用 `json_encode` 输出标准 JSON 供 API 或前端消费

这不是“格式化给人看”，而是“格式化给程序用”。很多开发者误把 json_encode 当调试工具，结果看到一堆转义字符或 null，其实是没设对选项或没清理数据。

必须加 JSON_UNESCAPED_UNICODE，否则中文变 \u4f60\u597d；加 JSON_PRETTY_PRINT 才有缩进
常见错误：直接 json_encode($stmt) —— PDOStatement 对象不能直接序列化，得先 $stmt->fetchAll(PDO::FETCH_ASSOC)
数字类型要干净：数据库里 DECIMAL 字段在 PHP 中常为字符串，json_encode 会当字符串输出。加 JSON_NUMERIC_CHECK 可自动转数字，但只对纯数字字符串有效（如 "123.45" 可转，"123.45 USD" 不行）
空值和布尔值会被正确编码，但要注意前端是否处理 null —— 这不是 PHP 的问题，是接口契约问题

自定义表格函数用于管理后台简单展示

不用框架时，快速搭个后台数据预览页，表格比纯文本直观得多，但别手写 <table> 拼接——容易漏闭合、字段错位、没转义。 <ul><li>核心逻辑就三步：检查 <code>$result 是否为非空数组 → 提取第一行键名作表头 → 每行循环生成 <tr><td> <li>每列值必须过 <code>htmlspecialchars()，否则用户存了 @@##@@ 就完了

示例骨架：

if (!empty($result) && is_array($result)) { echo "<table border="1">"; $keys = array_keys($result[0]); echo "<tr>" . implode("", array_map(fn($k) => "<th>" . htmlspecialchars($k) . "</th>", $keys)) . "</tr>"; foreach ($result as $row) { echo "<tr>" . implode("", array_map(fn($v) => "<td>" . htmlspecialchars($v) . "</td>", $row)) . "</tr>"; } echo "</table>"; }

不推荐在生产 API 中用这个输出，它本质是 HTML 片段，不是结构化数据

真正容易被忽略的点是：没有统一的数据提取入口。今天用 mysqli_fetch_all($res, MYSQLI_ASSOC)，明天换 PDO 写成 fetch(PDO::FETCH_NUM)，输出结构就变了——json_encode 结果可能多出数字键，表格列顺序错乱。与其反复补救输出，不如在获取结果那一刻就约定好模式。