openconnect/www/charset.xml

<PAGE>
	<INCLUDE file="inc/header.tmpl" />

	<VAR match="VAR_SEL_FEATURES" replace="selected" />
	<VAR match="VAR_SEL_FEATURE_CHARSET" replace="selected" />
	<PARSE file="menu1.xml" />
	<PARSE file="menu2-features.xml" />

	<INCLUDE file="inc/content.tmpl" />

<h1>Character set handling</h1>

<p>OpenConnect development started in 2008 on a modern Linux box, and
as such the character set handling was extremely simplistic. It boiled
down to the simple but reasonable assumption that <i>"everything is UTF-8,
all of the time"</i>. This was the case up to and including the OpenConnect
6.00 release in July 2014.</p>

<p>Since its inception, however, OpenConnect has been ported to
various less progressive POSIX-based systems and also to Windows,
which has its own particular style of charset insanity. It was
therefore necessary to implement some explicit handling for character
set conversion.</p>

<p>The design of this character set handling is that the internal
<tt>libopenconnect</tt> library still handles every string as UTF-8.
All input and output of the library remains UTF-8, and all callers
of the library are expected to handle them appropriately. For the GNOME and
KDE GUI tools, this should come naturally as all strings are expected to
be UTF-8 there. For the command-line tool <tt>openconnect</tt> itself,
implemented in <tt>main.c</tt>, this means that character set conversion
is done on all terminal input and output, and all arguments provided
on the command line.</p>

<p>Where it is necessary to open files or interact with the system in
other ways using the legacy character set, <tt>libopenconnect</tt>
will do the required conversion transparently. On POSIX systems with
legacy non-UTF-8 character sets, it will use <tt>iconv</tt> to
convert, while on Windows it will convert to UTF-16 and use the wide
character (so-called "Unicode") APIs instead.</p>


<INCLUDE file="inc/footer.tmpl" />
</PAGE>