summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/unicode.sgml
blob: 2f794aadc2506f94ad0a63b2baf4b531c60022ca (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
<chapter id="unicode">
<chapterinfo>
	&author.jelmer;
	<pubdate>25 March 2003</pubdate>
</chapterinfo>

<title>Unicode/Charsets</title>

<sect1>
<title>What are charsets and unicode?</title>

<para>
Computers communicate in numbers. In texts, each number will be 
translated to a corresponding letter. The meaning that will be assigned 
to a certain number depends on the <emphasis>character set(charset)
</emphasis> that is used. 
A charset can be seen as a table that is used to translate numbers to 
letters. Not all computers use the same charset (there are charsets 
with German umlauts, Japanese characters, etc). Usually a charset contains 
256 characters, which means that storing a character with it takes 
exactly one byte. </para>

<para>
There are also charsets that support even more characters, 
but those need twice(or even more) as much storage space. These 
charsets can contain <command>256 * 256 = 65536</command> characters, which
is more then all possible characters one could think of. They are called 
multibyte charsets (because they use more then one byte to 
store one character). 
</para>

<para>
A standardised multibyte charset is unicode, info available at 
<ulink url="http://www.unicode.org/">www.unicode.org</ulink>. 
Big advantage of using a multibyte charset is that you only need one; no 
need to make sure two computers use the same charset when they are 
communicating.
</para>

<para>Old windows clients used to use single-byte charsets, named 
'codepages' by microsoft. However, there is no support for 
negotiating the charset to be used in the smb protocol. Thus, you 
have to make sure you are using the same charset when talking to an old client.
Newer clients (Windows NT, 2K, XP) talk unicode over the wire.
</para>
</sect1>

<sect1>
<title>Samba and charsets</title>

<para>
As of samba 3.0, samba can (and will) talk unicode over the wire. Internally, 
samba knows of three kinds of character sets: 
</para>

<variablelist>
	<varlistentry>
		<term>unix charset</term>
		<listitem><para>
		This is the charset used internally by your operating system. 
		The default is <constant>ASCII</constant>, which is fine for most 
		systems.
		</para></listitem>
	</varlistentry>

	<varlistentry>
		<term>display charset</term>
		<listitem><para>This is the charset samba will use to print messages
		on your screen. It should generally be the same as the <command>unix charset</command>.
		</para></listitem>
	</varlistentry>

	<varlistentry>
		<term>dos charset</term>
		<listitem><para>This is the charset samba uses when communicating with 
		DOS and Windows 9x clients. It will talk unicode to all newer clients.
		The default depends on the charsets you have installed on your system.
		Run <command>testparm -v | grep "dos charset"</command> to see 
		what the default is on your system. 
		</para></listitem>
	</varlistentry>
</variablelist>

</sect1>

<sect1>
<title>Conversion from old names</title>

<para>Because previous samba versions did not do any charset conversion, 
characters in filenames are usually not correct in the unix charset but only 
for the local charset used by the DOS/Windows clients.</para>

<para>The following script from Steve Langasek converts all 
filenames from CP850 to the iso8859-15 charset.</para>

<para>
<prompt>#</prompt><userinput>find <replaceable>/path/to/share</replaceable> -type f -exec bash -c 'CP="{}"; ISO=`echo -n "$CP" | iconv -f cp850 \
  -t iso8859-15`; if [ "$CP" != "$ISO" ]; then mv "$CP" "$ISO"; fi' \;
</userinput>
</para>
</sect1>
</chapter>