Вид запутанной группы ответов, отчасти потому, что название вопроса на самом деле намного больше, чем конкретный вопрос, который задают. После прочтения, я не уверен, что какой-либо ответ будет в нескольких редакциях от усвоения всех хороших вещей здесь, поэтому я решил, что постараюсь подвести итог.
Вот метод расширения, который, я думаю, позволяет избежать ловушек, упомянутых здесь, и обеспечивает наиболее широкое применение.
public static string ReplaceCaseInsensitiveFind(this string str, string findMe,
string newValue)
{
return Regex.Replace(str,
Regex.Escape(findMe),
Regex.Replace(newValue, "\\$[0-9]+", @"$$$0"),
RegexOptions.IgnoreCase);
}
Так...
К сожалению, комментарий @HA о том, что у вас есть Escape
все три , неверен . Начальное значение и newValue
не должно быть.
Примечание: вы, однако, должны экранировать $
s в новом значении, которое вы вставляете, если они являются частью того, что может показаться маркером «захваченного значения» . Таким образом, три знака доллара в Regex.Replace внутри Regex.Replace [sic]. Без этого что-то подобное ломается ...
"This is HIS fork, hIs spoon, hissssssss knife.".ReplaceCaseInsensitiveFind("his", @"he$0r")
Вот ошибка:
An unhandled exception of type 'System.ArgumentException' occurred in System.dll
Additional information: parsing "The\hisr\ is\ he\HISr\ fork,\ he\hIsr\ spoon,\ he\hisrsssssss\ knife\." - Unrecognized escape sequence \h.
Скажу вам, что, я знаю, что люди, которым удобно с Regex, чувствуют, что их использование позволяет избежать ошибок, но я часто все еще неравнодушен к анализу байтовых строк (но только после прочтения Spolsky в кодировках ), чтобы быть абсолютно уверенным, что вы получаете то, что вы предназначен для важных случаев использования. Немного напоминает мне Крокфорда о « небезопасных регулярных выражениях ». Слишком часто мы пишем $10
регулярные выражения, которые разрешают то, что мы хотим (если нам повезет), но непреднамеренно допускают больше в (например, действительно ли является допустимой строкой «значения захвата» в моем регулярном выражении newValue, выше?), Потому что мы не были достаточно вдумчивыми , Оба метода имеют ценность, и оба поощряют различные типы непреднамеренных ошибок. Часто легко недооценить сложность.
Это странное $
побег (и это Regex.Escape
не ускользнуло от шаблонов захваченных значений, таких $0
как, как я ожидал бы от значений замещения), на какое-то время сводило меня с ума. Программирование сложно (с) 1842