Using 3.1.5, under Fedora Linux.

With options "incoming_utf8 = true" and "decode_unicode_text = yes"

The euro sign appears as '¬' ( & #172; ).

I didn't look at the source, because a simple "$Text =~ s/\302\254/\342\202\254/g;" in my script solved the problem.

Thank's for the bug report and workaround code.

Unicode decoding fails with euro character. Here is a fast fix for this bug:

# diff -Pur charset.c charset_fixed.c
--- charset.c 2009-05-18 21:32:34.000000000 +0300 +++ charset_fixed.c 2009-08-10 19:55:55.000000000 +0300 @@ -721,6 +721,7 @@ { int i; char *d = buffer; + int j; for (i = 0; i < len; ) { @@ -739,6 +740,12 @@ } i = (d -buffer) +len; *(buffer +i) = '\0'; + + // 3.1.6: Fix euro character(s): + for (j = 0; buffer[j]; j++) + if (buffer[j] == (char) 0xAC) + buffer[j] = (char) 0xA4; + return i; }

However, I do not yet publish a new version, because this problem is not very usual and workaround can be used. Standard messages (using GSM character set) work correctly with €.

Next version will have completely rewritten character set conversions from/to Unicode. This is because internal conversion do not currently handle cyrillic languages.

keke wrote

However, I do not yet publish a new version, because this problem is not very usual and workaround can be used. Standard messages (using GSM character set) work correctly with €.

I have no problem of course with the current version, as I have found a workaround.

So for me, the issue is solved.

But I think it's in your interest to realize that the problem is no so uncommon.

In non-English languages, with the help of T9, users can easily insert characters not in the GSM character set.

Just my 0,02$, to help you keep up your good work.