Avoiding non-ASCII characters in email notifications

Email subjects that contain non-ASCII characters can be interpreted in unexpected and sometimes unwanted ways by different email clients. For this reason, it's recommended that such characters be avoided in all eagle.io node names, state names, and custom active/inactive messages.

Some email clients will show special characters with no problems. Other email clients may substitute special characters with a ?, or convert the subject into a different character set using framing. For example, ANSI framing may be used by some clients; this would result in the subject text being split into multiple lines with =?ANSI_X3.4-1968?Q? at the start of each line and ?= at the end of each line.

To see a specific example of this problem, we will create a parameter named Temp °C

We will also create a state with an active message for this parameter:

Note the active message contains an em dash character, which looks like a very long dash and is not an ASCII character.

When the state alarm for this parameter is triggered and a notification email is sent, we can see the active message in the events looks good:

But when the email arrives, the subject looks like this:

Note that both the degrees character in the parameter name and the em dash character in the active message have been replaced by ?

Additionally, the body of the email has replaced the em dash with ?, although the degrees character has been preserved:

In summary, non-ASCII characters are best avoided in situations where they could be used in an email notification. This means that node names, state names, active state messages and inactive state messages should all be limited to ASCII only. Take extra care when copy/pasting names from other applications which may be disguising special characters; for example, naming a parameter in a Word document could result in two hyphen characters being automatically replaced by an em dash: