ora-01017报错大概率因oracle 12c+默认密码大小写敏感且navicat未用双引号传递密码；需在连接字符串中显式加引号如password="password123"，并确认用户密码版本为12c。
ora-01017 报错时密码“明明是对的”却连不上，大概率是 oracle 12c+ 默认启用了密码大小写敏感，而 navicat 没有按规则传参。
Oracle 12c 密码大小写敏感是默认行为
从 Oracle 12c 开始，SEC_CASE_SENSITIVE_LOGON 参数默认为 TRUE，这意味着：用户密码在认证阶段严格区分大小写。哪怕你创建用户时用的是 CREATE USER alice IDENTIFIED BY "PassWord123"，后续登录也必须完全匹配大小写 —— 不是靠客户端“记住”，而是数据库底层校验逻辑决定的。
Navicat 默认把密码当普通字符串处理，不加引号、不转义、不显式声明大小写意图，结果发给 Oracle 的就是全小写或被自动标准化后的形式（尤其当密码含大写字母但 Navicat 输入框焦点丢失后粘贴进来的字符被截断/变形），导致比对失败。
常见表现：
- SQL*Plus 或 SQL Developer 能连（它们内部做了适配或提示更明确）
- Navicat 测试连接报
ORA-01017: invalid username/password; logon denied - 改用全小写密码（如
123456）后 Navicat 立刻能连
Navicat 中必须显式用双引号包裹密码
Oracle 要求：当密码含大写字母、数字、特殊字符且需保持原始大小写时，连接语句中必须用双引号包裹。Navicat 不会自动加引号，得手动干预。
操作方式不是改界面字段，而是进「连接属性 → 高级」页签，找到 Connection String（连接字符串）输入框，在里面拼出带引号的完整格式：
username="alice";password="PassWord123";database=ORCL;
注意：username 和 password 是 Navicat 自己识别的键名，不是 Oracle SQL 语法；但值部分的双引号是 Oracle 认证必需的。
如果你用的是 TNS 连接（即填了服务名），也可以在「常规」页签的「服务名」字段后追加参数：
ORCL?user="alice"&password="PassWord123"
只要最终传给 Oracle 的密码字符串被双引号包围，认证就能通过。
别跳过检查用户实际存储的密码形态
即使你确认 Navicat 输对了，也要验证 Oracle 里这个用户密码到底存成什么样：
- 用 DBA 账户查：
SELECT username, password_versions FROM dba_users WHERE username = 'ALICE'; - 如果
PASSWORD_VERSIONS含12C，说明该用户密码已按 12c 规则加密，大小写敏感已生效 - 如果显示
10G 11G，那可能是老密码未重置过，此时大小写可能不敏感 —— 但一旦执行过ALTER USER ... IDENTIFIED BY "NewPass"，就会升级为 12c 版本
也就是说：不是“所有 12c 数据库都强制大小写”，而是“每个用户的密码版本决定是否敏感”。一个库可以混存两种用户，排查时必须落到具体用户名上。
OCI 配置和角色设置也会干扰认证路径
即便密码和大小写都对了，Navicat 还可能因环境配置绕过正确认证流程：
- OCI DLL 路径没选对（比如指向了旧版
oci.dll），会导致协议协商失败，错误仍表现为ORA-01017 - 高级设置里的
Role选了SYSDBA，但用户没授这个权限，或者没加AS SYSDBA—— Navicat 不会帮你补，直接拒登 - 连接的服务名实际指向的是 CDB 根容器，而用户只存在于某个 PDB 中，这时光密码对也没用，得改服务名为 PDB 对应的服务名，或在用户名后加
@pdb_name
这些都不是密码问题，但 Oracle 统一扔 ORA-01017，容易让人死磕密码本身。
真正卡住人的，往往是大小写敏感 + Navicat 不自动加引号 + 用户密码版本升级这三者叠加。单独看每一条都简单，合在一起就变成“输对了还是错”的玄学现场。
