Note that CP50220 isn't identical to ISO-2022-JP-MS despite the naming.
JISX0201 katakanas are not allowed by CP50220
Moriyoshi
On 2/3/10, Tex Texin wrote:
> Yes, microsoft doc is often loose with respect to encodings.
> E.g. they claim 932 and shift-jis are the same when they
That is not correct. .NET Names here are also used intenally in MS
products as well as codepages, and doesn't necessarily reflect the
actual codeset defined in the IANA charset if the names look the same.
Look at "additional information" for the differences.
Moriyoshi
On Wed, Feb
It just turned out ISO_2022,locale=ja,version=3 is actually ISO-2022-JP-MS.
Moriyoshi
On Wed, Feb 3, 2010 at 10:22 AM, Moriyoshi Koizumi wrote:
> None of them can handle CP50220.
>
> Moriyoshi
>
> 2010/2/3 Tex Texin :
>> icu has at least 5 versions of iso 2022-jp.
None of them can handle CP50220.
Moriyoshi
2010/2/3 Tex Texin :
> icu has at least 5 versions of iso 2022-jp.
>
> http://demo.icu-project.org/icu-bin/convexp
>
> If the one you refer to is not one of these send me the details and I'll log
> it with the icu team.
>
While that is one of the concerns, I don't quite think having multiple
encoding conversion libraries that requires huge RSS makes much sense.
Looking for possibilities to extend ICU itself should be worth a try.
Regards,
Moriyoshi
2010/2/2 KITAZAKI Shigeru :
> Koizumi-san
>
> L
The exclusion is rather intentional as it
has major problems in its design.
Moriyoshi
On Tue, Feb 2, 2010 at 9:00 AM, Tex Texin wrote:
> It can also be that you keep the existing conversions and call out to icu
> for others...
>
>
>
> -Original Message-
> From: St
of course supports GB18030. See
http://github.com/moriyoshi/mbstring-ng for detail.
Regards,
Moriyoshi
2010/1/28 KITAZAKI Shigeru :
> We made a patch to add a mbfilter for GB18030 encoding for PHP-5.3.1.
> Please take a look at our blog:
> http://developer.cybozu.co.jp/oss/2010/01/
Are you sure that $text was really encoded in UTF-8 when the output
was garbled? try dumping bin2hex($text) to see if there's any
difference.
Regards,
Moriyoshi
2009/10/2 Jarosek :
> Hello
>
> I noticed a problem using iconv, but investigation showed, that this is
> not exectly
s a wrong UTF-8 byte sequence,
it fails and then return false.
Moriyoshi
2009/3/23 Valkum :
> When i follow the way on:
>
> http://bugs.php.net/bugs-generating-backtrace.php
>
> i get this:
>
> Core was generated by `/usr/bin/php ./test.php'.
> Program terminated with signal
Hi,
That appears to be a PCRE's problem.
Try running it on gdb following the instruction:
http://bugs.php.net/bugs-generating-backtrace.php
Regards,
Moriyoshi
2009/3/22 Valkum :
> Hello,
>
> i have a big problem.
>
> When i try to encode a big string to utf8 i got a core dum
Hi,
mb_check_encoding() without the first parameter is never supposed to
work properly.
I'm thinking of removing this feature.
Regards,
Moriyoshi
On Sat, Mar 21, 2009 at 7:10 AM, Giacomo Mazzocato wrote:
> if (mb_check_encoding()) {
> echo "request encoding ok" ;
> }
lable since php 5.0.
Regards,
Moriyoshi
Cipriano Groenendal wrote:
> Hello all,
>
> My name is Cipriano Groenendal, and I'm the maintainer for
> pear.php.net's Mail_Mime package. I'm trying to make the mails
> generated by this package compatible with non ISO-8869-1
the original Unicode string is somewhat pointless and
it has to be done on the byte sequence converted to the intended
encoding (script_encoding / output_encoding) instead. Thus the mentioned
issue wouldn't exist basically.
Moriyoshi
--
小泉 守義 <[EMAIL PROTECTED]>
--
PHP Unicode &
eat! Could you send me a diff against the source in CVS? I'm going to
merge it.
Regards,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
using glibc's
mutex locking facility. The same may not apply to other platforms.
Moriyoshi
===
Make sure you check your webserver configuration before deciding
to use gettext, because if you are running in a multi-threaded
environment you
ility and your web server is threaded.
If you are using recent glibc and Apache 2.0 with prefork
MPM, it will most likely work just fine with it.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
i've tried again with this turned off, just to be sure i didn't mess
up here, but still the same - without the "foreign" characters in
mb_ereg_replace output.
Actually this had little to do with your problem. It was just FYI stuff.
Regards,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
oding = UTF-8
mbstring.http_input = UTF-8
mbstring.http_output = UTF-8
mbstring.encoding_translation = On
mbstring.substitute_character = _
mbstring.func_overload = 7
If http_input equals to internal_encoding then you don't need to turn
on encoding_translation.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
t settings did you put in your php.ini about mbstring?
Does it contain any part like "mbstring.language" comes after
"mbstring.internal_encoding"?
- http_input was set to UTF-8, SJIS, as was the detect_order.
Which encoding is used for the input data?
Regards,
Moriyoshi
--
PHP Int
nabled (if output_handler is set to
"mb_output_handler")
in your php.ini and turn it off if that's the case.
Also check the value of default_charset setting in the php.ini
AddDefaultCharset off
AddDefaultCharset UTF-8
This apache setting is irrelevant to PHP generated outp
Perhaps you haven't just set mbstring.language to "Japanese" in your
php.ini. Pass strings encoded in the same encoding as specified in
mbstring.internal_encoding to mb_send_mail(). Basically no additional
preparation should be needed.
HTH,
Moriyoshi
On 2004/10/19, at 22:01, Willa
n
Shift_JIS is discouraged.
If you really want to do so, It'd be better to use the zend-multibyte
feature.
Specify --enable-zend-multibyte to configure at build time and setting
mbstring.script_encoding to Shift_JIS in your php.ini.
HTH,
Moriyoshi
--
PHP Internationalization Mailing List (htt
ltex.jp/articles/imagettf_m10n/
- http://www.unicode.org/charts/PDF/U2500.pdf
- http://www.unicode.org/charts/PDF/U2580.pdf
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
UTF-7 IMAP encoding by default.
Regards,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
commands:
$ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot login
(Just press enter for the password prompt)
$ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot co php-i18n
Guys who want to take part in the development, please let me know.
I'll create cvs accounts for you.
Regards,
Moriyoshi
--
PHP Internat
t;n tilde"
doesn't need to be encoded at all, does it?
They don't have to be entitized, as the core idea behind HTML entitiy
is to represent
various characters in a document written in a legacy character set
which are not always
available across any other character se
On 2004/02/11, at 1:45, a.h.s. boy wrote:
When using Spanish, Swedish, etc files, however, many of the
translators have converted the text strings to HTML entities, e.g.
"español". In one way, this makes sense, since they are to be
displayed on a web page. But is it the right thing to do? Or sh
On 2004/02/10, at 9:39, walter fan wrote:
Hi,Moriyoshi
Thanks for your information. There is a strange thing, I had modified
it to charset=UTF-8, it can not display UTF-8 strings. But I modified
it to charset=CHARSET, it's okay. My server is RedHat Linux7.2.
Perhaps you don't issue
Seems I forgot to CC to the list. Sorry for messing about.
Moriyoshi
From: Moriyoshi Koizumi <[EMAIL PROTECTED]>
To: Hayk Chamyan <[EMAIL PROTECTED]>
Subject: Re: [PHP-I18N] String length
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[EMAIL PROTECTED]>
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
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://w
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
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe,
hen you use SQL
string manipulation functions / operators ("LIKE" / regex comparators)
and FULLTEXT
indexes with such a mismatched setting.
In other words, you can use UTF-8 unless you are planning to use any of
these features.
It's anyway discouraged though.
Moriyoshi
--
PHP Int
d or write either language so I can't even try
it to
see the differences.
Have a look at the documentation of mb_send_mail()
http://www.php.net/mb_send_mail
HTH,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
vendors use different
character mapping table between native character set and Unicode,
which ended up with sort of mass confusion.
Well, maybe enough said. If you want to know further information,
Ken Lunde's CJKV Information Processing [3], published by O'Reilly
would definitely help.
Moriy
First off, you can take a quick look over the archive of this list.
There should be a lot of useful information.
Moriyoshi
p.s. IIRC, the current stable version of MySQL doesn't natively
support UTF-8 encoding. It'd be better to also consider using
PostgreSQL if you really need to us
Hi,
(B
(BTurning off magic_quotes_gpc in your php.ini will fix that problem.
(BWhen doing this, be sure to escape any incoming strings that will be
(Bget through to the database as SQL with a function provided by the
(Bextension with which you actually make connection to the database
(B(e.g.
ake a look over this list's archive, as I posted a pointer to
the resource already.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
e
right way. Things are not that simple at all.
P.S. Please CC me on your replies, I am not subscribed to the list.
Hmm, I think I did.. Maybe I'm not used to Apple mail client yet :)
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
to an array of multibyte characters?
What do you want to do exactly with this idea? I've never been in a
situation
like that...
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Perhaps it'd be better to write a feature request at http://bugs.php.net/ .
I like your idea, but could it be that simple by preparing a function like
__() and using it everywhere instead.
Moriyoshi
>
> Not sure if this is right place for this, but anyways:
>
> Would
Just upgrade your php. 4.2.2 contains some buggy code.
Moriyoshi
Peter Vereshagin <[EMAIL PROTECTED]> wrote:
> Hello.
> I have php-4.2.2
> I have koi8-r encoded string and need to recode it to UTF-8.
> I use iconv() and see strange noise added to a string.
> I played wi
e specified at the third parameter of mail().
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
ommand.)
$ cvs -d:pserver:[EMAIL PROTECTED]:/repository co pecl/kakasi
$ cd pecl/kakashi
$ phpize
$ ./configure
$ make
$ make install
- SYNOPSIS -
BTW I'm not the author of this extension, so I don't seem to be the right
person to ask further questions :)
Anyway, hope this helps.
I guess the issue could be solved by setting default_charset=UTF-8 in
php.ini, or putting the following line
at the top of yourscript script.
Hope this helps.
Moriyoshi
Donal Regan <[EMAIL PROTECTED]> wrote:
> Hello,
> I'm trying to display some japanese characters in a
&
Hi,
Did you try mb_convert_kana()?
http://www.php.net/mb_convert_kana
But this function cannot be used with mbstring.http_input for now.
Moriyoshi
[EMAIL PROTECTED] wrote:
> Hi,
>
> I'm curious if there's any support for "on-the-fly" conversion of
> hankaku&l
n
is not documented yet as far as I know.
> Is there still (if there ever was) a problem with using mb_string and
> setting up my own output handler?
How did you set up the output handlers in your script? I didn't ever
encountered a problem with any combos of mb_output_handler() and
Hi,
I don't know anything about mssql, but as for htmlspecialchars() you have
to pass a correct charset name to the function to get it working.
Moriyoshi
"Filip De Graeve" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Using PHP 4.3.1 on a Windows 2k/Apache,i am tr
r "\" sign. I saw such redundant spaces in
your first mail in the thread.
Moriyoshi
"Patrick T. Tsang" <[EMAIL PROTECTED]> wrote:
> Dear Moriyoshi,
>
> surely I had restarted apached for each new configuration.
>
> If I just include --enable-mbstring=all
;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
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
t;,
> "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
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 Moriy
nd 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
--
PH
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
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
"
It works for me. See the attached example. Anyway, you don't have to
crosspost your question to [EMAIL PROTECTED], which is for developing
php internals and irrelevant for such user questions.
Hope this helps
Moriyoshi
"Michel Sahyoun" <[EMAIL PROTECTED]> wrote:
Just correcting a typo :)
Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote:
> mb_internal_encoding("Shift_JIS");
> $escaped = mb_ereg_replace("([\\\"'\0])", "1", $sjis_string);
> ?>
should be
Moriyoshi
--
PHP Internationalizatio
dows), and
CP950(big5, used in the traditional Chinese version of Windows).
However, as of the current implementation, the character sets / encodings
mentioned above are not supported by the zend multibyte stuff.
Hope this helps,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Jean-Christian Imbeault <[EMAIL PROTECTED]> wrote:
> Moriyoshi Koizumi wrote:
> >
> > Partially yes.
> >
> > Strings encoded in GB2312(CP936), big5, Shift_JIS are known to be
> > clobbered by addslashes().
>
> Sh*t ... and I just added a whole b
d by addslashes().
UTF-8, EUC-JP, EUC-KR, EUC-CN and EUC-TW are not affected.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 28 Feb 2003 14:43:38 +0100
(B"Simon Dedeyne" <[EMAIL PROTECTED]> wrote:
(B
(B> >
(B> I haven't tried the mb_ereg solution yet, but I thought of doing something with
(B> mb_convert_kana()
(B> Here's a little example script. I try it, but nothing gets converted at all! (I have
(B> mb
se they have
nothing at all to do with PHP itself. As it's unlikely that you'll get
plenty of responses from Chasen experts here, I think it'd be better if
you contacted to the author directly.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
with mb_convert_kana() and then comparing
it with the original.
Also try mb_ereg_* functions that allows localised characters to be used in
character classes.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
) namazu: http://www.namazu.org/index.html.en
Moriyoshi
Gary Ross <[EMAIL PROTECTED]> wrote:
> hello All,
> I'm new to the list!
> I'm wondering if anyone has information about indexing/splitting
> Japanese text strings in a mysql/php environment. So
> korehanihongod
Jan Schneider <[EMAIL PROTECTED]> wrote:
> Moriyoshi Koizumi wrote:
> > 1. libiconv is basically far better at transliteration than glibc iconv.
> >
> > 2. glibc iconv supports yet another external option.
> >See http://bugs.php.net/20809
> >
> >
your websites ready for Japanese
language, using mbstring's function overloading feature should always be
discouraged. It's likely to cause various unknown problems due to slight
diferrences in the function specs.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
1. libiconv is basically far better at transliteration than glibc iconv.
2. glibc iconv supports yet another external option.
See http://bugs.php.net/20809
Hope this helps.
Moriyoshi
Jan Schneider <[EMAIL PROTECTED]> wrote:
> Hi,
>
> does anybody have some experience o
overs Japanese letters...
> Will I need to increase the field size of MySQL fields to accomodate
> the extra bytes used in mb strings? Do I need to change MySQL's default
> encoding? What if that MySQL server is also used by others who aren't
> using Japaense?
UT
about detecting the type of input characters and rejecting the
malformed user inputs on the server side?
Moriyoshi
Simon De Deyne <[EMAIL PROTECTED]> wrote:
> I'm not sure if this is as PHP as it should be but I have a question about
> forms and language. I use a page with a fo
Tony Laszlo <[EMAIL PROTECTED]> wrote:
> On Sat, 1 Feb 2003, Moriyoshi Koizumi wrote:
>
> > > (as you can see from the top page here:
> > > http://www.issho.org/ , pretty much every language - and
> > > encoding - out there, needs to be supported).
>
erred. :)
> Is there not such a way?
Since encoding detection is essentially heuristic and thus its
accuracy depends on the number of likely candidates given in the first
place, there is no way to guess a right encoding out of any possible
encodings from limited length of st
s an alias
> MK> for the standard mail() function, though it's undocumented yet...
>
> Yes. But I may use some another software, like forum or CMS.
Okay, it sounds like a valid reason to me. I'm going to add that feature.
BTW, I'd be glad if you would put your request at http:
oaded.
Do you mean a case where mbstring.func_overload is enabled in
php.ini? If so, you can use mb_orig_mail() that is prepared as an alias
for the standard mail() function, though it's undocumented yet...
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
t; Last 3 lines added by MBString.
Good point. But isn't it easy thing to avoid this problem by not
appending those headers that are supposed to be appended by mbstring?
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
It turned out to be a genuine bug, and now fixed in CVS snapshot.
Thanks for the report.
Moriyoshi
Hayk Chamyan <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> MK> What if prepending a single line
> MK> mb_language("uni");
> MK> right before the mb
language("uni");
right before the mb_send_mail() call?
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
n use preg_* functions as well if your scripts use UTF-8 only.
Regards,
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> I needs to use the above sort of lines
> to convert rss feeds of _all_ possible
> encodings and to one encoding: utf-8 .
>
How about passing multiple encoding names to mb_convert_encoding()?
mb_convert_encoding($str, "UTF-8", array("ISO-8859-15", &
This topis has at all nothing to do with php internationalization
that this list is for. Please forward this to [EMAIL PROTECTED]
Moriyoshi
On Thu, Jan 16, 2003 at 07:46:20AM -0500, bda wrote:
> I have an issue that I am trying to solve. I can script this problem using
> fixed length
y the answer. So I assume that the mbstring extension has
> the modified utf-7 charset encoding as defined in rfc 2060 internally
> implemented?
Yep. mbstring extension makes use of a bundled library named "mbfilter",
and doesn't rely on any external libraries.
Moriyoshi
--
PH
; Just to clarify: utf7-imap is an official or at least supported charset
> name?
Although I still wonder if this is the exact answer to your question,
IMAP version of utf-7 is defined in RFC2060 but there's no entry for it
in IANA charset registry.
Moriyoshi
--
PHP Internationaliza
vert_encoding("blahblah", "utf7-imap", "iso-8859-15");
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
> I have to say no. It's too libc dependent, and most libc including
> msvcrt doesn't handle them correctly.
I meant by this "most libc including msvcrt don't handle multibyte
characters correctly :-)
Moriyoshi
--
PHP International
of the current PHP documentation is difficult for the non-expert
> to understand. I review web design books on a regular basis, and a
> leading computer publisher has told me it is very interested in
> including more on i18n and l10n in its publications, so this could serve
> a dual
On Thu, Jan 09, 2003 at 06:20:32PM +0100, Jan Schneider wrote:
> The subject says all. Is it?
I have to say no. It's too libc dependent, and most libc including
msvcrt doesn't handle them correctly.
I'm planning to work on this issue.
Moriyoshi
--
PHP Internationalization
ese would be useful.
Hmm... English information about Japanese text handling with PHP is very
limited since a small number of developers who fluently speak English
use Japanese or other east-asian languages in his/her project, and since
I don't have much time to add more explanation to the manual. I think
all I can do for now is fill up this list's archive with (hopefully) detailed
mails.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
is Postgres a better
> database solution than MySQL for supporting Japanese?
No significant changes have been made between these versions. All that
the mbstring developers did is bug fixing.
And I can't tell which database application is better at Japanese text
handling. I mean it's just up to your preference.
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
of PDF files.
Check out the following URL: http://www.net-newbie.com/support/pdf2
(Texts are written in Japanese)
Moriyoshi
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
: EUC-JP)
Regards,
Moriyoshi
"a.h.s. boy" <[EMAIL PROTECTED]> wrote:
> On Wednesday, December 4, 2002, at 01:37 PM, Renato De Giovanni wrote:
>
> > What happens is that "htmlspecialchars" seems to be always returning a
> > latin1 string, therefore
Hi Renato,
Hmm, I mistook your purpose somewhat...
I've just looked into the source codes but no related bugs have been found,
as I was also working on the improvement of htmlspecialchars() and
htmlentities() a month ago.
Moriyoshi
"Renato De Giovanni" <[EMAIL PROTEC
Hi,
If you want to do the full entity translation, use htmlentities() instead
of htmlspecialchars()
http://www.php.net/htmlspecialchars
Moriyoshi
"Renato De Giovanni" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We're working on a program that needs to generate an
Take a look at http://www.php.net/manual/en/ref.gettext.php
This appears exactly what you are looking for, while your idea is as good.
Moriyoshi
"Steve Vernon" <[EMAIL PROTECTED]> wrote:
> Hiya,
> I'm working on my first international PHP project, which is a site
> Currently mbstring doesn't support Armenian character maps, and only iconv
> extension with libiconv and glibc 2.3(IIRC) offers that functionality.
Sorry, my bad English ... All you need is libiconv *or* glibc(>=2.3) iconv.
Moriyoshi
>
> But AFAIK ArmSCII-8 encoding is a
ease.
Your contribution is greatly appreciated.
Moriyoshi Koizumi
Hayk Chamyan <[EMAIL PROTECTED]> wrote:
>
> Hi All.
> Is it possible to add the ArmSCII-8-to-UTF-8 charset conversion to the MB String
>extension?
>
> --
> Best regards,
> hayk
> mailt
93 matches
Mail list logo
