SQL Server&C#使用参数指定数据库名创建数据库报错

嘿，这个问题我太熟悉了！你遇到的错误是因为SQL Server不支持对数据库名称这类标识符（对象名）使用参数化查询——参数化只适用于查询中的值（比如WHERE子句里的条件值），而不能用来替换库名、表名这类对象标识符，这就是为什么直接用@userDatabase会报语法错误。

那既要避免动态SQL的注入风险，又要能安全创建数据库，该怎么做呢？这里有两个关键步骤：

1. 使用QUOTENAME()函数安全转义数据库名 #

SQL Server内置的QUOTENAME()函数会自动把输入的标识符用方括号括起来，并且会转义其中的特殊字符（比如闭合方括号]会被转成]]），这样即使传入恶意输入，也只会被当作数据库名称的一部分，不会执行注入的SQL代码。

结合动态SQL的正确写法如下：

var connString = @"Server=localhost\SQLEXPRESS;Integrated Security=SSPI;Database=master";
string userProvidedDbName = "YourDesiredDatabaseName"; // 这里替换成用户输入的库名

using (var sqlConnection = new SqlConnection(connString))
{
    // 先通过QUOTENAME处理得到安全的数据库名，再执行动态SQL
    string cmdText = @"
        DECLARE @safeDbName NVARCHAR(128) = QUOTENAME(@userDatabase);
        EXEC sp_executesql N'CREATE DATABASE ' + @safeDbName;
    ";

    using (var sqlCmd = new SqlCommand(cmdText, sqlConnection))
    {
        // 指定参数类型和长度，避免隐式转换问题
        sqlCmd.Parameters.Add("@userDatabase", SqlDbType.NVarChar, 128).Value = userProvidedDbName;
        sqlConnection.Open();
        sqlCmd.ExecuteNonQuery();
    }
}

2. 在C#层面提前验证数据库名合法性 #

除了SQL层面的转义，你还可以在C#代码里先验证用户输入的数据库名是否符合SQL Server的规则，进一步降低风险：

• 长度不能超过128个字符
• 不能是SQL Server的保留关键字（比如MASTER、ALTER等）
• 只能包含字母、数字、下划线、@、#、$这些允许的字符

示例验证函数：

private bool IsValidDatabaseName(string dbName)
{
    if (string.IsNullOrWhiteSpace(dbName) || dbName.Length > 128)
        return false;

    // 这里可以补充完整的SQL Server保留关键字列表
    var reservedKeywords = new HashSet<string>
    {
        "MASTER", "MODEL", "MSDB", "TEMPDB", "CREATE", "ALTER", "DROP", "INSERT", "UPDATE"
    };

    if (reservedKeywords.Contains(dbName.ToUpperInvariant()))
        return false;

    // 检查是否包含非法字符
    foreach (char c in dbName)
    {
        if (!char.IsLetterOrDigit(c) && c != '_' && c != '@' && c != '#' && c != '$')
            return false;
    }

    return true;
}

在使用用户输入的数据库名前，先调用这个函数验证，如果不合法就直接返回错误提示，不要继续执行SQL操作。

为什么这样安全？ #

比如如果用户输入恶意内容：]; DROP DATABASE TestDB; --，经过QUOTENAME()处理后会变成[]]; DROP DATABASE TestDB; --]，执行CREATE DATABASE时只会把这个字符串当作一个完整的数据库名称，而不会执行后面的DROP语句，完美避免了注入风险。

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