Hi,

I don't understand what's happen.

I use Debian Jessie x64 with utf8 fr locale

If I copy my files directly to an exfat usb stick, i have no problem with the filename like : hébétàç.txt

If I make a tar archive with a file like hébétàç.txt, and after I try to extract this file in an other plateform like Windows 8, instead of the original filename, it's replaced by strange caracters.

1)does Debian "translate" the filename in other encodage like iso when it copy to an allien filesystem on my usb stick ?
2)tar encode in an other encodage type make it unreadable ?

Off course if I make a tar archive of this file and extract on linux, no problem.

I apologize for my poor english...

Does the windows 8 system have the utf 8 fr locale installed?

If it works fine with a regular text file than this cannot be the issue.

I'd say it's either:
A. A problem with tar encode character support
B. A problem with the unzip utility that you're using in Windows.

Since you said you can run "untar" and it is readable, then the problem is likely in the decompression utility you're using in Windows. Though it could also be a problem with the tar utility if it has "bend" any encodings depending on what the TAR standard supports. I'd look at the Windows decompression utility you're using first.

Which utility are you using to decompress in Windows? Also, what happens if you compress that file in Windows and decompress it using the same utility?

I prefer 7zip myself, but I don't know much about its language support. Try the one which is built into Windows. I would think that supports all character of the encodings that the rest of the operating system does (and the operating system obviously does support that locale).

I found the solution.

It was an incomplete coverage of tar archive by 7z. This bug was reported on Source Forge 7z support.
I downloaded the up to date 7z v.16 (windows) and hopefully, the problem desapeared.
The name of the filename are correct.

You can archive with tar on Linux, and use this archive on Osx, Windows 8. I verified, it works.

Thanks for your's answaers.

Good job and Well done!

Well, I am not intended to frighten anyone but especially when you are working with filesystems on different OSes (even different flavors of the same OS), I DO recommend to respect the POSIX standard for filenames. This is IMO the only way that is guaranteed.
Kikela, in the particular case you described, you had a good luck but you could have a bad luck, too. According to my experience, problems can appear during compressing / decompressing as well as during just copying. It is mostly possible to overcome the particular problem but in many cases it is really annoying (for example, two weeks ago I faced such a problem when transferring – not mine – 32 GBs of data /tarred/ from PC with Win XP to PC with Win 7: one hour of work).
And – do you REALLY need non-posix characters is your filenames? I am sorry but I doubt. I can, of course, understand it well when user has problems to understand and work with the latin alphabet because he/she speaks Russian, Chinese, Bengali etc. and he/she has a localized OS installation but it is hardly your case

This is an interesting question and you can ask an another one : Do you really need a computer ? What I really need is eating, drinking and sleeping. Everything else is comfort.
My first computer was a Sinclair zx80. In this former time we have no choice but it was in 1983 and the length of the filename can be only something like 8 characters. We are now in 2016.
And what it's need 4U is not necessary need for me.

I completely agree
And this is the core; perhaps I formulated my idea not in the most proper way:
Per my experience (in the last 15 years, roughly), the comfort that is obtained by usage of é,à,ç,č (etc.) characters in filenames is remarkably smaller than the discomfort induced by problems in file operations and transfer. (Valid on condition that you are perfectly able to understand latin alphabet.) Of course, your mileage may vary.

Yes, I also remember ZX 80

I am completely agreeing, again.

And I forgot to congratulate you to solving the problem