TIL: The Wrong Character Set in GBase Database Can Turn Chinese Into `????`

I recently troubleshot a GBase Database(GBase 8s) character set issue: the database was running normally and connections worked, but Chinese data appeared as ???? after insertion. The root cause was simple—the wrong character set had been selected during installation.

This is an easy mistake to make when setting up GBase Database for the first time.

Reproducing the Problem

During the GBase Database(GBase 8s) installation, I accepted the default settings, leaving the locale as:

en_US.8859-1

The database itself worked normally. But after creating a table and inserting Chinese text:

CREATE TABLE test_cn (
    id INT,
    name VARCHAR(100)
);

INSERT INTO test_cn VALUES (1, '测试数据');

SELECT * FROM test_cn;

The result was:

id  name
1   ????

The database was Online. The SQL was valid. The problem was the character set configuration.

Why en_US.8859-1 Causes Problems

en_US.8859-1 uses ISO 8859-1, which is designed primarily for Western European characters. It does not provide the character coverage required for Chinese text.

In GBase Database(GBase 8s), locale settings affect how character data is handled between the database, client, and application.

Two important environment variables are:

For a Chinese UTF-8 environment, keeping these settings consistent helps avoid unexpected character conversion problems.

How to Configure the Character Set

Method 1: Set It During Installation

This is the simplest approach.

During the GBase Database(GBase 8s) installation and instance initialization process, select the appropriate locale instead of accepting the default:

zh_CN.utf8

Choosing the correct locale from the beginning is much easier than dealing with character conversion problems after production data has been loaded.

Method 2: Check the GBase Database Environment

If the instance has already been installed, check the GBase Database environment profile.

For example:

vi /home/gbasedbt/profile.gbase01

Look for the locale-related environment variables:

export DB_LOCALE=zh_CN.utf8
export CLIENT_LOCALE=zh_CN.utf8

The exact values should match your application's character set requirements.

After changing the environment variables, reload the profile before testing:

source /home/gbasedbt/profile.gbase01

Then verify the active values:

echo $DB_LOCALE
echo $CLIENT_LOCALE

You can also check the GBase Database environment with:

onstat -g env | grep LOCALE

The important point is to check the environment profile, rather than looking for these variables in the onconfig file.

UTF-8 or GBK?

GBase Database(GBase 8s) supports multiple character sets, so the right choice depends on your application and existing data.

For new applications that need multilingual support, UTF-8 is generally the safer choice because it provides broad character coverage and works well across modern applications and systems.

GBK can still make sense for legacy Chinese-only environments where existing applications and data already depend on it.

The key is consistency across the database, client, application, and data.

The Takeaway

A GBase Database instance can be completely healthy while Chinese text is still displayed as ????.

When troubleshooting character encoding in GBase Database(GBase 8s), check:

• DB_LOCALE

• CLIENT_LOCALE

• The database locale

• Application/client encoding

• Existing data encoding

Don't blindly accept the default locale during installation. If your GBase Database environment needs Chinese or multilingual data, make the character set decision before loading production data. A small configuration choice at installation time can prevent a much bigger migration problem later.