-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot display some local files with a space in their name #371
Comments
For verification purposes I changed the code that renames duplicate files to produce "file_(n)" instead of "file (n)". Images are now loaded correctly. |
I think %20 is not translated automatically to the space char by the file system, it's an url encoded char. |
As you can see above, I convert the file's path to an Uri and pass that to the image loader, as required. However, the image loader then fails to load the file, i.e. this is a bug in Universal Image Loader, not my code. The image loader does not seem to convert %20 to " " when decoding the URI to access the local file, which leads to the file not being found since the file's name on disk is "ad (1).jpg" and not "ad%20(2).jpg". When I changed the file's name to "ad_(1).jpg" the image loader successfully loaded the file. |
I am also facing the same issue, kindly suggest the possible solution. |
Hey, USE: setUrl(Uri.decode(fileUri)); Cheers! |
@Dcodechef How are you using setUri? (on what?) |
Use decoded uri where ever you are passing in image loader for local files. |
I can confirm that this solution works. My code now looks as follows:
I'll mark the issue as closed since this solution is really simple to use. Thanks a lot @Dcodechef. |
The Uri.decode() is only really needed for local files with a blank in "/storage/emulated/0/storage/emulated/0" There seems to be an issue with the code that creates your path. For On 17.03.2015 03:29, zoumy wrote:
|
I have same problem when path contains chinese. |
I'm loading images from the local storage using the following code:
This fails with the following exception:
// path manually truncated, due to length
It looks like the file name extracted from the URL does not decode the %20 to " ".
The text was updated successfully, but these errors were encountered: