首页 > 商业智能 > 解决维度成员中的非法Xml字符导致的查询错误

解决维度成员中的非法Xml字符导致的查询错误

2009年9月19日
看看评论 评论一个

update(2009-09-20): 增加了去除这些非法Xml字符的正则表达式以及C#代码。

问题描述

最近在项目中遇到这么个情况，在展开维度成员的时候，服务端抛出了“The server sent an unrecognizable response”的异常，看了下异常细节，给出的信息是“'', hexadecimal value 0x01, is an invalid character. Line 1, position 6771. (System.Xml) ”。

问题解决

出现这样问题的原因在于，微软的Analysis Service使用XMLA（XML for Analysis）语言和其他客户端进行交互，包括执行Mdx、DMX、Sql等。如果服务端返回的成员（关键列、名字、标题、成员值等）含有一些非打印字符的话，那么就无法直接在Xml中表示，这样就会导致客户端无法解析返回的Xml响应，而出现上述的错误。

Analysis Service在Process的时候，出于性能考虑默认情况下是不会对数据进行这种Xml非法字符的检测。不过Analysis Service也提供了一个设置开关，允许我们在处理阶段检测这些非法字符，并做一定的规范化处理。在BIDS中，我们打开维度属性的属性面板，有一个InvalidXmlCharacters的设置，如下图所示：

InvalidXmlCharacters设置

默认情况下其值为Preserve，也就是保留这些非法字符。它还有其他两个选项。Remove表示移除这些非法字符，只保留合法的Xml字符。Replace表示使用问号?替换非法字符，一个非法字符对应一个问号。在实际应用中，InvalidXmlCharacters需要根据项目的实际情况进行设置。如果对数据的这种清理可以放到ETL阶段，那么最好放到ETL阶段，因为这样可以加快Analysis Service处理的速度。否则就只能在Process的时候做检测了。对于Remove和Replace，我比较倾向于选择Remove。因为既然已经是非打印字符了，用问号代替固然能够和其他数据区分开来，但是对于最终用户来说，大部分情况下只会增加他们的迷惑而已。

剔除非法Xml字符

在Xml 1.0规范（第五版，06/11/2008）的2.2一节中提到了Xml合法字符的范围：

/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

Char ::=   #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

规范中建议，所有Xml处理器都应该正确处理上述范围的这些字符。

我们可以在处理字符串的时候使用正则表达式剔除掉非法的Xml字符，以保证最终进入Analysis Service的字符都是Xml合法字符。

[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD\u10000-\u10FFFF]

对应的C#代码如下，出于性能考虑，可以将函数内部的正则表达式存储为成员变量，并设置为预编译模式。

public static String StripInvalidXmlChars(String input)
{
  Regex re = new Regex(@"[^\x09\x0A\x0D\x20-\uD7FF\uE000-\uFFFD\u10000-\u10FFFF]");
  return re.Replace(input, "");
}

 

参考文档：

Invalid XML Characters: when valid UTF8 does not mean valid XML

unprintable characters in member names cause error

Xml 1.0规范

——Kevin Yang

你可能对下面的文章感兴趣

本博客遵循CC协议2.5，即署名-非商业性使用-相同方式共享
写作很辛苦，转载请注明作者以及原文链接~
如果你喜欢我的文章，你可以订阅我的博客:-D点击订阅我的文章

Kevin Yang 商业智能 , , , ,

  1. X﹏X 到现在还没有评论~
  1. 暂时没有trackbacks.