Terminal Encoding Issues
Last updated: April 2026
Default Encoding
RockTerm uses UTF-8 as the default character encoding for all new connections. UTF-8 is the dominant encoding on modern Linux, macOS, and BSD systems, and it supports the full Unicode character set including international characters, symbols, and emoji.
Encoding mismatches between RockTerm and the remote host are one of the most common causes of display corruption in terminal sessions.
Symptoms of Encoding Problems
If you see any of the following in your terminal output, you likely have an encoding mismatch:
- Garbled or scrambled characters — Readable text is interspersed with random accented characters or symbols. This is commonly called mojibake and occurs when UTF-8 byte sequences are interpreted as a single-byte encoding (e.g., Latin-1/ISO-8859-1) or vice versa.
- Question marks (
?) or diamonds (�) — The Unicode replacement character or plain question marks appear where special characters should be. This indicates the terminal received bytes it could not decode in the current encoding. - Empty boxes or rectangles — The encoding is correct, but the current font lacks a glyph for the character. This is a font issue rather than an encoding issue. Try switching to a font with broader Unicode coverage, such as Cascadia Code or a Nerd Font variant.
- Incorrect line-drawing characters — TUI applications like
htop,mc, ornmtuishow letters (e.g.,q,x,l) instead of box-drawing lines. This usually indicates the remote application is using VT100 line-drawing mode and the terminal type negotiation failed. Check that theTERMenvironment variable on the remote host is set toxterm-256color.
Checking the Remote Host Encoding
To determine what encoding the remote host expects, run the following commands after connecting via SSH:
# Display the current locale settings
echo $LANG
locale
# Typical output for a UTF-8 system:
# LANG=en_US.UTF-8
# LC_ALL=en_US.UTF-8
If the output shows a non-UTF-8 locale (e.g., en_US.ISO-8859-1, C, POSIX, or is empty), there is a mismatch with RockTerm's default UTF-8 encoding.
You can also check the available locales on the remote system:
# List all installed locales
locale -a | grep -i utf
# Check if en_US.UTF-8 is available
locale -a | grep en_US.utf8
Fixing Encoding Mismatches
Option 1: Change the Remote Host to UTF-8 (Recommended)
The best long-term fix is to configure the remote host to use UTF-8. On most Linux distributions:
# Set the locale for the current session
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
# To make it permanent, add the above lines to ~/.bashrc or ~/.profile
# On Debian/Ubuntu, you may need to generate the locale first:
sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8
# On RHEL/CentOS/Rocky:
sudo localectl set-locale LANG=en_US.UTF-8
Option 2: Change RockTerm's Encoding for a Specific Connection
If you cannot change the remote host's encoding (for example, on a legacy system or a managed appliance), you can configure RockTerm to match the remote encoding on a per-connection basis:
- Open the Connection Manager (
Ctrl+Shift+N). - Select the connection and click Edit.
- Under the Terminal section, change Character Encoding to match the remote host (e.g.,
ISO-8859-1,Windows-1252,EUC-JP,GB2312). - Save and reconnect.
This override only affects the selected connection. All other connections continue to use UTF-8.
Network Device Output Limitations
When connecting to network devices (routers, switches, firewalls, access points), be aware of the following encoding limitations:
- Most network device CLIs (Cisco IOS, Junos, EOS, NX-OS) only output 7-bit ASCII. They do not support UTF-8 or any extended character set. Encoding settings in RockTerm have minimal impact on these sessions since the output never contains multi-byte characters.
- Some devices output non-ASCII characters in specific contexts, such as SNMP descriptions, interface aliases, or banner messages that were configured with special characters. If these appear garbled, the device likely stored them in Latin-1 and you should set the connection encoding to
ISO-8859-1. - Certain older or embedded devices may send raw 8-bit bytes that are not valid in any standard encoding. In these cases, garbled output is expected and unavoidable. The data is being transmitted correctly; it simply does not conform to a character encoding standard.
Still need help?
If you're still experiencing issues, contact us or email info@rockriverresearch.com.