After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 140980 - g_filename_from_uri fails to parse URI in chinese
g_filename_from_uri fails to parse URI in chinese
Status: RESOLVED DUPLICATE of bug 140532
Product: glib
Classification: Platform
Component: general
2.4.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2004-04-23 22:02 UTC by Felipe Heidrich
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description Felipe Heidrich 2004-04-23 22:02:47 UTC
Select Language "Simplified Chinese" in the log in screen.

Run Nautilus, in the /tmp folder create and new folder.
(This new folder name is in chinese.)
Try to drag this folder to a GTK app that supports drag&drop.
In my case I used Eclipse (eclipse.org).

I could verify that the "data" of the drag_data_received callback is the string:
file:///tmp/%CE%B4%C3%FC%C3%FB%CE%C4%BC%FE%BC%D0
If a paste this string into mozilla (or nautilus) it will correctly open this
folder. Therefore I believe the URI is right.

The problem is: if I use g_filename_from_uri() to parse this URI it  returns a
error message:
The URI 'file:///tmp/%CE%B4%C3%FC%C3%FB%CE%C4%BC%FE%BC%D0' contains invalidly
escaped characters

Maybe the problem is that after unescaping the string glib expect to have a
valid UTF-8 string, I'm afraid that in this case the string might be encoded in
GB18030.

I believe this should work.

If after unescaping the URI the string resulting is already in the plaform
encoding it should bypass the "UTF-8"->"Platform encoding" conversion and return
the string.
Comment 1 Federico Mena Quintero 2004-07-08 23:12:41 UTC
I believe this is a duplicate of #140532.  Can you please test this with glib
2.4.3 or later?  If this is a different bug, please re-open it.

*** This bug has been marked as a duplicate of 140532 ***