dos charset and
should be set to the locale compatible with the character set
and encoding method used on Windows. This is usually CP932
but sometimes has a different name.
unix charset can be either Shift_JIS series,
EUC-JP series, or UTF-8. UTF-8 is always available, but the availability of other locales
and the name itself depends on the system.
Additionally, you can consider using the Shift_JIS series as the
value of the
parameter by using the vfs_cap module, which does the same thing as
setting “coding system = CAP” in the Samba 2.2 series.
Where to set
to is a difficult question. Here is a list of details, advantages, and
disadvantages of using a certain value.
Shift_JIS series means a locale that is equivalent to
used as a standard on Japanese Windows. In the case of
for example, if a Japanese filename consists of 0x8ba4 and 0x974c
(a 4-bytes Japanese character string meaning “share”) and “.txt”
is written from Windows on Samba, the filename on UNIX becomes
0x8ba4, 0x974c, “.txt” (an 8-byte BINARY string), same as Windows.
Since Shift_JIS series is usually used on some commercial-based
UNIXes; hp-ux and AIX as the Japanese locale (however, it is also possible
to use the EUC-JP locale series). To use Shift_JIS series on these platforms,
Japanese filenames created from Windows can be referred to also on
If your UNIX is already working with Shift_JIS and there is a user
who needs to use Japanese filenames written from Windows, the
Shift_JIS series is the best choice. However, broken filenames
may be displayed, and some commands that cannot handle non-ASCII
filenames may be aborted during parsing filenames. Especially, there
may be “\ (0x5c)” in filenames, which need to be handled carefully.
It is best to not touch filenames written from Windows on UNIX.
Note that most Japanized free software actually works with EUC-JP
only. It is good practice to verify that the Japanized free software can work
EUC-JP series means a locale that is equivalent to the industry
standard called EUC-JP, widely used in Japanese UNIX (although EUC
contains specifications for languages other than Japanese, such as
EUC-KR). In the case of EUC-JP series, for example, if a Japanese
filename consists of 0x8ba4 and 0x974c and “.txt” is written from
Windows on Samba, the filename on UNIX becomes 0xb6a6, 0xcdad,
“.txt” (an 8-byte BINARY string).
Since EUC-JP is usually used on open source UNIX, Linux, and FreeBSD, and on commercial-based UNIX, Solaris,
IRIX, and Tru64 UNIX as Japanese locale (however, it is also possible on Solaris to use Shift_JIS and UTF-8,
and on Tru64 UNIX it is possible to use Shift_JIS). To use EUC-JP series, most Japanese filenames created from
Windows can be referred to also on UNIX. Also, most Japanized free software works mainly with EUC-JP only.
It is recommended to choose EUC-JP series when using Japanese filenames on UNIX.
Although there is no character that needs to be carefully treated
like “\ (0x5c)”, broken filenames may be displayed and some
commands that cannot handle non-ASCII filenames may be aborted
during parsing filenames.
Moreover, if you built Samba using differently installed libiconv,
the eucJP-ms locale included in libiconv and EUC-JP series locale
included in the operating system may not be compatible. In this case, you may need to
avoid using incompatible characters for filenames.
UTF-8 means a locale equivalent to UTF-8, the international standard defined by the Unicode consortium. In
is expressed using 1 to 3 bytes. In case of the Japanese language,
most characters are expressed using 3 bytes. Since on Windows Shift_JIS, where a character is expressed with 1
or 2 bytes is used to express Japanese, basically a byte length of a UTF-8 string the length of the UTF-8
string is 1.5 times that of the original Shift_JIS string. In the case of UTF-8, for example, if a Japanese
filename consists of 0x8ba4 and 0x974c, and “.txt” is written from Windows on Samba, the filename
on UNIX becomes 0xe585, 0xb1e6, 0x9c89, “.txt” (a 10-byte BINARY string).
For systems where iconv() is not available or where iconv()'s locales
are not compatible with Windows, UTF-8 is the only locale available.
There are no systems that use UTF-8 as the default locale for Japanese.
Some broken filenames may be displayed, and some commands that
cannot handle non-ASCII filenames may be aborted during parsing
filenames. Especially, there may be “\ (0x5c)” in filenames, which
must be handled carefully, so you had better not touch filenames
written from Windows on UNIX.
In addition, although it is not directly concerned with Samba, since
there is a delicate difference between the iconv() function, which is
generally used on UNIX, and the functions used on other platforms,
such as Windows and Java, so far is concerens the conversion between
Shift_JIS and Unicode UTF-8 must be done with care and recognition
of the limitations involved in the process.
Although Mac OS X uses UTF-8 as its encoding method for filenames,
it uses an extended UTF-8 specification that Samba cannot handle, so
UTF-8 locale is not available for Mac OS X.
Shift_JIS series + vfs_cap (CAP encoding)
CAP encoding means a specification used in CAP and NetAtalk, file
server software for Macintosh. In the case of CAP encoding, for
example, if a Japanese filename consists of 0x8ba4 and 0x974c, and
“.txt” is written from Windows on Samba, the filename on UNIX
becomes “:8b:a4:97L.txt” (a 14 bytes ASCII string).
For CAP encoding, a byte that cannot be expressed as an ASCII
character (0x80 or above) is encoded in an “:xx” form. You need to take
care of containing a “\(0x5c)” in a filename, but filenames are not
broken in a system that cannot handle non-ASCII filenames.
The greatest merit of CAP encoding is the compatibility of encoding
filenames with CAP or NetAtalk. These are respectively the Columbia Appletalk
Protocol, and the NetAtalk Open Source software project.
Since these software applications write a file name on UNIX with CAP encoding, if a
directory is shared with both Samba and NetAtalk, you need to use
CAP encoding to avoid non-ASCII filenames from being broken.
However, recently, NetAtalk has been
patched on some systems to write filenames with EUC-JP (e.g., Japanese original Vine Linux).
In this case, you need to choose EUC-JP series instead of CAP encoding.
vfs_cap itself is available for non-Shift_JIS series locales for
systems that cannot handle non-ASCII characters or systems that
share files with NetAtalk.
To use CAP encoding on Samba-3, you should use the unix charset parameter and VFS
the VFS CAP smb.conf file.
|# the locale name "CP932" may be different
dos charset = CP932
unix charset = CP932
vfs option = cap
You should set CP932 if using GNU libiconv for unix charset. With this setting,
filenames in the “cap-share” share are written with CAP encoding.