注意到集算器函数更新了按定长拆分和合并文本的功能，这无疑是很好用的功能，赶紧试用了一下，尚有以下几点想法，恳请大佬们看看：

1、split@y 拆分时如果长度越界可否不抛出错误，继续拆？

比如以下拆分，按长度 1,2,3 拆分成 a,bc,def 后剩下的文本 g 相对于长度 4 不够长度，越界报错了，那此时可否继续拆，最终拆成 a,bc,def,g?

无独有偶，微软的 Power Query 里有一个对应的按长度拆分 Splitter.SplitTextByLengths，如下所示，在长度越界时会继续拆，有字符时拆出剩下的字符，无字符时拆出空 ""，观察下图中最后 3 行的结果，对应长度 4,5,6：

在长度越界时，如果有剩下的字符，则返回剩下的字符，这个我觉得是可以的，因为指定了一个长度总要拆出来结果，对吧，至于后续还有其他长度参数，要继续拆分成空，使得结果长度跟参数的长度保持一致，还是没有字符后截断不拆了，这个我也说不好。似乎有几个参数就拆分成几段看上去合理一些。

2、split@y 能否从右往左拆？

常规都是从左往右拆，但 split 也有 @z 选项表示从最后一个位置拆，相当于是右边。但这个 @z 并不是严格意义上的从右往左。这里只是举个例子，看能否实现从右往左拆，还是拿 Power Query 里的 Splitter.SplitTextByLengths 举例，可以指定参数 true/false 以确定方向，比如以下从右往左拆：

3、concat@y 也存在长度越界报错的问题，是否可以忽略越界，继续按规则合并？

如下所示，长度 4 对应最后的 g，补完 3 个空格后，到长度 5 和长度 6 时，索引越界报错了，希望不不抛出错误，返回补完空格后的结果。

在 Power Query 中也有对应的合并函数 Combiner.CombineTextByLengths，如下所示，长度 5 和 6 虽然越界了，但没有抛出错误，继续合并，在 g 后补完 3 个空位后，再补了 5 个空位，剩下的长度 6 就忽略了。

4、concat@y 合并时在长度大于字符串长度时会用空格补上，那如果长度小于对应的字符串长度，此时取较小的长度 (也就是在字符串左边截取部分) 还是取字符串本身合适？如果长度是 0 或者负数，又当如何约定？目前都是取字符串本身，如下，bc 对应的长度是 3，所以合并时在 bc 后补了一个空，同理 g 对应的长度是 2，所以在最后补上了一个空，而 def 对应的长度是 1，此时取了全部 def。

这个跟 Power Query 里的 Combiner 有点不同，PQ 里长度小于字符串时，变成在左边截取了长度位数，如下，可以看到，长度 3 对应于 bc，后边补上了空格，这个是一样的，观察 1 对应的 def 和 0 对应的 g，此时，def 只截取了 1 位 d，而 0 对应的 g 没有合并，结果中后边的两个空格是长度 0 后边的两个 1 形成的。PQ 中长度不能为负数，只允许大于等于 0。

这一点，麻烦大佬们看看，在 SPL 中长度小于字符串长度时，是截取合适还是返回字符串合适，长度为 0 或者负数时又要如何约定？

上述 4 点是当前存在的问题，以下是我一直想求助的问题，属于无中生有:

我是这样想的，既然 split 和 concat 可以用数列当参数，那拆分和合并时，可不可以让一个分隔符序列作为参数，比如 split@([“,”,"“,”;"]) 或者 concat@([“,”,"“,”;"])，什么意思呢？拆分的时候按指定的分隔符顺序拆，有几个拆几个，拆完就结束，即使后边还有同样的分隔符存在也不拆，如果参数序列中的分隔符在字符串中找不到，立即停止拆分。concat 时按指定的分隔符序列合并，有几个合并几个，不够分隔符时直接合并。在 Power Query 中有对对应的函数，Splitter.SplitTextByEachDelimiter 和 Combiner.CombineTextByEachDelimiter，如下所示：

按照空格、分号、逗号的顺序拆，接下来的冒号在后边字符串中找不到，就停止拆了：

再比如，按空格、空格、逗号…这样拆，第一个空格匹配上后，后续没有跟第二个空格匹配的了就停止拆了：

只要后续还有空格，就会继续拆：

相当于按照参数序列，严格按顺序一个一个拆，找不到时就停止。

合并时是这样的，依次按分隔符序列合并，字符串不够时直接合并，分隔符比字符串多时，直接忽略剩下的分隔符：

暂时就想到这些，恳请大佬们有空时看看，是否有必要改善实现，谢谢🙏