diary/Kojima

・file-roller のデバッグ

日本語ファイル名が再生できない vlc とか、ディレクトリ選択ウィンドウの化ける gthumb とか、引数で日本語のファイル名を指定できない file-roller とか、 GNOME関係で文字コードがらみでトラブっているパッケージが散見されるので、少し調べてみることに。

それぞれ、ざっとソースコードを眺めてみたけど、まずは一番分かりやすそうな file-roller の問題を追いかけてみた。

ソースコードのあちこちに debug 用の printf をバラまく昔からのやり方でしばらく四苦八苦してみたところ(GNOME 用の gtk ベースな GUI アプリだと処理の流れと画面表示が同時進行するので追いかけるのがかなり大変)、 日本語のファイル名を指定した場合、どうやら fr-archive.c の copy_remote_file() の中の、 g_file_query_exists() で False が帰ってくるのが原因らしい。

copy_remote_file (FrArchive  *archive,
                  const char *password)
{
        XferData *xfer_data; 

        printf("archive_file name:%s\n", g_file_get_basename(archive->file));
        printf("archive_file path:%s\n", g_file_get_path(archive->file)); 

        printf("archive_file name,conveted:%s\n", g_locale_from_utf8(g_file_get_basename(archive->file), -1, NULL, NULL, NULL));
        printf("archive_file uri:%s\n", g_file_get_uri(archive->file));

        if (! g_file_query_exists (archive->file, NULL)) {
                printf("Here it is!!\n");
                GError *error;
                error = g_error_new (G_IO_ERROR, G_IO_ERROR_NOT_FOUND, _("The file doesn't exist"));
                fr_archive_copy_done (archive, FR_ACTION_LOADING_ARCHIVE, error);
                g_error_free (error);
                return;
        }

こんな風に printf 文を散りばめてビルドした file-roller で、日本語のファイル名を引数に指定すると、

% ./work/usr/bin/file-roller ~/日本語_japanese.zip  
archive_file name:�—ユœ�茯ž_japanese.zip
archive_file path:/home/kojima/�—ユœ�茯ž_japanese.zip
archive_file name,conveted:日本語_japanese.zip
archive_file uri:file:///home/kojima/%E6%97%A5%E6%9C%AC%E8%AA%9E_japanese.zip
Here it is!

となり、g_file_query_exists() が Faluse になって、「"日本語_japanese.zip"を開けませんでした」というエラーウィンドウが開くのに対し、 同じファイルを Japanese.zip にコピーしてやると、

% ./work/usr/bin/file-roller ~/Japanese.zip 
archive_file name:Japanese.zip
archive_file path:/home/kojima/Japanese.zip
archive_file name,conveted:Japanese.zip
archive_file uri:file:///home/kojima/Japanese.zip

と、g_file_query_exists() のチェックもパスして、アーカイブを開くウィンドウが表示される。

結果的に見ると、g_file_get_basename() や g_file_get_path() で得られる、 GFile オブジェクトの 実際のファイルシステム上のファイルへの結び付きがUTF-8化されてしまっているので、EUC-JPなファイルを開けないことが原因らしい。

マニュアルとかを見てみると、g_file_get_basename() で得られる文字列は、UTF-8ではなく、ファイルシステム上で使っているエンコーディングにしておく、 ということなので、 file-roller がどこかで余計な変換をしてしまっているのだろうな。

All GFiles have a basename (get with g_file_get_basename()). These names are byte strings that are used to 
identify the file on the filesystem (relative to its parent directory) and there is no guarantees that they have 
any particular charset encoding or even make any sense at all. If you want to use filenames in a user interface 
you should use the display name that you can get by requesting the G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME 
attribute with g_file_query_info(). This is guaranteed to be in utf8 and can be used in a user interface. 
But always store the real basename or the GFile to use to actually access the file, because there is no way to go from a 
display name to the actual name. 

次はファイル名を UTF-8 に変換しているあたりを中心に調べてみるか。。


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-12-17 (金) 16:35:41