There is the API having the problem: NLS_translateThese are the parameters:
NLS_translate(PARAM1, 19, PARAM2, LENGTH_RET, NLS_NULLTERMINATE|NLS_TARGETISLMBCS, PARAM3);
PARAM1: This is the input name… in hexadecimal these are the values:
48 44 44 94 83 8E E6 82 E8 8C A9 90 CF 8F 91 2E 7A 69 70 00
As you see PARAM1 is composed of 20 characters (the last one is the NULL terminating string). The
ANSI representation is this: HDD”ƒŽæ‚茩.Ï.‘.zip
19 in the second parameter is OK since PARAM1 contains 19 good characters.
PARAM2 is just an empty string since it will receive the resulting translated string.
LENGTH_RET is 132 that is enough to receive the returned string.
PARAM3 is a NLS_PINFO. I use this to obtain the NLS_PINFO:
NLS_load_charset(NLS_CS_NECESJIS,&PARAM3)
After calling NLS_translate LENGTH_RET is 23 and PARAM2 is this:
48 44 44 3F 3F 0F 8E 3F 3F 3F 3F 10 10 A9 3F 10 10 CF 0F 8F 3F 2E 7A
That in ANSI it is:
HDD??.Ž???..©?..Ï… ?.z
So as you can see the returned string is .z while it should be .zip.
Interestingly if instead of passing 19 I pass 21 then I well obtain .zip instead of .z.
Here there is a clear bug in the NLS_translate and there is no easy workaround.