php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31016 Multilingual built in intelligence
Submitted: 2004-12-08 11:14 UTC Modified: 2004-12-08 17:37 UTC
From: ryomanhattan at yahoo dot com Assigned:
Status: Not a bug Package: Performance problem
PHP Version: 4.3.8 OS: NT, Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ryomanhattan at yahoo dot com
New email:
PHP Version: OS:

 

 [2004-12-08 11:14 UTC] ryomanhattan at yahoo dot com
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=?Ǘ??l

At this point, if the user manually changes the encoding mode to Japanese, then it goes through since now the browser encodes this "?Ǘ??l"(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

?Ǘ??l



Reproduce code:
---------------
index.php?id=profile&$name=?Ǘ??l

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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-08 17:37 UTC] iliaa@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Use the mbstring extension when dealing with multibyte character sets.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 08:01:28 2024 UTC