高分悬赏——有关混淆（乱码）与 XMLSerializer 的不可实现问题（并请求置顶） 补充：[XmlType("TC")]public class TestClass{中的 [XmlType("TC")]无关紧要的。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 首先，XML在传递中，对某些特殊字符是无法处理的，为什么我也不知道。但我遇到过。如同Uncode->gb2312的XML，XSL等之间的转换时就会发生这个问题，尤其对中文的支持更是糟糕。我想，应该是你在混淆时改变了其中部分字符的编码方式而导至的。 混淆器没有搞过。乱码一般都是编码的格式不正确。2000系统支持的编码格式在.net中都有支持吗？？而且混淆器的工作原理是什么。 混淆器的原理形象地说就是将一缸本来都已整齐地沉积到坛底的泥沙给搅浑，重新堆积。这样就不能看出以前是什么样子了。这是保护dll文件的好办法。因为没有经过混淆的dll很容易被反编译。经过混淆器以后反编译难度就增加很多倍了。 首先，如果你对Serialize之后的Xml的结构/名称有要求的话，还是不要用Obfuscator了——它们会把所有成员/类的名字改掉，得到的Xml文本也就面目全非了。至少，你需要选择preserve所有需要Serialize的类的公有成员（选择keep public就可以）。当然如果你Serialize的目的只是暂时保存数据，Xml格式变化对应用没有影响的话，用Obfuscator 还是可以的。我试了一下Remotesoft Obfuscator，下面是需要的修改。对另一个也应该差不多。1) XmlSerializer对Collection的要求是：a) 有一个DefaultMember b) 一个Add方法。 DefaultMember是通过Attribute参数（字符串）指定的（看到你也尝试过了），Obfuscator 只能理解程序的语法，不能理解语义，所以不知道这个字符串和Item属性的联系，所以它对Item Property重命名却没有修改DefaultMember Attribute。你需要做的就是从Obfuscator界面里选择Item Property，右建菜单选择preserve以保留原来的名字。 CollectionOfSimpClass的Add方法也是XmlSerializer的硬要求，同样需要选择preserve。2) Obfuscator会尝试最大程度的overload——为成员变量使用相同的名字。这在MSIL里面不是问题，因为MSIL引用成员的时候总是同时标出该成员的类型。但是在Serialize里面就有问题了: 同一个scope里面出现两个类型不同但是名字相同的成员。例如Remotesoft Obfuscator就把TestClass的TestSimp和SimpClasses同时命名成A，当然会出错了。 一种解决办法是preserve这两个成员的名字。另一种是从菜单里选择MapTo...，为它们指定互不相同的map名称。 TO qqchen79: 多谢你的关注。OBFUSCATOR 可以设置混淆选项的，其中就可以设置为不修改有关属性或集合的访问器的MetaData。这一点比 DOTFUSCATOR 要好的多了。这方面的问题在 Obfuscator 上,倒几乎没什么太大影响,然而解决了此问题, OBFUSCATOR 混淆后的代码引发其他异常更加匪夷所思，譬如会出现“aio3kdid.dll 程序集文件找不到”。其实根本就没有这么个 DLL 文件(在异常信息中其名称是变化的，不稳定的)。至于混淆后的 XML 元素名称我可以用 XMLElementAttribute, XMLTypeAttribute(或者 XMLRootAttribute)分别对每一个域、读写属性、及根类进行特别设置，确保以适当的 XSD 格式输出 XML 数据，问题绝不在这方面。但 OBFUSCATOR 有不如 DOTFUSCATOR 的地方，典型的就是你提到的第二个建议，应该说前者的 OVERLOAD 处理上远不如 DOTFUSCATOR ，但是后者尽管如此深的 OVERLOAD 也不会出现在 OBFUSCATOR 中出现的“在同一个层次中出现相同命名的错误”。但 DOTFUSCATOR(免费版)不提供有如 OBFUCATOR 中灵活的混淆选项设置，我想估计专业版也没有，因为在其使用手册中我没发现有关说明。看来 DOTFUSCATOR 的开发者没有注意到此问题。TO 其他各位： 本帖中的乱码不是指由于字符编码格式不同引起的常见问题，本帖中乱码就是指混淆，混乱 IL 代码的意思。另外，我知道如果实在不行的话，完全可自己实现 FromXML(XMLTextReader)、ToXML(XMLTextWriter)两个方法来回避这方面的问题。然而， XMLSerializer 用好了是完全可以替代大多数情况下的 XML 解析处理的，这也是微软在帮助文档中明确指出的 XMLSerializer 的典型用处。在我的测试工程中，不混淆的话，一点问题也没有，一混淆就出现了这样那样的问题了，问题是在混淆器上，不是 .NET Framework。本测试程序是根据一个实际项目的代码模拟而来，所以解决与否对于我来说意义重大，不论对此实现项目，而且对以后其他项目的系统架构分析也有着重要的指导意义。第一个吃螃蟹的人看来真的不好做，应该说整个 .NET(包括其他外延产品)还不是一个成熟的体系，一年多来，我所碰到的各种棘手问题举不胜举，严重影响了我的进度。但我不会埋怨任何人或公司，选择了 .NET，就会继续并支持下去，人生本来就是赌博吗，更何况选择是开发环境呢？在此先多谢了。 真是太失望了。CSDN 出了那么多的 MVP，居然参与者聊聊。 我还是倾向于把整个问题归结为所有混淆器的弱点：针对语法工作，而不是语义。该弱点的直接反映是Reflection不可能正常工作，程序中一字符串形式出现的语法单元名称和具体指代的对象不能建立起对应关系。例如Attribute里面指定的内容，等等。XmlSerialization的整个架构是建筑在Reflection基础上的，所以混淆以后的XmlSerializer代码不能工作是完全可以预期的。1) 关于你提到的Assembly Not Found的问题，我的猜想是混淆器错误的把一个Public的类/成员改成的Private或者Internal——猜想而一，并没有依据。2) 关于Overload，这本来应该是混淆器的一个优点——名称冲突越多，反汇编越困难，混淆效果越好。但是这样做风险很大，在你的程序中就体现出来了。一个By Default能够基本工作正常的混淆器需要保守一些，例如：不能随意改变类/成元的访问属性（public, private, etc)，不能改变名称空间结构，不能改变任何public的东西，不能造成同一层次的命名冲突（尽管.NET允许这种冲突存在，很多高级语言还是禁止此功能），等等等等。我的感觉是Remotesoft Obfuscator做得过于Aggressive了, 导致很多问题。如果Dotfuscator做得比较保守的话，可能并不需要很多选项。 我用它的时候都是这样的:<renaming> <excludelist> <type name=".*" regex="true" speclist="+public"> <method name=".*" speclist="+public" regex="true" /> <method name=".*" speclist="+family" regex="true" /> <method name=".*\..*" regex="true" /> <field name=".*" speclist="+public" regex="true" /> <field name=".*" speclist="+family" regex="true" /> </type> <type name=".*" regex="true" excludetype="false" speclist="-public"> <method name=".*" speclist="-assembly, -familyorassembly, +virtual" regex="true" /> <method name=".*\..*" regex="true" /> </type> <type name=".*Exception" regex="true" /> </excludelist> </renaming>不过因为它的类型规范里没有支持serializable标记,所以我一般是把公共类写到XXXXNS.Common里,那个名字空间反正是公共的,所以是不需要混淆的 其他类，我倒可以不混淆，偏偏与异常相关的类必须混淆。看来混淆器厂商有点夸大其辞，可能他们压根儿在开发过程中就没考虑到这种情况，希望以后能改进。我只能不用 XML 序列化方式了。我现已改用 XmlTextWriter 和 XmlPathDocument 来实现了。本来打算用性能很快的 XmlTextReader 来读取 XML 数据，因为我并不需要在 XML 数据上进行编辑操作，然而我真是够倒霉的...怎么碰到的怪事那么多？在我的 VS.NET 2002 中，对使用 XmlTextReader 读取 XML 数据的代码进行调试时，居然每一次执行 MoveToAttribute 方法，阅读器的位置会移到下一个 Element 节点。弄得我无法调试，也就无法写出正确的代码。哎……不知道诸位的使用经验如何？我头都大了。再等一天，就结帖。 C# MessageBox处理 XML文件的问题 遇上个难题，如何判断网络连的是GPRS还是CDMA 关于C#程序的路径问题 【100分】如何显示WMI创建的远程进程的窗口 suplistview控件 求C/S程序的开发框架！！！ 开发和客户机的sql server连接字符串不同，怎么解决？ 什么问题（button的新建）？ 能否实现这样一个程序 SOS！！！！解密NTFS加密文件。 C#中的动态链接库调用问题？
乱码一般都是编码的格式不正确。
2000系统支持的编码格式在.net中都有支持吗？？
而且混淆器的工作原理是什么。
1) XmlSerializer对Collection的要求是：a) 有一个DefaultMember b) 一个Add方法。
DefaultMember是通过Attribute参数（字符串）指定的（看到你也尝试过了），Obfuscator 只能理解程序的语法，不能理解语义，所以不知道这个字符串和Item属性的联系，所以它对Item Property重命名却没有修改DefaultMember Attribute。你需要做的就是从Obfuscator界面里选择Item Property，右建菜单选择preserve以保留原来的名字。
CollectionOfSimpClass的Add方法也是XmlSerializer的硬要求，同样需要选择preserve。2) Obfuscator会尝试最大程度的overload——为成员变量使用相同的名字。这在MSIL里面不是问题，因为MSIL引用成员的时候总是同时标出该成员的类型。但是在Serialize里面就有问题了: 同一个scope里面出现两个类型不同但是名字相同的成员。例如Remotesoft Obfuscator就把TestClass的TestSimp和SimpClasses同时命名成A，当然会出错了。
一种解决办法是preserve这两个成员的名字。另一种是从菜单里选择MapTo...，为它们指定互不相同的map名称。
多谢你的关注。OBFUSCATOR 可以设置混淆选项的，其中就可以设置为不修改有关属性或集合的访问器的MetaData。这一点比 DOTFUSCATOR 要好的多了。这方面的问题在 Obfuscator 上,倒几乎没什么太大影响,然而解决了此问题, OBFUSCATOR 混淆后的代码引发其他异常更加匪夷所思，譬如会出现“aio3kdid.dll 程序集文件找不到”。其实根本就没有这么个 DLL 文件(在异常信息中其名称是变化的，不稳定的)。至于混淆后的 XML 元素名称我可以用 XMLElementAttribute, XMLTypeAttribute(或者 XMLRootAttribute)分别对每一个域、读写属性、及根类进行特别设置，确保以适当的 XSD 格式输出 XML 数据，问题绝不在这方面。但 OBFUSCATOR 有不如 DOTFUSCATOR 的地方，典型的就是你提到的第二个建议，应该说前者的 OVERLOAD 处理上远不如 DOTFUSCATOR ，但是后者尽管如此深的 OVERLOAD 也不会出现在 OBFUSCATOR 中出现的“在同一个层次中出现相同命名的错误”。但 DOTFUSCATOR(免费版)不提供有如 OBFUCATOR 中灵活的混淆选项设置，我想估计专业版也没有，因为在其使用手册中我没发现有关说明。看来 DOTFUSCATOR 的开发者没有注意到此问题。
TO 其他各位：
本帖中的乱码不是指由于字符编码格式不同引起的常见问题，本帖中乱码就是指混淆，混乱 IL 代码的意思。另外，我知道如果实在不行的话，完全可自己实现 FromXML(XMLTextReader)、ToXML(XMLTextWriter)两个方法来回避这方面的问题。然而， XMLSerializer 用好了是完全可以替代大多数情况下的 XML 解析处理的，这也是微软在帮助文档中明确指出的 XMLSerializer 的典型用处。在我的测试工程中，不混淆的话，一点问题也没有，一混淆就出现了这样那样的问题了，问题是在混淆器上，不是 .NET Framework。本测试程序是根据一个实际项目的代码模拟而来，所以解决与否对于我来说意义重大，不论对此实现项目，而且对以后其他项目的系统架构分析也有着重要的指导意义。第一个吃螃蟹的人看来真的不好做，应该说整个 .NET(包括其他外延产品)还不是一个成熟的体系，一年多来，我所碰到的各种棘手问题举不胜举，严重影响了我的进度。但我不会埋怨任何人或公司，选择了 .NET，就会继续并支持下去，人生本来就是赌博吗，更何况选择是开发环境呢？在此先多谢了。
2) 关于Overload，这本来应该是混淆器的一个优点——名称冲突越多，反汇编越困难，混淆效果越好。但是这样做风险很大，在你的程序中就体现出来了。一个By Default能够基本工作正常的混淆器需要保守一些，例如：不能随意改变类/成元的访问属性（public, private, etc)，不能改变名称空间结构，不能改变任何public的东西，不能造成同一层次的命名冲突（尽管.NET允许这种冲突存在，很多高级语言还是禁止此功能），等等等等。
我的感觉是Remotesoft Obfuscator做得过于Aggressive了, 导致很多问题。
如果Dotfuscator做得比较保守的话，可能并不需要很多选项。
<excludelist>
<type name=".*" regex="true" speclist="+public">
<method name=".*" speclist="+public" regex="true" />
<method name=".*" speclist="+family" regex="true" />
<method name=".*\..*" regex="true" />
<field name=".*" speclist="+public" regex="true" />
<field name=".*" speclist="+family" regex="true" />
</type>
<type name=".*" regex="true" excludetype="false" speclist="-public">
<method name=".*" speclist="-assembly, -familyorassembly, +virtual" regex="true" />
<method name=".*\..*" regex="true" />
</type>
<type name=".*Exception" regex="true" />
</excludelist>
</renaming>不过因为它的类型规范里没有支持serializable标记,所以我一般是把公共类写到
XXXXNS.Common里,
那个名字空间反正是公共的,所以是不需要混淆的
我现已改用 XmlTextWriter 和 XmlPathDocument 来实现了。本来打算用性能很快的 XmlTextReader 来读取 XML 数据，因为我并不需要在 XML 数据上进行编辑操作，然而我真是够倒霉的...怎么碰到的怪事那么多？在我的 VS.NET 2002 中，对使用 XmlTextReader 读取 XML 数据的代码进行调试时，居然每一次执行 MoveToAttribute 方法，阅读器的位置会移到下一个 Element 节点。弄得我无法调试，也就无法写出正确的代码。哎……
不知道诸位的使用经验如何？我头都大了。再等一天，就结帖。