Eu estava prestes a diferenciar um backup da fonte para verificar manualmente se os dados estão corretos. Alguns caracteres, como åäö, não são mostrados corretamente nos dados originais, mas como os clientes (sobre o samba) os interpretam corretamente, não há nada com que se preocupar. Os dados restaurados do backup mostram os caracteres corretamente, levando o diff a não considerá-los os mesmos arquivos (com diffs, mas com arquivos completamente diferentes).
somas md5, mesmo arquivo, mas nome diferente.
# 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
Opções de montagem e sistemas de arquivos
/dev/sdb1 on /original type ext4 (rw,noatime,errors=remount-ro)
/dev/sdc1 on /frombackup type ext4 (rw)
Localidade
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 _ i m a g e s / k u n d
0000040 i d 8 0 / _ B a r n / i S t o c
0000060 k _ 0 0 0 0 0 3 6 3 7 0 8 3 L a
0000100 r g e - b a r n p 345 s t r a
0000120 n d . j p g \n
0000127
# ls "/frombackup/iStock_000003637083Large-barn på strand.jpg" | od -c
0000000 / d a t a / v a r / w w w / m e
0000020 d i a b a n k e n _ i m a g e s
0000040 / k u n d i d 8 0 / _ B a r n /
0000060 i S t o c k _ 0 0 0 0 0 3 6 3 7
0000100 0 8 3 L a r g e - b a r n p 303
0000120 245 s t r a n d . j p g \n
0000135
linux
diff
character-encoding
user135361
fonte
fonte
Respostas:
Os sistemas de arquivos Unix tendem a não ser locais, no sentido de que os nomes dos arquivos consistem em bytes e é o negócio do aplicativo decidir o que esses bytes significam se ficarem fora do intervalo ASCII. A convenção no unix hoje é codificar nomes de arquivos e tudo o mais no UTF-8, além de alguns ambientes legados (principalmente asiáticos). Os sistemas de arquivos do Windows, por outro lado, tendem a ter uma codificação especificada nas propriedades do sistema de arquivos.
Se você precisar trabalhar com nomes de arquivos em uma codificação diferente, crie uma visualização traduzida desse sistema de arquivos com convmvfs . Veja trabalhando com nomes de arquivos em uma codificação diferente sobre ssh
Parece que seu sistema original possui nomes de arquivos codificados em latin-1. Seu sistema atual usa UTF-8, e a sequência de um byte que representa
å
em latin-1 (\345
) é uma sequência inválida em UTF-8 que éls
impressa como?
. De alguma forma, seu processo de backup resultou em nomes de arquivos codificados em UTF-8. O Samba traduz nomes de arquivos com base em sua configuração.Para acessar os arquivos originais com sua codificação nativa, faça uma exibição recodificada:
(Você pode precisar de outras opções, dependendo de quais permissões e propriedade você deseja obter.)
fonte
No Unix / Linux, um nome de arquivo pode conter qualquer caractere, exceto
'\0'
(ASCII NUL) e'/'
(barra, separador de diretório). Em particular, se você quiser nomear seus arquivos em Kanji em alguma codificação estranha, vá em frente. Provavelmente, você verá apenas bobagensls(1)
ou outros comandos, mas nada de ruim acontecerá. Isso é o que você está vendo, opå
é renderizado comop?
,'?'
aqui é um atalho comum para "caractere desconhecido / não ASCII".Tente executar os dois nomes de arquivos
od -c
, ou seja, faça algo como:(o objetivo é filtrar nomes não relevantes, ajustar a gosto).
Somente se a saída diferir eu começaria a me preocupar. Mas, dada a sua configuração em svedish, suspeito que o nome correto seja
på
. Talvez o outro seja um nome em latim-4 restante de uma configuração anterior?fonte