不能直接用cat *.part > original，因shell通配符按字典序展开，split默认字母后缀（如xaa、xab、xba）会导致xba错排在xab前，破坏顺序；应改用printf构造序列、find | sort -v或显式列出文件，并合并后校验sha256sum或用file/unzip -t验证结构。
直接用 cat 拼接，但顺序错乱会导致文件损坏——这是最常踩的坑。
为什么不能直接 cat *.part > original？
shell 的通配符 * 默认按字典序展开，而 split -d 生成的 00、01、10 会被排成 00、01、10（正确），但 split 默认用字母后缀（aa、ab、ba）时，ba 会排在 ab 前面——因为 ba 字典序成立（<code>b 不成立，但比较首字母 <code>b > a，所以 ab 在前，ba 在后；真正出错的是像 aa、ab、az、ba 这种跨“十位”的情况，ba 实际应排在 az 后，但 shell 不理解数字逻辑）。
常见错误现象：cat x* > file.iso 合并后校验失败、ISO 无法启动、ZIP 解压报错 invalid compressed data--format violated。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 使用
-d参数分割的文件（如file.iso.00、file.iso.01）基本安全，ls默认排序即为数字顺序 - 未加
-d的默认字母后缀（xaa、xab、xac…xaz、xba）必须显式排序，否则xba可能插在中间 - 若用了
-a 3但没加-d（如xaaa、xaab、xaba），字典序更不可靠
怎么确保拼接顺序绝对正确？
核心原则：不依赖 shell 通配符的默认展开，改用 find + sort 或明确列出范围。
- 对数字后缀（
-d）：用printf构造有序序列，避免ls的潜在 locale 影响printf 'file.iso.%02d ' {0..99} | xargs cat > original.iso - 对字母后缀（默认）：用
find+sort -V（版本序，能识别aaab ba）find . -maxdepth 1 -name "file.iso.*" -print0 | sort -zV | xargs -0 cat > original.iso - 最稳妥（尤其跨系统传输后）：直接写死全部文件名
cat file.iso.00 file.iso.01 file.iso.02 > original.iso
合并后必须做的验证动作
二进制文件（ISO、ZIP、tar 等）一旦顺序错一位，整个文件即失效，且无明显报错——必须校验。
- 原始文件有
sha256sum或md5sum？合并后立刻比对：sha256sum original.iso对照切割前记录的值 - 没有原始校验和？至少做基础结构检查：
ISO：用file original.iso看是否识别为ISO 9660；
ZIP：运行unzip -t original.zip；
TAR：运行tar -tf original.tar | head -n5看能否列出开头文件 - 注意：不要用
ls -l比大小——切割+合并后字节总数一定相等，但内容可能全错
最容易被忽略的点：很多人合并完就直接用，连 file 都不跑一次。二进制文件不校验等于没合——顺序错位不会报错，只会静默损坏。
