sql - 无法在 SQL Azure for Mobile Services 上存储 Unicode 字符

Question

我正在将 Windows Azure 移动服务与 SQL Azure 数据库结合用于我的 Windows Phone 8 应用程序。

我正在尝试存储包含 Unicode 字符的字符串，具体来说，表情符号如 😁 ⛅ 🚀 🚵 等...

但是在 SQL Azure 资源管理器中，我总是看到带有“?”的符号 (�)。我已将此 Col. 声明为 Nvarchar(max)。

要插入带有字符串字段的行，我使用以下函数:await Table.InsertAsync(Register)。

数据库的排序规则为:SQL_Latin1_General_CP1_CI_AS

为什么我无法保存和检索这些 Unicode 字符？我认为使用 Nvarchar，所有 Unicode 字符串都将被允许。

谢谢。

Answer 1

当前运行时中存在一个错误，无法处理代码点 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]转义)，但在我的情况下这并不是一个瓶颈。另一种选择是在消息处理程序中实现转义/取消转义，以便在数据类型的正常使用(即访问其属性)中不会感受到这种性能影响(仅当通过网络时，并且可能是瓶颈而不是转化)。