短链接还原php后地址不对_检查加密密钥是否匹配【操作】

短链接跳转后目标URL错误，主因是密钥不一致、base64 padding缺失、未校验Hmac签名、编解码顺序颠倒；需逐一排查密钥配置、补全padding、强制签名验证、严格按base64_decode→urldecode→json_decode顺序处理。

短链接跳转后目标 URL 不对，先查 hash_hmac 密钥是否一致

php 短链接还原逻辑常依赖 hash_hmac 生成签名来验证和反解原始 URL。如果还原出的地址错误（比如多出字符、截断、乱码或指向错误域名），大概率是加解密环节的密钥不匹配——不是“没配”，而是“配错了位置”或“类型不一致”。

• 检查短链接生成时用的密钥（如 $secret_key = 'abc123'）和还原时用的是否完全相同，包括大小写、空格、不可见字符
• 确认两端 PHP 文件没有因 include 路径问题加载了不同配置文件，比如一个读 config.php，另一个读了 config.local.php
• 如果密钥来自环境变量（如 $_ENV['SHORT_URL_SECRET']），需验证该变量在 CLI 和 Web SAPI 下是否都已正确加载（phpinfo() 或 var_dump($_ENV) 查看）

还原函数里 base64_decode 处理前是否补足了 padding

短链接 ID 经常是 base64url 编码（去掉了 +、/，并省略末尾 =）。直接丢给 PHP 原生 base64_decode 会失败或解出乱码，导致后续解析 URL 出错。

• 还原前必须手动补全 padding：把 - 换成 +、_ 换成 /，再按长度补 = 到 4 的倍数
• 错误示例：base64_decode('aGVsbG8') → 返回 false（缺 padding）；正确应为 base64_decode('aGVsbG8=')
• 推荐封装处理函数，避免每次手写：

function urlsafe_b64decode($input) {     $remainder = strlen($input) % 4;     if ($remainder) {         $input .= str_repeat('=', 4 - $remainder);     }     return base64_decode(strtr($input, '-_', '+/')); }

还原时没校验 HMAC 签名就直接解密，导致恶意篡改被当作合法请求

很多实现只做“能解出来就行”，跳过了签名验证。攻击者可随意修改短链 ID 后半段，伪造出看似合法但目标 URL 完全不同的链接（例如把 https://a.com 变成 https://evil.com）。

• 还原流程必须是：取 ID → 拆出数据体和签名 → 用相同密钥和算法重新计算 HMAC → 对比是否恒等（用 hash_equals()，防时序攻击）
• 签名算法要统一，常见是 sha256，别一端用 sha1，另一端用 sha256
• 如果数据库存的是明文 URL + 独立签名字段，注意还原时不能只靠 ID 反查，必须验证签名后再取对应记录

URL 解码顺序错乱：先 urldecode 再 json_decode，还是反过来？

原始 URL 被编码进短链 ID 前，通常会先 json_encode（含双引号、斜杠转义），再 urlencode（处理中文、问号等）。还原时顺序反了，就会出现 %22https%3A%2F%2F... 这类嵌套编码残留。

立即学习“PHP免费学习笔记（深入）”；

• 正确顺序：base64 解码 → urldecode → json_decode
• 典型错误：json_decode(urldecode(base64_decode($id))) ✅；urldecode(json_decode(base64_decode($id))) ❌（此时 JSON 字符串本身含 % 编码，json_decode 会失败或误解析）
• 若原始存储用了 rawurlencode，还原时就得用 rawurldecode，二者不兼容

密钥不一致、padding 缺失、跳过签名校验、编解码顺序颠倒——这四个点覆盖了 90% 的“还原地址不对”问题。尤其注意密钥是否真的被两个上下文同时读到，而不是你以为它在那儿。