使用 HTML 文本预填充 Gmail 撰写屏幕
我发现要打开 Gmail 撰写屏幕，您必须登录并打开以下链接：
替换填写撰写表单上相应位置的变量。但是，如果我想输入正文多行文本或换行符，即使我对它进行 urlencode，它也不起作用。这里有什么想法吗？
I found out that in order to open a Gmail compose screen you'd have to be logged in and open the following link:
Replacing the variables fills in the corresponding places on the compose form. However if I want to enter into the body multiline text or line breaks its just not working even if I urlencode it. Any ideas here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
检查您的 UrlEncode 方法是否确实将换行符转换为“%0a”。以下是 2 行电子邮件正文的示例：
https://mail.google.com/mail/?view=cm&ui=2&tf=0&fs=1&to= WHOEVER%40COMPANY.COM&su=SUBJECTHERE&body=LINE1%0aLINE2
Check that your UrlEncode method really translates newlines into "%0a". Here's an example of a 2-line email body:
https://mail.google.com/mail/?view=cm&ui=2&tf=0&fs=1&to=WHOEVER%40COMPANY.COM&su=SUBJECTHERE&body=LINE1%0aLINE2
Gmail 支持 HTML5 的 registerProtocolHandler() 发出。
示例：
这就是 Gmail 希望您使用的内容。当然，修改特定于域的撰写 URI 的开头。
但是，它会自行加载撰写表单（不与收件箱页面集成）。因此，如果您希望将撰写表单集成到收件箱页面中，则需要改为加载：
。但是，这需要您首先解析 mailto URI 以获取 hfvalues 并修复它们的百分比编码，以确保它们适合在 HTTP URI 中发送。有关详细信息，请参阅下文。
现在，Gmail 对 HTML5 撰写 URI 的作用是对 url 参数进行百分比解码以获取 mailto URI。然后，它解析 mailto URI 以获取 hfvalues。然后，它使用这些 hfvalues 构建一个 URI（例如收件箱集成的 URI）并将您重定向到该 URI。
Gmail 的 HTML5 方法的问题在于，它不会将 hfvalues 中的“+”字符百分比编码为“%2B”。最终结果是 mailto URI 中的“+”字符（它们不是 mailto URI 中的空格）在 Gmail 撰写表单中显示为空格。
要解决 Gmail 错误，您只需这样做：
相反。
该错误几年前就已报告，但 Gmail 拒绝修复。
您还应该看到，对于收件箱集成的撰写 URI，如果您有 mailto URI“mailto:?subject=1+2”，则需要确保在撰写 URI 中发出 su=1%2B2，而不是发出 su=1%2B2苏=1+2。后者将导致主题字段中出现空格而不是“+”。这部分不是 Gmail 的错误。这就是 HTTP 的工作原理。
您可以查看my Gmail Compose Extension for Opera的源代码（解压缩）以了解如何使用我采用 HTML5 方式。这很简单。但是，它不包含 + 到 %2B 解决方法。
但是，您可以看到我正在测试的扩展程序的新版本（只需要有人测试首选项中的特定于域的选项）以进行更高级的处理。这个使用 我的自定义通用 mailto URI 解析器 来标准化 mailto URI 及其 hfvalues 以处理“+”情况，不安全字符和重复的 hfvalues。它还提供了一个选项来选择是否要使用 HTML5 撰写 URI。
您还可以查看此 Opera 的用户 JS 脚本了解如何操作。
对于前面提到的重复 hfvalue 问题和其他 mailto URI 内容，请参阅使用的 我的 mailto URI 规范针对 RFC6068 的研究和反馈。
注意：仅仅因为 Gmail 用户打开了富文本编辑功能，并不意味着 Gmail 将接受撰写 URI 中的 HTML 标记并按此处理。这一切都被解释为文本。
Gmail has support for what HTML5's registerProtocolHandler() emits.
Example:
That's what Gmail expects you to use. Modify the beginning for the domain-specific compose URI of course.
However, that loads the compose form by itself (not integrated with the inbox page). So, if you want the compose form integrated into the inbox page, you need to load:
instead. But, that requires you to parse the mailto URI first to get the hfvalues and fix their percent-encoding to make sure they're fit to send in an HTTP URI. See below for more info on that.
Now, what Gmail does with the HTML5 compose URI is percent-decode the url param to get the mailto URI. Then, it parses the mailto URI to get the hfvalues. Then, it uses those hfvalues to build a URI like the inbox-integrated one and redirects you to it.
The problem with Gmail's HTML5 method is that it doesn't percent-encode '+' characters in the hfvalues to "%2B". The end result of this is that '+' characters in the mailto URI (they're not spaces in a mailto URI) come out as spaces in the Gmail compose form.
To work around the Gmail bug, you just do:
instead.
The bug was reported years ago, but Gmail refuses to fix it.
As you should also see, for the inbox-integrated compose URI, if you had the mailto URI "mailto:?subject=1+2", you need to make sure that you emit su=1%2B2 in the compose URI and not su=1+2. The latter will cause a space to be in the subject field instead of '+'. This part isn't a bug with Gmail. That's just how HTTP works.
You can see the source of my Gmail Compose Extension for Opera (unzip it) to see how I do the HTML5 way. It's very simple. But, it doesn't contain the + to %2B workaround though.
However, you can see the newer version of the extension that I'm testing (just need someone to test the domain-specific option in preferences) for more advanced handling. This one uses my custom, generic mailto URI parser to normalize the mailto URI and its hfvalues to handle the '+' case, unsafe characters and duplicates hfvalues. It also offers an option to choose whether you want to use the HTML5 compose URI or not.
You can also take a look at this User JS script for Opera for how to do things.
For the duplicate hfvalue issue mentioned earlier and other mailto URI stuff, see my mailto URI spec, which was used for research and feedback for RFC6068.
Note: Just because the Gmail user has rich text editing turned on, that doesn't mean that Gmail will accept HTML markup in the compose URI and treat it as such. It's all interpreted as text.
我使用标准 javascriptencodeURIComponent() 来编码多行正文。它起作用了。
另外，如果想要预填充通用 Gmail 而不是应用程序域特定帐户，请改用以下 URL：
https://mail.google.com/?view=cm&fs=1&tf=1&....
I used standard javascript encodeURIComponent() for encoding multiline body. It worked.
Also those who want to prepopulate generic gmail and not app domain specific account, use this URL instead:
https://mail.google.com/?view=cm&fs=1&tf=1&....
谢谢你的提示。其他回复中未具体说明的一件事是，如果您使用多个帐户（例如个人帐户和使用 Google Apps 的专业帐户）登录 Gmail，请使用
https://mail.google.com/ a/domain.com/（而不是https://mail.google.com/mail/）允许您指定用于发送邮件的邮箱。否则 Gmail 只会加载您首先登录的帐户。Thanks for that tip. One thing that hasn't been specified in other replies is that if you're logged into Gmail with multiple accounts, like a personal account and a professional one with Google Apps, using
https://mail.google.com/a/domain.com/instead ofhttps://mail.google.com/mail/allows you to specify which mailbox to use for sending the message. Otherwise Gmail just loads the account you logged-in first.目前（2014 年 2 月），要使用“收件人”和“主题”字段预填充撰写屏幕，请使用：
注意：
cs=wh很重要，因为撰写超链接使用cs=b，它不会自动填充。At present (February 2014), to prepopulate the compose screen with to and subject fields, use:
Note:
cs=whis significant, as the compose hyperlink usescs=b, which doesn't autopopulate.另一个限制是 GET 请求仅限于一定数量的字符，因此尝试使用 MAILTO + GET params 方法不适用于较大的内容。有没有人找到另一种方法通过某种网络请求将更大的内容推送到新的撰写窗口？
据我所知，这会很困难，因为 mailto 实际上是浏览器操作，正确吗？
Another limitation is that GET requests are limited to a certain number of characters so trying to use the MAILTO + GET params method won't work for larger pieces of content. Has anyone found another way to push larger content to a new Compose window via some sort of web request?
From what I can tell this will be difficult since the mailto is actually a browser action correct?