SQL Server、MySQL、PostgreSQL 导入被勒索病毒加密的 SQL 文件失败，主因是控制字符、截断语句、损坏分隔符等语法层损坏，而非编码问题；需先十六进制清理、按GO/分号拆分、逐段执行并记录日志，再用正则提取可读INSERT行单条尝试插入。
SQL Server 导入时遇到“无法解析的字符”或“不正确的语法”错误
这不是编码问题，而是勒索病毒加密后残留的 sql 文件里混入了不可见控制字符、截断的语句、或损坏的 go 分隔符。sql server 的 sqlcmd 或 ssms 默认严格校验语法，遇到半个 insert 或乱码结尾就直接报错退出，根本不会跳过。
实操建议：
- 先用文本编辑器（如 VS Code）以十六进制模式打开残片，搜索
0x00、0xFF、0xFE等常见加密残留字节，手动删掉明显异常的头部/尾部块 - 把文件按
GO拆成小段（注意：有些残片里GO被加密成G?O或缺失换行），每段单独保存为chunk_001.sql这类命名 - 用
sqlcmd -S . -d YourDB -i chunk_001.sql -b -o log_001.txt执行，-b参数让出错时自动退出，配合-o记录输出，方便定位哪一段崩了
MySQL 中用 source 命令导入被破坏的 .sql 文件失败
MySQL 的 source 命令没有跳过错误选项，一旦遇到损坏的 INSERT 或缺失的引号，整个导入就终止。而且它对 UTF-8 BOM、Windows 换行符 \r\n 更敏感——勒索病毒常在文件头塞垃圾字节，导致 source 直接报 ERROR 1064 (42000)。
实操建议：
- 用
sed -i '1s/^\xEF\xBB\xBF//' broken.sql清除 UTF-8 BOM（Linux/macOS），Windows 下可用 PowerShell：(Get-Content broken.sql -Raw) -replace "^\uFEFF","" | Set-Content fixed.sql - 把大文件按分号
;拆成单条语句（注意避开字符串内的分号，简单场景可用awk -v RS=';' '{print $0";"}' broken.sql > lines.sql粗拆） - 逐行导入：
mysql -u root -p YourDB /dev/null || true，靠 shell 的|| true忽略单条失败，但要注意：这会掩盖真正的语法错误，只适合已知是数据损坏而非逻辑错误的场景
PostgreSQL pg_restore 遇到 “invalid byte sequence” 或 “unexpected EOF”
勒索病毒加密后的 .backup 或 .dump 文件，大概率不是标准格式——可能是被截断的 tar 流、损坏的自定义格式头、或二进制块中混入加密噪声。此时 pg_restore 会卡在解析阶段，连表名都读不出来。
实操建议：
- 先用
file corrupted.backup看真实类型，如果是data而非POSIX tar archive，说明已不是合法 pg_dump 输出，别硬跑pg_restore - 尝试用
strings -n 10 corrupted.backup | head -500提取长文本片段，找还能识别的CREATE TABLE、INSERT INTO片段，手工捞出可读部分 - 如果原始备份是 plain 格式（
.sql），用psql -v ON_ERROR_STOP=0 -f corrupted.sql YourDB，ON_ERROR_STOP=0是关键，它让 psql 遇错继续，但注意：它不会跳过解析错误（比如半截语句），只跳执行期错误
通用补救：从加密残片里抢救出可用 INSERT 数据行
比完整恢复更现实的目标，是把还能识别的 INSERT INTO ... VALUES (...) 行抽出来。勒索病毒通常加密文件内容但不动结构，所以大量 VALUES 后的括号内容虽乱，但前缀和括号配对可能还在。
实操建议：
- 用正则提取（Python 示例）：
re.findall(r"INSERT\s+INTO\s+\w+\s*\(.*?\)\s*VALUES\s*\([^)]*\);", text, re.DOTALL | re.IGNORECASE)，重点是[^)]*防止跨括号匹配，再人工筛出括号没被截断的行 - 对抽出来的每条
INSERT，用echo "这条INSERT" | psql -v ON_ERROR_STOP=0 -d YourDB 2>/dev/null单条试插，失败就丢弃，成功就记录 - 别依赖
mysql --force或psql -v ON_ERROR_STOP=0一揽子解决——它们跳过的只是执行错误，而加密残片的主问题是语法不完整，必须先做文本层清洗
真正难的不是命令怎么写，是判断哪一段还“算 SQL”。一个被加密 70% 的文件，可能只有最后 3% 的 INSERT 因为加密偏移没覆盖到而侥幸可读，得一行行看，不是靠工具能全自动搞定的。
