mirror of
https://github.com/jberkel/sms-backup-plus.git
synced 2026-04-26 09:25:55 +03:00
[GH-ISSUE #171] X-smssync-address does not parse correctly when it has utf-8 string in it #143
Labels
No labels
AM+RCS
FAQ
awaiting response
backup
bespoke
bug
calendar
call log
cannot reproduce
cloudless
device-specific
documentation
dual- & multi-SIM
duplicate
feature-request
fixed in beta
good first issue
half-missing
help wanted
helpful
meta
misattribution
mms
other message sources
pull-request
question
rejuvenation
restore
schedule
security
stale
task
thanks
v1.5.1
v1.5.10
v1.5.11
v1.5.2
v1.5.3
v1.5.3
v1.5.4
v1.5.4
v1.5.5
v1.5.5
v1.5.6
v1.5.7
v1.5.8
v1.5.9
v1.6β
xoauth
~$ bounty $~
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/sms-backup-plus-jberkel#143
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @priv on GitHub (Aug 18, 2011).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/171
When the contact name has utf-8, for example:
(+886987654321 below is a fake example number I created for example)
X-smssync-address: =?UTF-8?Q?=E6=AD=A3=E8=8A=AC-GSM_=3C+886987654321=3E?=
sms backup+ failed to parse out the number +886987654321
I restore the contact, and in messaging AP it shows the contact as "=?UTF-8?Q?=E6=AD=A3=E8=8A=AC-GSM_=3C+886987654321=3E?="
But when exact same contact(And actually they're in the same dialogues if you view them in gmail), but only has number in X-smssync-address, ie. X-smssync-address: +886 987654321
Sms backup+ restore can correctly file the message to correct contact in my phone.
What's your suggestion that I can prevent this problem? Will you fix this? Either you should strip the utf-8 string in X-smssync-address, or you should convert it back to a valid utf-8 string.
@jberkel commented on GitHub (Jun 12, 2015):
hopefully fixed with new K9