When I was prototyping for push notifications I had a php script with a non localized string pushed to the iphone, here I could also include emoji symbols.
I have now made a webservice using asp.net and I localize the push notifications on the IOS side.
But I cant seem to get emoji symbols to work now, Ive tried every combination og unicode escape
sequences in the localized string, and also tried sending the emoji as an argument in the push notification and having it included in the localized string "%#" and "%C" but to no luck.
Im stuck atm, so any tip to put me back on track is very much appriciated
Stefan
According to the JSON RFC, characters that are not part of the "Basic Multilingual Plane" can be escaped using a UTF-16 surrogate pair.
For example the emoji symbol "THUMBS UP SIGN" is Unicode codepoint U+1F44D, and the UTF-16 surrogate pair for this is
0xD83D, 0xDC4D
The JSON Unicode escape sequence would be
\ud83d\udc4d
If you include this in the alert part of the push notification payload, the symbol will be correctly displayed (I have tested it).
But you can also use UTF-8, for the "THUMBS UP SIGN" this would be the bytes
0xF0, 0x9F, 0x91, 0x8D
Related
I've tried building an intent that targets :thumbsup: and also the unicode representation U+1F44D
how can I build an intent around emojis ?
Unfortunately :thumbsup: and U+1F44D will be invalid.
An utterance can consist only of Unicode characters, spaces, and valid
punctuation marks. Valid punctuation marks are: periods for
abbreviations, underscores, apostrophes, and hyphens.
You have to handle emoji before sending it to Lex. Like if you get :thumbsup: value then send thumbsup to Lex and it will handle that intent.
I'm analyzing character set used in MIME to combine multiple character set.
For that wrote as sample email as:
This is sample test email 精巣日本 dsdsadsadsads
which is automatically gets convert into:
This is sample test email 精巣日本 dsdsadsadsads
I want to know, which character set encoding is used to encode theses character?
Is this possible to use that character set encoding in C?
Email client: Postfix webmail
The purpose of MIME is to allow for support of arbitrary content types and encodings. As long as the content is adequately tagged in the MIME headers, you can use any encoding you see fit. There is no single right encoding for your use case; though in this day and age, the simplest solution by far is to use Unicode for everything.
In MIME terms, you'd use something like Content-Type: text/plain; charset="utf-8" and then correspondingly encode the body text. If you need the email to be 7-bit safe, you might use a quoted-printable or base64 content-trasfer encoding on top, but any modern MIME library should take care of this detail for you.
The HTML entities you observed in your experiment are not suitable for plain-text emails, though they are a viable alternative for pure-HTML email. (If your webmail client used them in plaintext emails, it is buggy; it will only work if the sender and recipient both have the same bug.)
Traditionally, Japanese email messages would use one of the legacy Japanese encodings, like Shift_JIS or ISO-2022-JP. These have reasonable support for English, but generalize poorly to properly multilingual text (though ISO-2022 does somehow support it). With Unicode, by contrast, mixing Japanese with e.g. Farsi, Uzbek, and Turkish is straightforward and undramatic.
Using UTF-8 from C is easy and basically transparent. See e.g. http://utf8everywhere.org/ for some starting points.
I have sent a text file as an attachment from from whatsapp and then when opened the sent file in iPhone app I am seeing =EF=BB=BF in start which means it is BOM utf-8 file. My question is why '=' character is coming after every code instead of 0x?
Also all emoji are coming in this style =F0=9F=98=9D, how can I convert this into simple text in objective C? Any help is much appreciated.
Thanks
What you're seeing is quoted-printable encoding. This encoding scheme escapes non-printable ASCII or 8-bit characters as =xx where xx is the hex value of the byte. Quoted-printable is mainly used in email transmission. See the question Objective-C decode quoted printable text for tips on decoding.
I'm building a service to push out notifications to iOS devices over APNS. Everything is working great, except for the fact that if the message text includes the £ (British Pound) or € (Euro) characters then the notification is not sent by APNS. I don't think this is a JSON issue as they don't normally need escaping (I've tried escaping them anyway to no avail). Is there something I need to do in order to support the whole character set?
Have you tried the JSON ASCII escape for Unicode? Send \u00A3 for £ and \u20AC for €.
JSON character encoding - is UTF-8 well-supported by browsers or should I use numeric escape sequences?
I've noticed that emojis in my app have stopped displaying properly on a UIWebView in iOS 5.
All characters are encoded for HTML when they are displayed and the output HTML is:
<p>Emoji (iOS 4): 😒</p>
This UTF-8 encoded HTML is rendered correctly in a UIWebView in iOS 4, but not in 5:
I understand there have been some changes in iOS 5 with regards to emoji, but the emoji character that has been encoded into 😒 was generated on iOS 5, so the 2 byte characters should be correct. No other changes have taken place to the code so it's definitely something introduced with iOS 5.
Any advice would be much appreciated and I'll happily provide more information if required. Thanks.
I've had a response from the developer forums:
The HTML parser in iOS 5 and Safari 5.1 has changed, and character references in the range 0xD800..0xDFFF (55296..57343) are treated as parsing errors and produce an object replacement character (which is typically rendered as a diamond with a question mark). This change in behaviour is consistent with what HTML5 specifies. This means that you can no longer encode characters using surrogate pair character references.
A relatively simple solution is to use a single character reference instead of a surrogate pair. In your example, instead of (0xD83D, 0xDE12), use 0x1F612. You can use either hex or decimal:
😒 or 😒
This explains the reason for the problem. I however, worked around the issue by only encoding a smaller subset of characters as the HTML document is in unicode.