[jcifs] problem encoding

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> 
> In all that, however, I don't know if my point came across...
> 
> If both client and server support Unicode (in particular, UCS-2LE) then
> the character encodings match and there is no problem.
> 
> If they don't--if, in particular, there are DOS codepages involved--then
> there is nothing in the protocol that allows negotiation of the correct
> codepage and, therefore, no way to match the extended characters between
> client and server.
> 
	True. That's has nothing to do with Andrea's problem but it's true. There is
	no codepage negotiation in CIFS. In fact the docs don't say anything about
	codepages. Codepages are a hack. Unicode was the solution.

> That is only related to the escaping issue in that--if Unicode is not
> used--an escape sequence may not match the intended character.
> 
	No. The user would enter and be given Unicode. *Always*. At least with jCIFS
	they will. If a user's terminal is Cp437 the JVM file.encoding property will be
	Cp437 and when the String is read in it will automatically be converted to
	Unicode. Then even if jCIFS does not negotiate Unicode and the
	jcifs.encoding=ISO8859_1 it will still work if the server is ISO-8859-1 (which it
	is on a domestic Windows install).

> This is a protocol bug, however, and not a problem to be solved in the SMB
> URL.
> 
	The bug was solved with Unicode but we still have to support "ASCII" clients
	occationally and you're right in that it has 0 to do with the SMB URL.

	Mike