GetAsUrlEncoded("!") still broken in 19

Apparently first reported in FMP 17 (or earlier), GetAsUrlEncoded("!") still returns, in FMP 19: !

@FileKraft noted this on the regular FMI forum and I'm just echoing his posting here, but that forum is still so terrible, I can't find any messages I want.

SHOULD BE: (Java Result Shown Below)

image

Wow. But MBS( "Text.EncodeURLComponent"; "!" ) does it right.

1 Like

Strange, looks as if ! has a special meaning. I wonder how it's implemented inside. In my case it fails on Windows. If i fails also on MacOS then ?!?!

Oh maybe they call a micro-service :rofl:.

1 Like

Hahaha. :sunglasses:

I would be surprised if MBS didn't give the correct answer.

No surprise there. :heavy_check_mark: :slight_smile:

This bug seems so simple to fix, in pseudo code at the end:

If GetAsUrlEncoded ( Argument ) contains "!"

replace "!" by "%21"

:grinning:.

Ok,

I thought about that and made another test in FMP 19:

image

The only part of the string that was encoded is " ". Then I had a look at the Help:

This function removes all styles from text . All characters are first converted to UTF-8 format. Characters that are neither letters nor digits, or digits that are in the upper ASCII range, are converted to %HH format (a percent sign followed by the character’s hexadecimal value).

Then I went to HTML URL Encoding Reference

and submitted the.fmsoup Discourse! and clicked on the [URL Encode button]. Which string did I get ? Answer is the.fmsoup%20Discourse! I used the test under URL Encoding Functions.

On https://www.urlencoder.org/ I got what fmpdude showed.

Then who's wrong: FileMaker or the tool used by @fmpdude ?

Looks like there are more than one function used to encode and than they work differently. I am not enough knowledgeable about this, so I can't state on this, I leave it to the experts !

1 Like

This is one particular annoyance, that over time you make a Custom Function, and use that instead of the default function. Sometimes with URL encoding, it's beneficial to handle some other extra stuff, and it's easier to do it all in one function. This really comes down to preference, with how you handle it. Annoying, but only annoying once. Other than a few characters the function doesn't handle, I can't even think of an actual other example of what you might do. I'll have to find where I use it and see what I've run into in the past.

FIleMaker is wrong.

It appears to be another case where FMI is not using a standard library to do what other languages do correctly.

MBS gets it right also.

--

Try the same thing in Python at the command line (we all have Python installed I believe):

image

As long as you mean FMI fixing their bug and not us working around it... :crazy_face:

Ironically, any silliness aside, often times you need to URLEncode before you call a micro-service. Thus, this is one case where the internal function needs to be correct.

It's not a big issue.
You can put it in a CF and do a substitute yourself to fix it.

1 Like

Honestly, I was mainly just repeating what @FileKraft reported.

In any case, I don't work around FMI bugs like that, but thanks. That's a FMP-only CF you'd need to add to any possible FMP app that would use GetAsUrlEncoded().

A slightly better multi-year FMP bug workaround might be to use base64Encode and then decode the "!" on the service side.

FileMaker:
image

--
Then, in Java, python, or whatever modern language you choose...

Python:


IMHO, a better workaround would be for FMI to issue a point release after a multi-year bug, once discovered, the next day.


Maybe FMI is using a JavaScript library (eek!) that doesn't encode the "!"?

image

Output: "!"

Who is THE authority on how encoding should work ? I am curious about their definition.

1 Like

That's an interesting question. I tried to find that answer but really could only find related RFCs or how a particular language, like Java, does it. I guess W3C would be the definitive source.

Example: Java URL Encoding:
All the alphanumeric characters and certain special characters being used in the utility class such as ‘*’ ,’ _’,’ –‘ and ‘.’ remains unchanged and unnotified.

All extra spaces need to get converted into ‘+’ signs.

All the remaining characters within the string or other characters get encoded by individual parsing the encoded string one by one or it can be more than one byte for encoding any string as per scheme specified. Then further these bytes of string get converted into a three-character string with some string format of the form possessing the %xy, where xy represents the encoding string of characters with hexadecimal format.

UTF format is mostly a recommended standard sanctioned by W3C for any kind of encoding strategies related to the string.


>>>> What does xojo get? <<<<

I expected the question :wink:.

image
--- Result in Xojo ---

The name of the function is EncodeURLComponent, the name of the method in the MBS FileMaker.plugin.

Right. I already found the xojo documentation but I didn’t know how it handled the “!” The xojo document page I found was very sparse with function details—as in, which characters are encoded.

Thanks.

EDIT: whoops, looks like @fmpdude already mentioned this.
I get this in the Chrome console (and Safari and FireFox).
Screen Shot 2020-06-27 at 3.44.12 PM

2 Likes

The plot thickens ! According to Percent-encoding - Wikipedia , ! is part of the reserved characters, following RFC 3986, see RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax .

Some talks about URI, and others about URL. Could that make a difference ?