]> git.saurik.com Git - wxWidgets.git/blame - docs/doxygen/overviews/mbconvclasses.h
document standard IDs only in one place, not two; bring the list up to date
[wxWidgets.git] / docs / doxygen / overviews / mbconvclasses.h
CommitLineData
15b6757b 1/////////////////////////////////////////////////////////////////////////////
9715cf42 2// Name: mbconvclasses.h
15b6757b
FM
3// Purpose: topic overview
4// Author: wxWidgets team
5// RCS-ID: $Id$
6// Licence: wxWindows license
7/////////////////////////////////////////////////////////////////////////////
8
880efa2a 9/**
36c9828f 10
880efa2a 11@page overview_mbconv wxMBConv Overview
36c9828f 12
9715cf42
BP
13Classes: wxMBConv, wxMBConvLibc, wxMBConvUTF7, wxMBConvUTF8, wxCSConv,
14 wxMBConvUTF16, wxMBConvUTF32
36c9828f 15
9715cf42
BP
16The wxMBConv classes in wxWidgets enable an Unicode-aware application to easily
17convert between Unicode and the variety of 8-bit encoding systems still in use.
36c9828f 18
9715cf42
BP
19@li @ref overview_mbconv_need
20@li @ref overview_mbconv_string
21@li @ref overview_mbconv_classes
22@li @ref overview_mbconv_objects
23@li @ref overview_mbconv_csconv
24@li @ref overview_mbconv_converting
25@li @ref overview_mbconv_buffers
36c9828f 26
36c9828f 27
9715cf42 28<hr>
36c9828f
FM
29
30
9715cf42
BP
31@section overview_mbconv_need Background: The Need for Conversion
32
33As programs are becoming more and more globalized, and users exchange documents
34across country boundaries as never before, applications increasingly need to
35take into account all the different character sets in use around the world. It
36is no longer enough to just depend on the default byte-sized character set that
37computers have traditionally used.
38
39A few years ago, a solution was proposed: the Unicode standard. Able to contain
40the complete set of characters in use in one unified global coding system, it
41would resolve the character set problems once and for all.
42
43But it hasn't happened yet, and the migration towards Unicode has created new
44challenges, resulting in "compatibility encodings" such as UTF-8. A large
45number of systems out there still depends on the old 8-bit encodings, hampered
46by the huge amounts of legacy code still widely deployed. Even sending Unicode
47data from one Unicode-aware system to another may need encoding to an 8-bit
48multibyte encoding (UTF-7 or UTF-8 is typically used for this purpose), to pass
49unhindered through any traditional transport channels.
50
51
52@section overview_mbconv_string Background: The wxString Class
53
54If you have compiled wxWidgets in Unicode mode, the wxChar type will become
55identical to wchar_t rather than char, and a wxString stores wxChars. Hence,
56all wxString manipulation in your application will then operate on Unicode
57strings, and almost as easily as working with ordinary char strings (you just
58need to remember to use the wxT() macro to encapsulate any string literals).
59
60But often, your environment doesn't want Unicode strings. You could be sending
61data over a network, or processing a text file for some other application. You
62need a way to quickly convert your easily-handled Unicode data to and from a
63traditional 8-bit encoding. And this is what the wxMBConv classes do.
64
65
66@section overview_mbconv_classes wxMBConv Classes
67
68The base class for all these conversions is the wxMBConv class (which itself
69implements standard libc locale conversion). Derived classes include
70wxMBConvLibc, several different wxMBConvUTFxxx classes, and wxCSConv, which
71implement different kinds of conversions. You can also derive your own class
72for your own custom encoding and use it, should you need it. All you need to do
73is override the MB2WC and WC2MB methods.
74
75
76@section overview_mbconv_objects wxMBConv Objects
77
78Several of the wxWidgets-provided wxMBConv classes have predefined instances
79(wxConvLibc, wxConvFileName, wxConvUTF7, wxConvUTF8, wxConvLocal). You can use
80these predefined objects directly, or you can instantiate your own objects.
81
82A variable, wxConvCurrent, points to the conversion object that the user
83interface is supposed to use, in the case that the user interface is not
84Unicode-based (like with GTK+ 1.2). By default, it points to wxConvLibc or
85wxConvLocal, depending on which works best on the current platform.
86
87
88@section overview_mbconv_csconv wxCSConv
89
90The wxCSConv class is special because when it is instantiated, you can tell it
91which character set it should use, which makes it meaningful to keep many
92instances of them around, each with a different character set (or you can
93create a wxCSConv instance on the fly).
94
95The predefined wxCSConv instance, wxConvLocal, is preset to use the default
96user character set, but you should rarely need to use it directly, it is better
97to go through wxConvCurrent.
98
99
100@section overview_mbconv_converting Converting Strings
101
102Once you have chosen which object you want to use to convert your text, here is
103how you would use them with wxString. These examples all assume that you are
104using a Unicode build of wxWidgets, although they will still compile in a
105non-Unicode build (they just won't convert anything).
106
107Example 1: Constructing a wxString from input in current encoding.
108
109@code
110wxString str(input_data, *wxConvCurrent);
111@endcode
112
113Example 2: Input in UTF-8 encoding.
114
115@code
116wxString str(input_data, wxConvUTF8);
117@endcode
118
119Example 3: Input in KOI8-R. Construction of wxCSConv instance on the fly.
120
121@code
122wxString str(input_data, wxCSConv(wxT("koi8-r")));
123@endcode
124
125Example 4: Printing a wxString to stdout in UTF-8 encoding.
126
127@code
128puts(str.mb_str(wxConvUTF8));
129@endcode
130
131Example 5: Printing a wxString to stdout in custom encoding. Using
132preconstructed wxCSConv instance.
133
134@code
135wxCSConv cust(user_encoding);
136printf("Data: %s\n", (const char*) str.mb_str(cust));
137@endcode
138
139@note Since mb_str() returns a temporary wxCharBuffer to hold the result of the
140conversion, you need to explicitly cast it to const char* if you use it in a
141vararg context (like with printf).
142
143
144@section overview_mbconv_buffers Converting Buffers
145
146If you have specialized needs, or just don't want to use wxString, you can also
147use the conversion methods of the conversion objects directly. This can even be
148useful if you need to do conversion in a non-Unicode build of wxWidgets;
149converting a string from UTF-8 to the current encoding should be possible by
150doing this:
151
152@code
153wxString str(wxConvUTF8.cMB2WC(input_data), *wxConvCurrent);
154@endcode
155
156Here, cMB2WC of the UTF8 object returns a wxWCharBuffer containing a Unicode
157string. The wxString constructor then converts it back to an 8-bit character
158set using the passed conversion object, *wxConvCurrent. (In a Unicode build of
159wxWidgets, the constructor ignores the passed conversion object and retains the
160Unicode data.)
161
162This could also be done by first making a wxString of the original data:
163
164@code
165wxString input_str(input_data);
166wxString str(input_str.wc_str(wxConvUTF8), *wxConvCurrent);
167@endcode
168
169To print a wxChar buffer to a non-Unicode stdout:
170
171@code
172printf("Data: %s\n", (const char*) wxConvCurrent->cWX2MB(unicode_data));
173@endcode
174
175If you need to do more complex processing on the converted data, you may want
176to store the temporary buffer in a local variable:
177
178@code
179const wxWX2MBbuf tmp_buf = wxConvCurrent->cWX2MB(unicode_data);
180const char *tmp_str = (const char*) tmp_buf;
181printf("Data: %s\n", tmp_str);
182process_data(tmp_str);
183@endcode
184
185If a conversion had taken place in cWX2MB (i.e. in a Unicode build), the buffer
186will be deallocated as soon as tmp_buf goes out of scope. The macro wxWX2MBbuf
187reflects the correct return value of cWX2MB (either char* or wxCharBuffer),
188except for the const.
189
190*/
191