If I enter the value BancoImagens/öe ña.jpg into the IMAGEM field of the IMAGENS table, the Imagens form opens normally. Ctrl-clicking on the image invokes the default file extension handler.
Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 6; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL threaded
Indeed: the workaround 
Inserting manually via another form avoids the automatic % encoding.
By the way, if the file name contains the / character (as in our case), then this character is also present in the stUrl variable value (along with the leading \ in MS Windows). As we can see, Windows handles this situation.
In your example, in the form Imagens, after executing the operator
stUrl = Join(arUrl, GetPathSeparator())
the value of the variable stUrl is C:\Temp\BancoImagens/öe ña.jpg (my .odb file is in C:\temp folder).
Note the presence of both the \ and / separators. Windows handles this situation correctly.
ConvertToURL does not handle all characters allowed in URLs.
ConvertToURL_Bug.ods (42.1 KB)
There should be a bug report of mine, but I can’t find it.
Ah! Yes, I’ve noticed early on.
Problem was the % encoding when inserting the images in standard way.
But the problem isn’t the percentage sign because the image filename can contain spaces between its parts, which are represented by [%20]. For example:
Filename “216-Order Of The Phoenix.jpg”
Represented by: [216-Order%20Of%20The%20Phoenix.jpg]
And there’s no problem!
The real problem is with characters with accents, such as: á, à, ã, â, ä (in all vowels) and ç. In addition, of course, to the reserved characters of Windows, macOS and Linux: <, >, :, ", /, , |, ? and * that we were taught when we started learning how to use computers.
What’s your OS?
Because to me here on W-11 it doesn’t.
And if I manually replace the “/” for “\” in the table record, image doesn’t shows up in Image Control.
Version: 26.2.1.2 (X86_64)
Build ID: 620(Build:2)
CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: pt-BR (pt_BR); UI: pt-BR
Sanitize your path-names. Even if Windows supports the slash, LibreOffice converts between system notation and URL notation, where the slash is not allowed.
@
But issue here are accents (Diakritika?) + blanks.
But slashes arise for the images subfolder.
Not because one puts them in the file names.
There seems to be no doubt about that. However, the CRDF macro problem is also a LibreOffice problem because, when you load an image into an “image control” box on a form, LO assigns it a URL in UTF-8 characters when it should use the computer’s character set, in my case Windows-1252. Therefore, the macro does not open the image. So, either the macro decodes the characters that make up the image URL that are in UTF-8 and converts them to characters from the character set installed by default on the computer, or LibreOffice should do that when it establishes the image URL in the form’s table. For example: Images/Jos%C3%A9.jpg (UTF-8) for Images/José.jpg (Windows-1252).
Or, in other words: if the file name is José.jpg, why on earth does LO register it in the table as Jos%C3%A9.jpg?
Meanwhile, I am already manually correcting the file names that have accented letters, umlauts, and cedillas.
