PHP 8.5 全新 URI 扩展

Tinywan

发布于 2025-10-20 17:24:02

1030

概述

作为一名 web 开发者，我每天都离不开 URL 的处理——它们就像网络世界的基石，看似简单，却藏着无数坑。想象一下，你在构建一个网站时，突然发现 URL 解析出错，导致安全漏洞或数据混乱，那种感觉可真是不妙。今天，我想和大家聊聊 PHP 8.5 中即将推出的全新 URI 扩展。

URL 解析的那些“隐藏陷阱”

URL 是我们日常上网的必需品，对吧？它们由方案（scheme）、主机名（hostname）、路径（path）等部分组成，看起来再简单不过。但现实中，开发者们为了解析 URL，发明了成千上万的自定义解析器，每个都有自己的小脾气。更麻烦的是，有两个主要标准在主导这一切：2005 年的 RFC 3986（https://datatracker.ietf.org/doc/html/rfc3986），这是 URI 的经典标准；以及 WHATWG URL 活标准（https://url.spec.whatwg.org/），这是浏览器们追随的“现代派”。这两个标准竟然不兼容！如果你混用不同的解析器，尤其是那些不严格遵守标准的家伙，很容易酿成安全隐患。

举个例子，考虑这个输入：example.com/example/:8080/foo。根据 RFC 3986，它是一个有效的相对路径 URL；但在 WHATWG 标准下，如果没有基 URL，它就是无效的。然而，parse_url() 会把它解析成主机为 “example.com”、端口 8080、路径为 “/example/:8080/foo”，注意 8080 被重复放进了两个组件！来看看代码：

<?php

var_dump(parse_url('example.com/example/:8080/foo'));

/*
array(3) {
  ["host"]=> string(11) "example.com"
  ["port"]=> int(8080)
  ["path"]=> string(18) "/example/:8080/foo"
}
*/

看到没？这小错误就能让你的应用出大乱子。作为一个亲身经历过类似坑的开发者，我觉得是时候拥抱更安全的解决方案了。

欢迎新 API：安全、强大且易用

好消息来了！从 PHP 8.5 开始，一切都变了。PHP 将在标准库中引入一个全新的“URI”扩展，它总是可用，并且提供了符合 RFC 3986 和 WHATWG URL 标准的解析器。这不仅仅是解析，还能轻松修改 URL 的各个组件。太棒了！这让我想到，PHP 终于在 URL 处理上追上了时代，作为 web 开发的首选语言，它会更可靠。

让我分享一个简单的例子。假设我们有一个 URL：HTTPS://thephp.foundation:443/sp%6Fnsor/。我们可以用 Uri 类来处理它。首先，根据方案获取默认端口，然后移除默认端口，最后输出规范化后的 URL。注意，getter 方法默认会规范化 URL，而 Raw 变体则保持原样不变。

<?php

useUri\Rfc3986\Uri;

$url = new Uri('HTTPS://thephp.foundation:443/sp%6Fnsor/');

$defaultPortForScheme = match ($url->getScheme()) {
    'http' => 80,
    'https' => 443,
    'ssh' => 22,
    default => null,
};

// Remove default ports from URLs.
if ($url->getPort() === $defaultPortForScheme) {
    $url = $url->withPort(null);
}

// Getters normalize the URL by default. The `Raw`
// variants return the input unchanged.

echo $url->toString(), PHP_EOL;
// Prints: https://thephp.foundation/sponsor/
echo $url->toRawString(), PHP_EOL;
// Prints: HTTPS://thephp.foundation/sp%6Fnsor/

运行这个代码，你会发现它优雅地处理了大小写、百分比编码和端口问题。作为一个 PHP 爱好者，我特别喜欢这种 with-er 方法的设计——比如 withPort(8080)，它让修改 URL 变得像搭积木一样简单，却确保了安全性。这让我在开发时更有信心，不用再担心解析偏差。

幕后故事：用心打造，经得起时间考验

当然，好东西的诞生总有故事。今天，我想带大家看看这个 URI 扩展是怎么一步步成形的。这不仅仅是代码的堆砌，更是 PHP 社区对“做对，而不是做快”的承诺。作为 PHP 的忠实粉丝，我觉得这体现了开源精神的精髓。

一切从 2024 年 6 月开始，PHP Foundation 的开发团队成员 Máté Kocsis（https://github.com/kocsismate）发起了一个 RFC 讨论（https://wiki.php.net/rfc/url_parsing_api），提出引入新的 URL 解析 API。PHP 以强大的向后兼容性著称，所以这个 API 必须一击命中，不能留后患。它需要为社区服务十年以上，而不引入破坏性变更。结果呢？整整近一年时间，PHP Internals 邮件列表上发了超过 150 封邮件（https://news-web.php.net/php.internals/123997），加上各种聊天室的幕后讨论。社区专家们反复打磨 RFC，甚至细致到看似无关紧要的细节，确保实现不仅符合标准，还提供了一个干净、健壮的 API，帮助开发者选对工具。我们还提前规划了 Uri 命名空间，为未来添加更多 URI/URL 功能铺路。

2025 年 5 月，RFC 以 30:1 的压倒性票数通过。但工作远没结束——还需要实现和审查。Máté 聪明地选择了“站在巨人肩膀上”：用 uriparser 库（https://uriparser.github.io/）处理 RFC 3986 解析，用已经在 PHP 8.4 DOM API 中使用的 Lexbor 库（https://lexbor.com/）处理 WHATWG 解析。这避免了从零造轮子，我觉得这很明智。

开源协作的魅力：大家一起完善

开源的魔力就在于协作！在整合过程中，Máté 和 PHP Foundation 与上游维护者紧密合作，补充了库中缺失的功能。比如，这两个库原本都没有廉价复制内部数据结构的机制，而这是支持只读 PHP 对象克隆和修改组件（如 with-er 方法）所必需的。uriparser 甚至缺少修改解析 URL 组件的函数。现在，这些功能都已上游化，大家都能受益。

实现审查和测试由社区贡献者 Niels Dossche（https://github.com/nielsdos/）和 Ignace Nyamagana Butera（https://github.com/nyamsprod/）负责，他们甚至审查了上游库的新增功能。PHP Foundation 的创始成员兼银牌赞助商 Tideways（https://thephp.foundation/#sponsors_silver）赞助了工程时间，由 Tim Düsterhus（https://github.com/TimWolla/）贡献。在这个过程中，他们发现了上游库的几个预存 bug，并提交修复给维护者 Sebastian Pipping（https://github.com/hartwork）（uriparser）和 Alexander Borisov（https://github.com/lexborisov）（Lexbor），后者迅速审核并应用。看到这些名字，我不由得感慨：PHP 社区就是这样，通过集体智慧，让语言不断进步。作为开发者，我从中学会了耐心和协作的重要性。