php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #67815 strtolower/upper should be locale unaware for Turkish I
Submitted: 2014-08-09 18:44 UTC Modified: 2014-08-11 18:43 UTC
From: ongun dot kanat at gmail dot com Assigned:
Status: Not a bug Package: Strings related
PHP Version: 5.5.15 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
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: ongun dot kanat at gmail dot com
New email:
PHP Version: OS:

 

 [2014-08-09 18:44 UTC] ongun dot kanat at gmail dot com 
Description:
------------
There are many applications written that uses strtoupper/strtolower like phpMyAdmin. The Turkish 'I','i' causes errors in these applications since strtolower and strtoupper rejects the 'I'->'i'/'i'->'I' conversation on systems with locale "tr_TR.UTF-8". The function may be locale unaware.

Test script:
---------------
<?php
header("Content-type:text/plain; charset=UTF-8");
echo strtolower("I") . "\n" . strtoupper("i");

Expected result:
----------------
i
I

Actual result:
--------------
I
i

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-10 07:36 UTC] fa@php.net 
Related bugs: 

https://bugs.php.net/bug.php?id=18556
https://bugs.php.net/bug.php?id=21771
https://bugs.php.net/bug.php?id=18556
https://bugs.php.net/bug.php?id=29955

Maybe there should be a FAQ entry on the wiki?
 [2014-08-11 14:11 UTC] ongun dot kanat at gmail dot com 
I looked the bug below and found that the issue is 12 years old bug!
https://bugs.php.net/bug.php?id=18556
Although it's tagged closed and in the last comment [jpauli at php dot net] said it is fixed, it still exists.
There is a RFC in wiki but it is about mbstring plugin as I see.
https://wiki.php.net/rfc/multibyte_char_handling?s[]=turkish

Maybe the functions strtolower/strtoupper would work for ASCII as default and a locale parameter for other charsets. It will solve the most of the class loading problems in Turkish locale.
 [2014-08-11 18:43 UTC] nikic@php.net
-Status: Open +Status: Not a bug
 [2014-08-11 18:43 UTC] nikic@php.net 
strtolower and strotoupper work according to the current locale. The Turkish locale has that weird behavior, so that's what you get.

The referenced bugs are not referring to strtolower/strtoupper, but to lower-casing used for case-insensitive comparison of function names and other identifiers. That was a bug and was fixed by using a locale-independent lower-casing function.

My general recommendation is to avoid locales and locale-dependent functions, as locales are a fundamentally broken concept.
 [2014-08-11 23:22 UTC] ongun dot kanat at gmail dot com 
I know that it is not a bug. That is the why I opened this issue as "request".

I also know that str* functions work locale dependent and try to avoid them in the applications I code or explicitly setting en_US or tr_TR as parameter in functions. Yet there are lots of software uses str* functions to include its files, to change its mapped arrays' keys with these functions not only for loading class-names. Fixing the strtouppers in every software I download is utterly annoying. There should be a workaround which utilizes a locale-independent strtoupper/lower or another functions. A php.ini setting would be awesome.

To avoid locales I have to change my system configuration and obviously I don't want to change it to en_US.UTF-8 or something else. As [cankoy at ymail dot com] said in https://bugs.php.net/bug.php?id=18556 changing LC_CTYPE or something else does not solve anything.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Apr 26 20:01:27 2025 UTC