这个坑我之前踩过！当你的用户名或密码里带有@符号时，curl会默认把它当成「用户名:密码」和「主机地址」的分隔符，所以才会出现"Port number ended with 'I'"这种解析错误。给你几个实用的解决办法：

方法1：对@符号进行URL编码 #

URL里的@符号对应的百分编码是%40，把用户名里的@替换成这个编码，curl就能正确识别它是用户名的一部分了。修改后的命令如下：

$ curl -k -i -X POST -d '{ "path" : "/" }' https://abc%40example.com:qwer@53096wrxgcg.ibmaspera.com:33001/files/workspaces/42796/all/12345:2

方法2：使用--user参数（强烈推荐） #

直接在URL里拼接认证信息很容易出歧义，不如用curl的--user（缩写-u）参数单独指定用户名和密码，这样哪怕里面有@或者其他特殊字符，curl也能正确解析：

$ curl -k -i -X POST --user "abc@example.com:qwer" -d '{ "path" : "/" }' https://53096wrxgcg.ibmaspera.com:33001/files/workspaces/42796/all/12345:2

这个方法不仅避免了URL解析的问题，还让命令结构更清晰，后期维护也方便。

方法3：从文件读取认证信息（适合复杂场景） #

如果你的用户名或密码里有一堆特殊字符，还可以把用户名:密码的内容写到一个纯文本文件里，比如创建creds.txt，内容就是abc@example.com:qwer，然后用--user-file参数读取：

$ curl -k -i -X POST --user-file creds.txt -d '{ "path" : "/" }' https://53096wrxgcg.ibmaspera.com:33001/files/workspaces/42796/all/12345:2

这个方式适合认证信息特别复杂，或者需要复用的场景。

另外你之前移除@后出现连接超时，本质是因为用户名被修改后不正确，导致认证失败或者主机解析逻辑出错，用上面的方法就能同时解决用户名含@的问题，保证认证信息的正确性。

内容的提问来源于stack exchange，提问作者Aquarius_Girl