西安的某DBA给了一个用，号作为column delimeter，用”号作为字符串列的text qualifier的数据文件。估计是DTS倒出来的，结果我用SSIS设好了column delimeter和qualifier，并设好哪一列用qualifier哪一列不用后，导入却仍然失败。看数据，发现是如果列中又再含有”号的情况出错。虽然这样的”号已经被用两个”号表示，也即是vb的转义方法。但不知为何SSIS仍然不能识别，按理说只要不是单独的一个”号，就可以仍然识别为字符串内部，这应该是没有岐义的。一时google不出答案，就想到把双引号改成单引号，结果发现这样的数据就可以正常导入了。
于是就开始想用方法实现这个替换，结果一下子花了大半天时间才完成这个导入。。。后面有点赌气的感觉－－我就不信替换不掉。。。
最后用了一个vbs＋正则表达式解决的。首先是考虑,””,不能替换，因为这可能是一个空串列。但我没考虑””在行首行末的情形－－因为我是一行行应用RegExp的，如果对整个文件应用，怕机器吃不消。
中间还写过一个vbs，用纯粹的”转义的逻辑来处理－－也就是用一个flag来判断是否在串内部的，顺序处理整个文件，但这个方法太慢，运行了十多分钟放弃。
正则式无非就是[^,]””[^,] 以及””\n和\n””,后面两个还是后来补上的，用editplus做替换也挺方便。而在vbs内如果不是用递归（循环）调用，而是想一次过替换，我就复制到另一个字符串里，然后记下所有的match来对复制品进行替换。这样才能在替换完一个match后matchs数组还有效。其间我还用了（?=)正向预查来确保多个连续”号里的每一个都没有错过。不过后来还是用了递归,因为发现””的第二个”号并不需要专门替换而且替换后字符位置提前了一位。后天上班再把正则式拷贝上来记录一下。这次还是没考虑完全，因为a””,这样的本来应该被替换的结果没替换，好像是用editplus补上的[^,]'”,。 还有,””[^,]，还有行首行尾的情况。
总之，如果用regexp要注意的有点多，多亏了editplus支持正则。
vbs写些简单的小程序还是挺方便的，虽然性能对大文件一般。SSIS设置还是比较细的，如果不是不能识别这个文件的格式正确，还是挺完美的工具。还有就是由于collation可以随时方便地改变，SSIS导入文件时就直接用文件的code page好了,修改目标table的collation来匹配SSIS，省得match半天的。