Script email and char accents

RouterOS Scripting
1

Hi to all,

i have 2 similar scripts that launch an email.

The script 1 send email with the correct accents in the email text
The script 2 send email with wrong accents in the email text

For example the string " è back" is printed in different ways:

Script 1 print into the email "

è down

"
Script 2 print into the email "

č down

"

Why?

2

script example?
At a minimum, you must specify the encoding in the message you send.
example:

/tool e-mail send to=example@mail.domain subject="Mikrotik\r\nMIME-Version: 1.0\r\nContent-Type: text/plain; charset=utf-8"
3

Into NETWATCH i check an ip and

if is UP:

[..more script..]
# email notification UP
/tool e-mail send to=$destemail subject="$myhost X is UP" body="$mydate $mytime, $myhost:\nDosomething because $target è UP."
:delay 10
[..more script..]

if is DOWN:

[..more script..]
# email notification DOWN
/tool e-mail send to=$destemail subject="$myhost X is DOWN" body="$mydate $mytime, $myhost:\nDosomethingelse because $target é è down."
:delay 10
[..more script..]

For

é è down

is sent this way:

é č down

(INCORRECT visualization in email)

While

è UP

is sent this way:

è down

(CORRECT visualization in email)


In both the script i didn’t set the encoding but in the first one work and in the second one no. Why???

Anyway i will try to set encoding. It goes under the SUBJECT?

It seems an unofficial workaround because in the official wiki
https://wiki.mikrotik.com/wiki/Manual:Tools/email
i cannot see any note about this

Thank you

4

characters é and è are not represented by ASCII characters.
When you write a script, the OS remembers the hex value of the character of the current encoding. It is this hex value that is transmitted in the email. The mail client displays a letter depending on its regional settings. Character é converges with its hex values, and character è is substituted from the client encoding. Displaying on another client will probably be different.
Whatever this happens, you need to send national characters indicating the encoding.
UTF-8:
è= 0xC3A9
é=0xC3A8

[..more script..]
# email notification DOWN
/tool e-mail send to=$destemail subject="$myhost X is DOWN\r\nMIME-Version: 1.0\r\nContent-Type: text/plain; charset=utf-8" body="$mydate $mytime, $myhost:\nDosomethingelse because $target \C3\A9 down."
:delay 10
[..more script..]
5

I could accept your answer as good. So that i have to suppose that we can use only native ASCII char without setting charset and have them correctly visualized into the email.

But the strange thing that win a major question are:

  1. Why the email of the netwatch UP condition (the UP one) work with the ‘è’ char without the need of set charset and i see correctly the ‘è’ into the email while only in the second one that is not correctly decoded or transmitted???
  2. In the ANSI table both ‘è’ and ‘é’ are present, and they both aren’t ASCII however the ‘é’ char is correctly visualized in both my netwatch scripts, even without the charset UTF8 set. So form me the ‘é’ always work but only the ‘è’ work sometimes…that’s all strange.

Can you try?

6

I’ll recycle an older post of mine:

RouterOS has zero support for anything above basic 7-bit ASCII. It just stores and reads those bytes as they are, but has no understanding of any character sets. So e.g. comment “ěščřžýáíé” saved in WinBox will be ok in same WinBox, but even WebFig will mess it up.

Edit: And about difference between the two mails, are you sending them to same destination mailbox? If not, don’t wonder any longer, you have no control how e-mail without specified encoding will be interpreted, something on the way can get creative. If they do go to same destination and take the same path, it would be more interesting. But if setting the encoding fixes it, it would be interesting only if you’re really curious.

7

As you say it is only curiosity because this is not a real issue. I can live if email are without accent characthers.
The encoding solves the issue but in the log i see a row for every row of the subject thus i see in the log the encoding lines added as workaround. Even this it’s not a real issue.

Again as you said it is only curiosity because the destination email is the same so i cannot understand why with the first email the ‘è’ it correctrly visualized but in the second one it is not

8

They gave you a solution and explained why this happens. You can think of the rest yourself.
Code pages consist of 1 byte (except utf), i.e. 256 values ​​are available. The first 128, as a rule, are identical and equal to the ASCII table. The rest belong to a specific set of characters.
In the email you must indicate in the header - in which character set you are transmitting the content.
/tool e-mail does not add this heading to the letter, because it is believed that you will transmit the characters of ASCII. The host does not know how to interpret the contents and substitutes the default character set.
If you want a detailed answer, then tell me - on what encoding do you write the script?
That will be half the answer to your question.

9

Check the final mails in e-mail client. Look at headers if perhaps something about encoding was added on the way. If not and there’s nothing about encoding, it can be some autodetection in e-mail client and it can have different result if it sees only one é character or two é è.

10

I have enough information thank to all.
So ASCII charachter are the only one certainly well coded everywhere if we doesn’t use a encoding declaration in email header.
Like Sob said the receiving email try to guess the correct encoding.
I made a test and in the email where the ‘è’ was correctly visualized and i added ONLY one another non ASCII character. At this point the receiver changed the charset and ‘è’ was uncorrectly visualized. That confirm Sob assertion. In the first email the characther was luckily decoded by email receiver guessing.

We can close the thread it is solved for me.

Thank you pepelxl & Sob!