我正在使用ssis将数据导出到csv文件中。在我的sis软件包中，我以zip格式压缩文件，然后使用sftp将其上传到Linux服务器上。问题在于，在目标文件系统中，csv文件包含来自DOS系统的^ M字符。
我找到了三种解决方案。
首先，我可以将sftp传输模式设置为ascii而不是压缩文件（我后来发现这仅受ftp支持）。考虑到我解压缩后的文件> 3Gb效率不高，因此上传需要一段时间。
第二次传输后，我可以解压缩文件并使用dos2unix实用程序对其进行转换，但是再次没有安装dos2unix，并且我无权将其安装到目标系统。
最后，我可以使用sed之类的unix编辑器从行尾删除^ M。我的文件包含超过400万行，这又会花一些时间。
问：是否可以使用ssis以ASCII格式对我的文件进行预格式化，然后压缩并传输？
答案 0 :(得分：1)
我没有尝试过，但是我认为您可以在输出到csv文件时进行CR + LF-> LF转换。我查看了此链接here
向下滚动到“标题行定界符”部分。看来，如果选择{LF}作为行定界符，则生成的.zip文件将正确显示在Linux框中。
顺便说一句，也许您知道，但是我不得不提到^ M是Linux / Unix框中CR的表示形式。
BTW2，在大多数情况下，Linux中的^ M并不是问题，只是一些令人讨厌的事情。
希望我能帮助您！
答案 1 :(得分：1)
在搜索此问题时，我发现了一个非常有用的链接，他们在描述此问题的原因和可能的解决方案时：
文件已在具有不同换行符约定的不同类型的系统之间传输。例如，基于Windows的文本编辑器在行尾将带有特殊的回车符（CR + LF），以表示行返回或换行符，这些字符在Linux（^ M）中将无法正确显示。这可能很难发现，因为某些应用程序或程序可能会正确处理外来换行符，而其他应用程序或程序则无法。因此，某些服务可能会崩溃或无法正确响应。通常，这是因为文件是在Microsoft Windows计算机上创建或什至在文件中编辑，然后上传或传输到Linux服务器。从无ASCII或文本模式的MS-DOS（或MS-Windows）传输文件时，通常会发生这种情况。
dos2unix包含实用程序，可将DOS或MAC换行符的文本文件转换为Unix换行符，反之亦然。它还包括将UTF-16转换为UTF-8。
您可以通过Execute Process Task使用类似的命令：
dos2unix filename
您可以创建一个数据流任务，以将数据从平面文件源传输到新的平面文件目标中，这两个平面文件连接mAnager具有相同的结构，但Source中的行分隔符属性（{CR}{LF}除外， {LF}（目的地）
您可以使用具有类似代码的脚本任务：
string data = null;
//Open and read the file
using (StreamReader srFileName = new StreamReader(FileName))
{
data = srFileName.ReadToEnd();
data = data.Replace("\r\n","\n");
}
using (StreamWriter swFileName = new StreamWriter(FileName))
{
swFileName.Write(data);
}
来自以下unzip documentation：
-a
转换文本文件。通常，所有文件的提取都与它们存储时完全相同（作为“二进制”文件）。 -a选项使被zip识别为文本文件的文件（在zipinfo列表中带有't'标签而不是'b'的文件）被自动提取，从而转换行尾，文件结尾字符和字符根据需要进行设置。 （例如，Unix文件使用换行符（LF）来表示行尾（EOL），并且没有文件结尾（EOF）标记； Macintosh机使用回车符（CR）来表示EOL；大多数PC操作系统使用CR + LF用于EOL，control-Z用于EOF。此外，IBM大型机和密歇根终端系统使用EBCDIC而不是更常见的ASCII字符集，而NT支持Unicode。）请注意，zip文本文件的标识绝不是完善;一些“文本”文件实际上可能是二进制文件，反之亦然。因此，对于使用-a选项提取的每个文件，unzip会打印“ [text]”或“ [binary]”作为对其进行目测的检查。 -aa选项强制所有文件提取为文本，无论假定的文件类型如何。在VMS上，另请参阅-S。
因此，您可以使用以下命令来提取具有变化的行尾的文本文件：
unzip -a filename
对@jww条评论的信用