我想知道基于regx的替代品(可能是编译的)是否更快。必须测试，有人发现这是~5倍慢。

除此之外，您应该使用预期的长度初始化StringBuilder，这样在中间字符串增长时就不必复制它。

一个好的数字是原始字符串的长度，或者稍低一些(取决于函数输入的性质)。

最后，您可以使用一个查找表(范围0..127)来确定一个字符是否被接受。

我将使用字符串替换为正则表达式搜索“特殊字符”，替换所有字符找到一个空字符串。

这里有很多建议的解决方案，有些比其他的更有效，但可能不是很好读。这里有一个可能不是最有效的，但在大多数情况下肯定是可用的，并且非常简洁易读，利用Linq:

string stringToclean = "This is a test.  Do not try this at home; you might get hurt. Don't believe it?";

var validPunctuation = new HashSet<char>(". -");

var cleanedVersion = new String(stringToclean.Where(x => (x >= 'A' && x <= 'Z') || (x >= 'a' && x <= 'z') || validPunctuation.Contains(x)).ToArray());

var cleanedLowercaseVersion = new String(stringToclean.ToLower().Where(x => (x >= 'a' && x <= 'z') || validPunctuation.Contains(x)).ToArray());

如果你使用的是动态字符列表，LINQ可以提供一个更快更优雅的解决方案:

public static string RemoveSpecialCharacters(string value, char[] specialCharacters)
{
    return new String(value.Except(specialCharacters).ToArray());
}

我将这种方法与之前的两种“快速”方法(发行版编译)进行了比较:

字符数组解决方案由LukeH - 427毫秒 StringBuilder解决方案- 429毫秒 LINQ(这个答案)- 98毫秒

注意，算法略有修改-字符作为数组传入，而不是硬编码，这可能会有轻微的影响(即/其他解决方案将有一个内部for循环来检查字符数组)。

如果我使用LINQ where子句切换到硬编码的解决方案，结果是:

字符数组解决方案- 7ms StringBuilder解决方案- 22ms LINQ - 60毫秒

如果您计划编写一个更通用的解决方案，而不是硬编码字符列表，那么可能值得考虑LINQ或经过修改的方法。LINQ绝对能给你简洁、高可读性的代码——甚至比Regex更好。

StringBuilder sb = new StringBuilder();

for (int i = 0; i < fName.Length; i++)
{
   if (char.IsLetterOrDigit(fName[i]))
    {
       sb.Append(fName[i]);
    }
}

正则表达式的使用方法如下:

return Regex.Replace(strIn, @"[^\w\.@-]", "", RegexOptions.None, TimeSpan.FromSeconds(1.0));