HTML input type="url"网址格式校验？URL链接输入规范-html教程-PHP中文网

new url()比type="url"更靠谱，因其可主动捕获异常、精确控制反馈时机，并支持校验.protocol、.hostname等属性以满足业务规则；而type="url"仅静默解析且浏览器行为不一致。

$html input type=\$

input type="url" 不能当作 URL 格式校验的可靠手段，它只做最基础的 WHATWG URL 解析尝试，浏览器之间行为不一致，且完全不验证协议真实性、域名可达性或业务合规性。

为什么 new URL(input.value) 比 type="url" 更靠谱

浏览器对 type="url" 的校验逻辑，本质就是调用一次 new URL() 并捕获异常。但表单提交时的校验是静默的、不可控的，而 JS 中主动调用可以精确控制错误处理和反馈时机。

直接 new URL("example.com") 会抛 TypeError（缺协议），但 new URL("//cdn.example.com") 合法（协议相对 URL）
new URL("https://localhost:3000") 在 Chrome/Firefox 成功，Safari 16.4 之前可能失败
new URL("https://例.com/测试") 会自动转为 Punycode + UTF-8 编码，但输入未编码的 Unicode 可能被某些浏览器拒绝
校验后可进一步检查 .protocol、.hostname、.pathname 等属性，比如强制要求 .protocol === 'https:' 或 .hostname.endsWith('.mycompany.com')

pattern 属性能补多少短板

pattern 只在 type="url" 上生效，但它不是万能补丁：浏览器会自动给正则加上 ^ 和 $，你不能再自己加；而且它只校验字符串结构，不校验是否真能被解析为 URL。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

想限制 HTTPS 开头：pattern="https?://[^\s]+$"（注意 [^\s]+ 防空格，+ 表示至少一个字符）
匹配中文路径需先 URL 编码再写正则，否则跨浏览器行为不稳定；更稳妥的是用 encodeURIComponent() 在 JS 中预处理
pattern 不校验空值，仍要配 required
用户粘贴带换行或首尾空格的链接时，pattern 会直接失败——建议在 input 或 blur 事件里用 JS trim() 预处理

移动端键盘与粘贴行为的坑

type="url" 在 iOS Safari 和 Android Chrome 中通常唤起带 .com 快捷键的软键盘，但这不是保证；更隐蔽的问题是粘贴行为——用户从微信、邮件复制的 URL 常含首尾空格或不可见字符，type="url" 会静默截断，既不报错也不触发 :invalid 伪类。

监听 blur 事件手动 trim() 并比对原始值：if (input.value.trim() !== input.value) { console.warn('URL 含首尾空格') }
iOS 17+ 对无协议输入（如 github.com）可能降级为普通键盘，inputmode="url" 是必要双保险
Android WebView（尤其旧版）可能完全忽略 type="url"，始终弹出文本键盘
部分国产浏览器（如 QQ 浏览器）对 type="url" 支持不一致，inputmode 能提升兼容性

服务端必须重做全部校验

前端任何校验都可被绕过，服务端才是最终防线。不要假设传来的 URL 已“合法”——它可能来自禁用 JS 的用户、curl 直接请求、或恶意构造的 payload。

重新调用语言原生 URL 解析器（如 Node.js 的 new URL()、Python 的 urllib.parse.urlparse()），并捕获所有异常
白名单检查协议：git://、ftp://、javascript:、data: 必须显式拒绝
DNS 解析验证（可选但推荐）：对主机名执行 dns.lookup() 或类似操作，避免 http://this-domain-does-not-exist-12345.com
路径规范化与特殊字符过滤：防止开放重定向、XSS 注入（如 ?redirect=javascript:alert(1)）
长度限制、编码合法性检查（如非法 UTF-8 字节序列）、禁止空字节等底层安全细节