相关疑难解决方法(0)

我有一堆包含带有特殊字符的文件的目录和子目录，比如这个文件：

robbie@phil:~$ ls test?sktest.txt 
test?sktest.txt

Find 揭示了一个转义序列：

robbie@phil:~$ find test?sktest.txt -ls 
424512 4000 -rwxr--r-x   1 robbie   robbie    4091743 Jan 26 00:34 test\323sktest.txt

我什至可以在控制台上输入他们的名字的唯一原因是因为选项卡完成。这也意味着我可以手动重命名它们（并去除特殊字符）。

我已将 LC_ALL 设置为 UTF-8，这似乎没有帮助（也不是在新外壳上）：

robbie@phil:~$ echo $LC_ALL
en_US.UTF-8

我正在使用 ssh 从我的 mac 连接到机器。这是一个 Ubuntu 安装：

robbie@phil:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

Shell 是 Bash，TERM 设置为 xterm-color。

这些文件已经存在很长一段时间了，它们不是使用 Ubuntu 安装创建的。所以我不知道以前的系统编码设置是什么。

我已经尝试过以下方面的事情：

find . -type f -ls | sed 's/[^a-zA-Z0-9]//g'

但我找不到可以做我想做的一切的解决方案：

1. 识别所有具有不可显示字符的文件（以上忽略太多）
2. 对于目录树中的所有文件（递归），执行 mv oldname newname
3. 可选地，能够将特殊字符（如 ä）音译为 a（不是必需的，但会很棒）

或者

1. 正确显示所有这些文件（尝试打开它们时应用程序中没有错误）

我有一些零碎的东西，比如遍历所有文件并移动它们，但是识别文件并为 mv 命令正确格式化它们似乎是困难的部分。

任何关于它们为什么不能正确显示或如何“猜测”正确编码的额外信息也是受欢迎的。（我试过 convmv 但它似乎并没有完全按照我的要求做： …

我正要从它的源中区分备份以手动验证数据是否正确。一些字符，比如 åäö，在原始数据上没有正确显示，但是当客户端（通过 samba）正确解释它时，没有什么可担心的。从备份恢复的数据正确显示字符，导致差异不认为它们是相同的文件（有差异，而是完全不同的文件）。

md5 sums，相同的文件但不同的名称。

# md5sum /original/iStock_000003637083Large-barn*
e37c34968dd145a0e25692e1cb7fbdb1  /original/iStock_000003637083Large-barn p? strand.jpg

# md5sum /frombackup/iStock_000003637083Large-barn*
e37c34968dd145a0e25692e1cb7fbdb1  /frombackup/iStock_000003637083Large-barn på strand.jpg

挂载选项和文件系统

/dev/sdb1 on /original type ext4 (rw,noatime,errors=remount-ro)
/dev/sdc1 on /frombackup type ext4 (rw)

语言环境

LANG=sv_SE.UTF-8
LANGUAGE=
LC_CTYPE="sv_SE.UTF-8"
LC_NUMERIC="sv_SE.UTF-8"
LC_TIME="sv_SE.UTF-8"
LC_COLLATE="sv_SE.UTF-8"
LC_MONETARY="sv_SE.UTF-8"
LC_MESSAGES="sv_SE.UTF-8"
LC_PAPER="sv_SE.UTF-8"
LC_NAME="sv_SE.UTF-8"
LC_ADDRESS="sv_SE.UTF-8"
LC_TELEPHONE="sv_SE.UTF-8"
LC_MEASUREMENT="sv_SE.UTF-8"
LC_IDENTIFICATION="sv_SE.UTF-8"
LC_ALL=

od -c

# ls "/original/iStock_000003637083Large-barn p? strand.jpg" | od -c
0000000   /   v   a   r   /   w   w   w   /   m   e   d   i   a   b   a
0000020   n   k   e   n …