How to fix special character encoding errors on your MU Online site and server

Quick answer

Encoding problems — that text full of garbled symbols like "ção" showing up as "Ã§Ã£o", or question marks in place of accents — are frustrating because they look cosmetic but actually indicate a structural inconsistency between the layers of your project: database, backend, site HTML, and in MU Online's case, even the game client itself with its legacy encoding. Fixing it superficially (just changing the page's charset) tends to mask the symptom without fixing the cause. This tutorial walks through every layer where encoding can break and how to fix it for good.

What encoding is and why it breaks

Encoding is the rule that translates characters (letters, accents, symbols) into stored/transmitted bytes. UTF-8 is today's universal standard, capable of representing any character in any language. Latin1 (ISO-8859-1) and Windows-1252 (ANSI) are older encodings used by many legacy systems — including the classic MU Online client. When one layer of the system writes in one encoding and another reads assuming a different one, the result is the classic "mojibake": ç becomes Ã§, ã becomes Ã£.

Where the problem could be (layer map)

Layer	Expected encoding	Typical symptom if wrong
Database (table charset/collation)	`utf8mb4` (MySQL/MariaDB)	Text saved correctly but displayed with garbled symbols
Backend-to-database connection	Must explicitly declare `utf8mb4`	Even with a correct database, it shows up wrong if the connection doesn't declare the charset
Page HTML (`<meta charset>`)	`UTF-8`	The entire page has broken accents, even with a correct database
Game client (MU)	Legacy encoding (varies by language/season)	Item/NPC/chat name shows a garbled symbol only inside the game
Server configuration files (.txt/.ini)	Depends on the emulator, often ANSI	Skill/NPC text corrupted only on the server, site normal

Step 1 — Confirm the database's actual charset

Don't trust documentation or the memory of whoever configured it — check directly. In MySQL/MariaDB:

SHOW VARIABLES LIKE 'character_set_database';
SHOW TABLE STATUS WHERE Name = 'news';
SHOW FULL COLUMNS FROM news WHERE Field = 'content';

If the result shows latin1 or utf8 (without the mb4) instead of utf8mb4, that's a strong clue to the root cause — old MySQL's plain utf8 doesn't support 4 bytes per character (needed for emojis and some symbols), and it frequently causes inconsistency with the rest of the stack.

Step 2 — Fix the table's charset and collation

If the table is on the wrong charset, convert it carefully. Order matters — converting directly can corrupt data that's already broken. First, make a full backup:

mysqldump -u user -p --default-character-set=utf8mb4 database_name > backup_before_encoding.sql

Then, if the data is ALREADY corrupted (mojibake saved in the database), the correct conversion usually requires an intermediate step via binary:

ALTER TABLE news MODIFY content BLOB;
ALTER TABLE news MODIFY content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

If the data in the database is already correct (the problem is only in display), skip the data conversion and just adjust the table/column charset declaration:

ALTER TABLE news CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Step 3 — Make sure the backend connection declares the charset

Even with the database correctly set to utf8mb4, if the backend connection (PHP, Node.js) doesn't explicitly declare the charset, MySQL might negotiate a different default charset (often latin1), and the mojibake reappears. Example in PHP with PDO:

$pdo = new PDO(
    "mysql:host=localhost;dbname=viciadosmu;charset=utf8mb4",
    $user,
    $password,
    [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"]
);

In Node.js with mysql2:

const connection = mysql.createConnection({
  host: 'localhost',
  user: 'user',
  database: 'viciadosmu',
  charset: 'utf8mb4'
});

Forgetting to declare charset/SET NAMES in the connection is, in practice, the most common cause of broken encoding on sites that already have a correctly configured database.

Step 4 — Correctly declare UTF-8 in the HTML

The page needs to declare its charset before any relevant text content, ideally as the first tag inside <head>:

<head>
  <meta charset="UTF-8">
  <title>ViciadosMU</title>
</head>

If this tag is missing, or comes after other tags that already generated enough bytes, some browsers may "guess" the wrong encoding before processing the declaration. Also confirm the web server (Nginx/Apache) isn't sending a conflicting HTTP Content-Type header:

add_header Content-Type "text/html; charset=UTF-8";

Step 5 — Test the game client's legacy encoding

Unlike the site, the MU Online client (especially in older seasons) frequently doesn't use UTF-8 internally for NPC, item, and chat text — it uses a legacy regional encoding (variants of Windows-125x depending on the original season's language). This means:

