如果你以为XSLT只是一门“匹配模板然后取值”的简单语言那说明你还没被数据清洗毒打过。真正做过复杂XML转换的人都知道XSLT函数才是整门语言的精华所在——金额要带千分位日期要从杂乱的文本里抠出来多份文档要合并取数重复节点要去重这些需求光靠xsl:value-of是搞不定的。这篇内容就是一份关于XSLT函数的“从入门到敢上手”的经验总结把内置函数、自定义函数、扩展函数三个层次讲透再附上我实际开发中踩过的坑和排查思路适合正在做XML数据转换、接口报文处理、电子书制作、报表生成这类活儿的开发者参考。1. XSLT函数到底从哪来为什么会让人一头雾水1.1 先分清三类函数内置、专用、扩展新手第一次接触XSLT函数时最困惑的不是函数不会用而是搞不清楚某个函数到底是“哪里来的”。根据我自己的经验XSLT里的函数大致可以分成三类混在一起理解会非常痛苦。第一类是XPath核心函数库。比如concat()、substring()、string-length()、sum()、count()、round()这些。它们本质上属于XPath表达式的一部分只不过在XSLT模板里直接被我们调用了。只要你能写XPath这些函数就是你的基础工具跟用哪个XSLT处理器无关。第二类是XSLT专用函数。比如format-number()、current()、key()、generate-id()、document()。它们由XSLT规范定义依赖XSLT的处理上下文离开了样式表就没法单独运行。这类函数解决的是XSLT场景下的特定问题格式化数字、获取当前节点、建立索引、生成稳定ID、加载外部文档。第三类是扩展函数。包括EXSLT标准库str:split()、math:max()、date:format-date()等以及各个处理器厂商提供的专有扩展比如Saxon的扩展函数、基于Java或JavaScript自定义的外部函数。这类函数不是XSLT规范自带的需要显式声明命名空间才能使用。为什么要这么分因为遇到“函数找不到”的报错时三类函数的排查方向完全不同。内置函数报错多半是你把函数名拼错了或者当前版本不支持专用函数报错要看上下文节点对不对、处理器实现是否完整扩展函数报错八成是命名空间没声明或者处理器不支持该扩展库。搞清楚这个分类排错效率至少翻一倍。1.2 模板决定“去哪”函数决定“怎么做”很多人把XSLT理解成“模板匹配语言”这没错但只看到了一半。模板负责告诉你“现在要处理哪个节点、下一条该去哪”而真正干活的其实是里面的表达式和函数。我把它们的关系类比成一个人模板是骨架负责结构函数是关节和肌肉负责具体运动。没有函数的XSLT只能做最简单的位置搬运有了函数才能做判断、计算、清洗、格式化这些真正有技术含量的工作。举个例子。我有一个库存导出的XML目录结构大概是store下面一堆product每个产品有名称、分类、价格和库存量。要把它转成CSV给财务系统用里面就有一堆函数需求价格要保留两位小数并且加上千分位名称字段要清理掉前后空格和换行符分类要进行大小写统一最后还要对整列库存量做汇总。这些操作没有一个是模板匹配能直接搞定的全得靠函数在XPath表达式里完成。所以我的建议是学习XSLT函数时不要孤立地背函数签名而是带着具体场景去学。遇到一个需求先想“我需要用什么函数”再去看这个函数属于哪一类、参数怎么传、返回值是什么类型。这样学下来函数记不住都难。1.3 版本决定函数表1.0、2.0、3.0怎么选这是XSLT函数学习中最容易被忽视的一个问题。XSLT版本不一样你能用的函数完全是两个世界。XSLT 1.0是2000年前后的老标准函数表非常朴素。字符串函数就那么几个没有lower-case()、upper-case()更没有正则表达式函数。数值函数只有取整和求和这一类。最要命的是1.0里没有原生的自定义函数机制xsl:function想复用逻辑只能靠命名模板递归。如果你还在用老旧的MSXML、libxslt或者某些平台自带的旧版XSLT引擎就得忍受这个限制。XSLT 2.0是一次大跨越。它引入了xsl:function自定义函数、for表达式、序列类型、tokenize()、replace()、matches()这些正则函数字符函数也补上了lower-case()、upper-case()、string-to-codepoints()等。日常开发里90%的函数需求在2.0里都能靠内置函数解决。Saxon 9系列、XmlPrime这些都是比较成熟的支持2.0的处理器。XSLT 3.0更进一步加入了xsl:iterate、xsl:merge、transform()函数、JSON支持、map和array类型等。不过3.0实际使用率还没有那么高除了Saxon之外完整支持的处理器不多。我的建议是新项目尽量用XSLT 2.0能力去写这是当前兼容性和功能性的最佳平衡点如果你所处的环境锁死了1.0那就要做好用命名模板模拟函数的准备这部分后面第3节会详细讲。2. 高频内置函数逐个拆解字符串、节点集、数值与格式化2.1 字符串函数是日常主力三分钟掌握全部常用写法做过数据转换的人都知道真正的开发时间有一半以上花在字符串处理上。XSLT里的字符串函数虽然不多但组合起来非常强大。我把日常最高频的几个挑出来一个个说。concat(a, b, c)是最简单的拼接函数不过它有替代方案直接用{...}属性值模板或者表达式里的||运算符2.0以后。我更推荐在xsl:value-of的select里直接写($a || $b || $c)代码更紧凑。但1.0环境里concat()还是主力没得挑。substring(string, start, len)是截取函数这里有个必须刻进脑子里的坑XPath的位置从1开始不是从0开始。substring(12345, 2, 3)返回234而不是2345。如果你是从JavaScript或Python转过来的这个反直觉的设计很容易让你栽跟头。还有两个变形函数substring-before(string, target)和substring-after(string, target)用于截取某个目标串之前或之后的内容我经常拿它们解析文件名、提取订单号里的前缀。清洗数据时normalize-space()是神器。它能把字符串首尾的空格、换行、制表符全部去掉把中间连续空白合并成单个空格。很多外部系统导入的XML文本里塞满了乱七八糟的空白一个normalize-space()下去立竿见影。另一个容易被忽略的是translate(string, from, to)它可以做单字符映射替换。比如想把电话号码里的空格、横杠、括号都清理掉可以这样xsl:value-of selecttranslate($phone, ()-, ) /注意这里第二个参数是要替换的字符集合第三个参数是目标字符集合两个集合长度不对应时会按最短的来。这个函数的经典骚操作是在XSLT 1.0里模拟大小写转换translate($name, ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz)虽然啰嗦但确实能用。另外还有contains(string, target)、starts-with(string, prefix)、ends-with(string, suffix)三个判断函数配合xsl:choose做条件逻辑非常顺手string-length()就更不用说了数长度必备。2.2 节点集与去重count、position、key、generate-id的真实用法字符串函数只是基础XSLT真正区别于普通脚本语言的是它对节点集的直接操作能力。节点集相关的函数如果搞明白了你的XSLT水平直接上一个台阶。先说count(node-set)它就是数节点个数这个没什么花头但配合筛选条件就很有用了比如count(product[price 100])统计高价商品数量。position()和last()是位置函数返回当前节点在节点列表中的位置和列表长度经常用在序号生成和“每N条加分割线”这种需求上。这里有个隐蔽的坑position()的值是相对于“当前节点列表”的在xsl:for-each里和在xsl:apply-templates里含义不同。比如apply-templates selectproduct匹配到每个产品时模板里写position()得到的是产品在匹配列表里的序号但如果在某个子模板里写position()拿到的是子列表里的位置。调试时如果发现序号不对先检查上下文。generate-id()是节点集处理里非常实用的函数它给一个节点生成稳定唯一的ID字符串形式同一个处理过程中多次调用结果一致。这个函数最经典的应用就是去重。举个例子XML里每个商品有category字段现在想列出所有不重复的分类直接用selectproduct/category会有大量重复值。去重写法有很多种我比较习惯配合preceding轴来筛选xsl:for-each selectproduct/category[not(preceding::product/category .)] xsl:value-of select. / /xsl:for-each这段逻辑的意思是只取“前面没有出现过相同分类值”的节点自然就完成了去重。除了这个方式XSLT还提供了xsl:key机制相当于给节点建索引然后通过key(name, value)函数快速查找节点。比如建立分类索引xsl:key namebyCategory matchproduct usecategory /之后可以用key(byCategory, electronics)一键拿到所有电子类产品。这个查找效率比遍历高得多大批量数据处理时差别很明显。还有一个document()函数用于加载外部XML文档参与合并比如样式表里写document(catalog.xml)//product就能取出另一份文档的资料做跨文档比对、数据合并全靠它。最后提醒一句generate-id()不保证跨处理器或跨多次运行一致只能在单次处理内使用别拿它当永久主键。2.3 format-number与数值函数别再手拼千分位数值函数这块看起来简单但实际应用里翻车率并不低。sum(node-set)加总、floor()向下取整、ceiling()向上取整、round()四舍五入这些都是基础中的基础。值得展开讲的是format-number()因为它负责解决“数字怎么显示”的问题。format-number(value, pattern)的两个参数中pattern是关键它跟Java的DecimalFormat模式很像。我来列几个我平时常用的模式pattern输入值输出说明#,##0.001234567.8911,234,567.89千分位加两位小数#,##01234.51,235千分位取整0000420042固定位数补零0.00%0.85685.60%百分比格式#3.141593.142紧凑格式我在给财务系统生成对账单时金额一律用format-number(amount, #,##0.00)这样出来的数字直接能贴到Excel里不用再手工调格式。这里有两个细节值得注意第一format-number()对负数的处理默认会把负号放在最前面但某些财务格式要求负号在括号里这需要配合 pattern 的;分段符来定义正负格式比如#,##0.00;(#,##0.00)这个实践经验比较冷门但遇到时真的很管用。第二百分比符号%在pattern里有特殊含义它会把数值乘以100再显示所以输入0.856输出85.60%千万不要以为它只是纯格式标记。还有一个容易忽略的函数是number()它能把字符串转成数值。在做XML数据清洗时经常遇到“金额字段里带着货币符号”或者“数字旁边有中文注释”的情况这时候先配合translate()把杂质字符清掉再用number()转数值或者直接在sum()里对number(price)求和。不过要注意number()对无法解析的字符串返回NaN而NaN参与任何数值运算都会导致结果异常所以转换之前最好用xsl:choose判断一下字符串格式是否合法。3. 自定义函数与扩展函数的实操之道3.1 XSLT 2.0 后用 xsl:function 封装自己的函数如果你的运行环境支持XSLT 2.0那么恭喜你你可以用xsl:function定义自己的函数了。这是提高样式表可维护性的最大利器。先看一个最简单的自定义函数计算字符串里某个字符出现的次数。这个需求用内置函数组合也能做但每次都要写一大串表达式而封装成函数后整个样式表都清爽了xsl:transform version2.0 xmlns:xslhttp://www.w3.org/1999/XSL/Transform xmlns:localhttp://www.example.com/local-functions xsl:function namelocal:count-char asxs:integer xsl:param nameinput asxs:string / xsl:param namechar asxs:string / xsl:sequence selectstring-length($input) - string-length(translate($input, $char, )) / /xsl:function /xsl:transform调用的时候就是local:count-char($name, A)。这里有几个关键点函数名必须带自定义命名空间前缀不能是XSLT或者XPath已经占用的前缀as属性声明返回类型加上后既能提前发现类型错误又让代码意图一目了然函数体最后必须用xsl:sequence返回序列或值而不是xsl:value-of。自定义函数在数据清洗场景里特别有用。比如一套复杂的规则用内置表达式写出来长达半行、完全没法读这时候把逻辑拆成小函数一个个组合代码质量和可读性都会大幅提升。再比如计算加权平均这种业务逻辑可以写成接收两组序列参数的函数配合for表达式简洁高效xsl:function namelocal:weighted-avg asxs:decimal xsl:param namevalues asxs:decimal* / xsl:param nameweights asxs:decimal* / xsl:sequence select sum(for $i in 1 to count($values) return $values[$i] * $weights[$i]) div sum($weights) / /xsl:function函数内部能调用其他自定义函数也能递归调用自身所以写递归算法完全没问题。不过要提醒一点自定义函数跟所有XSLT处理一样是函数式风格没有“修改变量”的概念不要试图在函数里用xsl:variable多次修改同一个变量来做循环那会把自己绕晕。想清楚输入和输出一次写出纯表达式才是正道。3.2 1.0 时代的“函数替代品”命名模板递归现实很骨感很多生产环境至今还在跑XSLT 1.0用不了xsl:function。这种情况下想要复用逻辑只能靠xsl:template加xsl:call-template命名模板来模拟函数调用。这个套路的基本写法是定义一个带名字的模板用xsl:param声明参数模板体内用xsl:choose分情况处理递归调用自身会“返回结果”——严格来说是通过xsl:value-of输出结果再捕获或者通过参数携带结果。举个例子在1.0环境下实现字符串反转xsl:template namereverse-string xsl:param nametext / xsl:choose xsl:when teststring-length($text) lt; 1 xsl:value-of select$text / /xsl:when xsl:otherwise xsl:value-of selectsubstring($text, string-length($text), 1) / xsl:call-template namereverse-string xsl:with-param nametext selectsubstring($text, 1, string-length($text) - 1) / /xsl:call-template /xsl:otherwise /xsl:choose /xsl:template调用方式是xsl:call-template namereverse-stringxsl:with-param nametext select$name //xsl:call-template结果会输出到样式树中。这种写法在1.0里就是“自定义函数”的替代品。用命名模板模拟函数有几个必须养成的习惯第一个是边界条件一定要写清楚递归没有终止条件就是死循环而且XSLT处理器对递归深度通常没有友好报错很容易直接栈溢出排查起来挺费劲。第二个是注意参数传递方式with-param的select表达式是在调用方上下文中求值的如果没写select而是直接在模板标签里嵌套内容那传递的是节点内容两种模式很容易混淆。第三个是调试时在模板开头加一行xsl:message打印参数值能看到递归每次进入的状态。我在实际项目中会用这种模式实现日期格式化、Base64简单处理逻辑、复杂字符串解析等功能虽然不如xsl:function优雅但稳定可靠跑了好几年没出过问题。3.3 EXSLT 与处理器扩展能救急但别上瘾除了规范内置函数还有个常用函数库叫EXSLT它定义了一堆通用扩展函数很多XSLT处理器都实现了。我实际用下来最频繁的是这几个字符串方面str:split(string, separator)能把字符串拆成节点集str:replace()能做全局字符串替换。数学方面math:max()、math:min()取最大最小值1.0内置函数里是没有这些的。日期方面date:format-date()可以按指定格式输出日期字符串这在老旧的1.0环境里简直是救星不然手写日期格式化会非常痛苦。使用EXSLT函数需要先声明命名空间例如xsl:stylesheet version1.0 xmlns:xslhttp://www.w3.org/1999/XSL/Transform xmlns:strhttp://exslt.org/strings xmlns:datehttp://exslt.org/dates-and-times xmlns:mathhttp://exslt.org/math extension-element-prefixesstr date math然后就能调用str:split(...)、date:format-date(...)了。记住必须要声明extension-element-prefixesstr date math这一步漏掉的话某些处理器会认为你在试图创建“扩展元素”而直接报错。EXSLT虽好但跨处理器的兼容性风险不容忽视。同一个函数Saxon支持但别的引擎未必支持或者支持的参数行为有细微差异。我的原则是能用XPath内置函数解决就绝不用EXSLT必须在1.0环境用EXSLT时要在项目文档里明确记录“此样式表依赖EXSLT处理器必须支持”避免上线后才发现环境不支持。更深度的处理器扩展比如Saxon的Java扩展机制、调用静态Java方法更是如此这些功能能解决大问题但也把样式表锁定在特定处理器上。如果你接手的项目要部署到多个平台最好只在独立模块中使用扩展功能别让核心转换逻辑依赖某个专有扩展。4. 实战翻车现场与排查思路函数相关的坑我都踩过4.1 报错“函数未定义”时按这个顺序排查“函数未定义”或“Cannot find a matching function”应该是我见过最多的报错。每次遇到这个错我建议按下面这个顺序排查可以少走很多弯路。第一步查函数名拼写和大小写。XPath和XSLT函数名区分大小写String-Length、SUBSTRING这些写法统统不行必须是string-length、substring。这种报错一般是手滑检查一遍签名就能发现。第二步查命名空间声明。如果是自定义函数或EXSLT函数哪怕函数名写对了没声明命名空间照样报错。我之前就犯过这种错写了local:count-char但样式表根元素上漏了xmlns:local声明处理器直接说找不到函数。检查方法很简单看样式表根元素上的所有xmlns前缀函数调用时用的前缀必须都在里面。第三步查XSLT版本。lower-case()、xsl:function这些2.0特性在1.0环境里用了就会报错。这个问题的隐蔽之处在于很多处理器默认按1.0运行你的version2.0不一定被所有引擎认可。如果换了处理器报错先确认它对2.0标准的支持情况。第四步查函数所在库是否被处理器实现。EXSLT标准是一回事具体处理器是否实现是另一回事。有些精简版处理器只实现了一部分EXSLT函数调用没实现的那部分就会报“函数未定义”。下面是一个典型的报错和对应处理表报错现象可能原因处理方式Cannot find a matching 1-argument function named {http://exslt.org/strings}split处理器不支持EXSLT strings 库换用支持EXSLT的处理器或改用内置tokenize()2.0自定义函数报“未定义”xmlns:local前缀未声明在样式表根元素补上命名空间声明lower-case()报错运行在XSLT 1.0环境改用translate()模拟或升级到2.0处理器format-number()结果不对pattern 写错先单测验证pattern再套进模板4.2 类型与上下文陷阱结果树片段、position、隐式转换函数返回值的类型如果理解不到位会引发很多“看起来没问题但结果完全不对”的怪现象。XSLT 1.0里最常见的一个坑是“结果树片段”Result Tree Fragment。你用xsl:variable nametmpxsl:call-template namefoo//xsl:variable这种方式创建变量时变量内容不是真正的节点集而是一种叫结果树片段的东西。结果树片段几乎不能当节点集用——不能对它做$tmp//product、不能求count($tmp)不能直接传给普通节点集参数。要绕过这个限制在支持EXSLT的处理器里可以用exsl:node-set($tmp)把它转换回节点集升级到2.0后这个类型直接消失了所以如果你能用2.0这个问题自然不复存在。position()的上下文陷阱我之前提过一嘴这里再展开。同样一段position()放在xsl:for-each里跟在xsl:apply-templates匹配到的模板里含义完全不同。for-each会建立一个新的节点列表position()是当前节点在列表里的序号而apply-templates情况下模板里上下文依赖调用处选择的节点列表。还有更隐蔽的当你在表达式中使用谓词过滤节点时比如product[position() lt; 3]这个position()指的是在筛选出来的节点集中的位置而不是所有商品里的位置。这个细节在生成序号或者分页场景下特别容易出错调试时先用xsl:message把position()和current()同时打出来对比很快就能定位。还有一个让新手困惑的点是节点与字符串的隐式比较。在XSLT 1.0里节点集和字符串比较时会把节点集的字符串值拿出来转换后再比。比如product apple如果当前上下文是多个节点这个表达式的结果是“只要有某个节点等于apple就为true”这跟直觉可能不太一样。所以做多值判断时要明确你到底是想“全部满足”还是“存在满足”这决定了应该用not(product apple)还是product ! apple。很多过于精简的“好像逻辑对”的表达就是在这种地方栽的跟头。4.3 命令行环境和开发工具导致的问题别甩锅给函数函数本身没报错但命令跑不起来这种情况我见过太多回。比如你下载了Saxon在Windows PowerShell里输入saxon -s:input.xml -xsl:style.xsl -o:output.xml结果系统提示“无法将‘saxon’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这跟函数一点关系都没有就是saxon命令不在系统PATH环境变量里或者你根本没把可执行文件放到正确位置。我在新环境里配XSLT开发工具时通常会先确认三件事本机的Java或Python运行环境有没有就绪Saxon对应的启动脚本路径有没有加入PATH直接用完整路径能不能跑通。与其在全局PATH里塞一堆东西我更推荐写一个简单的构建脚本或者Makefile把调用命令的完整路径和参数固定下来这样不管换到哪台机器只要改两行配置就能跑。开发时的调试工具同样重要。我平时最快的方式是写一个最小复现样例用命令行处理器单独跑。要注意在样式表里加入xsl:message调试输出把中间变量打到标准错误输出能省下一大半排查时间。另外市面上也有可视化XSLT调试工具比如XML编辑器内置的调试器能看到节点匹配过程和变量值适合排查复杂上下文问题。不过在线调试工具这类东西用的时候留意数据隐私涉及敏感信息最好还是本地跑。4.4 函数排错速查表收藏就完事了最后把我这些年踩过的坑整理成一张速查表遇到问题可以先对着表查。表里每一行都是我实际处理过的案例不是从文档里抄出来的。现象可能原因处理方式position()序号和预期不符上下文节点列表变了用xsl:message打印position()与current()确认上下文sum()结果是0或NaN节点内容是字符串未number()转换先number(price)再求和并检查字段里是否有杂质字符generate-id()在多次运行间不一致把单次处理ID当成持久ID用只用于单次处理内的去重和引用持久化用业务字段format-number()输出多出空格或不对齐pattern 和语言环境不匹配显式指定十进制格式或统一环境配置exsl:node-set()报错处理器不支持EXSLT升级到2.0再重构或换处理器substring()结果多一位少一位从0开始计位的习惯影响记住XPath位置从1开始key()找不到节点xsl:key的match/use表达式写错检查索引表达式直接在文档里验证自定义函数递归栈溢出缺边界条件递归入口先写终止条件先在小样本上测试上面这些坑有些我重复踩过不止一次尤其是上下文和类型转换这两类问题表面现象五花八门根子就那几个。后来我养成一个习惯写XSLT时尽量在表达式最复杂的地方加一句xsl:message输出运行时的变量值宁可多打几行也要让执行过程透明。还有一个小技巧是专门建一个测试用的XML文件和对应的样式表把所有常用函数的输入输出都验证一遍形成自己的“函数验证集”。以后改样式表先用这个验证集跑一遍函数行为是否变化一目了然。这个习惯帮我挡掉了不少回归问题也让我每次写XSLT函数心里都有底。 
长河君 · 2026/9/28 7:49:46 · 阅读 1.2k XSLT函数实战：内置、自定义与扩展函数全解析
如果你以为XSLT只是一门“匹配模板然后取值”的简单语言那说明你还没被数据清洗毒打过。真正做过复杂XML转换的人都知道XSLT函数才是整门语言的精华所在——金额要带千分位日期要从杂乱的文本里抠出来多份文档要合并取数重复节点要去重这些需求光靠xsl:value-of是搞不定的。这篇内容就是一份关于XSLT函数的“从入门到敢上手”的经验总结把内置函数、自定义函数、扩展函数三个层次讲透再附上我实际开发中踩过的坑和排查思路适合正在做XML数据转换、接口报文处理、电子书制作、报表生成这类活儿的开发者参考。1. XSLT函数到底从哪来为什么会让人一头雾水1.1 先分清三类函数内置、专用、扩展新手第一次接触XSLT函数时最困惑的不是函数不会用而是搞不清楚某个函数到底是“哪里来的”。根据我自己的经验XSLT里的函数大致可以分成三类混在一起理解会非常痛苦。第一类是XPath核心函数库。比如concat()、substring()、string-length()、sum()、count()、round()这些。它们本质上属于XPath表达式的一部分只不过在XSLT模板里直接被我们调用了。只要你能写XPath这些函数就是你的基础工具跟用哪个XSLT处理器无关。第二类是XSLT专用函数。比如format-number()、current()、key()、generate-id()、document()。它们由XSLT规范定义依赖XSLT的处理上下文离开了样式表就没法单独运行。这类函数解决的是XSLT场景下的特定问题格式化数字、获取当前节点、建立索引、生成稳定ID、加载外部文档。第三类是扩展函数。包括EXSLT标准库str:split()、math:max()、date:format-date()等以及各个处理器厂商提供的专有扩展比如Saxon的扩展函数、基于Java或JavaScript自定义的外部函数。这类函数不是XSLT规范自带的需要显式声明命名空间才能使用。为什么要这么分因为遇到“函数找不到”的报错时三类函数的排查方向完全不同。内置函数报错多半是你把函数名拼错了或者当前版本不支持专用函数报错要看上下文节点对不对、处理器实现是否完整扩展函数报错八成是命名空间没声明或者处理器不支持该扩展库。搞清楚这个分类排错效率至少翻一倍。1.2 模板决定“去哪”函数决定“怎么做”很多人把XSLT理解成“模板匹配语言”这没错但只看到了一半。模板负责告诉你“现在要处理哪个节点、下一条该去哪”而真正干活的其实是里面的表达式和函数。我把它们的关系类比成一个人模板是骨架负责结构函数是关节和肌肉负责具体运动。没有函数的XSLT只能做最简单的位置搬运有了函数才能做判断、计算、清洗、格式化这些真正有技术含量的工作。举个例子。我有一个库存导出的XML目录结构大概是store下面一堆product每个产品有名称、分类、价格和库存量。要把它转成CSV给财务系统用里面就有一堆函数需求价格要保留两位小数并且加上千分位名称字段要清理掉前后空格和换行符分类要进行大小写统一最后还要对整列库存量做汇总。这些操作没有一个是模板匹配能直接搞定的全得靠函数在XPath表达式里完成。所以我的建议是学习XSLT函数时不要孤立地背函数签名而是带着具体场景去学。遇到一个需求先想“我需要用什么函数”再去看这个函数属于哪一类、参数怎么传、返回值是什么类型。这样学下来函数记不住都难。1.3 版本决定函数表1.0、2.0、3.0怎么选这是XSLT函数学习中最容易被忽视的一个问题。XSLT版本不一样你能用的函数完全是两个世界。XSLT 1.0是2000年前后的老标准函数表非常朴素。字符串函数就那么几个没有lower-case()、upper-case()更没有正则表达式函数。数值函数只有取整和求和这一类。最要命的是1.0里没有原生的自定义函数机制xsl:function想复用逻辑只能靠命名模板递归。如果你还在用老旧的MSXML、libxslt或者某些平台自带的旧版XSLT引擎就得忍受这个限制。XSLT 2.0是一次大跨越。它引入了xsl:function自定义函数、for表达式、序列类型、tokenize()、replace()、matches()这些正则函数字符函数也补上了lower-case()、upper-case()、string-to-codepoints()等。日常开发里90%的函数需求在2.0里都能靠内置函数解决。Saxon 9系列、XmlPrime这些都是比较成熟的支持2.0的处理器。XSLT 3.0更进一步加入了xsl:iterate、xsl:merge、transform()函数、JSON支持、map和array类型等。不过3.0实际使用率还没有那么高除了Saxon之外完整支持的处理器不多。我的建议是新项目尽量用XSLT 2.0能力去写这是当前兼容性和功能性的最佳平衡点如果你所处的环境锁死了1.0那就要做好用命名模板模拟函数的准备这部分后面第3节会详细讲。2. 高频内置函数逐个拆解字符串、节点集、数值与格式化2.1 字符串函数是日常主力三分钟掌握全部常用写法做过数据转换的人都知道真正的开发时间有一半以上花在字符串处理上。XSLT里的字符串函数虽然不多但组合起来非常强大。我把日常最高频的几个挑出来一个个说。concat(a, b, c)是最简单的拼接函数不过它有替代方案直接用{...}属性值模板或者表达式里的||运算符2.0以后。我更推荐在xsl:value-of的select里直接写($a || $b || $c)代码更紧凑。但1.0环境里concat()还是主力没得挑。substring(string, start, len)是截取函数这里有个必须刻进脑子里的坑XPath的位置从1开始不是从0开始。substring(12345, 2, 3)返回234而不是2345。如果你是从JavaScript或Python转过来的这个反直觉的设计很容易让你栽跟头。还有两个变形函数substring-before(string, target)和substring-after(string, target)用于截取某个目标串之前或之后的内容我经常拿它们解析文件名、提取订单号里的前缀。清洗数据时normalize-space()是神器。它能把字符串首尾的空格、换行、制表符全部去掉把中间连续空白合并成单个空格。很多外部系统导入的XML文本里塞满了乱七八糟的空白一个normalize-space()下去立竿见影。另一个容易被忽略的是translate(string, from, to)它可以做单字符映射替换。比如想把电话号码里的空格、横杠、括号都清理掉可以这样xsl:value-of selecttranslate($phone, ()-, ) /注意这里第二个参数是要替换的字符集合第三个参数是目标字符集合两个集合长度不对应时会按最短的来。这个函数的经典骚操作是在XSLT 1.0里模拟大小写转换translate($name, ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz)虽然啰嗦但确实能用。另外还有contains(string, target)、starts-with(string, prefix)、ends-with(string, suffix)三个判断函数配合xsl:choose做条件逻辑非常顺手string-length()就更不用说了数长度必备。2.2 节点集与去重count、position、key、generate-id的真实用法字符串函数只是基础XSLT真正区别于普通脚本语言的是它对节点集的直接操作能力。节点集相关的函数如果搞明白了你的XSLT水平直接上一个台阶。先说count(node-set)它就是数节点个数这个没什么花头但配合筛选条件就很有用了比如count(product[price 100])统计高价商品数量。position()和last()是位置函数返回当前节点在节点列表中的位置和列表长度经常用在序号生成和“每N条加分割线”这种需求上。这里有个隐蔽的坑position()的值是相对于“当前节点列表”的在xsl:for-each里和在xsl:apply-templates里含义不同。比如apply-templates selectproduct匹配到每个产品时模板里写position()得到的是产品在匹配列表里的序号但如果在某个子模板里写position()拿到的是子列表里的位置。调试时如果发现序号不对先检查上下文。generate-id()是节点集处理里非常实用的函数它给一个节点生成稳定唯一的ID字符串形式同一个处理过程中多次调用结果一致。这个函数最经典的应用就是去重。举个例子XML里每个商品有category字段现在想列出所有不重复的分类直接用selectproduct/category会有大量重复值。去重写法有很多种我比较习惯配合preceding轴来筛选xsl:for-each selectproduct/category[not(preceding::product/category .)] xsl:value-of select. / /xsl:for-each这段逻辑的意思是只取“前面没有出现过相同分类值”的节点自然就完成了去重。除了这个方式XSLT还提供了xsl:key机制相当于给节点建索引然后通过key(name, value)函数快速查找节点。比如建立分类索引xsl:key namebyCategory matchproduct usecategory /之后可以用key(byCategory, electronics)一键拿到所有电子类产品。这个查找效率比遍历高得多大批量数据处理时差别很明显。还有一个document()函数用于加载外部XML文档参与合并比如样式表里写document(catalog.xml)//product就能取出另一份文档的资料做跨文档比对、数据合并全靠它。最后提醒一句generate-id()不保证跨处理器或跨多次运行一致只能在单次处理内使用别拿它当永久主键。2.3 format-number与数值函数别再手拼千分位数值函数这块看起来简单但实际应用里翻车率并不低。sum(node-set)加总、floor()向下取整、ceiling()向上取整、round()四舍五入这些都是基础中的基础。值得展开讲的是format-number()因为它负责解决“数字怎么显示”的问题。format-number(value, pattern)的两个参数中pattern是关键它跟Java的DecimalFormat模式很像。我来列几个我平时常用的模式pattern输入值输出说明#,##0.001234567.8911,234,567.89千分位加两位小数#,##01234.51,235千分位取整0000420042固定位数补零0.00%0.85685.60%百分比格式#3.141593.142紧凑格式我在给财务系统生成对账单时金额一律用format-number(amount, #,##0.00)这样出来的数字直接能贴到Excel里不用再手工调格式。这里有两个细节值得注意第一format-number()对负数的处理默认会把负号放在最前面但某些财务格式要求负号在括号里这需要配合 pattern 的;分段符来定义正负格式比如#,##0.00;(#,##0.00)这个实践经验比较冷门但遇到时真的很管用。第二百分比符号%在pattern里有特殊含义它会把数值乘以100再显示所以输入0.856输出85.60%千万不要以为它只是纯格式标记。还有一个容易忽略的函数是number()它能把字符串转成数值。在做XML数据清洗时经常遇到“金额字段里带着货币符号”或者“数字旁边有中文注释”的情况这时候先配合translate()把杂质字符清掉再用number()转数值或者直接在sum()里对number(price)求和。不过要注意number()对无法解析的字符串返回NaN而NaN参与任何数值运算都会导致结果异常所以转换之前最好用xsl:choose判断一下字符串格式是否合法。3. 自定义函数与扩展函数的实操之道3.1 XSLT 2.0 后用 xsl:function 封装自己的函数如果你的运行环境支持XSLT 2.0那么恭喜你你可以用xsl:function定义自己的函数了。这是提高样式表可维护性的最大利器。先看一个最简单的自定义函数计算字符串里某个字符出现的次数。这个需求用内置函数组合也能做但每次都要写一大串表达式而封装成函数后整个样式表都清爽了xsl:transform version2.0 xmlns:xslhttp://www.w3.org/1999/XSL/Transform xmlns:localhttp://www.example.com/local-functions xsl:function namelocal:count-char asxs:integer xsl:param nameinput asxs:string / xsl:param namechar asxs:string / xsl:sequence selectstring-length($input) - string-length(translate($input, $char, )) / /xsl:function /xsl:transform调用的时候就是local:count-char($name, A)。这里有几个关键点函数名必须带自定义命名空间前缀不能是XSLT或者XPath已经占用的前缀as属性声明返回类型加上后既能提前发现类型错误又让代码意图一目了然函数体最后必须用xsl:sequence返回序列或值而不是xsl:value-of。自定义函数在数据清洗场景里特别有用。比如一套复杂的规则用内置表达式写出来长达半行、完全没法读这时候把逻辑拆成小函数一个个组合代码质量和可读性都会大幅提升。再比如计算加权平均这种业务逻辑可以写成接收两组序列参数的函数配合for表达式简洁高效xsl:function namelocal:weighted-avg asxs:decimal xsl:param namevalues asxs:decimal* / xsl:param nameweights asxs:decimal* / xsl:sequence select sum(for $i in 1 to count($values) return $values[$i] * $weights[$i]) div sum($weights) / /xsl:function函数内部能调用其他自定义函数也能递归调用自身所以写递归算法完全没问题。不过要提醒一点自定义函数跟所有XSLT处理一样是函数式风格没有“修改变量”的概念不要试图在函数里用xsl:variable多次修改同一个变量来做循环那会把自己绕晕。想清楚输入和输出一次写出纯表达式才是正道。3.2 1.0 时代的“函数替代品”命名模板递归现实很骨感很多生产环境至今还在跑XSLT 1.0用不了xsl:function。这种情况下想要复用逻辑只能靠xsl:template加xsl:call-template命名模板来模拟函数调用。这个套路的基本写法是定义一个带名字的模板用xsl:param声明参数模板体内用xsl:choose分情况处理递归调用自身会“返回结果”——严格来说是通过xsl:value-of输出结果再捕获或者通过参数携带结果。举个例子在1.0环境下实现字符串反转xsl:template namereverse-string xsl:param nametext / xsl:choose xsl:when teststring-length($text) lt; 1 xsl:value-of select$text / /xsl:when xsl:otherwise xsl:value-of selectsubstring($text, string-length($text), 1) / xsl:call-template namereverse-string xsl:with-param nametext selectsubstring($text, 1, string-length($text) - 1) / /xsl:call-template /xsl:otherwise /xsl:choose /xsl:template调用方式是xsl:call-template namereverse-stringxsl:with-param nametext select$name //xsl:call-template结果会输出到样式树中。这种写法在1.0里就是“自定义函数”的替代品。用命名模板模拟函数有几个必须养成的习惯第一个是边界条件一定要写清楚递归没有终止条件就是死循环而且XSLT处理器对递归深度通常没有友好报错很容易直接栈溢出排查起来挺费劲。第二个是注意参数传递方式with-param的select表达式是在调用方上下文中求值的如果没写select而是直接在模板标签里嵌套内容那传递的是节点内容两种模式很容易混淆。第三个是调试时在模板开头加一行xsl:message打印参数值能看到递归每次进入的状态。我在实际项目中会用这种模式实现日期格式化、Base64简单处理逻辑、复杂字符串解析等功能虽然不如xsl:function优雅但稳定可靠跑了好几年没出过问题。3.3 EXSLT 与处理器扩展能救急但别上瘾除了规范内置函数还有个常用函数库叫EXSLT它定义了一堆通用扩展函数很多XSLT处理器都实现了。我实际用下来最频繁的是这几个字符串方面str:split(string, separator)能把字符串拆成节点集str:replace()能做全局字符串替换。数学方面math:max()、math:min()取最大最小值1.0内置函数里是没有这些的。日期方面date:format-date()可以按指定格式输出日期字符串这在老旧的1.0环境里简直是救星不然手写日期格式化会非常痛苦。使用EXSLT函数需要先声明命名空间例如xsl:stylesheet version1.0 xmlns:xslhttp://www.w3.org/1999/XSL/Transform xmlns:strhttp://exslt.org/strings xmlns:datehttp://exslt.org/dates-and-times xmlns:mathhttp://exslt.org/math extension-element-prefixesstr date math然后就能调用str:split(...)、date:format-date(...)了。记住必须要声明extension-element-prefixesstr date math这一步漏掉的话某些处理器会认为你在试图创建“扩展元素”而直接报错。EXSLT虽好但跨处理器的兼容性风险不容忽视。同一个函数Saxon支持但别的引擎未必支持或者支持的参数行为有细微差异。我的原则是能用XPath内置函数解决就绝不用EXSLT必须在1.0环境用EXSLT时要在项目文档里明确记录“此样式表依赖EXSLT处理器必须支持”避免上线后才发现环境不支持。更深度的处理器扩展比如Saxon的Java扩展机制、调用静态Java方法更是如此这些功能能解决大问题但也把样式表锁定在特定处理器上。如果你接手的项目要部署到多个平台最好只在独立模块中使用扩展功能别让核心转换逻辑依赖某个专有扩展。4. 实战翻车现场与排查思路函数相关的坑我都踩过4.1 报错“函数未定义”时按这个顺序排查“函数未定义”或“Cannot find a matching function”应该是我见过最多的报错。每次遇到这个错我建议按下面这个顺序排查可以少走很多弯路。第一步查函数名拼写和大小写。XPath和XSLT函数名区分大小写String-Length、SUBSTRING这些写法统统不行必须是string-length、substring。这种报错一般是手滑检查一遍签名就能发现。第二步查命名空间声明。如果是自定义函数或EXSLT函数哪怕函数名写对了没声明命名空间照样报错。我之前就犯过这种错写了local:count-char但样式表根元素上漏了xmlns:local声明处理器直接说找不到函数。检查方法很简单看样式表根元素上的所有xmlns前缀函数调用时用的前缀必须都在里面。第三步查XSLT版本。lower-case()、xsl:function这些2.0特性在1.0环境里用了就会报错。这个问题的隐蔽之处在于很多处理器默认按1.0运行你的version2.0不一定被所有引擎认可。如果换了处理器报错先确认它对2.0标准的支持情况。第四步查函数所在库是否被处理器实现。EXSLT标准是一回事具体处理器是否实现是另一回事。有些精简版处理器只实现了一部分EXSLT函数调用没实现的那部分就会报“函数未定义”。下面是一个典型的报错和对应处理表报错现象可能原因处理方式Cannot find a matching 1-argument function named {http://exslt.org/strings}split处理器不支持EXSLT strings 库换用支持EXSLT的处理器或改用内置tokenize()2.0自定义函数报“未定义”xmlns:local前缀未声明在样式表根元素补上命名空间声明lower-case()报错运行在XSLT 1.0环境改用translate()模拟或升级到2.0处理器format-number()结果不对pattern 写错先单测验证pattern再套进模板4.2 类型与上下文陷阱结果树片段、position、隐式转换函数返回值的类型如果理解不到位会引发很多“看起来没问题但结果完全不对”的怪现象。XSLT 1.0里最常见的一个坑是“结果树片段”Result Tree Fragment。你用xsl:variable nametmpxsl:call-template namefoo//xsl:variable这种方式创建变量时变量内容不是真正的节点集而是一种叫结果树片段的东西。结果树片段几乎不能当节点集用——不能对它做$tmp//product、不能求count($tmp)不能直接传给普通节点集参数。要绕过这个限制在支持EXSLT的处理器里可以用exsl:node-set($tmp)把它转换回节点集升级到2.0后这个类型直接消失了所以如果你能用2.0这个问题自然不复存在。position()的上下文陷阱我之前提过一嘴这里再展开。同样一段position()放在xsl:for-each里跟在xsl:apply-templates匹配到的模板里含义完全不同。for-each会建立一个新的节点列表position()是当前节点在列表里的序号而apply-templates情况下模板里上下文依赖调用处选择的节点列表。还有更隐蔽的当你在表达式中使用谓词过滤节点时比如product[position() lt; 3]这个position()指的是在筛选出来的节点集中的位置而不是所有商品里的位置。这个细节在生成序号或者分页场景下特别容易出错调试时先用xsl:message把position()和current()同时打出来对比很快就能定位。还有一个让新手困惑的点是节点与字符串的隐式比较。在XSLT 1.0里节点集和字符串比较时会把节点集的字符串值拿出来转换后再比。比如product apple如果当前上下文是多个节点这个表达式的结果是“只要有某个节点等于apple就为true”这跟直觉可能不太一样。所以做多值判断时要明确你到底是想“全部满足”还是“存在满足”这决定了应该用not(product apple)还是product ! apple。很多过于精简的“好像逻辑对”的表达就是在这种地方栽的跟头。4.3 命令行环境和开发工具导致的问题别甩锅给函数函数本身没报错但命令跑不起来这种情况我见过太多回。比如你下载了Saxon在Windows PowerShell里输入saxon -s:input.xml -xsl:style.xsl -o:output.xml结果系统提示“无法将‘saxon’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这跟函数一点关系都没有就是saxon命令不在系统PATH环境变量里或者你根本没把可执行文件放到正确位置。我在新环境里配XSLT开发工具时通常会先确认三件事本机的Java或Python运行环境有没有就绪Saxon对应的启动脚本路径有没有加入PATH直接用完整路径能不能跑通。与其在全局PATH里塞一堆东西我更推荐写一个简单的构建脚本或者Makefile把调用命令的完整路径和参数固定下来这样不管换到哪台机器只要改两行配置就能跑。开发时的调试工具同样重要。我平时最快的方式是写一个最小复现样例用命令行处理器单独跑。要注意在样式表里加入xsl:message调试输出把中间变量打到标准错误输出能省下一大半排查时间。另外市面上也有可视化XSLT调试工具比如XML编辑器内置的调试器能看到节点匹配过程和变量值适合排查复杂上下文问题。不过在线调试工具这类东西用的时候留意数据隐私涉及敏感信息最好还是本地跑。4.4 函数排错速查表收藏就完事了最后把我这些年踩过的坑整理成一张速查表遇到问题可以先对着表查。表里每一行都是我实际处理过的案例不是从文档里抄出来的。现象可能原因处理方式position()序号和预期不符上下文节点列表变了用xsl:message打印position()与current()确认上下文sum()结果是0或NaN节点内容是字符串未number()转换先number(price)再求和并检查字段里是否有杂质字符generate-id()在多次运行间不一致把单次处理ID当成持久ID用只用于单次处理内的去重和引用持久化用业务字段format-number()输出多出空格或不对齐pattern 和语言环境不匹配显式指定十进制格式或统一环境配置exsl:node-set()报错处理器不支持EXSLT升级到2.0再重构或换处理器substring()结果多一位少一位从0开始计位的习惯影响记住XPath位置从1开始key()找不到节点xsl:key的match/use表达式写错检查索引表达式直接在文档里验证自定义函数递归栈溢出缺边界条件递归入口先写终止条件先在小样本上测试上面这些坑有些我重复踩过不止一次尤其是上下文和类型转换这两类问题表面现象五花八门根子就那几个。后来我养成一个习惯写XSLT时尽量在表达式最复杂的地方加一句xsl:message输出运行时的变量值宁可多打几行也要让执行过程透明。还有一个小技巧是专门建一个测试用的XML文件和对应的样式表把所有常用函数的输入输出都验证一遍形成自己的“函数验证集”。以后改样式表先用这个验证集跑一遍函数行为是否变化一目了然。这个习惯帮我挡掉了不少回归问题也让我每次写XSLT函数心里都有底。