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 April 16, 200916 yr by Guest

I think the web viewer might be encoding the percent sign (%) as %25. I don't know much about url encoding, but this site tipped me off.

That is what I thought as well but if that is the case then how do I encode the pound sign?

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?)

The let function I wrote evaluates if it is followed by a number. It only encodes it if it is not.

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?

Here is a sample file.

hash_encode.fp7.zip

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

The problem is I need it to encode the hash if followed by a letter. Your example does not do that.

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.

No option on the file naming... it is created by a system I have no control of. Thanks for the great effort and progressing the conversation so that perhaps someone else might pick it up. Thank :o

Hmmm. Okay, once again, sorry. Best of luck!

:therethere:

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.

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.