Add TM symbol in the subject of the email - ruby-on-rails-3

I need to show TM symbol in the subject of an email. I am adding it in the body of the mail using ™ as we can send the email as text/html encoding. But, I need to add this in the subject line also.
I guess this is not possible since we cannot use HTML in subject line of the email. But I want to make sure of that or maybe some other way of doing it. I am using Rails 3.

i don't know ruby, but generally, you would encode the subject like this :
=?utf-8?q?hello_world=E2=84=A2?=
=> this produces
"hello world™"
=E2=84=A2 is the quoted printable representation of the trademark symbol in utf-8
see: http://en.wikipedia.org/wiki/MIME#Encoded-Word

Add this Unicode Character trademark symbol \u2122 in from address for ex: "MakeMyShop\u2122 Offers" and in email subject like "Welcome to MakeMyShop.IN\u2122!"

Related

Where are named pdf characters defined like "f_f", "uni00D0" and "a204"?

I'm trying to read the official pdf specification "Document management — Portable document format — Part 1: PDF 1.7" (PDF32000_2008.pdf) as bytes and then interpret them according to that specification.
In Annex D, Character Sets and Encodings, there is a list of all named characters, like:
or
When I parse PDF32000_2008.pdf, there are also named characters like "f_f", "uni00D0" and "a204", which are missing in that specification.
My guess is that "f_f" is a symbol for two 'f' characters, which might get printed with a special glyph. There is a unicode "Latin Small Ligature Ff" for 'ff'.
For example, there is also "f_i" in that file, which I expect to mean 'fi', one glyph showing the 2 characters 'f' and 'i'. However, the pdf specification has 'fi' as named character "fi" and what is the point for having 2 named characters pointing to the same symbol ?
I can imagine that "uni00D0" means the unicode character 'Ð'. However, pdf defines it already as named character "Eth"
What could be "a204" ? Maybe Ansi 204 'Ì', which also has already a named character "Igrave" ?
Why do they use also "a62", which would be just a '<' ?
However, my main question is: Where can I find a specification for these additional named characters ?
Of course, Adobe Acrobat understands them, but also Gmail seems not to have a problem with them. So I guess, their meaning must be specified somewhere.

Is it possible to generate vcards 2.1 that get arroung the Thunderbird linebreaks bug?

Without breaking the compatibility of spec-compliant softwares of course!
The link to the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=589332
In fields encoded as Quoted printable, Thunderbird add an extra space on each line-break.
Try adding one whitespace character (a space or a tab) to the beginning of each folded line. This is what you are supposed to do to each folded line, according to the vCard version 2.1 specification.
Maybe Thunderbird is assuming that the first character of each line is whitespace, so it ignores it (whether it's actually whitespace or not)
BEGIN:VCARD
VERSION:2.1
N;LANGUAGE=en-nz:LastName;FirstName
FN:FirstName LastName
NOTE;ENCODING=QUOTED-PRINTABLE:=0D=0A=
D.O.B. 13.12.41 =0D=0A=
=0D=0A=
24.10.05 Rang and had a lovely chat. I am sending her one of the new sheet=
s with the piccies on.She is getting a new wig soon but is wanting to wait =
for the new products to be up and running. I will e-mail her once these ar=
e all sorted.
END:VCARD

Whitespace encoding using stringByAddingPercentEscapesUsingEncoding

I am encoding white spaces in a string using
[#"iPhone Content.doc" stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]
in SKPSMTP message sending. But while receiving mail at attachments place I am getting the name iPhone%20Content.doc - instead of a space it shows %20. How can this be avoided / correctly encoded?
If you're doing stringByAddingPercentEscapesUsingEncoding then you're going to get percent signs in your result string... You can either use something different, or go back through and remove the percent signs later.
From the doc:
stringByAddingPercentEscapesUsingEncoding: Returns a representation of
the receiver using a given encoding to determine the percent escapes
necessary to convert the receiver into a legal URL string.
aka, "this method adds percent signs". If you want to reverse this process, use stringByReplacingPercentEscapesUsingEncoding
Just a side note, %20 is there because the hex representation of the space character is 20 and the % sign is an escape. You only need to do this for URLs, as they disallow the use of whitespace characters.
I got solution for my question. Actually am missed to set the "" to a string.
Of course the remote receiver can not accept the url with whitespace, so we must convert the URL address using the stringByAddingPercentEscapesUsingEncoding function.
This function replaces spaces in the URL expression with %20. It is especially useful when the URL contains non-ascii characters - you have use the function to percent-escape the URL so that the remote server can accept your request.

Sum symbol in POST

I send to my sever this POST petition:
name=pepito&friends=pep+mar
And I notice what arrives is
name=pepito&friends=pep mar
Why sum symbol disappears?
Than you
A + sign is one way to represent spaces in URLs. The other would be %20. There has been a question describing this: When to encode space to plus (+) or %20?
If you want to send a plus, you have to properly encode it with %2B.
Read up on allowed characters in URLs and URLEncode functions.

MIME "From:" header with national characters

What is the correct format of "From:" header when From Name contains national characters and dot (.) character?
We generate (using C# Chilkat lib) this:
From: =?utf-8?Q?Micha=C5=82_from_domain.com?= <abcdef#domain.com>
(where From Name = Michał from domain.com)
This works OK in most cases. However, we encountered an email provider which marks this header as invalid and uses Return-Path header instead (which is machine-readable only).
The error is:
Illegal-Object: Syntax error in From: address found on ps11.m5r2.onet:
From: =?utf-8?Q?Micha=C5=82_from_domain.com?=<abcdef#domain.com>
^-missing end of mailbox
The provider insists the the problem is the lack of space between name and email. This is not the case on our end (see previous code example).
That email provider has a broken MTA. Unfortunately, you have to deal with it.
You're already formatting your non-ASCII "From" personal-part as an RFC 2047 encoded-word. Since you're using Q as the encoding, you can take advantage of the flexibility in the quoted-printable encoding and encode the . as well:
From: =?utf-8?Q?Micha=C5=82_from_domain=2Ecom?= <abcdef#domain.com>
(Note that the . has been replaced by its quoted-printable encoding, =2E.)