php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #31017 Multilingual built in intelligence
Submitted: 2004-12-08 11:17 UTC Modified: 2004-12-08 11:22 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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ryomanhattan at yahoo dot com
New email:
PHP Version: OS:

 

 [2004-12-08 11:17 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

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-08 11:22 UTC] derick@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 08:01:27 2024 UTC