Accented text in server configuration files (NPC names, item descriptions) may need to be saved in the specific encoding expected by the client, not in UTF-8.
Editing these files with a modern editor that saves as UTF-8 by default (without a correct BOM) is a common cause of text corruption inside the game, even when the site works perfectly.

File	Typical expected encoding	Recommended tool
NPC/item configuration (`.txt`)	ANSI/Windows-1252 (varies by season/language)	Editor with an explicit "save as" encoding option
Client strings (`Data/Local/`)	Depends on the client's original localization	Test character by character before distributing
Chat/character name (network protocol)	Frequently restricted to ASCII	Validate in the emulator core before allowing accents

Step 6 — Validate accented character names (if you plan to allow them)

Many emulators restrict character names to plain ASCII due to a legacy from the original network protocol. If you want to allow accents, you need to validate at three points: the character creation routine on the GameServer, the display on the client (which may lack the correct font/glyph), and storage in the database. Test with real names containing ç, ã, é before releasing it to the public — a poorly encoded name can break the display for other nearby players in the game.

Useful tools for quick diagnosis

Tool	Use
`SHOW FULL COLUMNS` (SQL)	Confirms the actual charset/collation of each column
Browser DevTools (Network → Headers)	Confirms the actual `Content-Type` sent by the server
Text editor with encoding detection (Notepad++, VS Code)	Shows and converts a `.txt` config file's actual encoding
`iconv` (command line)	Converts files between encodings in a controlled way

iconv -f WINDOWS-1252 -t UTF-8 npc_file.txt -o npc_file_utf8.txt

Common errors and fixes

Symptom	Likely cause	Fix
Accents show up as "Ã©", "Ã£" on the site	Database in `latin1`/`utf8` without `mb4`, or connection missing `SET NAMES`	Convert the table to `utf8mb4` and declare the charset on the connection
Site is fine, but the game shows a garbled symbol on an NPC	Configuration file saved in the wrong encoding for the client	Save the file in the legacy encoding expected by the client (via `iconv` or a specific editor)
Only some characters break (emoji, rare symbols)	Using `utf8` (3 bytes) instead of `utf8mb4` (4 bytes)	Migrate the column/table to `utf8mb4`
Accented character name corrupts display	Client/protocol doesn't support the character	Restrict names to ASCII, or validate exhaustively before releasing
Page shows question marks instead of text	`<meta charset>` missing or conflicting HTTP header	Add `<meta charset="UTF-8">` as the first tag of `<head>`

Encoding fix checklist

Database's actual charset verified via SHOW FULL COLUMNS.
Full backup made before any charset/collation conversion.
Tables/columns migrated to utf8mb4 where needed.
Backend connection explicitly declaring the charset (SET NAMES/connection parameter).
<meta charset="UTF-8"> present as the first tag of <head>.
Web server's HTTP Content-Type header free of charset conflicts.
Server configuration files (NPC/item) tested in the encoding expected by the client.
Accented character names validated across all three layers (creation, display, storage), if allowed.

With encoding stabilized across all layers, it's a good opportunity to review other common inconsistencies between site and server, like date formatting and timezone. If you're building the full stack from scratch, check out the MU Online server creation guide.

Frequently asked questions

This classic pattern is a sign of 'mojibake': the text was saved as UTF-8 but is being read/displayed as if it were Latin1 (or vice versa). The most common cause is a mismatch between the encoding declared in the database, the backend connection, and the HTML page's charset.

Does the MU Online client natively support UTF-8?

It depends heavily on the version/season. Many legacy clients (Season 6 and earlier) were built with old local encodings (like Windows-1252 or CP variants for other languages) and don't handle raw UTF-8 well in item, NPC, and chat names. You need to test character by character before assuming full support.

Do I need to change the entire database's encoding to fix this?

Not always. Sometimes the issue is only in the backend's connection string or the charset declared in the HTML, without requiring a full collation migration. Always diagnose the exact layer of the problem before jumping to a full migration, which is risky and time-consuming.

How do I back up before touching the database's encoding?

Export a full database dump (mysqldump or equivalent) before any charset/collation ALTER. Encoding migrations can corrupt existing data if the conversion process isn't done in the right order (converting to binary before switching the declared charset).

Do accented character names cause bugs in the game?

On many emulators, yes — character names are traditionally restricted to plain ASCII precisely because of the client's and the original MU network protocol's encoding limitations. Allowing accents in names requires careful validation and extensive testing before releasing it to the public.

Rodrigo

Founder & editor-in-chief

Rodrigo has run ViciadosMU since the portal's early days. A specialist in MU Online server creation and administration, game history and the evolution of the seasons — he wrote much of the archive before 2024.