php-i18n Digest 7 Feb 2004 01:08:04 -0000 Issue 214
Topics (messages 659 through 665):
Re: question about mail
659 by: Moriyoshi Koizumi
660 by: Ligaya Turmelle
661 by: Moriyoshi Koizumi
662 by: Ligaya Turmelle
gettext and utf8
663 by: walter fan
665 by: walter fan
String length
664 by: Hayk Chamyan
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
On 2004/02/04, at 13:44, Ligaya Turmelle wrote:
// send email
$sent = mail($add, $sub, $message, $headers);
You'd be better to use mb_send_mail() instead. It should work far
better.
Moriyoshi
--- End Message ---
--- Begin Message ---
I did and I got the unicode to work but then the japanese wasn't being sent.
Instead of viewing the Japanese in outlook I would get the base 64 encoding
. If I remove the base 64 encoding I receive garbage. Can you think of
anything else?
Respectfully,
Ligaya Turmelle
"Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> On 2004/02/04, at 13:44, Ligaya Turmelle wrote:
>
> > // send email
> > $sent = mail($add, $sub, $message, $headers);
> >
>
> You'd be better to use mb_send_mail() instead. It should work far
> better.
>
> Moriyoshi
--- End Message ---
--- Begin Message ---
On 2004/02/04, at 15:43, Ligaya Turmelle wrote:
I did and I got the unicode to work but then the japanese wasn't being
sent.
Instead of viewing the Japanese in outlook I would get the base 64
encoding
. If I remove the base 64 encoding I receive garbage. Can you think
of
anything else?
Oops, forgot to mention that you don't have to base64_encode
the mail body when it comes to mb_send_mail(). You can
safely pass it to mb_send_mail as is.
Moriyoshi
Respectfully,
Ligaya Turmelle
--- End Message ---
--- Begin Message ---
OK removed all the references to encoding in base64. And am still not
getting Japanese sent.
Code looks like this:
// create parts of email message
// headers
$headers = "From: $frName <$frEmail>\r\n"; // From
$headers .= "Reply-To: $frReToName<$frReToEmail>\r\n"; // Reply to
//$headers .= "MIME-Version: 1.0\r\n"; ////////Removed because
header was being put on by the MTA
//$headers .= "Content-type: text/plain; charset=UTF-8 \r\n";
//utf8 ////////Removed because header was being put on by the MTA
//$headers .= "Content-Transfer-Encoding: base64 \r\n"; // base 64
encoding
// body of the message
mb_language("uni"); // set to Unicode
$message = chunk_split($tMess); // split line into workable
parts (removed base64 encoding here)
// display email
echo "$add<br>";
echo "$sub<BR>";
echo "$headers<BR>";
echo "$message";
//$decodedMessage = base64_decode($message);
//echo "$decodedMessage<BR>";
// send email
$sent = mb_send_mail($add, $sub, $message, $headers);
And I am receiving in my mail box:
�,��,��f �,��fS�,��fS�,��f��f��,��f��f^�f��f��,��f��f- rather then
??????????????????
with this in the header
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from BASE64 to 8bit by host2.this
Any ideas?
"Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> On 2004/02/04, at 15:43, Ligaya Turmelle wrote:
>
> > I did and I got the unicode to work but then the japanese wasn't being
> > sent.
> > Instead of viewing the Japanese in outlook I would get the base 64
> > encoding
> > . If I remove the base 64 encoding I receive garbage. Can you think
> > of
> > anything else?
>
> Oops, forgot to mention that you don't have to base64_encode
> the mail body when it comes to mb_send_mail(). You can
> safely pass it to mb_send_mail as is.
>
> Moriyoshi
>
> > Respectfully,
> > Ligaya Turmelle
--- End Message ---
--- Begin Message ---
I have two questions as follows:
1. I wrote some codes
sample.php
<META HTTP-EQUIV="Content-Type"
content="text/html;<?=gettext("charset=iso-8859-1")?>">
messages.po
msgid "charset=iso-8859-1"
msgstr "charset=gb2312"
But I found gettext still return "charset=iso-8859-1"
2.I modified the charset of php files and messages.po to UTF-8
$iconv -f gb2312 -t utf-8 messages_gb2312.po>messages.po
$msgfmt messages.po
But the page didn't display UTF-8 strings.
I still research them. Can you answer me for the two questions?
Thanks & Regards,
Walter Fan
--- End Message ---
--- Begin Message ---
Sorry for my inattention.For issue 1, it have been resolved because I made a
mistake: setlocale after the gettext function.
For issue 2, my server is redhat linux7.1, I modified charset=UTF-8 to
charset=CHARSET in messages.po and re-generated messages.mo, it's okey,but I
don't know the reason. Who can tell me?
Thanks & Regards,
Walter Fan
"Walter Fan" <[EMAIL PROTECTED]> д���ʼ�
news:[EMAIL PROTECTED]
> I have two questions as follows:
>
> 1. I wrote some codes
> sample.php
> <META HTTP-EQUIV="Content-Type"
> content="text/html;<?=gettext("charset=iso-8859-1")?>">
>
> messages.po
> msgid "charset=iso-8859-1"
> msgstr "charset=gb2312"
>
> But I found gettext still return "charset=iso-8859-1"
>
> 2.I modified the charset of php files and messages.po to UTF-8
>
> $iconv -f gb2312 -t utf-8 messages_gb2312.po>messages.po
> $msgfmt messages.po
>
> But the page didn't display UTF-8 strings.
>
> I still research them. Can you answer me for the two questions?
>
> Thanks & Regards,
> Walter Fan
--- End Message ---
--- Begin Message ---
Hi All.
I've got a question regarding the length of binary strings in MB String.
Now strlen(file_get_contents('file.bin')) returns string length in bytes. However, if
in php.ini we overload the mb_strlen function in place of strlen, specifying
mbstring.internal_encoding='UTF8', the result will be wrong.
In this regard the question is whether or not a function like mb_strleninbytes
expected to return the string lenght in bytes is going to be introduced? Or, do you
plan to use mb_strlen($str, ASCII) everywhere instead?
If you want my opinion, I do not believe it makes sense to write strlen($str, ASCII)
in the existing applications.
--- End Message ---
