XSLT中的条件处理，说白了，就是让你能根据XML文档中数据的不同情况，输出不同的内容或执行不同的转换逻辑。这和我们日常编程语言里的
if/else或者
switch/case语句是一个道理。核心机制主要通过
xsl:if和
xsl:choose这两个元素来实现，它们都依赖强大的XPath表达式来判断条件。 解决方案
在XSLT中，处理条件逻辑主要围绕
xsl:if和
xsl:choose这两个核心元素展开。它们允许我们根据XML源文档中的特定条件，有选择性地生成输出。
1.
xsl:if：简单的“如果”判断
xsl:if用于处理单个条件的场景。如果其
test属性中的XPath表达式评估为
true，那么
xsl:if元素内部的内容就会被处理；否则，内部内容将被忽略。这就像编程语言中的一个简单的
if语句，没有
else分支。
示例： 假设我们有一个产品列表，只想显示库存大于0的产品。
XML (products.xml):
<products> <product id="p1" name="Laptop" stock="10"/> <product id="p2" name="Mouse" stock="0"/> <product id="p3" name="Keyboard" stock="5"/> </products>
XSLT (transform.xsl):
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" indent="yes"/>
<xsl:template match="/products">
<html>
<body>
<h1>Available Products</h1>
<ul>
<xsl:apply-templates select="product"/>
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="product">
<xsl:if test="@stock > 0">
<li>
<xsl:value-of select="@name"/> (Stock: <xsl:value-of select="@stock"/>)
</li>
</xsl:if>
</xsl:template>
</xsl:stylesheet> 在这个例子里，只有当
product元素的
stock属性值大于0时，才会生成对应的
<li>标签。
2.
xsl:choose：多重条件的“选择”判断
当你的逻辑需要处理多个互斥的条件，并且可能包含一个默认的“否则”情况时，
xsl:choose就派上用场了。它类似于编程语言中的
if-else if-else或
switch-case-default结构。
xsl:choose内部包含一个或多个
xsl:when元素，以及一个可选的
xsl:otherwise元素。
xsl:when
：每个xsl:when
都有一个test
属性。XSLT处理器会按顺序评估这些test
表达式，一旦找到第一个评估为true
的xsl:when
，就会执行其内部内容，然后跳出xsl:choose
。xsl:otherwise
：如果所有的xsl:when
表达式都评估为false
，那么xsl:otherwise
内部的内容就会被执行。它必须是xsl:choose
的最后一个子元素。
示例： 根据产品的状态显示不同的信息。
XML (products.xml):
<products> <product id="p1" name="Laptop" status="available"/> <product id="p2" name="Mouse" status="out-of-stock"/> <product id="p3" name="Keyboard" status="preorder"/> <product id="p4" name="Monitor" status="discontinued"/> </products>
XSLT (transform.xsl):
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" indent="yes"/>
<xsl:template match="/products">
<html>
<body>
<h1>Product Status</h1>
<ul>
<xsl:apply-templates select="product"/>
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="product">
<li>
<xsl:value-of select="@name"/>:
<xsl:choose>
<xsl:when test="@status = 'available'">
<span style="color: green;">In Stock!</span>
</xsl:when>
<xsl:when test="@status = 'out-of-stock'">
<span style="color: red;">Currently Unavailable.</span>
</xsl:when>
<xsl:when test="@status = 'preorder'">
<span style="color: blue;">Pre-order Now!</span>
</xsl:when>
<xsl:otherwise>
<span>Status Unknown. Please check back later.</span>
</xsl:otherwise>
</xsl:choose>
</li>
</xsl:template>
</xsl:stylesheet> 这个例子展示了如何根据
product的
status属性值，输出不同的文本和样式。
XPath在
test属性中的作用：
无论是
xsl:if还是
xsl:when，它们的
test属性都接受一个XPath表达式。这个表达式会被评估为一个布尔值（
true或
false）。XPath的强大之处在于它能够：
-
比较值：
test="@price > 100"
-
检查节点是否存在：
test="count(./description) > 0"
-
检查属性是否存在：
test="@id"
(如果属性存在，则为true
) -
使用逻辑运算符：
test="(@category = 'electronics' and @stock > 0)"
-
使用各种XPath函数：
test="starts-with(@name, 'New')"
，test="contains(./tags, 'urgent')"
等。
正是XPath的灵活性，让XSLT的条件处理变得异常强大和精准。
XSLT条件处理中，何时选择使用 xsl:if，何时选择 xsl:choose？这其实是一个很实际的问题，我在写XSLT时也经常琢磨。说白了，选择哪个工具，主要看你的条件逻辑有多复杂，以及你是否需要一个“万一都不满足”的默认处理。
选择
xsl:if的场景：
-
单一条件，无“否则”需求： 当你只需要检查一个条件，并且只有这个条件为真时才需要做点什么，否则什么都不做，
xsl:if
是最简洁、最直观的选择。比如，你只想在某个元素有特定属性时才输出一个<div>
，或者只有当数值满足某个要求时才显示一条警告信息。它没有else
的概念，所以如果条件不满足，就直接跳过。 -
嵌套的独立条件： 有时候你可能会看到
xsl:if
嵌套xsl:if
的情况。这通常发生在条件之间不是互斥关系，而是层层递进的依赖关系时。但如果嵌套过深，可读性会下降，这时可能需要重新审视逻辑。 -
性能考量（微乎其微）： 从理论上讲，
xsl:if
比xsl:choose
更“轻量”，因为它只评估一个表达式。但在实际应用中，这点性能差异通常可以忽略不计，除非你的转换非常庞大且性能瓶颈极其敏感。
选择
xsl:choose的场景：
-
多重互斥条件： 这是
xsl:choose
的主场。当你的逻辑类似于“如果A则做X，否则如果B则做Y，否则如果C则做Z”，并且这些条件是互斥的（即同一时间只有一个能为真），那么xsl:choose
是最清晰、最符合逻辑的表达方式。它能确保只有一个分支被执行，避免了多个xsl:if
可能导致的重复判断或逻辑错误。 -
需要默认处理（“否则”情况）：
xsl:choose
提供了xsl:otherwise
这个强大的“兜底”机制。当你希望在所有明确定义的条件都不满足时，依然能有一个默认的输出或处理方式，xsl:otherwise
就显得尤为重要。这在处理未知或异常数据时非常有用，能让你的转换更健壮。 -
提升可读性： 对于复杂的条件逻辑，
xsl:choose
的结构比一堆嵌套的xsl:if
要清晰得多。它明确地划分了不同的处理路径，让代码更容易理解和维护。
我的个人经验：
我通常会这样思考：如果我能用一个
if语句搞定，那就用
xsl:if。但一旦我发现需要写第二个
if来处理“否则”的情况，或者需要区分好几种状态，我就会毫不犹豫地转向
xsl:choose。它能让逻辑变得更结构化，避免了潜在的逻辑漏洞，并且
xsl:otherwise真的能救命，特别是在处理那些你没预料到的数据情况时。 在XSLT条件判断中，如何利用XPath实现更复杂的逻辑？
XPath在XSLT的条件判断中，简直就是灵魂所在。
test属性里写的那些表达式，决定了你的条件能有多精细，多灵活。它远不止简单的相等或大于小于判断，能玩的花样多着呢。
1. 组合逻辑：
and,
or,
not()
这是最基础也最常用的复杂逻辑构建方式。
and
：两个条件都为真时才真。比如test="(@status = 'active' and @category = 'premium')"
。or
：至少一个条件为真时就真。比如test="(@type = 'admin' or @type = 'moderator')"
。not()
：反转条件的真假。比如test="not(@visible = 'false')"
(等同于test="@visible != 'false'"
, 但更明确地表示“不为假”) 或者test="not(./comment)"
(如果不存在comment
子元素则为真)。
2. 强大的XPath函数：
XPath提供了大量的内置函数，可以用于字符串处理、数值计算、节点集操作等，这些在条件判断中非常有用。
-
字符串函数：
starts-with(string, prefix)
：检查字符串是否以某个前缀开头。test="starts-with(@name, 'Special')"
。contains(string, substring)
：检查字符串是否包含某个子串。test="contains(./description, 'urgent')"
。ends-with(string, suffix)
(XSLT 2.0+)：检查字符串是否以某个后缀结尾。string-length(string)
：获取字符串长度。test="string-length(@code) = 5"
。normalize-space(string)
：移除字符串前后的空白并替换内部连续空白为单个空格。用于清理输入。concat(string1, string2, ...)
：连接多个字符串。在XPath 1.0中，这可以用来模拟contains
多个值的场景，比如test="contains('|red|green|blue|', concat('|', @color, '|'))"。
-
数值函数：
number(value)
：将值转换为数字。这在比较可能被当作字符串的数字时非常关键，比如test="number(@price) > 100.00"
。sum(node-set)
：计算节点集中所有数值的总和。test="sum(./item/price) > 500"
。count(node-set)
：计算节点集中节点的数量。test="count(./user) > 10"
(如果用户数量超过10个)。
-
节点集函数：
position()
：当前节点在同级节点中的位置。test="position() = 1"
(第一个节点)。last()
：当前节点集中的最后一个节点的位置。test="position() = last()"
(最后一个节点)。local-name(node)
：获取节点的本地名称（不带命名空间前缀）。test="local-name() = 'product'"
。name(node)
：获取节点的完整名称（带命名空间前缀）。
-
布尔函数：
true()
/false()
：直接返回布尔值。
3. 轴（Axes）的运用：
虽然
test属性通常是相对于当前上下文节点进行判断，但你也可以利用XPath的轴来访问其他节点，从而构建更复杂的条件。
parent::node-name
：访问父节点。test="parent::section/@type = 'important'"
。ancestor::node-name
：访问祖先节点。following-sibling::node-name
：访问后续同级节点。preceding-sibling::node-name
：访问先行同级节点。descendant::node-name
：访问后代节点。
示例： 检查当前商品是否是其父类别中的最后一个，并且该类别是“特价”类别。
test="position() = last() and ancestor::category/@name = 'SpecialOffers'"
我的看法：
XPath的强大在于它的表达能力。很多时候，我们觉得一个条件很复杂，需要多步处理，但用好XPath函数和轴，往往能把几步逻辑浓缩到一个
test表达式里。这不仅让XSLT代码更紧凑，也更符合其声明式编程的风格。当然，也要注意不要过度追求“一行流”，牺牲了可读性。如果表达式变得难以理解，拆分成多个变量或者重新考虑逻辑结构会更好。 XSLT条件处理中常见的陷阱与优化实践有哪些？
XSLT的条件处理虽然强大，但使用不当也容易踩坑，或者写出效率不高的代码。这些都是我在实际项目中遇到过的一些问题和总结出的经验。
常见的陷阱：
-
XPath 1.0 的局限性： 很多时候我们还在用XSLT 1.0（因为浏览器兼容性或旧系统），它的XPath 1.0标准确实有一些限制。
-
没有
if/else
表达式： XPath 1.0中没有像编程语言那样的if (condition) { true_value } else { false_value }表达式。这意味着你不能在一个XPath表达式内部根据条件返回不同的值，只能通过xsl:choose
这样的结构来实现。
-
没有
以上就是XSLT如何条件处理？的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。