(질문에 답할 수 있다면 마지막 몇 줄까지 세부정보를 건너뛰어도 됩니다 :) )
우분투 12.04를 사용하고 있습니다. 과거에 게시한 오래된 질문을 해결하려고 합니다(궁금하신 경우:https://superuser.com/questions/339877/trouble-viewing-files-with-non-english-names-on-hard-disk/339895#339895). Linux, Mac, HFS+ 및 한국어 이름의 파일 간에 알려진 호환성 문제가 있으며, 마침내 일종의 해결 방법을 찾으려고 오늘 하루 종일 보냈습니다.
기본적으로 Linux에 HFS+ 드라이버를 설치했습니다. 일반 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 코드이기 때문입니다. 그러나 이제 다음 디렉토리 중 하나를 읽으면(뒤에서 아무 일도 일어나지 않도록 각별히 주의하기 위해 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이 내가 제공한 파일 이름을 가져와 올바른 디렉토리 항목과 일치시키는 경우 인덱스 노드를 찾는 데 문제가 없을 것이라고 생각하기 때문에 이것이 나를 혼란스럽게 합니다. 그리고 디렉토리를 엽니다. 이는 opendir이 파일 이름에 대해 완전히 정직하지 않다는 것을 나타내는 것 같습니다.
opendir이 보고한 디렉토리 항목의 파일 이름이 디스크의 실제 파일 이름이 아닙니까(즉, 인코딩되어 있습니까)? 그렇다면 opendir 및 readdir이 이름을 인코딩하는 방법을 제어하거나 뒤에서 콘텐츠를 인코딩하는 대신 원시 바이트를 처리하는 다른 시스템 호출을 사용할 수 있는 방법이 있습니까? 일반적으로 어떤 수준의 인코딩이 발생하는지 매우 혼란스럽습니다. 이를 더 잘 이해할 수 있도록 설명이나 참조를 주시면 감사하겠습니다! 감사해요!
답변1
opendir
기본적으로 바이트 단위로 작동 readdir
합니다. 그들은 공연하거나 녹음하지 않습니다.
일부 파일 시스템 드라이버는 바이트 시퀀스에 제한을 가할 수 있습니다. 예를 들어, HFS+는 독점적인 유니코드 정규화 체계를 사용하여 파일 이름을 정규화합니다. 그러나 OP에서와 같이 readdir
에 전달될 때 반환된 양식이 제대로 작동하기 를 원합니다.opendir
우분투 포럼 주제저것jw013 언급하다, HFS+ 드라이버에 버그가 있는 것 같습니다. 이것은유일한 프로그램은 아니다HFS+의 한글은 이 오류를 발생시킵니다.심지어 OSX곤경에 처한 것 같아유니코드표준화.