最务实的文本文件检测方法是：先检查魔数和前512字节二进制特征，再用StreamReader尝试以UTF-8、UTF-16 LE/BE读取前4KB并捕获解码异常，两者均通过才标记为“疑似文本”。
用 StreamReader 尝试读取前几 KB 并捕获编码异常
文本文件没有绝对可靠的文件头标识，Windows 的 .txt 后缀或 MIME 类型都可伪造。最务实的做法是尝试以常见文本编码（如 UTF-8、UTF-16、ASCII）解析文件开头部分，看是否抛出解码异常。
关键点：只读前 4096 字节（约 4 KB），避免大文件阻塞；优先用 Encoding.UTF8，它对 ASCII 兼容且对 BOM 敏感；若失败再试 Encoding.Unicode（UTF-16 LE）和 Encoding.BigEndianUnicode（UTF-16 BE）。
- 不要用
File.ReadAllText全量加载，可能 OOM 或卡死 - 跳过 BOM 检测逻辑（
StreamReader默认会处理） - 若所有编码都抛
DecoderFallbackException或IOException（如遇到 NUL 字节、控制字符乱码），基本可判定非文本
检查是否含大量不可见控制字符或二进制特征字节
纯文本中连续出现多个 \0、\x01–\x08、\x0B–\x0C、\x0E–\x1F（除 \t、\n、\r 外）是强二进制信号。PDF、ZIP、EXE 等格式开头还有固定魔数（magic bytes），可一并验证。
示例快速扫描逻辑：
var bytes = File.ReadAllBytes(path).Take(512).ToArray();
if (bytes.Length == 0) return false;
// 检查常见魔数
if (bytes.Take(2).SequenceEqual(new byte[]{0x4D, 0x5A})) return false; // PE header
if (bytes.Take(4).SequenceEqual(new byte[]{0x25, 0x50, 0x44, 0x46})) return false; // %PDF
// 统计“可疑”字节占比（排除 \t\n\r\x20–\x7E）
int binaryCount = bytes.Count(b => b == 0 || (b < 0x09 && b > 0) || b == 0x0B || b == 0x0C || (b > 0x0D && b < 0x20) || b > 0x7E);
if (binaryCount > bytes.Length * 0.1) return false; // 超过 10% 即怀疑
注意 IsTextEncoding 不是 .NET 标准 API
有人搜到第三方库的 IsTextEncoding 方法，或误以为 Encoding.GetEncoding("utf-8").GetByteCount(...) 能判断——这些都不行。.NET 没有内置「检测文件是否为文本」的通用函数。所有靠谱方案都是组合策略：先魔数过滤，再编码试探，最后统计字符分布。
特别注意 Windows 记事本的“ANSI”编码其实是系统本地代码页（如 CP1252），但该编码无法可靠推断，且现代文本基本不用。强行尝试易误判，建议跳过。
- 别依赖
Path.GetExtension——report.pdf.txt可能是 PDF - 别用
file -i命令调用（跨平台不稳，权限/路径问题多） - 若业务允许，加个用户确认弹窗比全自动更稳妥
实际项目中建议分两级判断
一级（快）：检查魔数 + 前 512 字节二进制特征；二级（准）：用 StreamReader 以 UTF-8 打开前 4 KB，捕获 DecoderFallbackException 和 IOException。两者都通过才标记为“疑似文本”。
这个阈值不是理论最优，而是工程平衡点：99% 的真实文本（UTF-8/UTF-16/ASCII）能过，绝大多数 ZIP/PDF/EXE/图片也能被拦住，且单次判断耗时稳定在毫秒级。
真正难缠的是某些日志文件混入少量二进制 dump、或自制协议里夹带文本字段——这种场景必须结合业务上下文，光靠字节分析无解。
