if "server string" of a Samba or Win* server contains multibyte characters, smbclient -L shows this incorrect. If "server string" of the server is for just an string containing am umlaut like "schön" smbclient shows it correct. When it contains Japanes characters it shows it not correct. An smbclient -L servername which should show "ありがとう" (thank you in Japanese) as server string, shows something like this in UTF-8 locale: IPC$ IPC IPC Service (ÒüéÒéèÒüîÒü¿Òüå) I hope this bugzilla a configured so that it cares about charsets ...
What have you configured your character set parameters as in your smb.conf ? You do know these need to be set correctly ? Jeremy.
yes, of course, if the default, utf8. The smb.conf is also utf-8 encoded and clients like w2k and xp also show the Japanese server string correctly. Just smbclient does not, as shown above.
Ok, I cannot reproduce this. I have the following set in my smb.conf unix charset = utf8 dos charset = cp932 server string = 院陰 Doing bin/smbclient -L //localhost I see : ..... IPC$ IPC IPC Service (院陰) ADMIN$ IPC IPC Service (院陰) Anonymous login successful Server Comment --------- ------- J2 院陰 This looks correct to me. Please tell me what the problem you see is. Remember, you must tell the smbd what dos client codepage you are using - not just the unix codepage of utf8. Jeremy.
I'm sorry, I guess you tried the wrong things because this bugzilla is configured in a way that it is just cappable of accepting ASCII correcly. I have put the main information on http://j3e.de/sambabug859.html The dos charset should not matter at all in this case, just the unix charset which is utf8. Win XP and and 2000 clients show the information of server string correct. (Okay, XP also has a bug which causes the Japanese string to be shown incorrect at one place)
okay, additionally to what I wrote there I just found out that "dos charset" *does* matter here though it should be irrelevant at this point in my opinion. "dos charset" is used for smbclient for output encoding. smbclient should use the locale's charset for output encoding. If I set "dos charset" to "utf8" the output of smbclient is correct! smbclient should get it's charset by doing nl_langinfo(CODESET), shouldn't it?
> smbclient should get it's charset by doing nl_langinfo(CODESET), shouldn't it? No. smbclient gets it's charset from the "dos charset" parameter. This *does* matter for displaying a server string as it is retrieved using the RAP calls that use DOS charsets. I don't think this is a bug. Closing. Jeremy.
hm, but smbclient is not a dos client but a unicode talking client isn't it? and there are strange effects: 1. starting the server with "dos charset = utf8" - smbclient with "dos charset = utf8" -> correct Jap. server string - smbclient with "dos charset = cp932" -> correct Jap. server string - smbclient without server string explictly set -> broken Jap server string 2. starting the server with "dos charset = cp932" - smbclient with "dos charset = utf8" -> correct server string - smbclient with "dos charset = cp932" -> correct server string - smbclient without server string explictly set -> broken Jap server string The "dos charset" seems to trigger something but it does not do what one would expect it to do at this point.
> but smbclient is not a dos client but a unicode talking client isn't it? Not for server string. It's a RAP (DOS Codepage) client. smbclient is behaving as designed. You *must* set the correct DOS codepage. I'm closing this (again). Please don't re-open it just because you don't want to set the dos codepage. Jeremy.
I did not reopen because I did not believe you or because I didn't want to set "dos charset". As I wrote, I can set "dos charset" to utf8 or to cp932 and in *both* cases I get a correct result, though one of the settings must be the wrong one.
jeremy says no bug here.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.