Mail 4.5: accented characters bug in subject of emails

Hey,
Does anyone know how to fix this (minor) issue with Mail v4.5 and accents? The subject lines of some emais with accents do not appear correctly in the list of emails. For example, "dépôt" shows up as "dÃ©Ã´t" .
The subject line appears correctly in the preview pane, and the body of the email starts with the following 3 lines:
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Does it make sense to anyone?
Cheers,

Could be an os x bug, or a defective sending email app. The subject line is being read with the wrong encoding. If you do View > Message > Raw Source, you should be able to see an indicator of the encoding for the subject line right in the subject line.

Similar Messages

Mail with French / Spanish accented characters appear as Question marks

Hi
I am facing issues in mails that have French / Spanish accented characters in mail subject.Accented characters appear as Question marks (?) when received in the inbox.Mail subject is read from properties file.
Please let me know the following
- Should I have the entries in properties file in Unicode ? For example French accent character � is represented as á
- Should I replace msg.setSubject(subject); to msg.setSubject(subject,"UTF-8");
Please suggest.
Below is code snippet :
     Session session = getSession();
               // create a message
               Message msg = new MimeMessage(session);
               // set the from and to address
               InternetAddress addressFrom = new InternetAddress(from);
               InternetAddress[] addressTo = new InternetAddress[recipients.length];
               for (int i = 0; i < recipients.length; i++)
                    addressTo[i] = new InternetAddress(recipients);
               msg.setFrom(addressFrom);
               msg.setRecipients(Message.RecipientType.TO, addressTo);
               msg.setSentDate(new Date());
*               msg.setSubject(subject);*
               MimeMultipart mp = new MimeMultipart("related");

String subject = "\u00C 9tat de l'inscription en ligne";You need 4 hex digits after \u. You only included 3.
mailSubject = new String(subject.getBytes(), "UTF-8");
message.setSubject(MimeUtility.encodeText(mailSubject,"UTF-8", "B"), "UTF-8");Remove the above two lines. You're trying to make
this much too hard. All you need is:
message.setSubject(subject, "utf-8");
Should I use ISO8859_1 as Charset or UTF-8 ?I think the characters you're included are
representable in iso-8859-1 so you can use
that.
I am using Outlook express as my mail client. Do we have to decode it ?No.

How to get subject of the Mail greator than 50 characters length

Hi Friends,
I am sending a mail by using the Class Interface cl_document_bcs and method create_document
there the Parameter i_subject is of 50 characters length
but the client need the subject of the mail nearly 100 chars lenght
Please guide me how to go furthur
are there any other Methods to go furthur to have subject of the mail greator than 50 characters lenght
Thanks in Advance
Ganesh

Hi Ravi,
could you plz help me how to set that subject... (len > 50 char )
my previous code is
TRY.
    gwa_sendreq = cl_bcs=>create_persistent( ).
    gwa_document = cl_document_bcs=>create_document( i_type    = gc_htm
                                                      i_text    = gt_mail
                                                      i_subject = gwa_subject ).
   gwa_subject1 = 'Material Arrival (GIN No:12566) notification Against PO 26735 (To be Inspected)'.
   gwa_sendreq = cl_bcs=>set_message_subject( ip_subject = gwa_subject1 ).
    CALL method GWA_SENDREQ->SET_DOCUMENT( gwa_document ).
    gwa_sender = cl_sapuser_bcs=>create( sy-uname ).
    CALL METHOD gwa_sendreq->set_sender
      EXPORTING
        i_sender = gwa_sender.
    gwa_recipient = cl_cam_address_bcs=>create_internet_address( gv_mail_id ).
    CALL METHOD gwa_sendreq->add_recipient
      EXPORTING
        i_recipient = gwa_recipient
        i_express   = ' '.
    gwa_sendreq->set_send_immediately( gc_x ).
    CALL METHOD gwa_sendreq->send(
      EXPORTING
        i_with_error_screen = 'X'
      RECEIVING
        result              = gwa_sent_status ).
    IF gwa_sent_status <> 'X'.
    ENDIF.
CATCH cx_bcs INTO gwa_bcs_exception.
ENDTRY.
COMMIT WORK.

How to get the Subject of Mail Greater than 50 Characters length

Hi Friends,
I am sending a mail by using the Class Interface cl_document_bcs and method create_document
there the Parameter i_subject is of 50 characters length
but the client need the subject of the mail nearly 100 chars lenght
Please guide me how to go furthur
are there any other Methods to go furthur to have subject of the mail greator than 50 characters lenght
Thanks in Advance
Ganesh

