不同应用程序（WPF 和 Unity）中的 C# struct 序列化返回不同大小的字节数组答案

【问题标题】：C# struct serialization in different applications (WPF and Unity) returns byte array of different sizes不同应用程序（WPF 和 Unity）中的 C# struct 序列化返回不同大小的字节数组
【发布时间】：2018-12-26 05:43:56
【问题描述】：

我有一个 dll，它具有结构定义以及对它们进行序列化和反序列化的几个函数。我想将它们放在一个 dll 中，以便可以在不同的应用程序之间共享完全相同的结构。

该 dll 由 WPF 应用程序（通过 MQTT 发送序列化数据）和 HoloLens 应用程序（使用 Unity 和 VS 开发）共享，后者接收该数据并尝试使用相同的 dll 对其进行反序列化。

问题在于，当 WPF 应用程序序列化结构时，Marshal.SizeOf(str) 返回的大小为 12。而 Unity C# 脚本中完全相同的 dll 函数 app 返回的大小为 24。此外，数组中的最后 12 个字节都是 0。

因此，尝试反序列化来自 WPF 应用程序的对象时会出现超出范围的异常，因为它们的大小是 Unity 脚本中预期大小的一半。

这是我正在序列化的结构示例：

[Serializable]
public struct SimulationVariableModel
{
    public string Name { get; set; }
    public string Category { get; set; }
    public string ObjectId { get; set; }
}

这是将结构序列化为字节数组的函数：

    public static byte[] StrucToByteArray<T>(T str) where T : struct
    {
        // In Unity: size = 24
        // In standalone WPF and UWP application: size = 12
        int size = Marshal.SizeOf(str);
        byte[] arr = new byte[size];

        IntPtr ptr = Marshal.AllocHGlobal(size);

        try
        {
            Marshal.StructureToPtr(str, ptr, false);
            Marshal.Copy(ptr, arr, 0, size);
        }
        finally
        {
            Marshal.FreeHGlobal(ptr);
        }

        return arr;
    }

以及将字节数组转换为原始结构的函数：

    public static T ByteArrayToStruct<T>(byte[] arr) where T : struct
    {
        T str = default;

        int size = Marshal.SizeOf(str);
        IntPtr ptr = Marshal.AllocHGlobal(size);

        try
        {
            Marshal.Copy(arr, 0, ptr, size);
            str = (T)Marshal.PtrToStructure(ptr, str.GetType());

        } finally
        {
            Marshal.FreeHGlobal(ptr);
        }

        return str;
    }

这是在 Unity 中接收序列化数据并尝试将其反序列化为原始结构的事件处理程序：

private void Client_MqttMsgPublishReceived(object sender, MqttMsgPublishEventArgs e)
{
    if (e.Topic == NewSimulationVariableTopic) {

        // Dummy item to test that the byte Array length is not due to extra data in e.Message.
        SimulationVariableModel test = new SimulationVariableModel { Name = "Bla", Category = "Bla" };

        // testByteArray.Length = 24
        byte[] testByteArray = StrucToByteArray(test);

        // De-serialization is successful
        test = ByteArrayToStruct<SimulationVariableModel>(testByteArray);

        // e.Message is the result from serialization 
        // using StructToByteArray<SimulationVariableModel>(str) in standalone WPF and UWP app.
        // De -serialization fails because e.Message.Length = 12
        SimulationVariableModel simVar = ByteArrayToStruct<SimulationVariableModel>(e.Message);

        // Logic with SimulationVariableModel
    }
}

我认为这可能是由 Unity 环境引起的？我测试了一个 UWP 独立应用程序，它将结构序列化为 12 个字节而不是 24 个字节。

是否有人知道可能发生的情况以及如何解决此问题？

非常感谢。

【问题讨论】：

字符串通过像这样的“简单”路由序列化是出了名的尴尬，因为它们不是就地数据；坦率地说，我想知道你是否会更好地使用定义明确的序列化程序 - JSON、protobuf 等
我猜这与 string 数据类型在一个中被视为 Unicode（每个字符 2 个字节）而不是另一个（即 ASCII，每个字符 1 个字节）有关？
我建议使用接口（而不是 where T : struct 使用 where T : IMySerializable ）这样您就可以为不同的数据类型编写自己的逻辑
您是直接从 CLR 使用的内存中复制字节来表示结构，这不是“真正的”序列化，它可能仅在“两端”在类似环境中运行时才有效（即使用相同的 CLR）。如果您只是想序列化数据，那么所有编组和指针处理对我来说似乎有点奇怪......您是否考虑过使用“传统”序列化？（例如使用XmlSerializer、BinaryFormatter 或某种 JSON 库）
c#中的一个字符是两个字节。使用 WCHAR（两个字节）或 CHAR（一个字节）的 WPF 也是如此。我怀疑你使用的是 T "char" 而不是 "byte"

标签： c# visual-studio unity3d serialization

【解决方案1】：

正如一些 cmets 所建议的，字符串在两个平台中的处理方式不同。我通过指定结构在其定义中的序列化方式解决了这个特定问题。示例：

[Serializable]
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi, Pack = 1)]
public struct SimulationVariableModel
{
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]
    public readonly string Name;

    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]
    public readonly string Category;

    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]
    public readonly string Id;

    public SimulationVariableModel(string name, string category, string objectId)
    {
        Name = name;
        Category = category;
        Id = objectId;
    }
}

但是，对于更强大的解决方案，我最好使用 Mark Gravell 和 bassfader 建议的实际序列化器。

干杯！

【讨论】：