DECODE64 and ENCODE64 actually do not work properly with some binary data.
proc COMPARE_BASE64 {} {
set code {2lIU1ZNw5BYvKi79j4L/+GGmjAQK7uiBQG7elDdKZcE=}
set vgn_result [DECODE64 $code]; #VGN built-in function
set tcl_result [::base64::decode $code]; #TclLib tcl-only implementation
return [join [list \\
[BIN2HEX $vgn_result] \\
[BIN2HEX $tcl_result] \\
[string compare $vgn_result $tcl_result ] \\
] "\\r\\n"]
}
proc BIN2HEX { text } { binary scan $text H* result; return $result }
COMPARE_BASE64
--- result ----
da52145370e4162f2a2efd8f82fff861a68c040aeee881406e94374a65c1
da5214d59370e4162f2a2efd8f82fff861a68c040aeee881406ede94374a65c1
1
If you need to encode/decode base64 for use in non-vignette systems make sure you use tcllib's base64.
This was tested on Vignette's V6 but I am sure it's true for Storyserver 4.2 and V5 as well.
As far as I remember the problem is with the character set of Vignette. V's version of base64 will decode into ascii 8-bit strings while the native base64 implementation will decode into Latin-1 Unicode representation.
ReplyDeleteIt's not an encoding problem. It's probably a bug in the implementation of ENCODE64. It's using a very old C code (dated back to tcl 7.6).
ReplyDeleteYou are right the vignette version doesn't even get the right size:
ReplyDelete4 base64 encoded bytes = 3 decoded bytes
Is it wrong in both directions the same way ? I mean does ENCODE64 [DECODE64 {...}] give the same result as the input?
it's wrong both ways:
ReplyDeleteENCODE64 [DECODE64 $a] always gives $a
Both directions are wrong.ENCODE64 & DECODE64 are
ReplyDeletesame the result as input
I think you have to check one more time because this is totally wrong from both direction.
ReplyDelete