Invers function of $encode("HEX",) is $decode("HEX",) ?
Author: i2stiller@gmx.de (istiller)
Correct me, if I'm wrong: $encode("HEX",) is the invers function of $decode("HEX",) and vs. This seems true for plain text, but what about UILs (UnifaceItemList)? Say, there is an UIL like this:"A=1·;B=X=3·!·;X=3·;C=4"
$decode("HEX",$encode("HEX","A=1·;B=X=3·!·;X=3·;C=4") --> "A=1{<B=X=3{6{<X=3{<C=4"
Oops, that looks like good old TRX-Syntax Okay, a $replace($replace(<value>,1,"{6","!",-1),1,"{<",";",-1) heals that bug(?) But I don't believe that this behavior is intended Ingo
6 Comments
Local Administrator
I think decode returns a raw value. You can convert this back to a Uniface string by using $encode("USTRING",value), for example: $encode("USTRING",$decode("HEX",$encode("HEX","A=1·;B=2·;C=3"))) Returns the original list, such as: A=1·;B=2·;C=3 Regards, Mark
Author: Mark Rennison (mark.rennison@tribalgroup.com)
Local Administrator
Mark is correct. $decode will "return decoded or decrypted data in the Uniface raw data type". For details see the Uniface Library: Uniface Reference > Proc: Functions > $decode Regards, Daniel
Author: diseli (daniel.iseli@uniface.com)
Local Administrator
Very strange behavior $encode("HEX",";") always has the result "1B" (0x1B) variables string v_STR raw v_RAW endvariables v_STR=";" v_RAW=$encode("RAW",v_STR) $encode("HEX",";") --> 0x1B $encode("HEX",v_STR) --> 0x1B $encode("HEX",v_RAW) --> 0x1B But the inverse function does not work as expected ... Is an UIL a string, a raw or whatever data type? Why does UnifAce convert an 0x1B to a TRX-string and not back to what is was before? If 0x1B i a valid character in a string (=UIL), $decode should consider this! Please make UnifAce more consistent pertaining to data types
Author: istiller (i2stiller@gmx.de)
Local Administrator
Not sure that I can follow you. When reading the doc then the behavior of $decode seems to be as expected and intended:
All other algorithms return encoded or encrypted data in the Uniface raw data type, which can handle the null byte (0x00) that the data may contain. If you need to get the data in the string data type, you can convert it from raw to string data type using $encode with the USTRING or HEX algorithms. And there's even an example that demonstrates how to encrypt and decrypt string data:
$decode returns raw data, so you can use $encode with the USTRING algorithm to convert it to a string data type using Uniface internal encoding, UTF-8.
Could we have implemented the function differently? Probably, but we've chosen this approach. Hope this helps. Regards, Daniel
Author: diseli (daniel.iseli@uniface.com)
Local Administrator
If vStrgData is a "string", a $decode($encode()) should result in the identical string value If vRawData is "raw" then $decode($encode()) should result in the identical raw value If $decode() always deliver a raw value, why does $encode() take a "string"-value? Either $decode("algo",$encode("algo",vStrgData)) and/or $encode("USTRING",$decode("algo",$encode("algo",$encode("URAW",vStrgData)))) should results in the same value of vStrgData for EVERY given "string" Both is not true with UnifAce :-( proof: just test this with vStrgData="A;B" btw: $encode("USTRING",$encode("URAW",vStrgData) does its Job! Ingo
Author: istiller (i2stiller@gmx.de)
Local Administrator
In case you see some room for improving the mentioned functions then it's probably better to put this on the wish list. As said, $encode and $decode currently work as expected and documented. Sorry that I can't be any more helpful here.
Daniel
Author: diseli (daniel.iseli@uniface.com)