Error in Elixir when interpreting the Ñ

I am currently working locally with Elixir 1.13.4 and Erlang/OTP 24 and in the project image we use Elixir 1.17, we are having problems in Production when interpreting the ñ, the data arrives fine but when we show it Elixir interprets it as “├▒ ”We are already trying to convert to different systems like ISO-8859-1 and Windows-1252 but in both cases it is not possible to decrypt, although elixir handles the system by default UTF-8, we put it explicitly in the headers, we verify that the server response is the same, but even creating a local variable and assigning it “child” in inspection we see it as “ni├▒o”.
We also tried different ways of handling string and even applying String.valid?(text) returns it as true, we also tried to handle it with the equivalent ASCII code but it didn’t work.

I am thinking that it is a version problem, since on the server the version of Elixir is 1.17 and exactly the same problem happens and trying in another version such as 1.16 the Ñ (in uppercase) returns it as N and the ñ (in lowercase ) returns it to me correctly, but we need it to be interpreted in both upper and lower case.

No matter what we try we always get the same answer.

   texto = "niño"
    IO.inspect(texto)
    char = "\u00F1"
    IO.inspect(char)

iex(1)> "ni├▒o"
iex(1)> "├▒"

Elixir is processing everything correctly it seems, it is your terminal that is messing up your display.

Make sure that your terminal interpretes things as UTF-8, not anything else.

I’m not really sure if it’s the terminal because the same thing happens in production, but I’m going to try to do something with it.

WDYM “in produvtion”?

Tested how?

You’ll have to clarify on the production thing. It does look that your terminal cannot show certain characters. Either a font problem or it’s not setup to show UTF-8 by default.

2 Likes

It’s not the terminal either, I already did the test and it shows it as it should be
echo "Español, ñandú, café" Español, ñandú, café

Nothing jumps to mind then, sorry. I would double-check the terminal encoding settings and the font. I mean OK, the other characters are rendered fine but the font might still have a few omissions.

Here the terminal and system encoding might be just inline and sync. Can you echo that ñ into xxd or another hex dumper?

The exact bytes represented by "\u00f1" are 0xC3 0xB1, found via:

Base.encode16("\u00f1")

On code page 850 those bytes are interpreted as:

  • 0xC3
  • 0xB1
2 Likes