7 Replies Latest reply on Jan 18, 2017 7:50 PM by user19752

    Passing special characters in fmp url param

    Extensitech

      Hoping someone either has a more elegant solution than I can come up with, or has already done the gruntwork for something inelegant that works...

       

      Within an fmp url, the script parameter I need to pass may include special characters (i.e. @, #, !, etc.). This appears to "break" my link.

       

      If I use GetAsURLEncode for the link, the link works, but the script I'm calling doesn't "decode" the parameter.

       

      The parameter I'm passing is user-entered and free text.

       

      At this point, I'm considering doing replaces for every special character I can think of in the url, then swapping them all back in the script. This feels like a rabbit hole, or at best a terrible hack, so I'm hoping someone has a better idea?

       

      Chris Cain

      Extensitech

        • 1. Re: Passing special characters in fmp url param
          siplus

          What about putting the input text in a global, passing Base64Encode (yourglobal) as parameter and decoding it to another global in the receiving script ?

           

          Screen Shot 2017-01-18 at 19.40.33.png

          2 of 2 people found this helpful
          • 2. Re: Passing special characters in fmp url param
            taylorsharpe

            I was going to refer Chris to a table for decoding all the special characters and I've actually made a table before to do such decoding.  However, I really like Siplus' Base 64 Encode/Decode suggestion.  That certainly is thinking outside of the box and great idea!  Pretty cool Siplus!

            • 3. Re: Passing special characters in fmp url param
              siplus

              Thank you Taylor.

               

              The first idea was to pass Code(yourText) and decode with CHAR(Get(ScriptParameter)).

               

              It works perfectly up to 80 chars in yourText, then it comes up with "?" .

              This is a limitation I was unaware of, so I learned something from this, too.

               

              Screen Shot 2017-01-18 at 20.41.53.png

               

               

              BTW, where comes this limit to Code() ?

               

              Nota bene: if I get the result of a 80-char aGlobal CODEd in bGlobal, copy and paste it in bGlobal, then I get the CHAR() of it in DataViewer, I get no error, I get

               

              ±“#Ç[]|{}≠¿´œ∑€®†Ω°¡øπ§‘åß∂ƒ@ªº∆¬¢æ¶§∞”‹⁄⁄[]^ÚÔÒ\][⁄’ÿ∏ØıÙÍÎÈË»˚˙ ◊ ™Ÿ™ ◊—÷»˚◊䔷嗰ප䶼⎌⑔ば「ピ㢀䪤䙐葬ᦤ踸䐀垀渌䓀㻤惠眀䄼呠奼圜Ꮘ鴐ᤀ䉨䢨ᕘ䌸㽈姘䜘䄼Ẹ噜慌斘斘⎔⑔Ⓒ∼啧勐刈⏰⑔⎌斐哌掤ᣜ周眤哄倔偸丠佌䤌ᴨ᳄ߐ݈ݵ뱈鋨뱈ݴ݈務悄䤌ᴨ݈ݵ

               

              so maybe somebody from Filemaker could illuminate us with the reason of the 80 char limit.... maybe this ?

               

              https://i.stack.imgur.com/XvPKy.jpg

               

              Cultural Impact

              • A legacy of the 80 column punched card format is that a display of 80 characters per row was a common choice in the design of character-based terminals. As of November 2011 some character interface defaults, such as the command prompt window's width in Microsoft Windows, remain set at 80 columns and some file formats, such as FITS, still use 80-character card images.

               

               

               

              Nice one: Back in the days of 80x24 terminals, one of the original authors of a popular un... | Hacker News

              • 4. Re: Passing special characters in fmp url param
                user19752

                Code() returns "number", so there is limit of 400 digits. Looks a bit foolish, since the return have 0 prefix...

                • 5. Re: Passing special characters in fmp url param
                  siplus

                  from Technical Specifications for FileMaker Pro 15 | FileMaker

                   

                   

                  • Number: Support values from 10^-400 up to 10^400 and the negative values of the same range. Index based on the first 400 significant digits. Up to 1 billion characters per field. The first 400 digits are indexed.

                   

                  (bold is mine)

                  • 6. Re: Passing special characters in fmp url param
                    user19752

                    It is good point. Number field can keep text value as the another long limit. But number value can't be so long.

                    And I don't like FMI doesn't provide "Specifications" that not so correct in detail, that 10^400 is not real limit.

                    This is data viewer but field also can save 405 digits of number value.

                    But index looks not use 400 digits.

                    I created records with decreasing digits but there keep only one index value. I tired then stopped at 1e+394 and enter 1, it appeard.

                    (looking 1e+... is come from default field formatting, all vaules are entered as 1000....0001 changing number of 0s)

                     

                    Returing to Code() function, I misrecalled about "prefix", it is not there.

                    The function returns really number value, so there is limit of 400 digits.

                     

                    I'm not sure it is better if this function returns text as "0004800049" (reversed order of current implementation). In such case, using HEX string should be considered.

                    • 7. Re: Passing special characters in fmp url param
                      user19752

                      I agree. Good idea, siplus.

                       

                      Using Base64 is a way MS suggest.

                      Registering an Application to a URI Scheme (Windows)

                      and there may be another limit on command line length on Windows.

                       

                      In addition,

                      FM function Base64Encode() contain CRLF in the result, it could be removed for shortening or making good URL. Base64Decode() function can work without CRLF.

                       

                      Appended "=" or "==" in the result (if Mod(LengthOfBytes(text);3)>0) make bad URL, so it should be replaced with something. Or remove it in URL and add it before decode if Mod(Length(encodedtext);4)>0)

                       

                      I noticed FM encode text as UTF-8 bytes, not UTF-16.