iconv() and path separator

[guest]

Hi/2.

Current iconv() implementation does not recognize path separator. At least in Korea, '\' is used as currency, WON sign, as well. So if iconv() does not treat it as path separator, path icluding '\' is not recognized correctly. This is the cause of SAMBA client not working with path including DBCS chars and '\'.

So I think it is better that you let us make a choice for using '\' as path separator or others.

Of course, this proposal goes for CVTTYPE_CTRL7F.

That is, at first, you'd not better set attribute of uconv object, and later if requested, set attribute. Or you can use init string as UconvCreateObject() does.

Anyway give us a choice right.

KO Myung-Hun

[bird]

I don't quite get this defect. In which way does iconv() need to care about path separators? A testcase explaining what's wrong and how it really should would be probably clarify things quite a bit (though I'm not sure if I can find any Korean OS/2 to test it on, if that's necessary). As always, even better if a patch with a fix is also attached.

[KO Myung-Hun]

For examples, if trying to convert A\B\C to unicode, the result is [41][5C][42][5C][43] in unicode with path mode, but [41][20a9][42][20a9][43] with non-path mode. [20a9] is a WON sign in unicode.

So, if you create a directory structure using the unicode string, you can get the directory whose name is A[WON]B[WON]C not a A - B - C directory tree.

And GNU iconv() treats both \ and 0x7F as an ASCII. That is, it converts them to [5C] and [7F] in unicode, respectively.

So clearing CVTTYPE_CTRL7F flag only is the way compatible with GNU iconv().

[KO Myung-Hun]

A patch to clear CVTTYPE_CTRL7F flag only

[bird]

Changed iconv to not clear CVTTYPE_PATH in r3754. Backported to 0.6 in r3755. Case closed.

[KO Myung-Hun]

Comment is wrong.

WON is assigned to an ASCII code of a backward slash('\') not a forward slash('/').

[bird]

Fixed comment.