[EMAIL PROTECTED] wrote: > Hi, > > On Sun, Jan 05, 2003 at 12:20:51AM -0000, David Powers wrote: >> This is a cut-down version of what I now have in my php.ini. As you >> will see, I have commented out the output_handler line. When >> enabled, all I got was mojibake. >> >> output_buffering = On >> ;output_handler = mb_output_handler > > I see no problem in this.
That brings me back to my original query. The PHP documentation says SJIS users should set output_handler to mb_output_handler. Doing so results in mojibake. Turning it off (by commenting it out with the semi-colon) is the only way I can get my pages to display correctly. So, either there is a mistake in the documentation or the explanation of SJIS users needs to be clarified. > Both on Windows and *nix machines you can compose arbitrary > Japanese texts in Shift_JIS, EUC-JP, UTF-8, ISO-2022-JP, or UTF-8 > with appropriate editors, which you can find at numerous sites out > there. This would seem to add an unnecessary level of complication. I am using PHP in combination with MySQL to provide an online database in both Japanese and English. All input is done through a browser interface over the internet, and most - if not all - users are on Windows. PHP seems to do an excellent job of conversion without adding a further layer. > But, I'm afraid that PHP binaries that come up with basic compile-time > configuration (most RPMs, DEBs, and Windows binaries distributed at > the official sites AFAIK) don't support Shift_JIS encoded scripts and > pages. I have just downloaded the Windows binaries for PHP 4.3.0 from a UK mirror site and installed them on my Windows 2000 machine. With the same php.ini settings as on my Linux 6.2, it has run the same Japanese Shift_JIS pages without problem so far. >> based on PHP 4.2.2 and PostgreSQL. Are there any major differences >> between 4.2.2 and 4.3.0 as far as Japanese is concerned? > > No significant changes have been made between these versions. All that > the mbstring developers did is bug fixing. Again, this is where I get confused - or maybe I'm misunderstanding a vital element. The PHP documentation states that as of 4.3.0, --enable-mbstr-enc-trans has been eliminated. Under 4.2.2, I needed to use mb_convert_encoding($_POST['variable'], "SJIS") to gather variables submitted by a form. Now I don't need to. Since Japanese is not my native language, it's not as easy for me to search for information in news groups and websites as it is in English. I intend to study the PDF files you recommended, but I see they were written before --enable-mbstr-enc-trans was eliminated, so any guidance on how this affects the handling of Japanese would be useful. >> Also, is >> Postgres a better database solution than MySQL for supporting >> Japanese? > And I can't tell which database application is better at Japanese text > handling. I mean it's just up to your preference. Understood, but if I take your meaning correctly, Postgres is worth investigating. It's not a bad choice. Sorry to take up so much of your time, but your answers so far have been helpful and are much appreciated. David Powers -- PHP Internationalization Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
