opendir et readdir codant des strings derrière mon dos?

(Vous pouvez passer les détails aux deux dernières lignes si vous êtes en mesure de répondre à la question :))

Je suis sur un Ubuntu 12.04. J'essaie de résoudre un ancien problème que j'ai signalé dans le passé (si vous êtes curieux: https://superuser.com/questions/339877/trouble-viewing-files-with-non-english-names -on-disque dur / 339895 # 339895 ). Il y a un problème de compatibilité connu entre Linux, Mac, HFS + et les files nommés en coréen, et j'ai passé toute la journée aujourd'hui à essayer de find une sorte de solution de rechange.

Fondamentalement, j'ai monté mon lecteur HFS + sur linux. Normal ls et cd ont du mal à accéder aux files, car ils sont en coréen. J'ai donc écrit un programme en C pour essayer d'accéder à ces files au niveau le plus bas, afin que je puisse être plus sûr que rien ne se passe derrière mon dos:

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

Voici un exemple de la sortie que je reçois pour cela:

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

Donc, apparemment, openddir n'a pas de problème pour visualiser les inputs du directory. Les numéros d'inode sont là, ils sont correctement marqués comme des directorys (4 signifie directory) et il semble que les noms de files sont stockés en UTF-8, puisque ces hexadécimaux sont les codes UTF-8 corrects pour les noms de files coréens. Mais maintenant, si je devais faire un readdir d'un de ces directorys (et j'utiliserai le nom de file dans l'hexagone pour être très prudent que rien ne se passe derrière mon dos):

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

Il n'est pas capable d'ouvrir le directory. Cela me dérange parce que si opendir ne faisait que rapporter les bits bruts du nom de file dans l'input du directory et que readdir prenait juste mon nom de file donné et l'assortissait avec l'input de directory correcte, alors j'aurais pensé qu'il ne devrait pas y avoir de problème find l'inode et ouvrir le directory. Cela semble suggérer qu'opendir n'est pas complètement honnête sur les noms de files.

Les noms de files dans les inputs du directory sont-ils rapportés par opendir et non ce qui est réellement sur le disque (c'est-à-dire sont-ils encodés)? Si oui, est-il possible de contrôler comment opendir et readdir encodent des noms, ou peut-être utiliser d'autres appels système qui fonctionnent avec des octets bruts au lieu d'encoder des choses derrière mon dos? En général, je trouve cela très confus à quel niveau d'enencoding se passe et j'apprécierais toutes les explications ou mieux encore, une reference pour comprendre cela! Merci!

opendir et readdir travaillent eux-mêmes sur des octets. Ils n'effectuent pas et ne ré-encodent pas.

Certains pilotes de système de files peuvent imposer des contraintes sur les séquences d'octets. Par exemple, HFS + normalise les noms de files en utilisant un système de normalisation Unicode propriétaire. Je suppose que le formulaire returnné par readdir fonctionne quand il est passé à opendir , cependant, comme l'OP dans le thread du forum Ubuntu que jw013 a mentionné , je soupçonne un bug dans le pilote HFS +. Ce n'est pas le seul programme qui est déclenché par Hangul sur HFS +. Même OSX semble avoir des problèmes avec la normalisation Unicode .