¿Mismo archivo, nombre de archivo diferente debido a un problema de codificación?


9

Estaba a punto de diferenciar una copia de seguridad de su fuente para verificar manualmente que los datos son correctos. Algunos caracteres, como åäö, no se muestran correctamente en los datos originales, pero como los clientes (a través de samba) lo interpretan correctamente, no hay de qué preocuparse. Los datos restaurados desde la copia de seguridad muestran los caracteres correctamente, lo que hace que diff no los considere los mismos archivos (con diffs, sino archivos completamente diferentes).

sumas md5, mismo archivo pero nombre 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

Opciones de montaje y sistemas de archivos

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

Lugar

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

¿Se ha rellenado sd [bc] 1 en la misma máquina? Es decir, ¿con la misma opción de montaje y configuración regional?
Tink

No, buen lugar. Sin embargo, lo saqué de la copia de seguridad en la misma máquina en este momento, y el problema persiste. Vea el resultado de 'od' agregado en la edición.
user135361

Respuestas:


6

Los sistemas de archivos Unix tienden a ser independientes de la localidad en el sentido de que los nombres de los archivos consisten en bytes y es asunto de la aplicación decidir qué significan esos bytes si caen fuera del rango ASCII. La convención en Unix hoy es codificar nombres de archivos y todo lo demás en UTF-8, aparte de algunos entornos heredados (principalmente asiáticos). Los sistemas de archivos de Windows, por otro lado, tienden a tener una codificación que se especifica en las propiedades del sistema de archivos.

Si necesita trabajar con nombres de archivo en una codificación diferente, cree una vista traducida de ese sistema de archivos con convmvfs . Consulte cómo trabajar con nombres de archivo en una codificación diferente a través de ssh

Parece que su sistema original tiene nombres de archivo codificados en latin-1. Su sistema actual usa UTF-8, y la secuencia de un byte que representa åen latin-1 ( \345) es una secuencia no válida en UTF-8 que se lsimprime como ?. Su proceso de copia de seguridad de alguna manera ha resultado en nombres de archivos codificados en UTF-8. Samba traduce nombres de archivos en función de su configuración.

Para acceder a los archivos originales con su codificación nativa, cree una vista recodificada:

mkdir /original-recoded
convmvfs -o icharset=LATIN1,ocharset=UTF8 /original /original-recoded
diff -r /original-recoded /frombackup

(Es posible que necesite otras opciones según los permisos y la propiedad que desee obtener).


Gracias por la explicación de cómo funciona. No estoy seguro de que esto realmente me esté ayudando, ¿me está diciendo que (probablemente) tengo sistemas de archivos que tienen diferentes codificaciones y, por lo tanto, necesito crear una vista traducida de ... etc.?
user135361

@ user135361 Tiene conjuntos de datos donde los nombres de archivo tienen diferentes codificaciones. He ampliado mi respuesta.
Gilles 'SO- deja de ser malvado'

Esto realmente hizo el truco. Muchas gracias por tu perspicacia.
user135361

1

En Unix / Linux, un nombre de archivo puede contener cualquier carácter, excepto '\0'(ASCII NUL) y '/'(barra oblicua, separador de directorio). En particular, si desea dar nombres a sus archivos en Kanji con alguna codificación extraña, simplemente continúe. Probablemente solo verá galimatías en ls(1)u otros comandos, pero no sucederá nada malo. Eso es lo que está viendo, se representa como p?, '?'aquí hay un atajo común para "carácter desconocido / no ASCII".

Intente ejecutar ambos nombres de archivo od -c, es decir, haga algo como:

ls /the/dir/offending/fi* | od -c

(el glob es filtrar nombres no relevantes, ajustar al gusto).

Solo si la salida difiere comenzaría a preocuparme. Pero dada su configuración Svedish, sospecho que el nombre correcto es . ¿Quizás el otro es un nombre en latín-4 sobrante de una configuración anterior?


Aunque no es una solución, creo que proporciona una explicación valiosa de cómo funciona. Además, no sabía de 'od', editado para proporcionar una salida od.
user135361
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.