☰

내 뒤에서 opendir 및 readdir 인코딩 문자열이 있습니까?

tag-icon • tag-icon directory-structure character-encoding
내 뒤에서 opendir 및 readdir 인코딩 문자열이 있습니까?

(질문에 답할 수 있으면 마지막 두 줄까지 세부정보를 건너뛸 수 있습니다. :))

저는 우분투 12.04를 사용하고 있습니다. 과거에 게시한 오래된 문제를 해결하려고 합니다(궁금하신 경우:https://superuser.com/questions/339877/trouble-viewing-files-with-non-english-names-on-hard-disk/339895#339895). Linux, Mac, HFS+ 및 한국어 이름의 파일 간에는 알려진 호환성 문제가 있으며, 마침내 일종의 해결 방법을 찾으려고 오늘 하루 종일 보냈습니다.

기본적으로 저는 HFS+ 드라이브를 Linux에 마운트했습니다. 일반 ls와 cd는 한국어로 되어 있어서 파일 접근에 문제가 있습니다. 그래서 나는 가장 낮은 수준에서 이러한 파일에 액세스하려고 C 프로그램을 작성하여 뒤에서 아무 일도 일어나지 않을 것이라고 더 확신할 수 있습니다.

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! ");
}

이에 대해 얻은 출력 샘플은 다음과 같습니다.

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

따라서 표면적으로는 openddir이 디렉토리 항목을 보는 데 아무런 문제가 없는 것처럼 보입니다. inode 번호가 있고 디렉토리(4는 디렉토리를 의미)로 올바르게 표시되어 있으며 파일 이름은 UTF-8 인코딩으로 저장되어 있는 것으로 보입니다. 왜냐하면 해당 16진수는 한국어 파일 이름에 대한 올바른 UTF-8 코드이기 때문입니다. 그러나 이제 이 디렉토리 중 하나에 대해 readdir을 수행한다면(그리고 뒤에서 아무 일도 일어나지 않도록 특별히 주의하기 위해 파일 이름을 16진수로 사용하겠습니다):

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!!!

디렉토리를 열 수 없습니다. opendir이 디렉토리 항목에 있는 파일 이름의 원시 비트만 보고하고 readdir이 단지 내 주어진 파일 이름을 가져와서 올바른 디렉토리 항목과 일치시키는 것이라면 이 문제는 나를 당황하게 합니다. 그러면 나는 문제가 없을 것이라고 생각했을 것입니다. inode를 찾아 디렉토리를 엽니다. 이는 opendir이 파일 이름에 대해 완전히 정직하지 않다는 것을 암시하는 것 같습니다.

opendir이 보고한 디렉토리 항목의 파일 이름이 실제로 디스크에 있는 이름이 아닙니까(즉, 인코딩되고 있습니까)? 그렇다면 opendir 및 readdir이 이름을 인코딩하는 방법을 제어하거나 뒤에서 인코딩하는 대신 원시 바이트로 작동하는 다른 시스템 호출을 사용할 수 있는 방법이 있습니까? 일반적으로 어떤 수준의 인코딩이 발생하는지 매우 혼란스럽습니다. 이에 대한 설명이나 이를 이해하기 위한 참고 자료를 주시면 감사하겠습니다! 감사해요!

답변1

opendir그리고 readdir그들 자신은 바이트로 작업합니다. 수행 및 재인코딩을 수행하지 않습니다.

일부 파일 시스템 드라이버는 바이트 시퀀스에 제약을 가할 수 있습니다. 예를 들어, HFS+는 독점적인 유니코드 정규화 체계를 사용하여 파일 이름을 정규화합니다. 그러나 readdir에서 반환된 양식은 에 전달될 때 작동할 것으로 기대합니다. opendir따라서 OP의 OP와 같습니다.우분투 포럼 스레드저것jw013 말하는, HFS+ 드라이버에 버그가 있는 것으로 의심됩니다. 그것은유일한 프로그램은 아니다HFS+에서 한글에 의해 트립됩니다.심지어 OSX문제가 있는 것 같아유니코드표준화.

관련 정보