System.perspective.navigate() fails when filename contains certain characters

For our 8.1.14 Perspective app, we’re trying to show files from the filesystem in a new browser tab using:

system.perspective.navigate(url = fullHTTPPathToFile, newTab = True)

This works fine for most files (e.g. 200.txt and 200 Space.txt), but have found some patterns that fail:

  • 404(.txt fails with a 404 File Not Found, we assume because of the paren.

  • 500 (.txt fails with a 500 Server Error java.nio.file.InvalidPathException, we assume because of the space followed by the paren.

We’ve tried leaving the filename portion of fullHTTPPathToFile unencoded, as well as encoding it with urllib.quote(), urllib.quote_plus(), and even Java URLEncoder.encode() , but they all fail the same way.

Is this a bug, or should we being doing something differently?

I haven’t tried Perspective, but probably all special characters should be escaped.

Space = %20

Thanks, but that’s what I meant when I said "encoding it with urllib.quote() , urllib.quote_plus() , and even Java URLEncoder.encode()".

Here are log statements showing the encoding from the different calls:



Why have such wierd names?
Arent there easier ways to get text out of the file and into display? xd
Also those files would be on the local computer not the ones on the gateway?

What are trying to show and how are you making these files?

I’m thinking those names are just there to show the issue, they’re not using files with those exact names.

1 Like

That is correct. I tried to create the simplest possible tests that failed.

Ah makes sense xD

But i dont think there is anything ignition can do about that if the browser doesnt recognize the name

I’m going to guess that you are using jython’s stdlib to browse the filesystem and urlencode the names. This is unreliable with any special characters, due to jython’s python2 legacy. Use java classes ( to enumerate files and folders, and use to transform the names.

Thanks to everyone for trying to help. A couple of follow-on comments.

First, these files open fine in Chrome directly from the filesystem, so I don’t think it’s a problem with the filename itself e.g.


Second, we did try URLEncoder. Here’s the code:

from import URLEncoder

fullPath = GetBaseURL() + URLEncoder.encode(fileName)
system.perspective.navigate(url = fullPath, newTab = True)

And the results:


space should be %20 though

also https:// is wrong
if you want to open a file you gotta do file:///

idk if its usefull but i made a tiny bat script that installs a regestry for the browsers (works on chrome on windows atleast, but doesnt work in the app)
Which allows you to “surf” to the fileexplorer or open the file directly in the default app (often used with excel here to a path on a shared folder)
The problem is every client’s pc needs to install the regestry, but only a selected few people use this feature from us xd

copy this in a bat file, and run it as admin:

REG ADD HKCR\explorer /v "URL Protocol"
REG ADD HKCR\explorer\shell\open\command /d "cmd /c set url=\\\"%%1\\\" & call set url=%%%%url:explorer:=%%%% & call start explorer file:%%%%url%%%%"

then you can surf to explorer:yourpath It still needs a correct path name though so your encoding will have to be right xd

I appreciate the suggestion, but it seems like I’m not explaining this clearly enough.

Our navigate() call is made in the onClick() handler of a button we call “View” in the web browser running our Ignition app. We present the user a list of Gateway files in a list box, they select one, and when they press “View”, it’s supposed to open the file in a new tab in the browser (though some filetypes actually download instead).

Whey I try to view “200.txt” or “200 Space.txt”, they open just fine in a new tab. But the same button press on “404(.txt” generates a 404 error, and “500 (.txt” generates a 500 error. No technique for escaping, encoding, etc. is successful for the last two files.

I’m not sure if your “file:///” comment is because I didn’t explain it well enough, though, or it’s actually the solution, so I’ll try it now. But “https://” works just fine for the two files that don’t have “(” in their name.