parse_url()无法自动解码国际化域名（IDN），返回的host可能是Punycode（如xn--fsq.xn--0zwm56d）而非可读形式（如例子.中国），需用idn_to_utf8()转换；该函数在PHP 5.4+内置，对非Punycode输入原样返回，安全可靠。
PHP中用parse_url()直接获取域名会出错
国际化域名（IDN）如 例子.中国 或 café.fr 在URL中实际以Punycode编码传输（如 xn--fsq.xn--0zwm56d），但parse_url()只做简单字符串拆分，不会自动解码。直接取host字段得到的是Punycode形式，不是用户可读的原始域名。
常见错误现象：显示 xn--fsq.xn--0zwm56d 而非 例子.中国；浏览器地址栏正常，后端却存错或校验失败。
- 必须在解析后手动调用IDN转换函数，不能依赖
parse_url()原样输出 -
parse_url()对https://café.fr/path返回的host是caf%C3%A9.fr（URL编码）还是xn--caf-dma.fr，取决于输入是否已Punycode化——PHP本身不干预，完全看传入的URL原始形态 - 若从
$_SERVER['HTTP_HOST']或$_SERVER['SERVER_NAME']读取，Apache/Nginx通常已转为Punycode，需解码；而某些代理或客户端可能传原始Unicode，此时反而不能直接idn_to_ascii()
用idn_to_utf8()把Punycode转回可读域名
PHP 5.4+ 内置idn_to_utf8()，专门将ASCII形式的Punycode（如xn--fsq.xn--0zwm56d）还原为UTF-8 Unicode域名（例子.中国）。这是处理IDN最稳妥的一步。
注意它不处理URL编码（如caf%C3%A9.fr），也不校验格式，仅做IDN层转换。
立即学习“PHP免费学习笔记（深入）”；
- 推荐用法：
idn_to_utf8($host, IDNA_NONTRANSITIONAL_TO_ASCII, INTL_IDNA_V2)—— 显式指定v2标准，兼容性更好 - 若传入非Punycode字符串（如已是
例子.中国），函数默认返回原值，安全；但旧版本PHP（@抑制或先用preg_match('/^xn--/')粗筛 - Windows下需启用
intl扩展，否则函数不存在；可用function_exists('idn_to_utf8')检测
从$_SERVER取域名时要区分来源
$_SERVER['HTTP_HOST']、$_SERVER['SERVER_NAME']、$_SERVER['REQUEST_URI']三者内容差异大，IDN处理时机不同。
-
$_SERVER['HTTP_HOST']：客户端发来的Host头，现代浏览器已转Punycode，适合idn_to_utf8()直转 -
$_SERVER['SERVER_NAME']：由Web服务器配置决定，通常不含IDN（Apache默认不支持Unicode ServerName），基本不用作IDN来源 -
$_SERVER['REQUEST_URI']：完整路径，含查询参数，需先parse_url()提取host，再判断是否Punycode - 如果用Nginx + FastCGI，确保
fastcgi_param SERVER_NAME $server_name未被误设为$host，否则可能混入客户端传的Punycode
验证和存储前务必统一编码形式
IDN处理最易忽略的点：同一域名在不同环节可能以Unicode、Punycode、URL编码三种形式存在，混用会导致匹配失败（如数据库查例子.中国却存了xn--fsq.xn--0zwm56d）。
- 建议统一策略：接收时立即
idn_to_utf8()转为Unicode存储和展示；对外输出（如生成链接）再用idn_to_ascii()转回Punycode（浏览器能识别） - MySQL存储时用
utf8mb4字符集，否则例子.中国中的中文或emoji会截断 - Redis或文件缓存键名避免直接用Unicode域名（部分旧客户端不友好），可用
spl_object_hash()或md5($domain)做映射，而非硬编码Punycode
IDN真正的复杂点不在转换函数，而在整个请求链路中编码状态不可见——从DNS解析、TLS SNI、HTTP头、Web服务器配置到PHP运行时，任何一环静默转码都会让开发者误以为“这里应该已经是Unicode了”。动手前先用bin2hex()打个日志看真实字节流，比猜靠谱得多。
