現在、コードポイント 0x10000 を超える Unicode 文字を処理できないランタイムのバグがあります (C# では、Unicode サロゲート文字のペアで表されます)。それは多くの絵文字キャラクターがいる地域です。しばらく前に取り組んでいた PoC でこの問題が発生し、クライアント側でそのような文字をエンコードすることで回避しました。現在コードはありませんが、以下のコードに似たものを使用していました。
public class MyType
{
private string value;
public string Value
{
get
{
var sb = new StringBuilder();
for (int i = 0; i < this.value.Length; i++)
{
if (this.value[i] == '\\')
{
if (i < this.value.Length - 1 && this.value[i + 1] == '\\')
{
sb.Append('\\');
i++;
}
else if (i < this.value.Length - 5 && this.value[i + 1] == 'u')
{
sb.Append((char)Convert.ToInt32(this.value.Substring(i + 2, 4), 16));
i += 5;
}
else
{
throw new ArgumentException("Invalid encoding");
}
}
else
{
sb.Append(this.value[i]);
}
}
return sb.ToString();
}
set
{
var sb = new StringBuilder();
foreach (var c in value)
{
if (c == '\\')
{
sb.Append("\\\\");
}
else if (Char.IsSurrogate(c))
{
sb.AppendFormat("\\u{0:X4}", (int)c);
}
else
{
sb.Append(c);
}
}
this.value = sb.ToString();
}
}
}
これは間違いなく最高のパフォーマンスを発揮しません (プロパティにアクセスするときに多くの [un] エスケープが発生します) が、私の場合は少しボトルネックではありませんでした。もう 1 つの方法は、メッセージ ハンドラーにエスケープ/エスケープ解除を実装することです。これにより、データ型の通常の使用 (つまり、そのプロパティへのアクセス) では、そのようなパフォーマンス ヒットが感じられなくなります (ネットワークを経由する場合のみ、およびそのコンバージョンではなくボトルネックになる可能性があります)。