#11 add support to unicode string for ktnef library

Merged
MicheleC merged 2 commits from bug/307 into master 10 months ago

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
MicheleC reviewed 10 months ago
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.
MicheleC commented 10 months ago
Owner

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:

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:
efferre commented 10 months ago
Poster

@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.
MicheleC commented 10 months ago
Owner

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 :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 *

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 *
SlavekB approved these changes 10 months ago
Using kdDebug() as a stream looks very good. I have no objections. Thank you for your good contribution.
efferre commented 10 months ago
Poster

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.

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.
MicheleC deleted branch bug/307 10 months ago
MicheleC commented 10 months ago
Owner

Thanks Fabio, looks good. Merged and closed.

Keep up the good work :wink:

Thanks Fabio, looks good. Merged and closed. Keep up the good work :wink:
MicheleC added this to the R14.0.6 release milestone 10 months ago

Reviewers

SlavekB approved these changes 10 months ago
The pull request has been merged.
Sign in to join this conversation.
Loading…
Cancel
Save
There is no content yet.