I have issues with Unicode msgs, I live in Pakistan and use Arabic, Farsi & Urdu along with English of course in msgs.
When i typed a msg in MPE and save it as draft, it shows in some strange characters. I search this forum but couldn't find the solution,
because the MPE clam that it support Unicode but i have issues with it.
Now from many posts i have learned that RS must be in that language and a proper keyboard should be installed along with Unicode
character support. Well i think i have all of these tools but still couldn't find the solution. So i decide to share this problem coz
with this i am losing too much time to write the sms on notepad (Unicode) and then saved it as file and send it to phone Copy
and Paste the Unicode line and then send the msg. Wow to much steps but i have no Unicode. Well then lets start with complete
info so that you can find a solution.
OS = Windows XP Sp3
Updated = Fully updated with all updates
Phone = W960i (Fully updated)
Firmware = World Wide Generic (English)
Here are the regional settings of my OS.
Clicked on Details button
Now i just open notepad
Press Alt+Shift to change my input to Urdu or Farsi and then typed a msg (please note that this is the method i always use to change my
input language while typing)
Now i will transfer this file to W960i and open it there
Transfer method = Direct copy from Winodws Explorer while phone is connected in Normal Mode
First i save my file named "MyUnicode.txt" and set encoding to "Unicode"
Then i transfer it to W960i Phone Memory (Document Folder)
Now lets check it on mobile
Till now i don't have any issues. Now lets use Copy & Paste command to copy from that file and paste it in msg. Save it to draft and check it
again to ensure that its save properly.
As we can see that with this workaround i can send msgs as Unicode (Urdu, Arabic, Farsi)
Now let update MPE draft msg and Edit it and then Save it again with MPE commands
1.
2.
3.
4.
5.
6.
Now lets check it on the Phone (W960i)
1. 2. 3.
The result is
4.
Now if i open the one i saved with phone it self (the original one)
5.
Its still shows the right characters. This will be same if i try to create new msg (with this i will use "New Message" command from MPE and then
switch my language with Alt+Shift keys and write my msg, click Save to draft. This will save my message to draft and MPE will show correct
message text (in Urdu, Arabic or Farsi of course). But when i go to Draft folder in phone and open that message the same result will shown
(strange characters as we see in previous image).
Please Help me to resolve this issue, i have tried to describe it as much as i could, if there is something missing please let me know.
Thanks.
Zuletzt geändert von powerofleo am So 1. Aug 2010, 05:05, insgesamt 2-mal geändert.
Here is the complete LOG
=======================================
Logdatei MyPhoneExplorer
************************
Programmversion: 1.7.6
Datum: 01/08/2010
08:13:27.37 Setting Port: 3
08:13:27.37 Setting Baud: 921600
08:13:27.37 Avaiable Ports: COM3=\Device\zebrmdm0; COM4=\Device\zebrmdm1; COM5=\Device\VCom5; COM6=\Device\VCom6; COM7=\Device\VCom7; COM8=\Device\VCom8; COM9=\Device\VCom9; COM10=\Device\VCom10; COM11=\Device\VCom11; COM12=\Device\VCom12; COM13=\Device\VCom13; COM14=\Device\VCom14; COM15=\Device\VCom15; COM16=\Device\VCom16; COM17=\Device\VCom17; COM18=\Device\VCom18; COM19=\Device\zebrsce0;
08:13:27.43 Main Load frmSplash
08:13:27.48 Load frmSplash...
08:13:27.48 Show splash...
08:13:27.51 frmSplash geladen
08:13:28.48 Hauptfenster wird geladen
08:13:29.28 Sidebar fertig geladen
08:13:29.43 UC SMS wird geladen
08:13:29.51 UC Phonebook wird geladen
08:13:29.56 UC Phonebook fertig geladen
08:13:29.56 UC Calls wird geladen
08:13:29.59 UC Organizer wird geladen
08:13:29.68 Organizer initiated
08:13:29.78 Startpage=3
08:13:29.79 UC Filebrowser wird geladen
08:13:29.90 UC Filebrowser fertig geladen
08:13:29.90 UC AppBrowser wird geladen
08:13:29.92 UC Notes wird geladen
08:13:29.93 UC Calls wird geladen
08:13:30.20 Avaiable Ports: COM3=\Device\zebrmdm0; COM4=\Device\zebrmdm1; COM5=\Device\VCom5; COM6=\Device\VCom6; COM7=\Device\VCom7; COM8=\Device\VCom8; COM9=\Device\VCom9; COM10=\Device\VCom10; COM11=\Device\VCom11; COM12=\Device\VCom12; COM13=\Device\VCom13; COM14=\Device\VCom14; COM15=\Device\VCom15; COM16=\Device\VCom16; COM17=\Device\VCom17; COM18=\Device\VCom18; COM19=\Device\zebrsce0;
08:13:30.20 Neue COM-Bibliothek wird verwendet
08:13:30.21 SPort Properties set, opening COM3
08:13:30.23 After OpenPort
08:13:30.23 Settimeout: RT=2000 WT=500
08:13:30.73 Port 3 wurde geöffnet !
08:13:30.73 bOpened=True
08:13:30.73 [TX]: AT+CGSN
08:13:30.79 [RX]: AT+CGSN
08:13:30.79 [RX]: 359502011077171
08:13:30.81 [RX]: OK
08:13:30.84 Settimeout: RT=15000 WT=1000
08:13:30.84 [TX]: ATI
08:13:30.88 [RX]: ATI
08:13:30.88 [RX]: Sony Ericsson W960i
08:13:30.88 [RX]: OK
08:13:30.90 [TX]: AT+CSCS="UTF-8"
08:13:30.95 [RX]: AT+CSCS="UTF-8"
08:13:30.95 [RX]: OK
08:13:30.95 [TX]: ATI3
08:13:31.00 [RX]: ATI3
08:13:31.00 [RX]: Sony Ericsson USB WMC Modem
08:13:31.00 [RX]: OK
08:13:31.00 [TX]: AT+CNMI=2,1,0,1
08:13:31.09 [RX]: AT+CNMI=2,1,0,1
08:13:31.09 [RX]: OK
08:13:31.09 [TX]: AT*ECAM=1
08:13:31.15 [RX]: AT*ECAM=1
08:13:31.15 [RX]: OK
08:13:31.15 [TX]: AT+CIND=?
08:13:31.26 [RX]: AT+CIND=?
08:29:51.75 [RX]: +CIND: 1,0,0,0,5,0,4,0,1,0,0
08:29:51.79 [RX]: OK
08:30:01.79 [TX]: AT+CBC
08:30:01.79 WritePort failed. TransferedBytes=0 Systemerror: 0 [The operation completed successfully.]
08:30:01.79 Port 3 wird geschlossen
08:30:01.90 Port wurde geschlossen
08:30:02.32 DBT_DEVICEREMOVECOMPLETE: COM4
08:30:22.78 DBT_DEVICEREMOVECOMPLETE: COM3
08:30:22.79 Neue COM-Bibliothek wird verwendet
08:30:22.79 SPort Properties set, opening COM3
08:30:22.79 After OpenPort
08:30:22.79 Could not open COM3! (Port cannot be found)
08:30:43.25 DBT_DEVICEARRIVAL: COM3
08:30:43.26 Neue COM-Bibliothek wird verwendet
08:30:43.26 SPort Properties set, opening COM3
08:30:43.29 After OpenPort
08:30:43.29 Settimeout: RT=2000 WT=500
08:30:43.79 Port 3 wurde geöffnet !
08:30:43.79 Settimeout: RT=1500 WT=500
08:30:43.79 [TX]: AT+CGSN
08:30:43.85 [RX]: AT+CGSN
Its a known issue that Symboian-Phones (M600i, P1i, W950, W960) are not able to decode Unicode-Messages correctly when they get saved on the phone. This is a issue of the phone, not of MPE. If you send such a message it will be delivered correctly to the recipient.
I have a question in my mind, That why Windows Explorer can handle Unicode based file (while transferring and maintaining the Unicode font)? While MPE didn't.
.
I think this should be investigate that while retrieving the sms from phone is in original condition (Urdu, Farsi, Arabic) but when saved from MPE to Phone result in strange characters.
.
Retrieving from Phone mechanism works perfectly but Saving them to Phone is not working properly for Unicode.
.
As far as for fonts support in Phone, if it can show the SMS in Unicode then there should not be a problem of the fonts.
There are problems with unicode especially in handling filenames with MyPhoneExplorer. This is basicly related to the programming language. But the SMS-Content is fully unicode-compatible. Your problem you described here is related to the phone and not to MyPhoneExplorer. If you take a look at the logfile then you'll see that both PDU's (the one which was read and the one which was write) are basicly identical. The only diffrence is that the SC-Header is not set by MPE but this has nothing to do with the body.
09:02:13.37 [RX]: +CMGL: 269963520,2,,78
09:02:13.43 [RX]: 088100291398424444150000810008FF46062706CC06410020062C06D2002006330627064106790020064806CC06312029064506CC06310627002006320627062A06CC0020062706CC06A90633067E0644064806310631
09:02:13.46 [RX]: OK
I am also a programmer in Visual Basic form 4 year, also i have experienced with Java. So if we talk in technical language that will not be a problem.
.
anyway when i matched the both lines "from your msg" there are some characters missing and at the end of the MPE saved message there is -> type character, witch is also missing from original print.
here is the difference and the charterer.
088100291398424444150000810008FF4606 (after this all other are Identical)
................................00110000810008FF4606 (after this all other are Identical)
I cannot type the charterer that is -> (to see it, copy it to notepad)
7E0644064806310631
7E0644064806310631
I am not saying that the Active X control is not working, what i said is that the MPE can not save the msg print in original state to phone. While it is showing correctly in MPE even if we create that on phone (like i did) but if it created with MPE it shows correctly to MPE control but while saving its missing something that it should save it along the message (now i don't know how MPE is saving the message data to Phone, but i am sure that if you debug that part while saving and retrieving the Unicode based message form phone you will find the problem.)
Also why MPE is not saving SC-Header???
The only difference is that the SC-Header is not set by MPE but this has nothing to do with the body.
Zuletzt geändert von powerofleo am Mo 2. Aug 2010, 18:08, insgesamt 1-mal geändert.
OK, so i think you'll understand me. The first characters from the retrieved message is the used Service-Center-Address. This address is optional, MyPhoneExplorer does not use it.
The last character is the escape-char which is needed to tell the phone that the data ends here. This is only used on write- and send-operations.
There is a very useful tool avaiable to decode PDU-Strings: PDUSpy -> Google this tool and decode PDUs to see which byte has which meaning
FJ hat geschrieben:OK, so i think you'll understand me. The first characters from the retrieved message is the used Service-Center-Address. This address is optional, MyPhoneExplorer does not use it.
The last character is the escape-char which is needed to tell the phone that the data ends here. This is only used on write- and send-operations.
There is a very useful tool avaiable to decode PDU-Strings: PDUSpy -> Google this tool and decode PDUs to see which byte has which meaning
Now i think we are on track to understand the problem (for me )
Question: Even if that SCA is optional why not to use it? If it use it or not (currntly not) will not make any difference, right?
The Escape-Char is working fine i think because its the char that tells phone that message is ended, can we use another char or there is fixed EC???
And one last thing, thank you for your prompt reply
You could use the SCA to send the message to a special service-center, if this value is omitted then the phone uses the presaved address - so in case of MPE it would make no diffrence to use it or not.
The Escape-Char cannot be changed, its based on GSM (or Modem) Standard. If you use HyperTerminal for testing you can set this character with CTRL+Z
I am not saying that the Active X control is not working, what i said is that the MPE can not save the msg print in original state to phone. While it is showing correctly in MPE even if we create that on phone (like i did) but if it created with MPE it shows correctly to MPE control but while saving its missing something that it should save it along the message (now i don't know how MPE is saving the message data to Phone, but i am sure that if you debug that part while saving and retrieving the Unicode based message form phone you will find the problem.)
If you find a way to save Unicode-Messages correctly on Symbian-phones then just let me know . It works on "normal" SE-Phones with the same input so i think its really a problem raised by the phone.
.......
.
.
As you can see that in Orignal Message there is no Latin1 font refrence at all, while the message saved form MPE have the Latin1 and Arabic refrence. Now what i think is that, the reason that is not showing the Unicode correctly after we saved it from MPE is that Latin1 encoding ref.
To understand it correctly i will give an example in style sheet. For example we have a Text "My Phone Explorer" and we applied font style on that text.
<Script language="Java/Script"
.NomalText{
Font.face: Arial, Verdana, Times New Romans;
}
</Script>
here the first font (which is Arial) have the priority on other fonts, if somehow the font Arial is missing then the 2nd font which is Verdana have to most priority and if that is not found also then the Last font which is Times New Romans have the priority. And if that is not found also then the system will decide to show that text on pre-defind font which is the last option.
As we can see that in original message there is not Latin1 ref. and only have Arabic, which is the high priority and thus shows the message in correct characters.
In 2nd message which is saved by MPE there are two fonts Latin1 and Arabic and both are present on phone, so here Latin1 have priority on Arabic thus shown the text on Latin1 encoding rather then showing it in Arabic encoding which is also present but have low priority compare to Latin1.
So i my opinion if you remove that Latin1 ref. it will solve the problem, because there will be no other font which have priority on Arabic. This Latin1 should only be removed if the message is in Unicode format. Other wise the Latin1 will encode the message which is the default language font.
You are right, there is one character diffrent which i missed in the log. But i don't think it raises the problem - this would be to easy. You cannot set charsets on UCS-2 Messages cause they are already Unicode.
But i think you could avoid also this diffrence very easy for testing (i dont want to start my P1i extra for this test :
- copy your message from drafts to Archive (in MyPhoneExplorer)
- and from Archive you upload it back to draftsfolder
- check how its displayed on the phone
With this procedure MPE will not create a new PDU, MPE uses in this case the original PDU for uploading (you can verify this also throught the logfile). If the message is shown correct on the phone then there is maybe a bug in MPE, if the message is still shown wrong then it must be a bug in phone (cause identical data).
I have tried it and still msg shows wrong characters.
.
I don't understand how can it be copied correctly, because when it create the msg wrong then it will also be wrong when we copy it. It dosent matter that PDU is original or not because that data is already going wrong.
My point it when there is still going Latin1 then how can it shows correctly?
Log still shows the wrong print not the original print. So when that wrong print copied to phone it will still shows wrong characters.
This log shows exactly the same pdu which was received already from phone. And again: You cannot switch any charset in a SMS-Messages (Except GSM and UCS2)
2. 
3. 
5. 
6. 
8. 
2. 
3. 
)
.......