乱码主因是nls_lang与数据库字符集不匹配，须先查select value from nls_database_parameters where parameter = 'nls_characterset'确认al32utf8/zhs16gbk/us7ascii，再据此设置nls_lang并source ~/.bash_profile，最后确保终端编码与之一致。
乱码不是 SQL*Plus 本身坏了，而是客户端声明的字符集和数据库实际字符集对不上——NLS_LANG 环境变量设错，是唯一需要优先排查的核心点。
查清数据库真实字符集，别猜
所有后续配置都必须基于这个值，不能凭印象或安装默认值。直接连库执行：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';
常见返回值只有三个关键类型：
-
AL32UTF8：Oracle 推荐的 UTF-8 变体，对应NLS_LANG第三段必须是.AL32UTF8 -
ZHS16GBK：Windows 或老系统常用，对应.ZHS16GBK -
US7ASCII：纯英文库，根本不能存中文，设任何中文NLS_LANG都是徒劳
顺手再查一句确认语言偏好：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_LANGUAGE';
返回 SIMPLIFIED CHINESE 就说明提示/错误信息应为中文，AMERICAN 则是英文。
Linux 下设置 NLS_LANG 必须写进 ~/.bash_profile 并 source
临时 export 无效——SQL*Plus 启动时只读一次环境变量，且 su - oracle 会新建 shell，不继承父进程的 export。
在 Oracle 用户家目录下执行：
vi ~/.bash_profile
追加一行（按上一步查到的值选）：
- 若库是
AL32UTF8：export NLS_LANG="AMERICAN_AMERICA.AL32UTF8" - 若库是
ZHS16GBK：export NLS_LANG="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
然后必须运行：
source ~/.bash_profile
再开新终端或重新登录，否则 sqlplus / as sysdba 仍用旧值。
终端本身也要能渲染这些字节
NLS_LANG 解决的是 Oracle 客户端协议层的编码声明，但终端（如 SecureCRT、xterm、GNOME Terminal）得能正确解码并显示这些字节。
检查当前系统语言：
echo $LANG
如果返回 zh_CN.UTF-8，而 CRT 的 Character encoding 设成 ISO-8859-1，照样显示 ???。
终端设置要点：
- Linux 图形终端：确保已安装中文字体（如
fonts-chinese或liberation-fonts-common），并设终端字体为支持 Unicode 的（如DejaVu Sans Mono） - SecureCRT / Xshell：在会话选项里把
Character encoding明确设为UTF-8或GBK，与NLS_LANG第三段一致 - Windows CMD：默认是
GBK，若数据库是AL32UTF8，仅靠set NLS_LANG=...AL32UTF8不够，CMD 本身不支持 UTF-8 渲染，建议换用 Windows Terminal 或 Git Bash
最容易被忽略的是：改完 NLS_LANG 后没 source，或者终端编码和它不匹配。这两步缺一不可，且顺序不能反——先让系统环境变量生效，再让终端能画出来。
