From: ryomanhattan at yahoo dot com Operating system: NT, Linux PHP version: 4.3.8 PHP Bug Type: Performance problem Bug description: Multilingual built in intelligence
Description: ------------ Hi, I have recently developed multiligual membership website using php & mysql, including Japanese, English and Estonian. User language choice is selected either by language cookie(user's option) or ip(automatic choice using comparison script to detect user's ip and choose the encoding accordingly upon loading the index.php). User can click on the names of registered members appears in subsequent pages to learn about their profiles, simply targetted such as: index.php?id=profile&$name=smith It works fine if the names are commonly shared characters in respective encoding mode for the browser at this action. However, the problem arises if the target username was entered in Japanese characters, but the current user is using English encoding mode. For example, it will appear like below and php will output blank screen since it cannot resolve to the non-existing target in English encoding mode. index.php?id=profile&$name=管理人 At this point, if the user manually changes the encoding mode to Japanese, then it goes through since now the browser encodes this "管理人"(means "admin" in Japanese BTW) into meaningful Japanese characters as existing target in Mysql database and it parses and resolves it without a problem. My question here is that why php cannot intelligently detects this invalid target characters for the current encoding mode before parsing it and give meaningful output instead of blank page? Such as; a) Parsing error! Target cannot be resolved in the current encoding mode. b) Check if the user has relevant encoding installed or not first then switch the encoding system before parsing it. If not then give an error. Or, may be there is a way to detect the contents of the current page prior to the loading whether there are invalid characters in the current encoding mode and warn user to switch the encoding before dsplaying that page from the scripting side? Thanx for your time. Ryo 管理人 Reproduce code: --------------- index.php?id=profile&$name=管理人 Expected result: ---------------- a) Parsing error! Target cannot be resolved in the current encoding mode. or b) Check if the user has relevant encoding installed or not first then switch the encoding system before parsing it. If not then give an above error. Actual result: -------------- Blank Screen -- Edit bug report at http://bugs.php.net/?id=31016&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31016&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31016&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31016&r=trysnapshot51 Fixed in CVS: http://bugs.php.net/fix.php?id=31016&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=31016&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31016&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31016&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31016&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31016&r=support Expected behavior: http://bugs.php.net/fix.php?id=31016&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31016&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31016&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=31016&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31016&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=31016&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31016&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31016&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31016&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=31016&r=mysqlcfg
