我之前也踩过这个坑——用ADO通过FoxPro OLEDB驱动读DBF文件，普通查询完全正常，但碰到带不可打印字符的字段（尤其是开头包含AS相关字符的字符串）时，读取结果就和Visual FoxPro里显示的原始内容对不上，那些奇怪的字符点一下还会消失。下面是我亲测有效的几个排查和解决方向：

1. 匹配字符编码+升级驱动版本 #

FoxPro的DBF文件大概率用的是DOS编码（比如CP850）或者Windows ANSI编码，OLEDB驱动默认的编码如果不匹配，就会乱码或者吞掉特殊字符。你可以在连接字符串里强制指定字符集：

' VB示例：指定CP850编码的连接字符串
Dim conn As New ADODB.Connection
conn.Open "Provider=VFPOLEDB.1;Data Source=C:\你的DBF文件路径;Character Set=CP850;"

另外一定要用最新版的VFPOLEDB驱动（比如9.0版本），旧版本对特殊控制字符的处理真的有bug，我之前就是升级驱动解决了一半的问题。

2. 用FoxPro函数预处理特殊字符 #

有些不可打印的控制字符（比如ASCII 0这类空字符）会被OLEDB当成字符串终止符，尤其是出现在开头的时候。你可以在查询里先对字段做清洗：

-- 替换所有空字符，或者用ASC函数定位具体是哪个控制字符
SELECT STRTRAN(目标字段名, CHR(0), '') AS 清洗后字段 FROM 你的表名
-- 查看第一个字符的ASCII码，确认是什么特殊字符
SELECT 目标字段名, ASC(LEFT(目标字段名,1)) AS 首字符ASCII码 FROM 你的表名

先搞清楚是哪个控制字符在搞鬼，再针对性替换就好办了。

3. 用FoxPro原生工具批量处理DBF #

如果ADO层面的处理没效果，直接用Visual FoxPro打开DBF文件做预处理最稳妥：

* FoxPro命令行示例：批量清除字段中的不可打印控制字符
USE 你的表名 EXCLUSIVE
REPLACE ALL 目标字段名 WITH STRTRAN(目标字段名, CHR(0), '') FOR ASC(LEFT(目标字段名,1)) < 32
USE

处理完之后再用ADO读取，基本就能拿到和FoxPro里一致的内容了。

4. 对比原始字节流找问题 #

有时候FoxPro的显示会自动过滤不可打印字符，但DBF文件里实际是存着的。你可以用十六进制编辑器打开DBF，查看对应字段的原始字节，再对比ADO读取的字节流，就能确认是驱动解析的问题，还是DBF存储本身的问题。

内容的提问来源于stack exchange，提问作者Macros