Hi Ganesh
Its not possible to use more thatn 50 characters in send mail step for subject. May be you can try with the FM SO_NEW_DOCUMENT_ATT_SEND_API1 with more than 50 line in the subject.
Regards
vijay

Accented characters not encoded properly in Mail since 10.6

Messages I type that contain accented or otherwise special characters appear fine as long as I'm typing them but get re-encoded in a way that is unreadable by recipients AND by me. I.e, if I go to my Sent folder and check such messages, all accented characters have become unreadable.
I don't remember ever having that problem with 10.5
It also does not seem to be a systematic issue. I think I have it more when answering to a message or when transferring a message, as if Mail used the encoding method of the initial sender.
Anyone else has this problem?

The general approach at this time is to ask if you've checked for any problematic fonts (all languages) with Apple's Font Book (look in the Applications folder). Find and remove all duplicates also.
Start there to be sure all fonts that are in play come out with a clean bill of health.
Don't hesisate to perform wholesale deletion of old and/or little used fonts - be skeptical of anything that has come from Office 2008, including those related to an Equation Editor installation.
By all means be sure any 3rd party apps AND plug-ins are Snow Leopard compatible.
An additional measure is to clear the existing font caches:
http://www.macworld.com/article/139383/2009/03/fontcacheclear.html
That said, 10.6.2 release notes have this to say about fonts:
http://support.apple.com/kb/HT3874
Fonts fixes provided for:
• an issue with font spacing
• an issue in which some Fonts are missing
• font duplication issues
• an issue with some PostScript Type 1 fonts not working properly
Good luck in any case.

Problems with Greek accented characters

After the update to AIR 2.0.2 I cannot input into any application greek with accented characters.
Tried TweetDeck and Twhirl and neither work (used to before the update)
Is this a bug or it needs some configuration
I am working on Fedora13 but heard the same problem reported on Ubuntu.
Have not tried on MS Windows or MacOSX

