Unicode Support in Lazarus

From Free Pascal wiki
Revision as of 23:50, 31 January 2015 by JuhaManninen (talk | contribs) (Reading individual codepoints)


This page covers Unicode support in LCL starting from version 2.0 which uses features of FPC 3.0+.


Note: The feature and this page are under construction. Please test it with Lazarus trunk and report your findings in Lazarus mailing list or in bug tracker.

The old way to support UTF-8 in LCL using FPC versions up to 2.6.4 is explained here: LCL_Unicode_Support

RTL with default codepage UTF-8

Usually the RTL uses the system codepage for strings (e.g. FileExists and TStringList.LoadFromFile). On Windows this is a non Unicode encoding, so you can only use characters from your language group. The LCL works with UTF-8 encoding, which is the full Unicode range. On Linux and Mac OS X UTF-8 is typically the system codepage, so the RTL uses here by default CP_UTF8.

Since FPC 2.7.1 the default system codepage of the RTL can be changed to UTF-8 (CP_UTF8). So Windows users can now use UTF-8 strings in the RTL. You can test it by adding "-dEnableUTF8RTL" to the Lazarus build options and recompiling your project (you might want to add -FcUTF8 to your project and packages).

  • For example FileExists and aStringList.LoadFromFile(Filename) now support full Unicode. See here for the complete list of functions that already support full Unicode:


  • AnsiToUTF8, UTF8ToAnsi, SysToUTF8, UTF8ToAnsi have no effect. They were mainly used for the above RTL functions, which no longer need a conversion. For WinAPI functions see below.
  • Many UTF8Encode and UTF8Decode calls are no longer needed, because when assigning UnicodeString to String and vice versus the compiler does it automatically for you.
  • When accessing the WinAPI you must use the "W" functions or use the functions UTF8ToWinCP and WinCPToUTF8.
  • "String" and "UTF8String" are different types. If you assign a String to an UTF8String the compiler adds code to check if the encoding is the same. This costs unnecessary time and increases code size. Simply use String instead of UTF8String.

More information about the new FPC Unicode Support: http://wiki.freepascal.org/FPC_Unicode_support

Open issues

  • TFormatSettings char: for example: ThousandSeparator, DecimalSeparator, DateSeparator, TimeSeparator, ListSeparator. These should be replaced with string to support UTF-8. For example under Linux with LC_NUMERIC=ru_RU.utf8 the thousand separator is the two byte nbsp/160. Workaround: use space instead of nbsp.

Testing with Lazarus

You can enable the new mode by compiling Lazarus with -dEnableUTF8RTL. If you use string literals with WideString, UnicodeString or UTF8String, your sources now must have the right encoding. For example you can use UTF-8 source files (Lazarus default) and pass -FcUTF8 to the compiler.

There are 2 easy ways to test with the flags

-dEnableUTF8RTL and
  • A button "Support UTF-8 RTL" in the "Other" page in project settings. It can be used for any existing build mode, including Release and Debug modes which can be created with a button click as well.
  • Project -> New project ... -> "UTF-8 Application". This creates a project with those flags already set.

What actually happens then? These 2 FPC functions are called in an early initialization section, setting the default String encoding in FPC to UTF-8 :


The UTF8...() functions in LCL are set as backends for RTL's Ansi...() functions.

Compatibility with Unicode Delphi

RTL functions in ASCII area

RTL functions that work in ASCII area (e.g. UpperCase) are compatible, but they work faster in the UTF-8 RTL. In Delphi all string functions became slower after they switched to UTF-16.

RTL Ansi...() Unicode functions

RTL Ansi...() functions that work with codepages / Unicode (e.g. AnsiUpperCase) are compatible.

Reading individual codepoints

Not compatible. Code that needs to read individual codepoints inside a string must be different for UTF-16 and UTF-8.

See section : "Dealing with UTF8 strings and characters" for examples of how to use UTF-8.

Helper functions for CodePoints

LCL will have special functions for dealing with codepoints. They will use the old UTF8...() functions in LCL but can be made alias to functions using other encoding in Delphi and in FPC's {$mode DelphiUnicode}.

  • CodePointCopy() - Like UTF8Copy()
  • CodePointLength() - Like UTF8Length()
  • ToDo ...

Compatibility with LCL in Lazarus 1.x

Lazarus LCL applications will continue to work without changes. However the handling Unicode has become simpler and it makes sense to clean the code.

Explicit conversion functions are not needed. FPC takes care of converting encodings automatically when needed. Empty conversion functions are provided to make your code compile.

  • UTF8Decode, UTF8Encode - Almost all can be removed.
  • UTF8ToSys - SysToUTF8 - All can be removed.

File functions in RTL now take care of file name encoding. For example FileExistsUTF8 can be replaced with FileExists.

Most UTF8...() string functions can be replaced with the Delphi compatible Ansi...() functions.

Dealing with UTF8 strings and characters

See details in UTF8_strings_and_characters.


What about Mode DelphiUnicode?

The {$mode delphiunicode} was added in FPC 2.7.1 and is like {$Mode Delphi} with {ModeSwitch UnicodeStrings}. See the next question about ModeSwitch UnicodeStrings.

What about ModeSwitch UnicodeStrings?

The {$ModeSwitch UnicodeStrings} was added in FPC 2.7.1 and defines "String" as "UnicodeString" (UTF-16), "Char" as "WideChar", "PChar" as "PWideChar" and so forth. This affects only the current unit. Other units including those used by this unit have their own "String" definition. Many RTL strings and types (e.g. TStringList) uses 8-bit strings, which require conversions from/to UnicodeString, which are added automatically by the compiler. The LCL uses UTF-8 strings. It is recommended to use UTF-8 sources and compile with "-FcUTF8".