hexdump -C 是最直观的十六进制+ASCII双栏查看方式，固定每行16字节、左侧偏移、中间两位十六进制、右侧ASCII字符（不可见字符显示为.），避免双字节错位，适合快速定位和比对魔数。
用 hexdump -C 看最直观的十六进制+ASCII双栏
默认直接运行 hexdump file 会按双字节解释（比如 48 65 变成 6548），根本不是你想要的“逐字节十六进制”。真正能一眼看懂原始字节的，只有 hexdump -C。
它固定每行 16 字节，左边是偏移地址，中间是 16 个 00 格式的十六进制字节，右边是对应 ASCII 字符（不可见字符显示为 .）。
-
-C已隐含-v，不会省略重复行 - 输出格式稳定，不依赖字节序，适合快速比对魔数（如 ELF 的
7f 45 4c 46） - 别用
hexdump -x—— 它把每两个字节当一个 short 打印，位置全错
定位某段内容：用 -s 跳过、-n 截取
查文件头？跳过 MBR？分析协议字段？靠翻屏或肉眼计数容易出错。关键参数是 -s 和 -n，但注意：-s 是 skip（跳过前 N 字节），不是 seek 到 offset。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查看第 2048 字节起的 32 字节：
hexdump -C -s 2048 -n 32 file -
-s支持后缀：-s 0x800、-s 2K都合法，单位始终是字节 -
-n是“最多读取”，不是“必须读满”；若文件剩余不足，只输出实际可读部分，不报错 - 别写
cat file | hexdump -C—— 丢失文件名，且 stdin 流可能被截断或缓冲干扰
中文/UTF-8 文件里全是点？这是正常渲染，不是乱码
hexdump -C 右侧 ASCII 栏只显示 ASCII 可打印字符（0x20–0x7e），其余一律用 . 替代。UTF-8 中文每个字占 3 字节，必然含非 ASCII 字节，所以整块变点 —— 这恰恰说明编码没损坏。
- 确认编码类型：
file -i file - 想验证中文是否真实存在：
iconv -f utf-8 -t ascii//ignore file | hexdump -C，过滤后剩的点就少了 - 需要 UTF-8 解码效果？
xxd -g1 file或od -tc更合适，hexdump不负责解码 - 二进制分析时，这种“非 ASCII 显示为点”的特性反而是优势 —— 能一眼扫出
00、0a、ff等控制字节
替代工具选 xxd 还是 od？看你要不要跨平台
xxd 和 od 都能干 hexdump -C 的活，但行为差异影响实操效率：
-
xxd file默认就是单字节分组、十六进制+ASCII，语法比hexdump -C更简洁；xxd -r反向转换也更稳定 -
od -t x1 -An -w1 file才接近hexdump -C效果；od在 AIX/Solaris 上更可能预装，但默认按 4 字节对齐，不加参数会错位 - 导出纯十六进制字符串（比如用于脚本调试）：
xxd -p file | tr -d ' '比hexdump -v -e '1/1 "%02x"' file更可靠，后者容易漏空格或换行
真正麻烦的不是命令本身，而是混淆了“字节解析单位”和“显示格式”——-x 和 -C 看似都带 x，作用却完全相反。一旦记错，看到的十六进制就不是原始字节顺序，后续所有分析都会偏移。
