☰

Opendir und Readdir kodieren Zeichenfolgen hinter meinem Rücken?

tag-icon • tag-icon directory-structure character-encoding
Opendir und Readdir kodieren Zeichenfolgen hinter meinem Rücken?

(Sie können die Details bis zu den letzten Zeilen überspringen, wenn Sie die Frage beantworten können :))

Ich verwende Ubuntu 12.04. Ich versuche, ein altes Problem zu lösen, über das ich in der Vergangenheit gepostet habe (falls Sie neugierig sind:https://superuser.com/questions/339877/trouble-viewing-files-with-non-english-names-on-hard-disk/339895#339895). Es gibt ein bekanntes Kompatibilitätsproblem zwischen Linux, Mac, HFS+ und Dateien mit koreanischen Namen und ich habe heute den ganzen Tag damit verbracht, endlich eine Art Workaround zu finden.

Im Grunde habe ich mein HFS+-Laufwerk unter Linux gemountet. Normale LS- und CD-Befehle haben Probleme beim Zugriff auf die Dateien, da sie auf Koreanisch sind. Daher habe ich ein C-Programm geschrieben, um zu versuchen, auf der untersten Ebene auf diese Dateien zuzugreifen, damit ich sicherer sein kann, dass nichts hinter meinem Rücken passiert:

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

Hier ist ein Beispiel für die Ausgabe, die ich dafür erhalte:

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

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

434033 Nummer 4 0xEB 0xB0 0x95 0xED 0x95 0x98 0xEC 0x82 0xAC 0xED 0x83 0x95

Oberflächlich betrachtet sieht es also so aus, als hätte openddir keine Probleme, die Verzeichniseinträge anzuzeigen. Die Inode-Nummern sind da, sie sind korrekt als Verzeichnisse gekennzeichnet (4 bedeutet Verzeichnis) und es scheint, dass die Dateinamen als UTF-8-codiert gespeichert sind, da diese Hexadezimalzahlen die korrekten UTF-8-Codes für die koreanischen Dateinamen sind. Aber wenn ich jetzt ein readdir eines dieser Verzeichnisse ausführen würde (und ich werde den Dateinamen in Hex verwenden, um besonders sicher zu sein, dass nichts hinter meinem Rücken passiert):

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

Das Verzeichnis kann nicht geöffnet werden. Das verwirrt mich, denn wenn opendir nur die Rohdaten des Dateinamens im Verzeichniseintrag meldet und readdir nur meinen angegebenen Dateinamen nimmt und ihn mit dem richtigen Verzeichniseintrag abgleicht, dann hätte ich gedacht, dass es kein Problem sein sollte, den Inode zu finden und das Verzeichnis zu öffnen. Das scheint darauf hinzudeuten, dass opendir bei den Dateinamen nicht ganz ehrlich ist.

Sind die Dateinamen in den von opendir gemeldeten Verzeichniseinträgen nicht das, was sich tatsächlich auf der Festplatte befindet (d. h. werden sie kodiert)? Wenn ja, gibt es eine Möglichkeit, dass ich entweder steuern kann, wie opendir und readdir Namen kodieren, oder vielleicht andere Systemaufrufe verwenden kann, die mit Rohbytes arbeiten, anstatt Dinge hinter meinem Rücken zu kodieren? Im Allgemeinen finde ich es sehr verwirrend, auf welcher Ebene die Kodierung stattfindet, und ich wäre für jede Erklärung oder besser noch für eine Referenz dankbar, um dies zu verstehen! Danke!

Antwort1

opendirund readdirsie selbst arbeiten an Bytes. Sie führen keine Neukodierung durch.

Einige Dateisystemtreiber können Beschränkungen für die Byte-Sequenzen auferlegen. Beispielsweise normalisiert HFS+ Dateinamen mithilfe eines proprietären Unicode-Normalisierungsschemas. Ich würde jedoch erwarten, dass die von zurückgegebene Form readdirfunktioniert, wenn sie an übergeben wird opendir, also wie der OP in derUbuntu-ForumsthreadDasjw013 erwähnt, ich vermute einen Fehler im HFS+-Treiber. Es istnicht das einzige Programmdas durch Hangul auf HFS+ ausgelöst wird.Sogar OSXscheint Probleme zu haben mitUnicodeNormalisierung.

verwandte Informationen