I have enabled the ktnef library to decode unicode strings, it may solve the bug #307 (that was my case) but the original author of the bug should provide more data about his issue
I have enabled the ktnef library to decode unicode strings, it may solve the bug [#307](http://bugs.trinitydesktop.org/show_bug.cgi?id=307) (that was my case) but the original author of the bug should provide more data about his issue
Using ascii() in almost all cases is not a good idea. Therefore, it is not good to add code that use ascii().
At least for the unicode string value, it seems better to use utf8().
Please, can you test the patch where you will use utf8() instead of ascii()?
Using `ascii()` in almost all cases is not a good idea. Therefore, it is not good to add code that use `ascii()`.
At least for the unicode string value, it seems better to use `utf8()`.
Please, can you test the patch where you will use `utf8()` instead of `ascii()`?
toString().ascii()
is used in many places for debug here. Although the use of ascii() can give wrong result for strings with special characters, for the scope of the patch provided by Fabio I think it is acceptable to use ascii() here, in line with the rest of the code.
Converting from ascii() to utf8() should be the scope of a different PR and the conversion should be global.
toString().ascii()
is used in many places for debug here. Although the use of ascii() can give wrong result for strings with special characters, for the scope of the patch provided by Fabio I think it is acceptable to use ascii() here, in line with the rest of the code.
Converting from ascii() to utf8() should be the scope of a different PR and the conversion should be global.
sorry, comment above in "Review" was intended in reply to Slavek's comment in the code, but it seems gitea does not accept a comment in reply to another comment. still testing comment feature out 😉
sorry, comment above in "Review" was intended in reply to Slavek's comment in the code, but it seems gitea does not accept a comment in reply to another comment. still testing comment feature out :wink:
@SlavekB: utf8() doesn't work because the strings are UCS2, which is common on Windows platforms. I have changed the code to leave TQString() managing the encoding and it seems to work as expected now.
@SlavekB: utf8() doesn't work because the strings are UCS2, which is common on Windows platforms. I have changed the code to leave TQString() managing the encoding and it seems to work as expected now.
hopefully I am not saying something totally wrong here.
utf8() alone should fail. The reason is in the way utf8() and TQCString work.
In short, utf8() returns a TQCString object. TQCString has a conversion "operator char * " method to convert to char . This works fine whenever utf8() result is passed to a const char * parameter. But when passed to a variable format string (%s), the conversion is not done automatically: the address of the TQCString is passed and interpreted as a const char, resulting in garbage printed to the screen.
Using printf(), I am 100% sure this happens (I had the same problem just yesterday 😉), using kdDebug() I am not 100% sure but it is likely to be the same.
Using utf8() requires something like this:
mapi.value.toString().utf8().data()
PS: ascii() works fine because it returns a const char *
Ciao Fabio,<br>
hopefully I am not saying something totally wrong here.
utf8() alone should fail. The reason is in the way utf8() and TQCString work.<br>
In short, utf8() returns a TQCString object. TQCString has a conversion "operator char * " method to convert to char *. This works fine whenever utf8() result is passed to a const char * parameter. But when passed to a variable format string (%s), the conversion is not done automatically: the address of the TQCString is passed and interpreted as a const char*, resulting in garbage printed to the screen.
Using printf(), I am 100% sure this happens (I had the same problem just yesterday :wink:), using kdDebug() I am not 100% sure but it is likely to be the same.
Using utf8() requires something like this:
```
mapi.value.toString().utf8().data()
```
PS: ascii() works fine because it returns a const char *
The raw data is ucs2 so utf8 cannot work (I guess), please have a look to the new commit that should fix the debugging statement (at least on my system, I am not sure which is the default coding for TQString, otherwise it should be set in advance).
The above referenced TNEF file has unicode chars even in strings advertised as not unicode (so probably it's buggy). You can see in the GUI with Action -> Message Properties looking at the subject property.
I don't know anything about MAPI details (and I am not interested to know more :-) ), but it seems that the message subject is repeated twice in the file, the first time as "stand-alone" property (0x8004) and the second one in the MAPI properties (tag 0x0037). The first time is treated as regular string, the second as unicode.
First of all I am using the file [unicode-mapi-attr-name.tnef](https://github.com/verdammelt/tnef/blob/master/tests/files/datafiles/unicode-mapi-attr-name.tnef) as usecase
The raw data is ucs2 so utf8 cannot work (I guess), please have a look to the new commit that should fix the debugging statement (at least on my system, I am not sure which is the default coding for TQString, otherwise it should be set in advance).
The above referenced TNEF file has unicode chars even in strings advertised as not unicode (so probably it's buggy). You can see in the GUI with Action -> Message Properties looking at the subject property.
I don't know anything about MAPI details (and I am not interested to know more :-) ), but it seems that the message subject is repeated twice in the file, the first time as "stand-alone" property (0x8004) and the second one in the MAPI properties (tag 0x0037). The first time is treated as regular string, the second as unicode.
I have enabled the ktnef library to decode unicode strings, it may solve the bug #307 (that was my case) but the original author of the bug should provide more data about his issue
Using
ascii()in almost all cases is not a good idea. Therefore, it is not good to add code that useascii().At least for the unicode string value, it seems better to use
utf8().Please, can you test the patch where you will use
utf8()instead ofascii()?toString().ascii()
is used in many places for debug here. Although the use of ascii() can give wrong result for strings with special characters, for the scope of the patch provided by Fabio I think it is acceptable to use ascii() here, in line with the rest of the code.
Converting from ascii() to utf8() should be the scope of a different PR and the conversion should be global.
sorry, comment above in "Review" was intended in reply to Slavek's comment in the code, but it seems gitea does not accept a comment in reply to another comment. still testing comment feature out 😉
@SlavekB: utf8() doesn't work because the strings are UCS2, which is common on Windows platforms. I have changed the code to leave TQString() managing the encoding and it seems to work as expected now.
Ciao Fabio,
hopefully I am not saying something totally wrong here.
utf8() alone should fail. The reason is in the way utf8() and TQCString work.
In short, utf8() returns a TQCString object. TQCString has a conversion "operator char * " method to convert to char . This works fine whenever utf8() result is passed to a const char * parameter. But when passed to a variable format string (%s), the conversion is not done automatically: the address of the TQCString is passed and interpreted as a const char, resulting in garbage printed to the screen.
Using printf(), I am 100% sure this happens (I had the same problem just yesterday 😉), using kdDebug() I am not 100% sure but it is likely to be the same.
Using utf8() requires something like this:
PS: ascii() works fine because it returns a const char *
Using kdDebug() as a stream looks very good. I have no objections. Thank you for your good contribution.
First of all I am using the file unicode-mapi-attr-name.tnef as usecase
The raw data is ucs2 so utf8 cannot work (I guess), please have a look to the new commit that should fix the debugging statement (at least on my system, I am not sure which is the default coding for TQString, otherwise it should be set in advance).
The above referenced TNEF file has unicode chars even in strings advertised as not unicode (so probably it's buggy). You can see in the GUI with Action -> Message Properties looking at the subject property.
I don't know anything about MAPI details (and I am not interested to know more :-) ), but it seems that the message subject is repeated twice in the file, the first time as "stand-alone" property (0x8004) and the second one in the MAPI properties (tag 0x0037). The first time is treated as regular string, the second as unicode.
Thanks Fabio, looks good. Merged and closed.
Keep up the good work 😉
1340cc3235でマージされています。