Bug #76936
closed
[Fluid] publicUrl encoding
Added by E. G. over 8 years ago.
Updated about 8 years ago.
Description
The getter publicUrl (FileReference) will return an invalid value with encoded special characters like "%C3%B6", "%C3%9F", "%C3%A9" or "%C3%80" instead of their decoded state ("ö", "ß", "é" or "À").
- Status changed from New to Needs Feedback
Is this only when output in/with fluid? Or also when directly outputted in the controller for instance?
For instance has the download button on the file info window in the BE the same issue?
I can confirm the problem and I think it's either a bug or a misconception - or both.
Just put a file in fileadmin with name 'example-öäü.jpg' and you will see several problems. It doesn't work in BE and not in FE.
Please don't tell me not to use umlauts in filenames, we have 2016 and a software that doesn't work with umlauts in filenames is just buggy.
FileReference has a method publicUrl() which url encode the path. The problem is that all the code that just want to access the file (eg. for image processing) uses that method. Obviously that fails because there is no file example-%C3%B6%C3%A4%C3%BC.jpg in the filesystem.
Why is publicUrl() used everywhere? Because there's no method publicFilePath() - at least not when I had a look.
If you need the file path for processing etc use $file->getForLocalProcessing()
.
The publicUrl is intended to be used as url so thats why it's rawurlencoded.
René Fritz wrote:
Just put a file in fileadmin with name 'example-öäü.jpg' and you will see several problems. It doesn't work in BE and not in FE.
TYPO3 can handle these characters in filenames. But you need to be sure that [SYS][UTF8filesystem] = 1
is set in the install tool.
- Status changed from Needs Feedback to Closed
Closing this since Frans Saris has already given the completely correct answer. Public stream URL is intentionally already encoded. File for local processing (stream path) is not. And do consider the notes about UTF-8 file systems!
Also available in: Atom
PDF