I've seen this exact scenario play out dozens of times: a developer imports a dataset containing names or addresses from a non-English source, sees a bunch of weird symbols like é or , and immediately tries to "fix" it by running Encoding(x) <- "UTF-8". They assume they are converting the text to UTF-8.

The Myth: Encoding() Changes the Actual Data

Here is the hard truth: Encoding() in R is essentially a label, not a converter. When you use the assignment operator with Encoding(), you aren't changing a single byte of the underlying data; you are simply telling R, "Hey, trust me, these bytes are actually UTF-8."

Let's look at why this fails. Imagine you have a string that was saved in Latin-1 (ISO-8859-1), where the character é is represented by the single byte 0xE9. If you tell R that this byte is UTF-8, R will look at 0xE9, realize it's an invalid starting byte for a UTF-8 sequence, and either display a replacement character or throw an error when you try to manipulate it. You haven't fixed the data; you've just lied to R about what the data is.

# The wrong way: lying to R
city <- "München" # Let's assume this was read in as Latin-1
# If we just tell R it's UTF-8 without converting...
Encoding(city) <- "UTF-8" 
print(city) # It still looks wrong or breaks downstream functions

The Reality: Distinguishing Between Labeling and Converting

To actually fix encoding issues, you need to move the data from one encoding standard to another. This is a process of translation, not labeling. In R, the heavy lifter for this is iconv().

When you use iconv(x, from = "Latin1", to = "UTF-8"), R actually looks at the bytes, identifies the Latin-1 representation of a character, and replaces those bytes with the corresponding UTF-8 byte sequence. This is the only way to ensure your data is portable and renders correctly across different operating systems (especially if you're moving between Windows and macOS/Linux).

I usually recommend a "read-then-verify" workflow. If you're using read.csv(), you can often nip this in the bud by specifying the fileEncoding argument. But if the data is already in your environment and looking like gibberish, iconv() is your best friend.

Handling "Mojibake" with iconv()

When you see "Mojibake"—that's the technical term for those garbled characters—it's usually because a file was read using the wrong encoding. If a Latin-1 file is read as UTF-8, the character é (one byte in Latin-1) might be misinterpreted.

Here is how I handle this in production code:

# Sample: A string that looks like "René" instead of "René"
bad_string <- "René" 

# We recognize that this happened because Latin-1 bytes 
# were interpreted as UTF-8. We convert them back.
fixed_string <- iconv(bad_string, from = "UTF-8", to = "Latin1")
print(fixed_string) # "René"

It feels counter-intuitive to convert from UTF-8 to Latin-1 to fix it, but remember: you are undoing the mistake made during the initial import. Once you have the raw characters back, you can then permanently convert them to a clean UTF-8 format for the rest of your pipeline.

📋 Practical Task

Rescuing European City Names from Latin-1

You have been handed a character vector of cities that was imported from an old legacy system using Latin-1 encoding, but R has treated them as UTF-8. As a result, the characters are garbled.

Your task: Write a script to fix the following vector. You must use iconv() to convert the strings from their current misinterpreted state back into a clean, readable UTF-8 format.

# The corrupted data
cities <- c("München", "Montréal", "Sao Paulo", "Bogotá")

# Your code here:
# 1. Convert 'cities' from UTF-8 to Latin1 to recover the original characters
# 2. Ensure the final result is encoded as UTF-8 for modern compatibility
# 3. Print the cleaned vector