String.Replace(string,string)对Unicode代理对是否安全？求安全替代方案

嘿，这个问题问到点子上了——刚好我对.NET字符串的底层处理逻辑比较熟悉，给你明确说结论先：.NET原生的String.Replace(string oldValue, string newValue)在Unicode代理对方面是完全安全的，绝不会拆分代理对导致数据损坏。

为什么它是安全的？ #

要搞懂这个，得从.NET字符串的本质和Replace的实现逻辑说起：
-.NET的string是基于UTF-16编码存储的，每个char占16位。但Unicode里的补充平面字符（比如大部分emoji、一些罕见的表意文字）需要用两个char组成的代理对（高代理项+低代理项）来表示。
-String.Replace的匹配逻辑是基于完整的字符序列，但它会严格遵循UTF-16的规则处理整个字符串：它不会把代理对中的单个char当成独立的匹配单元，只有当oldValue完全匹配一段有效的字符序列（包括完整的代理对）时，才会执行替换。如果oldValue是半个代理对这种无效的UTF-16序列，它虽然能执行，但正常业务场景里几乎不会出现这种情况——因为合法的字符串操作不会生成单独的代理项，除非你手动构造了无效字符串。

举个实际的例子：假设你有字符串"Hello 👋 World"，其中👋是由两个char组成的代理对。你用Replace("👋", "🙂")，它会完美替换；但如果你试图替换那个代理对里的单个char（比如手动取出高代理项字符），这种操作本身就不符合正常的字符使用逻辑，而且Replace也不会把它和完整代理对的一部分混淆。

如果你要自己实现类似函数，需要注意什么？ #

如果因为特殊需求必须手动实现替换逻辑，那就要额外关注代理对的处理：

• 遍历字符串时，用char.IsHighSurrogate()和char.IsLowSurrogate()判断当前字符是否属于代理对，确保每次处理的是完整的Unicode字符（要么是单个char，要么是一对代理项），绝对不能拆分它们。
• 可以借助StringInfo类，它会自动识别代理对，把每个完整的Unicode字符作为一个单元来处理，能帮你避开很多坑。

总结一下：原生的String.Replace已经帮你处理好了代理对的问题，完全不用担心数据损坏。只有手动实现字符串遍历匹配逻辑时，才需要额外留意代理对的处理。

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