终端与Cron执行时Bash IFS行为差异问题排查

这个问题我之前遇到过类似的情况，核心原因是Cron环境的locale设置和终端不同，导致多字节分隔符的解析出现问题，进而让数组统计数量翻倍。

问题根源分析 #

你在脚本中使用了§作为分隔符，这是一个UTF-8多字节字符。终端环境通常默认配置为UTF-8 locale，所以bash能正确识别§是单个字符；但Cron的默认环境是POSIX/C locale（仅支持ASCII字符），此时bash会把§拆成两个独立的ASCII字节（0xC2和0xA7）。

当你执行IFS="$delimiter" read -r -a tags <<<"$tagString"时：

• 在终端UTF-8环境下，IFS被设置为单个字符§，read只会用这个字符分割字符串，得到正确的元素数量。
• 在Cron的C locale环境下，IFS实际上包含了两个独立的字节字符，而hxselect输出的§是UTF-8格式的单个多字节字符，此时每个§会被这两个字节分别匹配，相当于每个分隔位置被分割两次，产生大量空元素，最终数组长度就变成了原来的两倍（比如原本6个标签，变成6个标签+6个空元素，总数12）。

解决办法 #

这里有几个可行的方案，按推荐程度排序：

1. 在脚本开头强制设置UTF-8 locale
   在脚本的#!/bin/bash下方添加一行，确保Cron环境使用UTF-8字符集：

   export LC_ALL=en_US.UTF-8
   export LANG=en_US.UTF-8
   

   这样bash就能正确识别§为单个字符，IFS的行为和终端一致。

2. 改用ASCII分隔符
   把分隔符换成ASCII范围内的字符（比如|、^或者@@@这类不会出现在HTML标签中的字符串），避免多字节字符的解析问题。比如：

   delimiter="|"
   

   同时修改hxselect的参数：

   tagString=$(wget -qO - --user-agent="$useragent" $p | hxnormalize -x | hxselect -s "$delimiter" $searchtag )
   

3. 用awk替代bash数组统计数量
   不依赖bash的IFS分割，直接用awk统计分隔符的数量+1，这种方式不受locale影响，更可靠：
   把原来的数组统计代码替换成：

   tagCount=$(echo "$tagString" | awk -F "$delimiter" '{print NF}')
   # 处理空字符串的特殊情况（空字符串时NF为1）
   if [ -z "$tagString" ]; then
       tagCount=0
   fi
   echo "Amount of img tags: $tagCount" >> $scriptdirpath/testimages.txt
   

验证建议 #

你可以先检查Cron执行后的testtagstring.txt，里面的分隔符应该是正常的§，但用C locale的bash去分割就会出问题。添加locale设置后，应该就能和终端执行的结果一致了。

内容的提问来源于stack exchange，提问作者Christian