☰

¿Cadenas de codificación opendir y readdir a mis espaldas?

tag-icon • tag-icon directory-structure character-encoding
¿Cadenas de codificación opendir y readdir a mis espaldas?

(Puedes saltar los detalles a las últimas líneas si puedes responder la pregunta :))

Estoy en Ubuntu 12.04. Estoy intentando resolver un problema antiguo sobre el que publiqué en el pasado (si tienes curiosidad:https://superuser.com/questions/339877/problemas-para-ver-archivos-con-nombres-que-no-ingleses-en-el-disco-duro/339895#339895). Existe un problema de compatibilidad conocido entre Linux, Mac, HFS+ y archivos con nombres coreanos, y hoy pasé todo el día tratando de encontrar finalmente algún tipo de solución.

Básicamente, monté mi unidad HFS+ en Linux. Los ls y cd normales tienen problemas para acceder a los archivos porque están en coreano. Así que escribí un programa en C para intentar acceder a estos archivos en el nivel más bajo, para poder estar más seguro de que no sucedería nada a mis espaldas:

DIR* dp; 
struct dirent *ep;
char* parent = "/media/external/Movies";
dp = opendir( parent );
if( dp != NULL )
{   
    while( ep = readdir(dp) )
    {   
        printf( "%d %s %X\t", ep->d_ino, ep->d_name, ep->d_type );

    // now print out the filenames in hex
        for( int i = 0; i != strlen( ep->d_name ) ; i++)
        {   
            printf( "0x%X " , ep->d_name[i] & 0xff );
        }   
        printf("\n");
    }   
    closedir(dp);
}
else
{   
     perror("Couldn't open the directory! ");
}

Aquí hay una muestra del resultado que obtengo para esto:

433949 4 0xEB 0xB0 0x80 0xEC 0x96 0x91

413680 4 0xEB 0xB0 0x95 0xEC 0xA5 0x90

434033 박하사탕 4 0xEB 0xB0 0x95 0xED 0x95 0x98 0xEC 0x82 0xAC 0xED 0x83 0x95

Entonces, en la superficie, parece que openddir no tiene problemas para ver las entradas del directorio. Los números de inodo están ahí, están marcados correctamente como directorios (4 significa directorio) y parece que los nombres de archivos están almacenados con codificación UTF-8, ya que esos hexadecimales son los códigos UTF-8 correctos para los nombres de archivos coreanos. Pero ahora, si tuviera que hacer un readdir de uno de estos directorios (y usaré el nombre del archivo en hexadecimal para tener mucho cuidado de que no suceda nada a mis espaldas):

unsigned char new_dirname[] = {'/',0xEB,0xB0,0x80,0xEC,0x96,0x91,'\0'};
unsigned char final[ strlen(parent) + strlen(new_dirname) + 1 ];
memcpy(final, parent, strlen( parent )); 
strcpy(final + strlen(parent), dirname );
dp = opendir( final ); // dp == NULL here!!!

No puede abrir el directorio. Esto me confunde porque si opendir solo estaba informando los bits sin procesar del nombre del archivo en la entrada del directorio, y readdir simplemente tomaba el nombre de mi archivo dado y lo comparaba con la entrada correcta del directorio, entonces habría pensado que no debería haber ningún problema en encontrando el inodo y abriendo el directorio. Esto parece sugerir que opendir no está siendo completamente honesto acerca de los nombres de los archivos.

¿Los nombres de los archivos en las entradas del directorio reportadas por opendir no son los que realmente están en el disco (es decir, están codificados)? Si es así, ¿hay alguna forma de controlar cómo opendir y readdir codifican nombres, o tal vez usar otras llamadas al sistema que funcionen con bytes sin formato en lugar de codificar cosas a mis espaldas? En general, me resulta muy confuso a qué nivel se produce la codificación y agradecería cualquier explicación o, mejor aún, una referencia para entender esto. ¡Gracias!

Respuesta1

opendiry readdirellos mismos trabajan en bytes. No realizan y recodifican.

Algunos controladores del sistema de archivos pueden imponer restricciones a las secuencias de bytes. Por ejemplo, HFS+ normaliza los nombres de archivos utilizando un esquema de normalización patentado Unicode. Sin embargo , esperaría que el formulario devuelto por readdirfuncione cuando se pase a opendir, por lo que, al igual que el OP en elHilo del foro de Ubuntuesojw013 mencionado, Sospecho que hay un error en el controlador HFS+. Esno es el único programaque Hangul activa en HFS+.Incluso OSXparece tener problemas conUnicódigonormalización.

información relacionada