PHP无piso函数，乱码主因是编码不一致；需确认函数名、检查default_charset、脚本UTF-8无BOM、header设置及数据入口统一转码。
PHP 输出乱码，90% 是编码不一致导致的，不是函数本身的问题 —— piso 并非 PHP 内置函数，你可能想说的是 echo、print、var_dump 或某个自定义/第三方函数（比如拼写错误的 print_r）。先确认函数名是否正确，再排查编码链路。
确认你用的到底是不是 PHP 原生函数
PHP 没有叫 piso 的函数。常见混淆情况：
- 打错了：本意是
print、echo、print_r、var_dump或json_encode - 用了某框架/类库的私有方法（如某些旧 CMS 自定义了
piso_output()），需查其源码或文档 - 函数存在但未加载：比如依赖扩展未启用，或文件没
include/require
执行 var_dump(function_exists('piso'));，如果返回 bool(false)，就别在编码上浪费时间了 —— 先解决“函数不存在”这个根本问题。
输出中文乱码时必须检查的三个编码节点
PHP 输出乱码本质是「源码编码 → PHP 解析 → HTTP 响应 → 浏览器渲染」任一环节编码不匹配。重点盯死以下三项：
立即学习“PHP免费学习笔记（深入）”；
-
php.ini中default_charset建议设为"UTF-8"（不是utf8，少横杠可能导致 header 不生效） - PHP 脚本文件本身必须存为 UTF-8 无 BOM 格式（用 VS Code / Sublime 看右下角编码标识，Notepad++ 可在“编码”菜单转换）
- 发送响应头前必须调用
header('Content-Type: text/html; charset=utf-8');，且该语句不能有任何输出（包括空格、BOM、echo）在它之前
如果用了 mb_http_output('UTF-8')，要确保 mbstring 扩展已启用（php -m | grep mbstring 验证）。
调试时用 bin2hex() 和 mb_detect_encoding() 定位真实字节
别只看浏览器显示，直接看原始字节流才能排除渲染干扰：
- 用
echo bin2hex($str);查看变量实际存储的十六进制值，比如中文“你好”在 UTF-8 下是e4bda0e5a5bd，若看到c4e3bac3就是 GBK 编码的痕迹 - 用
echo mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true);猜测当前字符串编码（注意：这个函数不可靠，仅作辅助） - 强制转码：如果确认源数据是 GBK，但页面要 UTF-8，用
mb_convert_encoding($str, 'UTF-8', 'GBK')，而非iconv('GBK', 'UTF-8', $str)（后者遇到非法字符会失败）
使用 json_encode() 输出中文时默认转义，需加参数
很多人用 json_encode() 返回 JSON 接口，发现中文变成 \u4f60\u597d，这不是乱码，是标准 JSON 行为。要输出可读中文，必须传参：
echo json_encode(['msg' => '你好'], JSON_UNESCAPED_UNICODE);
漏掉 JSON_UNESCAPED_UNICODE 是高频疏忽。另外注意：json_encode() 对非 UTF-8 字符串输入会返回 false，务必用 mb_convert_encoding() 预处理。
真正麻烦的不是“怎么设 header”，而是当项目混用多种编码来源（数据库、文件、API 返回、用户输入）时，统一收口成 UTF-8 的时机和位置。别在每个 echo 前做转换，而应在数据进入 PHP 的第一入口（如 $_POST 接收后、PDO 查询后、fgets() 读取后）立刻转码并验证。
