# 最佳实践：电子邮件中的 ASCII 分隔符？ **URL:** \ **Category:** Support\ **Created:** [2020年八月10日 17:40 UTC](https://meta.discourse.org/t/best-practices-ascii-separators-in-emails/160393 "2020-08-10T17:40:54Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![BradCray](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@BradCray](https://meta.discourse.org/u/BradCray)\ **Post date:** [2020年八月10日 17:40 UTC](https://meta.discourse.org/t/best-practices-ascii-separators-in-emails/160393/1 "2020-08-10T17:40:54Z")
Discourse 社区的朋友们，大家好—— 首先，感谢你们打造了这个我认为非常棒、实用、灵活且（大部分情况下）直观的工具。我们正计划将项目的多种沟通方式迁移到 Discourse，包括从基于用户的社区讨论邮件列表，到由脚本生成的通知邮件（用于报告关键事件，如新问题、测试失败等），我们对这些变化充满期待。 在设置过程中，我遇到的一个问题是：发送到 Discourse 的邮件中，`-----` 这类行之后的内容会被自动剥离。据我理解，这是为了避免通过邮件发布的帖子携带整个回复链。我也一直对基于邮件的回复在 Discourse 中的呈现效果印象深刻，因此在这个问题上，我完全认可这一设计选择。 我们传统上经常在这些脚本生成的通知邮件（现在正转发到 Discourse）中使用此类分隔符，以便无论使用传统还是现代技术，邮件都易于阅读。我目前正在移除这些分隔符，并尝试改用其他方法，比如“增加更多的垂直空白”。但在深入进行这项工作之前，我想确认一下：是否有其他建议的最佳实践，用于在发送给 Discourse 的邮件中创建此类分隔符？或者是否有办法转义它们，使其绕过当前的过滤器（我目前最好的尝试是使用 n 连字符而非连字符/ASCII 减号，但出于简洁考虑，我并不倾向于使用非 ASCII 字符）。 我们中的许多人还习惯在邮件中使用小小的 `---` 分隔符来区分代码块或其他内容。因此，我担心即使我们完成了所有脚本生成消息的转换，这仍会影响那些依赖“回复”功能来响应转发到其收件箱的 Discourse 主题的用户（但这也许只是我们需要克服的一个学习曲线？）。 感谢大家提供任何提示或建议， -Brad ---
**Author:** ![BradCray](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@BradCray](https://meta.discourse.org/u/BradCray)\ **Post date:** [2020年八月10日 19:51 UTC](https://meta.discourse.org/t/best-practices-ascii-separators-in-emails/160393/2 "2020-08-10T19:51:05Z")
啊哈……我自己刚发现的一个可能对找到这个帖子的其他人有帮助的技巧：在原本作为分隔符的行中混入非分隔符/标点符号的 ASCII 字符，可以使其通过 Discourse 的过滤。因此，将类似这样的行： ```plaintext 标题 -------------------------------- ``` 改为： ```plaintext --- 标题 --------------------- ``` 就是一种在避免被 Discourse 移除的同时保留某种分隔线形式的方法。当然，这仍然无法帮助那些习惯依赖简单的 `----` 分隔线来在邮件中区分内容的用户，所以我仍很好奇大家对此是否有推荐的最好做法。 ---
**Author:** ![BradCray](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@BradCray](https://meta.discourse.org/u/BradCray)\ **Post date:** [2020年八月13日 23:21 UTC](https://meta.discourse.org/t/best-practices-ascii-separators-in-emails/160393/3 "2020-08-13T23:21:15Z")
冒着继续自言自语的风险，这里有一个我们今天遇到的具体激励性示例： 我们使用脚本通知人们事件的一个场景是：当新的 PR 合并到我们的 GitHub 仓库时，向开发人员发送邮件。现在，我们已经将这些脚本改为向 Discourse 网站上的特定类别发送邮件。然而，由于 GitHub 使用 Markdown 来描述 PR，我们的 PR 描述中经常会出现如下所示的章节标题： ```plaintext 此 PR 的详细信息 ------------------ ``` 这些标题在 GitHub 上会被渲染为章节标题。但当邮件发送到 Discourse 时，这一行破折号会导致邮件的其余部分被截断。 我们当然可以培训所有开发人员使用其他不会被截断的标题样式（例如 `## 此 PR 的详细信息`），但如果有一种方法可以修改我们的脚本，以处理合并消息并保护或转义此类模式，使其能够完整保留到 Discourse 中，那似乎更具吸引力。