【问题标题】:URL encoding a very long link and sending via emailURL 编码很长的链接并通过电子邮件发送
【发布时间】:2014-10-13 11:20:18
【问题描述】:

我正在通过电子邮件发送一个链接,该链接相当长,因此经过一些谷歌搜索后,它建议发送带有链接作为实际链接的富文本电子邮件 - 我测试了此解决方案,但遇到了其他问题:

这是链接:

www.example.com/bridge/aHR0cDovL2QxbW8zdHp4dHRhYjNuLmNsb3VkZnJvbnQubmV0L3N0YXRpYy9yZW50YWxzLzcyMC9WSU5UMDA2Ni5tcDQ%2FaWQ9MTI3NSZFeHBpcmVzPTE0MTM0NTMyMjcmU2lnbmF0dXJlPUZvWDJvU2ZjVURwbjlIMzhWN3FCR0NqMWhMUTEyZGNaaXN%2BQ2lOTGZyVDVYWkNyeXZCejBNZEtQUjZFdHU2SmsySlI3OU04dldYeE1VRVRwNVhJNlgwVERLeHQyLWhUZUdQd0JPamZqLW9%2BaTBoM0hNb29pU0ZPZmE1MFhXMXhoLWZGNFlOMVFqdTY2UlhqU1oyODVSY2tpUkFxeU1zTFJDNlptdDI0ZEhNSmlITVI4Sld5QXhEOVlVcmxOOHc1OWxkVHkzNG5ySmFPazQySk1Ca2VQYnpUSVBxZWU5MXg0dmM3QVlsby1lampldzZodVBQVWx%2BWUxIbWhRYTJEdy12RFhqNFJ2blFYWVdUdnhkRmxBMXNTREgzRzdrRjg2N25tT240ZGNvTE53SW1VUWNoNH4xSTUtQ3ZudVQwQUh6UnZSc2FnbFY2US1IRmdKUUNTbzNCUV9fJktleS1QYWlyLUlkPUFQS0FJSTVPQlNRRUdZVzNSNVVB

链接是通过base 64编码一个字符串构建的(为了让它看起来更漂亮,我不喜欢只是URL编码的URL的外观)然后对这个进行url编码:

$url = urlencode(base64_encode($string));

然后我通过富文本电子邮件发送此内容,但部分 URL 正在被替换,例如。

DQ%2Fa

变成

DQ/a

为什么会发生这种情况,有办法解决吗?

我只是通过 OSX Mail 发送链接,但将来它会通过 Hotmail、Gmail 等发送。

【问题讨论】:

  • 您是通过 HTML 邮件发送的吗?似乎它可能会被转换回来。 %2F 确实是一个反斜杠。 obkb.com/dcljr/charstxt.html
  • 不要建立这样的长网址。浏览器对它们有长度限制,并且会默默地截断过长的。您可能会面临数据损坏的风险。
  • @MarcB 他在 2000 个字符内是安全的。他发布的链接大约有 600-700 个字符,所以我认为这很好。
  • 我需要构建长 URL,这是 S3 的策略。它只是通过 OSX 邮件发送的。
  • 你在 url 中传递什么样的数据?

标签: php email


【解决方案1】:

挖掘恐龙,但这个问题在 2021 年仍然存在。

当我使用富文本通过 OSX Mail 客户端发送长链接时,它们将被解码。长链接在 Sketch、Figma 等软件中很常见。

我能找到的唯一解决方案是使用纯文本发送邮件,但这可能不适用于某些人。

我在 Big Sur,我从没想过会遇到这样的问题。 有没有其他解决方法?

【讨论】:

  • 链接必须那么长吗?可以将长链接翻译成短链接(256chrs URL),访问时可以传递给原始长链接吗?
  • 链接是软件自动生成的,我无法控制。 URL 包含一个哈希值和共享设计文件的特定位置,这就是这些 URL 通常很长的原因。
猜你喜欢
  • 1970-01-01
  • 2016-04-08
  • 2014-07-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-09-23
相关资源
最近更新 更多