Migration and Upgrade Center

What determines the need to make any Unicode changes is how you’re using strings and for what purposes. If you’re not doing heavy text processing or manipulations and stick to the standard string operations, mostly likely your code will simply just work. Additionally, just because you have lots of string literals in your code that also doesn’t necessarily mean you have to make any code changes. The most common things that you do have to watch for is file I/O and interfacing with external non-Delphi libraries and/or DLLs.

The default string in Unicode Delphi is the new UnicodeString type. By default, the UnicodeString type will have an affinity for UTF-16, the same encoding used by Windows. This is a change from previous non-Unicode versions which had AnsiString as the default type. The Delphi RTL has in the past included the WideString type to handle Unicode data, but this type is not reference-counted as the AnsiString type is, and thus isn’t as full-featured as Delphi developers expect the default string to be.

For the newer Unicode versions of Delphi, a new UnicodeString type has been designed, that incorporates the capabilities of both the AnsiString and WideString types.

A UnicodeString can contain either a Unicode-sized character, or an ANSI byte-sized character. (Note that both the AnsiString and WideString types will remain in place.)

The Char and PChar types will map to WideChar and PWideChar, respectively.

Note, as well, that no string types have disappeared. All the types that developers are used to still exist and work as before. However, for Unicode Delphi, the default string type will be equivalent to UnicodeString.

In addition, the default Char type is WideChar, and the default PChar type is PWideChar.

That is, the following code is declared by the compiler:

type
  string = UnicodeString;    Char = WideChar;   PChar = PWideChar;

With the addition of Unicode as the default string, Delphi can accept, process, and display virtually any alphabet or code page in the world. Applications you build with the newer Unicode versions of Delphi will be able to accept, display, and handle Unicode text with ease, and they will work much better in almost any Windows locale.

In current Unicode versions of Delphi, 'Char' and 'PChar' are now 'WideChar' and 'PWideChar'. You cannot assign an AnsiChar/PAnsiChar to a WideChar/PWideChar, and vice versa, without extra coding.

In any case, such code is redundant in current Unicode Delphi anyway, since AnsiString is now codepage-aware. You can assign any AnsiString-based string type (as AnsiString can be typedefed with a specific codepage at compile-time) to a WideString or UnicodeString, and the RTL will convert the characters to UTF-16 automatically for you.

If you really want to keep the code, then at the very least you should change the AnsiString parameter to a RawByteString (so that it can accept any codepage-specific AnsiString), and then use the new StringCodePage() function to know which codepage the character data is actually encoded as.

For example:

function StringToWideString(const s: RawByteString): WideString;
var
    l: integer;
    cp: Word;
begin
    if s = '' then
        Result := ''
    else
    begin
        cp := StringCodePage(s);
        l := MultiByteToWideChar(cp, MB_PRECOMPOSED, PAnsiChar(s), Length(s), nil, 0);
        SetLength(Result, l-1);
        if l > 1 then
            MultiByteToWideChar(cp, MB_PRECOMPOSED, PAnsiChar(s), Length(s), PWideChar(Result), l);
    end;
end;

Which can be simplified to this:

function StringToWideString(const s: RawByteString): WideString;
begin
  Result := s;
end;

One of the most relevant changes since Delphi version 2009 is that String types are now based on Unicode. Previously based on the ANSI standard, the AnsiString and WideString types still work the same way, except regarding their data size in bytes.

Unicode changes, in short:

• String maps UnicodeString, no longer AnsiString
• Char now maps WideChar (2 bytes, not 1 byte) being a UTF-16 character
• PChar maps PWideChar
• AnsiString maps the old String type

No changes were applied to:

• AnsiString
• WideString
• AnsiChar, PAnsiChar
• Short String contains AnsiChar elements
• Implicit conversions still work.

The user's active code page controls the mode (ANSI vs. Unicode), so that ANSI strings are still supported.

Operations that do not depend on character size:

• String concatenation
• Standard String functions. E.g., Length, Copy, Pos, and so on.
• Operators. E.g., <string> < comparison> <string>, CompareStr(), CompareText(), etc.
• FillChar ( <struct or memory> )
• Windows API

Operations involving the character size (measured in bytes) may require a few changes. Nothing too complicated, but here’s a tip: pay special attention to code in which you:

1. Assume Sizeof (Char) is 1.
2. Assume the size of a string equals the number of bytes in the string.
3. Handle String or PChars directly.
4. Saves or reads a string from/to a file.

Items 1 and 2 do not apply to Unicode, because in Unicode the Sizeof (Char) is 2 bytes and the size of a string is twice as big as the number of bytes. Besides, the code that reads and saves files must understand the right number of bytes to perform those operations, for a character is no longer represented as 1 byte.