php-i18n Digest 27 Mar 2003 17:17:04 -0000 Issue 162
Topics (messages 508 through 518):
Re: Sending UTF-8 data from form to mysql
508 by: Moriyoshi Koizumi
509 by: Nino Katic
510 by: Moriyoshi Koizumi
511 by: Nino Katic
mbstring problem
512 by: Patrick T. Tsang
513 by: Moriyoshi Koizumi
514 by: Moriyoshi Koizumi
mb_encode_mimeheader problem
515 by: Gary Ross
516 by: Moriyoshi Koizumi
517 by: Gary Ross
518 by: Moriyoshi Koizumi
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 ---
The current stable version of MySQL doesn't provide a support for UTF-8
encoding. It is announced in the page pointed below that the feature will
be in 4.1.0.
http://www.mysql.com/doc/en/News-4.1.0.html
And for your interest, PostgreSQL already has a support for UTF-8.
Moriyoshi
"Nino Katic" <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm using UTF-8 to store data in mysql and to display it using php but i
> noticed one problem. I'm getting wrong comparison of data in mysql db fields
> and data i send from form. For example this query: select * from table where
> username=$_POST['username'] returns wrong result if i use croatian specific
> characters in form - $_POST['username'] (in some cases). How to make this
> work?
>
> Nino
>
>
> --
> PHP Internationalization Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
I'm currently on win, so i can't use Postgres and there are no binaries for
mysql 4.1 yet :-( but i don't know why couldn't i work with utf-8 and mysql
if mysql stores all data in raw (binary) format? I know that sorting will
not work but the things like select from where=somethnig should work??
Nino
Moriyoshi Koizumi wrote:
> The current stable version of MySQL doesn't provide a support for
> UTF-8 encoding. It is announced in the page pointed below that the
> feature will be in 4.1.0.
>
> http://www.mysql.com/doc/en/News-4.1.0.html
>
> And for your interest, PostgreSQL already has a support for UTF-8.
>
> Moriyoshi
--- End Message ---
--- Begin Message ---
Ah, I see. Are you sure that the incoming data is properly encoded in
UTF-8? I suppose that would be actually encoded in iso-8859-* or so on.
Did you try to compare the result of SELECT statement and the form
input? If both are the same, it should be a MySQL issue.
Moriyoshi
"Nino Katic" <[EMAIL PROTECTED]> wrote:
> I'm currently on win, so i can't use Postgres and there are no binaries for
> mysql 4.1 yet :-( but i don't know why couldn't i work with utf-8 and mysql
> if mysql stores all data in raw (binary) format? I know that sorting will
> not work but the things like select from where=somethnig should work??
>
> Nino
>
--- End Message ---
--- Begin Message ---
Yep, this is what i do. I insert username using form (post) within UTF-8
page (declared in meta tag). Before insert i do the check to see if there is
the same username already in database (this is select query mentioned
earlier). All this work fine with standard US characters and it also works
fine with my croatian ones, BUT in some cases not. So, it's strange to me
how come it doesn't compare values right in all cases. When i get those
values from a db and print them on a page i get them displayed correctly as
they were entered through the form. Uh :-(
Nino
Moriyoshi Koizumi wrote:
> Ah, I see. Are you sure that the incoming data is properly encoded in
> UTF-8? I suppose that would be actually encoded in iso-8859-* or so
> on. Did you try to compare the result of SELECT statement and the form
> input? If both are the same, it should be a MySQL issue.
>
> Moriyoshi
>
> "Nino Katic" <[EMAIL PROTECTED]> wrote:
>
>> I'm currently on win, so i can't use Postgres and there are no
>> binaries for mysql 4.1 yet :-( but i don't know why couldn't i work
>> with utf-8 and mysql if mysql stores all data in raw (binary)
>> format? I know that sorting will not work but the things like select
>> from where=somethnig should work??
>>
>> Nino
--- End Message ---
--- Begin Message ---
Dear all,
I am using PHP 4.3.0 and have compiled it with mbstring support.
here is the compile line.
================
./configure --with-apxs=/usr/local/apache/bin/apxs \
--with-config-file-path=/usr/local/apache/conf --enable-versioning \
--with-mysql --enable-ftp --enable-bcmath --enable-inline-optimization \
--disable-debug \
--enable-memory-limit=yes --enable-track-vars --enable-save-mode \
--enable-magic-quotes --with-gettext=/usr/bin \
--with-xml --with-imap=/usr/local/imap \
--with-curl=/usr/local --enable-mbstring --enable-mbstr-enc-trans \
--with-jpeg-dir=/usr --with-png-dir=/usr \
--with-zlib-dir=/usr/local --with-t1lib=/usr/local \
--with-gd=/usr/local --with-zlib=/usr/local --enable-gd-imgstrttf \
--enable-gd-native-ttf --with-freetype-dir=/usr \
--with-pdflib=/usr/local --with-openssl=/usr/local/openssl \
--enable-trans-sid --with-cpdflib --with-pgsql --with-ming=/usr \
--with-bz2 --enable-calendar --with-pspell \
--enable-tokenizer --with-iconv=/usr/local \
--with-gmp --with-mcrypt --with-ldap --with-mm=/usr/local/lib/mm \
--with-mbstring=cn --with-mbstring=tw --enable-mbregex \
--enable-xslt --with-xslt-sablot \
--with-sablot-js --with-expat-dir=/usr/local \
================
>From php.net, it says no more '--enable-mbstring' needed in PHP 4.3.0 but I
failed to have mbstring support without this!
Also I can't see any GB and BIG5 support shown on phpinfo(), only Japanese
is supported.
I can't successfully test GB and BIG5 using mb_* functions
had tested with PHP 4.3.2RC1 using the same compile line still got the same
problem.
Anyone could help?
Thanks
Patrick Tsang
--- End Message ---
--- Begin Message ---
Hi,
Patrick T. Tsang" <[EMAIL PROTECTED]> wrote:
> From php.net, it says no more '--enable-mbstring' needed in PHP 4.3.0 but
> I failed to have mbstring support without this!
That's not the case, just a documentation problem.
> Also I can't see any GB and BIG5 support shown on phpinfo(), only Japanese
> is supported.
> I can't successfully test GB and BIG5 using mb_* functions
>
> had tested with PHP 4.3.2RC1 using the same compile line still got the
> same problem.
Please try --enable-mbstring=all.
Moriyoshi
--- End Message ---
--- Begin Message ---
Are you sure that you've restarted Apache after the new installation?
Besides you don't need to specify --enable-mbstring twice in the configure
line. A single --enable-mbstring=all will just do.
Moriyoshi
"Patrick T. Tsang" <[EMAIL PROTECTED]> wrote:
> Dear Moriyoshi,
>
> had tried --enable-mbstring=all --enable-mbstring
> still get no support for big5 and gb2312
> I have seen some sites show:
> japanese support
> simplified chinese support
> traditional chinese support
> korean support
> multibyte (japanese) regex support
>
> But I just get japanese and multibyte regex supported.
>
> Please help
>
> Best Regards
> Patrick Tsang
>
>
> ----- Original Message -----
> From: "Moriyoshi Koizumi" <[EMAIL PROTECTED]>
> To: "Patrick T. Tsang" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 25, 2003 11:49 PM
> Subject: Re: [PHP-I18N] mbstring problem
>
>
> > Hi,
> >
> > Patrick T. Tsang" <[EMAIL PROTECTED]> wrote:
> >
> > > From php.net, it says no more '--enable-mbstring' needed in PHP 4.3.0
> but
> > > I failed to have mbstring support without this!
> >
> > That's not the case, just a documentation problem.
> >
> > > Also I can't see any GB and BIG5 support shown on phpinfo(), only
> Japanese
> > > is supported.
> > > I can't successfully test GB and BIG5 using mb_* functions
> > >
> > > had tested with PHP 4.3.2RC1 using the same compile line still got the
> > > same problem.
> >
> > Please try --enable-mbstring=all.
> >
> > Moriyoshi
> >
> >
>
--- End Message ---
--- Begin Message ---
When I try to use mb_encode_mimeheader on the subject line on an email
like so:
$subject = mb_encode_mimeheader
(
mb_convert_encoding($subject, "ISO-2022-JP","AUTO"),
"ISO-2022-JP",
"B"
);
the result is split up into a lots of parts something like this:
"=?ISO-2022-JP?B?_SOMESTUFF_?=\n =?ISO-2022-JP?B?_SOMESTUFF2_?=\n
=?ISO-2022-JP?B?_SOMESTUFF3_?=";
I've simply avoided using
mb_encode_mimeheader
and done this:
function my_mime($str){
$str = "=?ISO-2022-JP?B?". base64_encode($str). "?=";
return $str;
}
What am I doing wrong here?
Gary
--- End Message ---
--- Begin Message ---
Hi,
Gary Ross <[EMAIL PROTECTED]> wrote:
> When I try to use mb_encode_mimeheader on the subject line on an email
> like so:
>
> $subject = mb_encode_mimeheader
> (
> mb_convert_encoding($subject, "ISO-2022-JP","AUTO"),
> "ISO-2022-JP",
> "B"
> );
>
> the result is split up into a lots of parts something like this:
>
> "=?ISO-2022-JP?B?_SOMESTUFF_?=\n =?ISO-2022-JP?B?_SOMESTUFF2_?=\n
> =?ISO-2022-JP?B?_SOMESTUFF3_?=";
>
The behaviour is not wrong, as mbstring is made to be compliant with
RFC2047 (http://www.rfc-editor.org/rfc/rfc2047.txt).
Moriyoshi
--- End Message ---
--- Begin Message ---
Hello,
But it seems that on many/some(?) emailers the \n in "STUFF_?=\n
=?ISO-2022-JP?B" is interpreted as a new header line, not as part of
the subject. I'm not very familiar with the exact rfc rules, does the
choice of \n over other possibilities have an effect?
Should I be doing something like this:
$subject =
mb_encode_mimeheader(
trim(mb_convert_encoding($subject, "ISO-2022-JP","AUTO")),
'ISO-2022-JP',
'B',
"\r\n\t "
);
Thanks,
Gary
On Wednesday, March 26, 2003, at 12:23 pm, Moriyoshi Koizumi wrote:
Hi,
Gary Ross <[EMAIL PROTECTED]> wrote:
When I try to use mb_encode_mimeheader on the subject line on an email
like so:
$subject = mb_encode_mimeheader
(
mb_convert_encoding($subject, "ISO-2022-JP","AUTO"),
"ISO-2022-JP",
"B"
);
the result is split up into a lots of parts something like this:
"=?ISO-2022-JP?B?_SOMESTUFF_?=\n =?ISO-2022-JP?B?_SOMESTUFF2_?=\n
=?ISO-2022-JP?B?_SOMESTUFF3_?=";
The behaviour is not wrong, as mbstring is made to be compliant with
RFC2047 (http://www.rfc-editor.org/rfc/rfc2047.txt).
Moriyoshi
--- End Message ---
--- Begin Message ---
Hi,
Gary Ross <[EMAIL PROTECTED]> wrote:
> Hello,
> But it seems that on many/some(?) emailers the \n in "STUFF_?=\n
> =?ISO-2022-JP?B" is interpreted as a new header line, not as part of
> the subject. I'm not very familiar with the exact rfc rules, does the
> choice of \n over other possibilities have an effect?
>
> Should I be doing something like this:
> $subject =
> mb_encode_mimeheader(
> trim(mb_convert_encoding($subject, "ISO-2022-JP","AUTO")),
> 'ISO-2022-JP',
> 'B',
> "\r\n\t "
> );
I've never got a problem with the mails that have such folded headers.
Did you try mb_send_mail() and had no luck with it? I think that's most
likely a MTA problem..
Moriyoshi
--- End Message ---
