Character encoding problem in attached files’ names

Hello once again and thank you in advance for your time and dedication.

I have a silly problem that’s been bugging me for a while now. It has probably nothing to do with eMC per se, I’m just wondering if some of you have encountered a similar situation.

The laptop I use has eMC (v. 8.1.876 Pro – English language) and Windows 10 (French) but Microsoft Office 2019 has both French and English installed (and both as a display language and for authoring and proofing).

Now, if I send an email from within any Office app (image below), and if by chance, the file’s name has French accent characters (à, é, ç, etc.), the result in eMC is awful as the accents are replaced with what I believe are UTF-8 characters. Recipients see them as such also.

Note that switching from one language to the other (as preferred) in Office didn’t change a thing.

However, everything is fine when I send files normally from within eMC (see image).

I had this problem with previous versions of eMC as well (8.1. and 8.0) but never with my previous email app (Thunderbird, that I’ve been using since v.0.4).

What could be done to avoid this gibberish in attachments names?

I don’t use MS Office, so can’t test it with your setup, but I did test it with LibreOffice (File > Send) and I don’t get that issue. A file called fidélité.odt is attached.


Windows 10 is set to English and so it eM Client.

I wonder if this issue is specific to MS Office and they way it interacts with eM Client?

I have MS Office 2016 and Libreoffice on my PC, and get the same results. eM Client displays the file name of the Word document incorrectly, but the LibO document is OK. If Thunderbird displays also the Word document correctly, it can apparently interpret file names handed over from Word in a way that eM Client doesn’t.

1 Like

Thanks for the confirmation @eisbaer

I did notice when using LibreOffice that is it not attaching the file directly from the disk, but instead sends a different file (with the same name) to the email client. So it must be something to do with the way the name is passed to the client, as @Son-of-A-Gun also confirmed that it works fine when adding a file directly from the disk without MS Word involved.

I wonder if this is somehow linked to this issue:

Thank you @eisbaer and @Gary for your time.

As you might have noticed English is not my native language, so thank you for bearing with me.

I pushed a bit further my investigation and I’m convinced the problem - as @eisbaer said it - lies with emC unable of interpreting file names handed over from Word. So, what I did:

  1. First, I tried on my laptop to send emails within all applications possible.

For Office 2019: Surprisingly Excel works just fine. However, I couldn’t test with Powepoint and Project since they required to Sync with Sharepoint or with a cloud app in order to send email.

Also, all my image software (such as Corel PaintShop Pro 2020 and FastStone Image Viewer 2020) work just fine with eMC.

  1. I installed the latest release of eMC (free) on my wife’s laptop for testing. Everything works fine except with her Word 2013.

  2. I installed Thunderbird for testing purposes on my laptop and it worked fine in combination with Word 2019 and the latest release of eMC.

I won’t open a ticket with support as it is a minor issue that won’t prevent me from using this wonderful app. I’m just puzzled no one has raised it before given the millions of eMC non-English users.

1 Like

No @Gary, I don’t think they’re related. I implemented @rumcajs suggestion a month ago as soon as he published it (as I had the same problem with my HTML signature). It has no impact on my actuel encoding problem.


I’ll chime in since my thread was mentioned here and I’ve noticed another problem: sharing the MS Word document as an attachment also adds an extra div to the composed message which breaks eM Client’s dark theme:

Looking at the source also reveals that the div contains a <tt> tag which is not supported by HTML5:

<div id="xd4c893ecdffc426" class="plain">
  <tt style="word-wrap:break-word">
    <div class="plain_line">&nbsp;</div>
  <br />
<div id="signature">

Pretty sure it’s Word’s fault but it would be nice if eM Client could remove those unnecessary tags.

1 Like

Maybe just not fully integrated. The extra line is not there when done from LibreOffice.

I’d be thankful @Gary if you could invite a member of the development team to read this thread.