Hi,
I'm using Adobe AIR 2.0.3 on Windows machine. I wrote an app in Aptana Studio (build: 2.0.5.1278522500) with ExtJS library and I found the problem with polish national characters like ż and Ż (all the other national characters like ą, ę, ń are possible to input).
In order to reproduce, here you have the sample code in ExtJS:
http://dev.sencha.com/deploy/dev/examples/form/anchoring.html
As you will see - it is possible to input ż and Ż in text fields.
Now, use the same code to build AIR applicaton and then run the application. It is not possible to input those characters in Air window. Right Alt+z acts like undo operation - it removes last entered text. All the other characters work fine.
Here is the code I used:
<html>
    <head>
        <title>New Adobe AIR Project</title>
        <link rel="stylesheet" type="text/css" href="lib/ext/resources/css/ext-all.css" />
        <link rel="stylesheet" type="text/css" href="lib/ext/air/resources/ext-air.css" />
        <script type="text/javascript" src="lib/air/AIRAliases.js"></script>
        <script type="text/javascript" src="lib/ext/adapter/ext/ext-base.js"></script>
           <script type="text/javascript" src="lib/ext/ext-all.js"></script>
        <script type="text/javascript" src="lib/ext/air/ext-air.js"></script>
        <script type="text/javascript">
        Ext.onReady(function(){
    var form = new Ext.form.FormPanel({
        baseCls: 'x-plain',
        labelWidth: 55,
        defaultType: 'textfield',
        items: [{
            fieldLabel: 'Send To',
            name: 'to',
            anchor:'100%' // anchor width by percentage
            fieldLabel: 'Subject',
            name: 'subject',
            anchor: '100%' // anchor width by percentage
            xtype: 'textarea',
            hideLabel: true,
            name: 'msg',
            anchor: '100% -53' // anchor width by percentage and height by raw adjustment
    var window = new Ext.Window({
        title: 'Resize Me',
        width: 500,
        height:300,
        minWidth: 300,
        minHeight: 200,
        layout: 'fit',
        plain:true,
        bodyStyle:'padding:5px;',
        buttonAlign:'center',
        items: form,
        buttons: [{
            text: 'Send'
            text: 'Cancel'
    window.show();
        </script>
    </head>
    <body>
    </body>
</html>
Is it possible to input those characters or is there a workaround for this (disable undo operation or so) ?
I really appreciate any help.
Kind regards,
Marcin.

Reading of accented characters in US-ASCII format in Exchange 2010

I finished a migration from Exchange 2003 to Exchange 2010.
I have one unsolved problem. An internal application generates and sends automatically reporting mails using the US-ASCII format through an anonymous Exchange 2010 Receive connector. This connector was configured following the Microsoft recommandations (article
"Allow Anonymous Relay on a Receive Connector",
http://technet.microsoft.com/en-us/library/bb232021(printer).aspx).
The problem is that accented characters like "é", "è" or "à" are converting in "?" when the reporting mails arrive in the user mailboxes in Exchange 2010.
I made the following test :
1. When I generate from the shell in Powershell a mail in US-ASCII format, the accented characters are converted to ?
$encoding = [System.Text.Encoding]::ASCII
Send-MailMessage -To '[email protected]' -Subject 'Test' -Body 'Test mail avec des é è à et @' -SmtpServer '172.16.3.55' -From
'[email protected]' –encoding $encoding
2. When I generate from the shell in Powershell a mail in UTF7 format, the accented characters remains unchanged in the mailbox :
$encoding = [System.Text.Encoding]::UTF7
Send-MailMessage -To '[email protected]' -Subject 'Test' -Body 'Test mail avec des é è à et @' -SmtpServer '172.16.3.55' -From
'[email protected]' –encoding $encoding
Is there a solution to keep the accented characters without changing the US-ASCII message format in the reporting application ?
Best regards,
Pascal

hi,
I think it is by design.
In an Exchange Server 2010 organization, content conversion is handled by the categorizer on a server that has the Hub Transport server role installed. Categorization on each message happens after a newly arrived message is put in the Submission queue. In
addition to recipient resolution and routing resolution, content conversion is performed on the message before the message is put in a delivery queue.
Please see this link:http://technet.microsoft.com/en-us/library/bb232174.aspx
thanks,
CastinLu
TechNet Community Support

Accented characters in email fields

I'm using this script to have email sent to me through a mail form:
<?php
// initialize variables for To and Subject fields
$to = '[email protected]';
$subject = 'Een testmail';
$from = $_POST["from"];
$email = $_POST["email"];
$comments = $_POST["comments"];
// build message body from variables received in the POST array
$message = "Van: $from \n\n";
$message .= "Email: $email \n\n";
$message .= "Bericht: $comments";
$message = stripslashes($message);
//convert flash line breaks
$message= str_replace("\r", "\n", $message);
$message=nl2br($message);
// add additional email headers for more user-friendly reply
$additionalHeaders = "From: $from <".$email.">\r\n";
$additionalHeaders .= "Reply-To: ".$email."\r\n";
$additionalHeaders .= "MIME-Version: 1.0\r\n";
$additionalHeaders .= "Content-type: text/html; charset=utf-8\r\n";
// send email message
$OK = mail($to, $subject, $message, $additionalHeaders);
// let Flash know what the result was
if ($OK) {
echo 'sent=OK';
else {
echo 'sent=failed&reason='. urlencode('Er is een probleem met de server. Probeer het later nog eens.');
?>
The problem is that I can't get accented characters appear into the From: cc: bcc: fields. For example, when I fill the From field with 'René' it appears as 'RenX' in the From: field. I've set everything to utf-8 but that doesn't seem to matter. When I receive an html text mail, the From: fields displays accented characters as strange codes, like RenA@ or RenX for René.
In the message text itself it varies: it either displays René when the mail is viewed as plain text mail, or RenA@ when the mail is views as html text. How can I get accented characters appear inside email fields too? And also in the body text when the email is viewed as html text?

It comes down to this. Since flash outputs in utf-8 I used utf-8 in here too. But narrowing it down to the most basic part:
<?php
$headers = "MIME-Version: 1.0\r\n";
$headers .= "Content-type: text/html; charset= UTF-8\r\n";
$headers .= "From: René <[email protected]>\r\n";
$OK = mail('[email protected]', 'A question', 'René is my name', $headers);
if ($OK) {
echo 'sent=OK';
else {
echo 'sent=failed&reason='. urlencode('There is a problem with the server. Try again later.');
?>
When I view this through webmail I get to see RenX in the From field where it should be René. Changing charset to ISO8859-1 won't work either. I get RenX in the From field and RenA@ in the message part. And when I switch in webmail from text/html to text/plain it says Ren? in the message part.
How can I make it display René in all headers and message? Both in html mode and in plain text mode?

Accented characters do not display correctly if there is a variable beside it

Hello,
We are experiencing a problem when we have text with accented characters an a variable beside it within the same text box.
The problem is that the accented characters in the text do not display correctly in the preview or publised course to Flash9
These characters display correctly in Captivate in edit mode.
This is the process we have followed:
Export to XML
Translated
Import XML
Publish to Flash9
Captivate version: 4
OS: Windows Vista SP2
We have tried to work with locale in Spanish with no luck, the only solution we have found is to put the text and the variable in different text boxes
I have pasted an image of the preview and also of the text in Captivate edit mode.
Any help will be very welcomed !
Tess

Hi there
I agree with Lilybiri that you should definitely file a Bug Report.
However, a thought occurs here. Have you tried placing the accented text in a User Defined variable?
Assuming this is a workaround, my thought is that you could then just have a caption with two variables. The User Defined variable containing the accented text followed immediately by the system variable providing the Project Name.
Cheers... Rick
Helpful and Handy Links
Captivate Wish Form/Bug Reporting Form
Adobe Certified Captivate Training
SorcerStone Blog
Captivate eBooks

Accented characters in exported images getting munged

Lightroom 2.x, OS X 10.5.6, G5, Nikon D80, Raw/NEF/DNG
I'm trying to sort out a problem I'm having that looks similar to other issues with international characters, but is a little different. My problem is specific to keywords.
I don't think this should matter, but I generally import as DNG and never save metadata to XMP. I mainly export to JPEG (to a folder that I zip up) in order to upload photos (outside of Lr) to a sharing site.
What I'm finding is that if I tag my photos (in Lr) with keywords that have accented characters (which I use a fair amount because I often travel to Francophone areas to take photos, and my IPTC data and keywords use correct French spelling) upon upload to any photosharing site I try, the keywords will be munged, duplicated and/or generally messed up. For example, I have a keyword "café". Upon export I can see this correctly in the IPTC Keyword metadata (via a third party EXIF/IPTC viewer, and also using "Get Info" in the Finder). However, as soon as I upload this JPEG to any photo sharing site the photo will end up with a series of keywords applied to it: "caf, cafe, cafã©"
Similarly, a keyword like "naïve" will end up as two keywords: "naã¯ve, nave" I get similar results with HTTP uploaders as well as uploader plugins inside Lr. And so on for è, ô &etc. In the case of Flickr, there will be one "copy" of the keyword that is correct. The others will still be present.
I've read hints that suggest that the IPTC metadata stored in the exported file by Lr might not be Unicode-clean, which causes anything that parses and normalizes select metadata (as all online sharing sites will want to do) to choke. I've heard rumours that the XMP data is properly Unicode clean, but most sharing sites ignore that data, since they are pretty much interested only in EXIF or IPTC metadata (and rightly so, I suppose.)
Is this a defect in the way Lr creates metadata in exported images? Or is is a problem with the way all these sites suck in and normalize the metadata stored in the image? Or is it a subtle interaction between the two that results in incompatibilities?
I haven't tried experimenting with creating or finding a JPEG with no keywords at all and manually inserting IPTC keywords with accents, just to see what Flickr (et al) do upon upload. I've also tried various permutations of the keyword options in the Lr export dialogue with no significant change in behaviour.
I'm interested in who else might be seeing this problem. Is it a Lr only thing, or is it Lr-on-Mac? Or something specific to the two sites I upload photos to?
I should point out that I've been seeing this behaviour since Lr 1.x.

(Jao, AdobeRGB is an experiment. I have a colour managed browser, so I wanted to see if I could tell the difference. This is a test photo from my junk pile.)
I think I see the problem. With something like ExifTool you can see that the keywords are stored in a number of places in the EXIF/IPTC header: Keywords, Subject and Hierarchical Subject. It is the Keywords section that is not Unicode clean, apparently. This is even more apparent if you show the output encoded in HTML entities:
Keywords : Franais, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, cafŽ, l'h™tel, na•ve, tests
Subject : Français, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve, tests
Hierarchical Subject : Français, Test Shots|tests, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve
So, it depends on what section the keywords are taken from. It appears that both Flickr and 23 will try to find the keywords in as many places as possible. This explains the many duplicates I am seeing.
So, now I just have to figure out why Subject is so wrong, and how to correct it (or leave it blank.)

Accented characters lost in description of alias email address

I recently noted that accented characters are lost in long name description of email alias address when using Mail.app but ok when using webmail in iCloud.com
Setup in the prefs of the master mail account in iCloud, the long name description "Frédéric" for the corresponding alias <[email protected]>
is transcripted as "Frdric" in Mail.app when selecting the sender address in the dropdown list box
However, all is fine when using webmail within iCloud.com
The problem appears only with OSX not with iOS
I have been using my alias with accented char in its long name description for the last 4 years with Leopard, Snow Leopard and Lion until recently. I can replicate on 3 differents Macs. Even tried to create a new user account. Same stuff.
Any views? Can someone replicate?

I found the same problem but only when creating an alias. The dropdown menu on mail app is not showing the accent and when is sent the name arrives to the sander as-is without the letter carrying the accent. No problems on iCloud interface though.
See, first one is my main icloud account, the second one is an alias account on icloud. Both have the same ó character but only shows in the main one.
Will someone help us fix that? Will apple fix that weird iCloud behavior?

Pages breaks words using "Justify text" on certain accented characters

I'm working on a document in Hungarian, and it seems that when I use the "justified text" setting, this puts extra white space around certain accented characters.
Please see these screenshots:
http://www.kkovacs.hu/~kkovacs/Pages-bug-with-accented-words.jpg
In this case, "időszak" should be a single word, and it is, when I write it as "Idõszak" (using õ instead of ő, but this is not the character that is needed there). The problem seems independent of the font that I use (Big Caslon, in the example above).
Is there a way to work around this?
Thanks in advance,
Kristóf

Hello
My old eyes fooled me.
I saw a "lowercase o with a tilde" when it was a "lowercase o with double acute"
With your font which is a bit more recent than mine, the missing glyph is grabbed from an other font (I didn't search which one it is).
I didn't got what was in your original screenshot.
I just get a character with a fully different drawing.
It's funny because it's the kind of problem RC-R and me where exchanging about in:
http://discussions.apple.com/thread.jspa?threadID=1644259&tstart=0
Given what I get, I will not call that a bug but a feature that many users (most of them ?) are unaware of.
The operating system does its best to display the character we are asking for even if it is not built in the used font.
This trickery has PROs and CONs.
For your use, I'm afraid that CONs are the most important and that you will have to search for a font embedding the needed characters.
To scan the contents of a font, I uses the free Linotype FontExplorer which displays the defined glyphs in black and the missing ones in red so, it's easy to see if a font fit our needs.
Yvan KOENIG (from FRANCE mardi 5 août 2008 16:01:46)

Entering accented characters via Simulator

I turned on international keyboard support in Simulator. I can switch to French keyboard. I can hold down 'e' to show me the options for 'e' (é,è,ê,ë...), but I can pick any of them. The keys for r,t,y...are highlighted instead.
This a bug? Anyone get it to work?

Follow up....I can enter accented characters into the contact app in the simulator so it's not keyboard related as I thought. But, I can't enter the characters if I'm running the SQLiteBooks example Apple posted today.

How can I disable the accented characters from popping up on the iPad?

Hello all,
I work with clients who are unable to talk due to various developmental delays. We use the Proloquo2go app which uses the regular iPad keyboard for communication. Is there a way to disable the accented characters from popping up when typing on the keyboard? This is very distracting for some of our clients. Thanks in advance for any advice.
Nikki

I don't use an external keyboard but I wonder if you would have any different functionality with one. I'm sorry that I cannot recommend anything but have you thought about that approach?
http://mashable.com/2012/05/11/ipad-special-needs/

How to load CSV with accented characters?

Hi,
I have a database instance with NLS_CHARACTERSET = 'AL32UTF'. I upload a csv file with APEX into WW_FLOW_FILES table and then parse it with dbms_lob.instr. The problem that I am facing is that if I save the CSV file in UTF8, then this works fine, if I save it in any other encoding then it's displaying 'funny' characters when I try to parse it and display the parsing result and the source data contains some accented characters, like, á, é, ő etc,
I am not sure if this is an APEX issue or I rather be turning to NLS forum. TIA.
Tamas
Edited by: Tamas Szecsy on Jan 30, 2011 6:34 PM

Did you every find a resolution to this issue on importing with accented characters?

Mail 4.5: accented characters bug in subject of emails

Similar Messages

Maybe you are looking for