A low-level error in Oracle SQLPlus

A few days ago, Oracle 10 Gb was installed on RedHat AS 4.1. It was always reported during database creation:
ORA-12154: TNS: cocould not resolve service name. I don't know why, so I went to the Internet to search for solutions. For every possible reason, I tried it. Oracle had no more than 10 words in 10 Gb. I was busy that night until AM. I tried all possible causes. The last struggle last night was really unmeasurable. Sometimes the solution to the problem is a matter of instant. You can say that it exists from the cracks of the stone. In short, it is also an indescribable happiness. After talking about it for a long time, I didn't tell you the essence of the matter.
That is, the password of an Oracle user must not contain the "@" character. Although the vast majority of Oracle database tools in the world, including third-party software, do not reject user connections whose passwords contain the "@" character, SQLPLUS rejects. Later, I thought about the cause that SQLPLUS incorrectly parsed the TNSName in the connection string.
For example, if your TNSName is SZVW1047, set the System password to I @ SUZHOU.
Use SQLPLUS to connect:
SQL> connSystem @ szvw1047
Enter password:
ERROR:
ORA-12154: TNS: cocould not resolve service name

Warning: You are no longer connected to ORACLE.

I guess SQLPLUS connects the user password with system @ szvw1047: system/I @ SUZHOU @ szvw1047 and then run conn system/I @ SUZHOU @ szvw1047. The tnsname analyzed by sqlplus is "SUZHOU @ szvw1047" and the password is "I ", in this case, the cocould not resolve service name is reported. The following figure shows the connection status after I reset the system password to "hello:
SQL> connSystem @ szvw1047
Enter password:
ERROR:
ORA-12154: TNS: cocould not resolve service name
SQL> conn// @ Szvw1047As sysdba
Connected.
SQL> alter user system identified by "hello"
2/

User altered.

SQL> connSystem @ szvw1047
Enter password:
Connected.
SQL>

In order to find out the truth, I added two lines in SQLNET. ORA to track client connections:
TRACE_LEVEL_CLIENT = ADMIN
TRACE_DIRECTORY_CLIENT =/Client
The two rows indicate that the customer's tracking is enabled, the tracking information is written to the/Client, and the following actions are performed:
SQL> connSystem @ szvw1047
Enter password:
ERROR:
ORA-12154: TNS: cocould not resolve service name
View the trace file and take the following part:
Nnfgrne: Going though read path adapters
Nnfgrne: Switching to DCE adapter
Nnfgrne: Original name: SUZHOU
Nnfgrne: Name did not qualify, skipping to next adapter
Nnfgrne: Switching to CDS adapter
Nnfgrne: Original name: SUZHOU
Nnfgrne: Name did not qualify, skipping to next adapter
Nnfgrne: Switching to TNSNAMES adapter
Nnfgrne: Original name: SUZHOU
Nnftqnm: entry
Fcnnagmd: entry
Fcnnagmd: Attribute name a. smd is a predefined meta type, syntax is 4.
Fcnnagmd: exit
Nnfgrne: Query unsuccessful, skipping to next adapter
Nnfgrne: Switching to ONAMES adapter
Nnfgrne: Original name: SUZHOU
Nngtnms_new_msg: new message, ID 26752, type 100
Nngtnms_new_msg: initial message pool block, size 2
Nngtrms_release_msg: entry
Nngtrms_release_msg: exit
Nnfgrne: Query unsuccessful, skipping to next adapter
Nnfgrne: Switching to ONRS adapter
Nnfgrne: Original name: SUZHOU
Nngtnms_new_msg: new message, ID 26753, type 100
Nngtrms_release_msg: entry
Nngtrms_release_msg: exit
Nnfgrne: Query unsuccessful, skipping to next adapter
Nnfgrne: Switching to HOSTNAME adapter
Nnfgrne: Original name: SUZHOU
Nnfhqnm: entry
Fcnnagmd: entry
Fcnnagmd: Attribute name a. smd is a predefined meta type, syntax is 4.
Fcnnagmd: exit

From this file, we can see that it is not much different from my imagination, except that the name is not SUZHOU @ szvw1047, but SUZHOU.
It is really surprising that Oracle has made such a low-level mistake.