Jump to content
Server Maintenance This Week. ×

URL Encode problem


This topic is 3152 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I am using the web viewer to listen to .wav files. This works great 90% of the time. My inconsistency problem comes from URL encoding I believe.

Actual file name:

-CCSKD#W01568613.WAV

I can navigate to this working url in safari:

http://1.1.1.1/folder/-CCSKD%23W01568613.WAV

This is the url I am setting the web viewer to:

http://1.1.1.1/folder/-CCSKD%23W01568613.WAV

This is what

GetLayoutObjectAttribute ( "player" ; "source" ) shows:

http://1.1.1.1/folder/-CCSKD%2523W01568613.WAV

I know that a pound sign (#) is encoded only if a number character (0 through 9) follows it.

This is the calc used to set the web viewer. Part of it takes care of when there is a letter following the pound sign.




Let

(

[

$address = "http://1.1.1.1/folder/" ;

$text = $$file ;

$position = Position ( $text; "#" ; 1; 1 ) ;

$character = Middle ( $text ; $position +1 ; 1 ) ;

$integer_filter = Filter ( $character; "0123456789" ) ;

$integer_present = not IsEmpty ( $integer_filter )

];



$address & 



Case

(

$integer_present = 1 ; $text ;

Substitute ( $text ; "#" ; "%23" )

)

)



The problem is that the web viewer converts D%23W to D%2523W

Can someone point me in the right direction?

Thanks,

Drew

Edited by Guest
Link to comment
Share on other sites

You know, that is a very good question. I poked around, and found a Filemaker help file on web viewers. (Here) It says that the pound sign is always encoded if it's followed by numbers. So my thought is, leave the pound sign alone, and the web viewer will work for you? (Maybe?)

Link to comment
Share on other sites

Let me make sure I understand:

If the file name includes a pound sign (#), the Case evaluates and encodes the # into a url accepted hex?

Now, when a file name DOES include a #, is it always followed by a number? If so, you don't need the Case statement, because the web viewer object automatically checks urls to see if they are encoded properly. When you do the encoding, you're introducing a percent sign (%) which the web viewer object then encodes when it evaluates the url. At least that is how I'm interpreting the help file I referenced above.

I haven't tried a sample file of what you're talking about, but from my limited experience the FM help files are not wrong.

Do you have a sample file or an example you can post?

Link to comment
Share on other sites

Okay, I took your sample file and tweaked it. I'm running on Windows and don't know how to do the cool local host thing that Apples have. (I normally use Apples, but as usual, work uses windows.) So, the URL that I specified is just a file location. Hopefully there aren't any problems with me doing that. In my file, I don't use any fancy calculations to check for hashes. In fact, if you look at my file path, some of the folders have spaces in their name, and the web viewer handles those as well.

File is attached. (Hopefully you can unzip it, as it's zipped in Windows, which tends to do weird things.)

hash_encode.zip

Link to comment
Share on other sites

Okay, I was able to recreate your problem. (I first had to figure out where Windows keeps it's web publishing files so I could add my test files.)

Anyway, as it turns out, when you call a file from the web viewer, it encodes everything that a URL wouldn't like, regardless of conditions. I was stumped by this, but I was blinded by my limited web development knowledge. (See here.)

So, all I can think of would be to change your file naming convention to not include hash symbols. I know it's a crappy answer, but, I'm stumped. If you absolutely must have hashes in your file names the web viewer will work correctly if the # is followed by a number.

I'm not ruling out the possibility of being able to accomplish this. It might be possible, however, the more I think about, the more I realize that it just doesn't seem worth the trouble.

Link to comment
Share on other sites

  • 6 years later...

I found this thread while Googling for encoding problems.  The solution is to upgrade FileMaker.  

 

Version 14 has an option to automatically encode the URL.  Turn that option off & it works.  Version 11 does not have it.  Apparently FM was listening & fixed it somewhere around versions 12-14.

 

Thanks to the Developers at FM for giving us control on this issue.

Link to comment
Share on other sites

The option was added in version 12:

http://help.filemaker.com/app/answers/detail/a_id/10084/~/miscellaneous-behavior-changes-in-filemaker-pro-12

A 4-year-old solution to a 6-year-old thread. But there are no doubt many people still running older versions of FileMaker, so maybe this will help someone.

Link to comment
Share on other sites

This topic is 3152 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.