mkarabulut, I read through this thread again. In your first post, you said that the SMTP server refuses to send non-English characters. Does this happen even if you use an e-mail program such as Microsoft Outlook using the charset that you desire or UTF-8 as I suggested? If the problem happens even with Outlook, then the problem would point to the SMTP server, thus any mods to the headers in your PHP mail would make no difference, no?

Do you know what charset your SMTP server supports? I regularly send e-mails to Russia using UTF-8, but I am doing it through Outlook. However, I am at work right now, so I am not able to test this with a PHP application. Maybe I will test this later when I am free to do so. In the meantime, though, ifyou could let me konw about answers to my questions, it might help the three of us troubleshoot this.

    Okay, for both of you:

    I tested this out now using UTF-8 as the encoding type. I have a form where a user can (for example) input Cyrillic letters, which is used for the Russian language among other Slavic languages. In my XHTML form, I specify UTF-8 as the charset:

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    The remainder is just XHTML used for a form, nothing special to show if you are alredy familiar with <form> <textarea> etc.

    That's one third of it. The next thing is to make sure your PHP code containing the mail() function uses a header type supporting UTF-8. In my "e-mail" code, I have this:

    $headers  = "MIME-Version: 1.0\r\n";
$headers .= "Content-type: text/html; charset=utf-8\r\n";

    Then I click submit, and the e-mail arrives at whatever address I am sending to.

    Now, the last third of this is specific to the computer where the e-mail is being read after it reaches the inbox. If the user hasn't set upt their computer to allow for reading of (for example) Cyrillic or Czech or whatever, then forget it, they will see strange symbols in place of the letters.

    All of this info may be more useful to Boris Senker since he is at least sending e-mails, but probably has an incorrect encoding type. As far as why your SMTP server, mkarabulut, is not allowing anything but English characters, you'd have to answer the questions from my previous post for me to help.

      Rachel2004, thanks for your reply and efforts. Really thanks a lot.

      I shall try with your advice, see what happens.

      Just one question. It may be a stupid question, but need to be clear here.

      The form I have itself has no meta tags, hence has no charset info. It is because it is included into a main page containing meta, so when the whole page is read into the browser it produces a validated structure composed of the index page, included header, content and footer pages.

      So the form page actually inherits the iso-8859-2 encoding from the page it is included into.

      Could this produce a problem when the form content is submitted to a mail () function before it is actually sent?

      Going to try as you have advised. Thanks a lot for help.

        Boris, if I recall correctly UTF-8 should include the charset included in iso-8859-2 since that was the whole idea of inventing Unicode. If I have time later today, I will do a Google search to confirm because I need to know for myself. If I am correct about UTF-8, then it should be okay to use UTF-8 (as I have) in the parent's <meta> tag as I described in my previous post. Since you are testing today, I guess you will know the answer before I post again later.

        Please, I would like that you post back and let me know if my suggestions work and solve your problem.

          Rachel - I believe you are right - UTF-8 does include iso-8859-2 charset.

          And - as soon as I test - of course I'll report back, successful or not.

          Thanks again, a zillion times.

          Will post back with progress. 😉

            Erm, it's actually working, but in an unexpected combination.

            I have set my main parent page's encoding to:

            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

            And adjusted as you instructed. I am posting the relevant piece of the code as follows:

            $headers="Return-Path:info@somemail.com\nMIME-Version: 1.0\r\nContent-type: text/plain; charset=utf-8\r\n";

            This produced garbage. At least I thought. But looking better, I remembered something related to codepages and Croatian characters I knew from the prepress and font issues in PS/PDF generation. Half of Croatian accented characters are positioned the same in Win-1250 and iso 8859-2 charset as in Unicode range.

            The other half characters, I was receiving here as garbage, have different positions in Win-1250 and iso 8859-2 than in Unicode. In Unicode, these characters lie within the extended Unicode range and are placed in different positions within the font table than they are in latter two codepage standards.

            Surprisingly, in this combination, the characters that are positioned differently in Unicode got themselves remapped to iso- codepage, although $headers was supplying the UTF-8 information. Could it be settings on a webserver?

            iconv.input_encoding ISO-8859-1 ISO-8859-1
            iconv.internal_encoding ISO-8859-1 ISO-8859-1
            iconv.output_encoding ISO-8859-1 ISO-8859-1

            mbstring.http_input pass pass
            mbstring.http_output pass pass
            mbstring.internal_encoding ISO-8859-1 no value
            mbstring.language neutral neutral
            mbstring.substitute_character no value no value

            However, if I set this:

            $headers="Return-Path:info@somemail.com\nMIME-Version: 1.0\r\nContent-type: text/plain; charset=iso-8859-2\r\n";

            BUT leave parent page encoding in UTF-8, I am getting all characters displayed properly, and all my accented characters are displayed properly.

            And it works.

            rachel2004, thanks a lot for your time and help. A LOT. You made me think and test various combinations and now I'm a happy mailman 😃

            mkarabulut, have you tried setting the main page's encoding to utf-8 but send headers as iso-8859-9?

              Important to mention, although specified as iso-8859-2 in $headers, mail IS sent as UTF-8.

              In Eudora displayed correctly at once, in Outlook Express the default encoding has to be set to UTF-8 and all characters are displayed correctly. Presumably Outlook (full) is to be set in the same manner.

                Boris, thank you very much for posting back your detailed findings. I will try playing with this at work on Monday and see if I can reproduce what you have done.

                Something I would like for you to post: your DOCTYPE delcaration. (e.g. :
                <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                "http://www.w3.org/TR/html4/loose.dtd"> )

                Your doctype will vary depending on whether you use HTML, XHTML, or XML. If you are using XHTML or XML, you probably have a line that appears before you doctype which states that you are using XML and the version. Do you have that in your code as well? If yes, please include that in your post.

                  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="hr" xml:lang="hr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
                  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

                  Both cases perform identically with the combination I have posted above, and both cases produce a W3C valid output - parent + includes produce a properly structured HTML output.

                    Write a Reply...