Shell-script-internal encoding 与重定向输出不同

Question

目前，我正在处理一堆旧文件，这些文件在它们的生命周期中已经看到了很多机器、操作系统和文件系统。其中一些包含德语变音符号（ä、ö、ü），显然这些已导致某些文件名在其中一个移动过程中中断。一个原名为

的文件

München.txt

显示为

M?nchen.txt (invalid encoding)

在当前托管它们的 ubuntu 系统上。

所以现在我正在尝试批量修复它们。在循环浏览带有初稿的文件时，我偶然发现了这种现象：

• 在屏幕上回显给我带有问号的文件名，我理解这是对文件名中非法字符的解释：

   ./list_files.sh path_to_files
  
   M?nchen.txt
   K?ln.txt
  

• 如果我将输出保存到文件中，它会给我一个仍然包含无效字符的二进制文件：

   ./list_files.sh path_to_files > file_list
  
   less file_list
   M<FC>nchen.txt
   K<F6>ln.txt
  

这是代码：

#!/bin/bash

rootdir=$1

find "$rootdir" -print0 | while IFS= read -r -d '' broken_file_name; do
    echo $broken_file_name
done

我正在努力理解：

1. 为什么屏幕输出与文件中的不同？字符替换发生在哪里，问号是在哪里创建的？
2. 如何防止在脚本进程中使用问号的东西解释非法字符？它可以防止我有选择地用相应的正确字符替换非法字符。

Answer 1

问号替换可能发生在 Bash 本身中，只要您使用 Bash echo 并尝试输出在当前语言环境中无法表示的字符。它也可能是终端驱动程序的一个特性。

我们只能推测原始编码，但症状与Latin-1（ISO-8859-1）一致。

假设我猜对了编码，并假设您当前的语言环境是 UTF-8，尝试类似

while IFS= read -r original; do
    dest=$(iconv -f iso-8859-1 <<<"$original")
    mv -- "$original" "$dest"
done <file_list

Answer 2

less 的不同行为可能是 less 的事情。来自手册：

控制和二进制字符以突出显示（反向视频）。如果可能，每个这样的字符都以插入符号显示（例如，^A 表示 control-A）。仅当反转 0100 位导致正常的可打印字符时，才使用插入符号。否则，字符将显示为尖括号中的十六进制数字。可以通过设置 LESSBINFMT 环境变量来更改此格式。

但是由于您想要重命名文件，因此各种实用程序显示名称的方式并不那么重要。在您的脚本中，您可以使用 tr 通过替换其他人不喜欢的字符来计算新名称。例如，如果您想分别用 o 和 u 替换 ö 和 ü：

new=$(tr '\366\374' 'ou' <<< "$old")
if [ "$new" != "$old" ]; then
  mv "$old" "$new"
fi

（366和374是ö和ü的ASCII码，八进制）。