<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">Am 2016-05-10 um 17:48 schrieb Tony
Whyman:<br>
</div>
<blockquote cite="mid:573202B3.1060700@mccallumwhyman.com"
type="cite">I don't think this is what I meant as StringCodePage
is a unicode string function. I am looking at the single byte
string types.
<br>
<br>
On 10/05/16 14:15, Bart wrote:
<br>
<blockquote type="cite">It already is [part of the string type.
<br>
See the StringCodePage function.
<br>
</blockquote>
<br>
</blockquote>
<br>
Codepages are not restricted to Unicode.<br>
They can be others too (although it should only be used if unicode
is no option for some reason).<br>
Ansistring is single byte and can contain non-unicode codepages.<br>
From<br>
<a class="moz-txt-link-freetext" href="http://wiki.freepascal.org/FPC_Unicode_support">http://wiki.freepascal.org/FPC_Unicode_support</a><br>
:<br>
<h3><span class="mw-headline" id="Shortstring">-----------------------------------------------------------------------------------------------------------<br>
Shortstring</span></h3>
<p>The code page of a shortstring is implicitly CP_ACP and hence
will always be equal to the current value of
DefaultSystemCodePage.
</p>
<h3><span class="mw-headline" id="PAnsiChar.2FAnsiChar">PAnsiChar/AnsiChar</span></h3>
<p>These types are the same as the old PChar/Char types. In all
compiler modes except for <i>{$mode delphiunicode}</i>,
PChar/Char are also still aliases for PAnsiChar/AnsiChar. Their
code page is implicitly CP_ACP and hence will always be equal to
the current value of DefaultSystemCodePage.
</p>
<h3><span class="mw-headline"
id="PWideChar.2FPUnicodeChar_and_WideChar.2FUnicodeChar">PWideChar/PUnicodeChar
and WideChar/UnicodeChar</span></h3>
<p>These types remain unchanged. WideChar/UnicodeChar can contain a
single UTF-16 code unit, while PWideChar/PUnicodeChar point to a
single or an array of UTF-16 code units.
</p>
<p>In <i>{$mode delphiunicode}</i>, PChar becomes an alias for
PWideChar/PUnicodeChar and Char becomes an alias for
WideChar/UnicodeChar.
</p>
<h3><span class="mw-headline" id="UnicodeString.2FWideString">UnicodeString/WideString</span></h3>
<p>These types behave the same as in previous versions:
</p>
<ul>
<li> <i>Widestring</i> is the same as a "COM BSTR" on Windows,
and an alias for UnicodeString on all other platforms. Its
string data is encoded using UTF-16.
</li>
<li> <i>UnicodeString</i> is a reference-counted string with a
maximum length of high(SizeInt) UTF-16 code units.
</li>
</ul>
<h3><span class="mw-headline" id="Ansistring">Ansistring</span></h3>
<p>AnsiStrings are reference-counted types with a maximum length of
high(SizeInt) bytes. Additionally, they now also have code page
information associated with them.
</p>
<p>The most important thing to understand about the new AnsiString
type is that it both has a declared/static/preferred/default code
page (called <i>declared code page</i> from now on), and a
dynamic code page. The declared code page tells the compiler that
when assigning something to that AnsiString, it should first
convert the data to that declared code page (except if it is
CP_NONE, see <a
href="http://wiki.freepascal.org/FPC_Unicode_support#RawByteString">RawByteString</a>
below). The dynamic code page is a property of the AnsiString
which, similar to the length and the reference count, defines the
actual code page of the data currently held by that AnsiString.<br>
-----------------------------------------------------------------------------------------------------------<br>
</p>
with<br>
<br>
CP_ACP: this value represents the currently set "default system code
page". See <a
href="http://wiki.freepascal.org/FPC_Unicode_support#Code_page_settings">#Code
page settings</a> for more information.
<br>
</body>
</html>