php获取域名乱码主因是idn域名未解码：$_server['http_host']返回xn--开头的punycode字符串，需用idn_to_utf8()转为utf-8；若非xn--开头却乱码，则为输出环境编码不匹配；还需排查nginx/apache透传限制及终端utf-8支持。
PHP 获取域名时出现乱码，基本可以确定是 $_SERVER 变量中原始值本身含非 ASCII 字符（比如中文注册域名、IDN 域名），而 PHP 默认未做 Punycode 解码或字符编码转换导致的。直接用 $_SERVER['HTTP_HOST'] 或 $_SERVER['SERVER_NAME'] 读取，拿到的是 ASCII 兼容编码（ACE）格式的 xn--xxx 字符串，不是人眼可读的中文/日文等原生域名。
确认是否为 IDN 域名（xn-- 开头）
先检查实际获取到的域名字符串是否以 xn-- 开头——这是 Punycode 编码的明确标志，说明浏览器已将国际化域名（如 “例子.中国”）自动转为 ASCII 兼容格式发送给服务器：
var_dump($_SERVER['HTTP_HOST']); // 输出类似：xn--fsq082e.xn--fiqs8s
如果是，乱码不是 PHP 解析错误，而是你没做反向解码；如果不是 xn-- 开头却显示乱码（如 符号），则大概率是终端/日志输出环境编码不匹配，或字符串被错误地用 UTF-8 解释了 GBK 编码内容。
用 idn_to_utf8() 进行 Punycode 解码
PHP 自带 idn_to_utf8() 函数，专门用于把 xn-- 格式的域名还原为 Unicode 字符串（UTF-8 编码）：
立即学习“PHP免费学习笔记（深入）”；
- 确保 PHP 已启用
intl扩展（idn_to_utf8()依赖它；可通过extension=intl在 php.ini 中开启） - 函数默认使用
IDNA_DEFAULT模式，兼容大多数场景；若需严格 RFC 5891 行为，可显式传参 - 注意该函数返回
false表示解码失败（如非法 Punycode），务必检查返回值
$host = $_SERVER['HTTP_HOST'] ?? '';
$decoded = idn_to_utf8($host);
if ($decoded === false) {
$decoded = $host; // 解码失败时回退原值
}
echo $decoded; // 如：例子.中国避免在 CLI 或日志中误判乱码
很多“乱码”其实只出现在 CLI 脚本执行、error_log 输出或某些 IDE 控制台里，本质是显示环境不支持 UTF-8 或未正确声明编码：
- CLI 下运行 PHP 脚本时，终端本身可能默认用 GBK/Latin-1 渲染 UTF-8 字符 → 显示为 或方块
- 写入文件前未指定
mb_internal_encoding('UTF-8')，且字符串含多字节字符，可能导致截断或替换 -
error_log()不处理编码，直接按字节写入，若日志查看器用错编码打开，就会看到乱码
验证方式：把解码后的域名 echo 到浏览器 HTML 页面（并设置 <meta charset="utf-8">），如果显示正常，说明问题出在输出环境而非 PHP 处理逻辑。
注意 Nginx/Apache 的 Host 头透传限制
部分老旧 Web 服务器或代理（尤其未配置 underscores_in_headers on 的 Nginx）会静默丢弃含下划线或非标准字符的 Host 头，导致 $_SERVER['HTTP_HOST'] 为空或被替换成默认值，后续逻辑误判为异常。更隐蔽的是：某些 CDN 或 WAF 会在转发请求时主动对 Host 头做标准化（如强制转小写、过滤非字母数字字符），破坏原始 Punycode 格式。
排查方法：在 PHP 中打印 getallheaders()（或启用 apache_request_headers()）对比原始 Host 和 $_SERVER['HTTP_HOST'] 是否一致；若不一致，问题不在 PHP 层，而在上游服务配置。
IDN 域名解码看似简单，但实际涉及 intl 扩展可用性、Web 服务器透传行为、终端渲染链路三重依赖，任一环节断裂都会表现为“乱码”。最常被忽略的是：以为自己在修 PHP，结果发现是 Nginx 把 xn-- 给截了，或者终端根本没设 UTF-8。
