email - 如何发送行超过 990 个字符的 csv 附件？

Question

好吧。我认为这个问题与我的 rails 应用程序有关，但它似乎与电子邮件附件的更深层次的工作有关。

我必须将一个 csv 文件从我的 rails 应用程序发送到一个仓库来完成我商店中的订单。仓库有 CSV 格式，讽刺的是 CSV 文件的标题行超长(1000+ 个字符)。

当我收到测试电子邮件时，我在 csv 文件的标题行中出现换行符，但无法弄清楚是什么放在那里。然而，一些谷歌搜索终于显示了原因:附件的行字符限制为 1000。为什么？我不知道。这看起来很荒谬，但我仍然必须以某种方式发送这个 csv 文件。

我尝试将附件的 MIME 类型手动设置为 text/csv，但这没有帮助。有谁知道如何解决这个问题？

一些相关的谷歌搜索结果:http://www.google.com/search?client=safari&rls=en&q=csv+wrapped+990&ie=UTF-8&oe=UTF-8

更新

我试过用 base64 编码附件，如下所示:

    attachments['205.csv'] = {:data=> ActiveSupport::Base64.encode64(@string), :encoding => 'base64', :mime_type => 'text/csv'}

这似乎没有什么区别。我通过 Mac 版 Sparrow 收到带有 me.com 帐户的电子邮件。我会尝试使用 gmail 的网络界面。

Answer 1

这似乎是因为 SendGrid 邮件服务器正在修改附件内容。如果您发送带有纯文本存储 mime 类型(例如 text/csv )的附件，它将每 990 个字符包装一次内容，正如您所观察到的。我认为这与RFC 2045/821有关:

6. Content-Transfer-Encoding Header Field

   Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary
   data. Such data cannot be transmitted over some transfer protocols.
   For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII
   data with lines no longer than 1000 characters including any trailing CRLF line separator.

   It is necessary, therefore, to define a standard mechanism for
   encoding such data into a 7bit short line format. Proper labelling
   of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. This document
   specifies that such encodings will be indicated by a new "Content-
   Transfer-Encoding" header field. This field has not been defined by
   any previous standard.

如果您使用 base64 编码而不是默认的 7 位编码发送附件，则附件保持不变(不添加换行符):

attachments['file.csv']= { :data=> ActiveSupport::Base64.encode64(@string), :encoding => 'base64' }