Unicode Support

.NET strings use UTF-16. This gives managed code a Unicode representation, but does not convert existing files, database columns, or native interfaces. Older ANSI Team Developer applications need particular attention at these boundaries; newer releases may already use Unicode.

UNICODE Database

Match PPJ string parameter types to database column types and provider requirements. The encoding setting in sql.config selects ANSI or Unicode parameter types; it does not change database encoding or repair lost characters.

Test accented characters, non-Latin scripts, empty strings, nulls, and maximum field lengths through insert, update, search, and fetch. Incompatible parameter types can also introduce implicit conversions that affect index use.

UNICODE Files

Choose the encoding required by the file format and its consumers. PPJ flags include Sys.OF_Unicode and Sys.OF_UTF8; legacy Sys.OF_UTF7 support should not be used for new file formats. Check byte-order marks, line endings, and whether lengths count characters or bytes.

Opening an ANSI file as UTF-8 is not a conversion. Decode with the known source encoding, then write the desired output encoding. See Microsoft's character encoding guidance.

UNICODE Externals

Match each P/Invoke declaration to the native signature. On Windows, CharSet.Ansi uses the applicable ANSI code page, not necessarily ASCII; CharSet.Unicode marshals UTF-16. Changing the attribute alone is incorrect if the DLL expects ANSI bytes. See Charsets and marshalling.

For output buffers, verify capacity, length units, null termination, and receive-parameter declarations. .NET strings are immutable; do not depend on native writes into an input string being reflected in managed code.