We would like to hash certain data in our recipients table, but do notice that the returned hash isn't the right one when we use the SHA256 or SHA512 expression. For MD5 the returned result is however the right one.
We've checked the conversion in numerous ways (cf. https://dencode.com/hash --> UTF8, UTF16, ... CRLF, LF, ...) and investigated a lot of deviations (capitals vs regular letter, spaces, ...) already.
Example string: 1ZZ1234
|SHA256 generated by Adobe Campaign||5c12c786e84b2b7f8bf4b89e5c88ded8bf6a4fd05908b63050945f9fa5b6322d|
|MD5 generated by Adobe Campaign||29e110be8987fd8403f2940a617e668d|
|SHA512 generated by Adobe Campaign||e14c06f1c43bb65ee8487f54528a8278bbdd96582b9f23a93901fef04e3f6ed664a85308f56c5360413791bd384c14e2b0adb81b988c6c0fb05cf06530278919|
We are using the following functions:
Does anyone experienced the same or know what might be at the roots of the wrong hash generation by Adobe Campaign?
If you are a campaign user, do you get the same wrong hash?
Solved! Go to Solution.
I also found the issue.
After my test, I found that normally when we use SHA256 hash on online website or elsewhere.
That function will perform on varchar datatype.
But in Adobe Campaign because of Adobe mapping datatype String as nvarchar (in unicode case).
Then when we generate with SHA256 function it will has data based on nvarchar --> not varchar.
In this case, it return incorrect value.
In my case, I try to modify the datatype on SQL create table page while using update database structure.
Modify the target field from 'nvarchar' to 'varchar' -> And 'YESSSSS!!!' -> I can use SHA256 function as normally.
Warning: However, varchar may not support some language.