same with PHP-7rc6

it looks like the nature of this issue is the same as in require() which cannot find file until i use iconv() on filename in utf8 encoded code file like

require iconv('utf-8', 'Windows-1251', 'стартова.php');


p.s.
this is not a critical bug for me, i just play with php, but i find it as a bug

also to get URL path i have to do next

urldecode(iconv('cp1251','utf-8', $_SERVER['REQUEST_URI']))

anyway, i'm stopping to comment on this, looks like a bug house

regards

Thanks for the report. You should use ASCII filenames anyway. But then - the charset you configured for the PHP output and the charset of the actual content you output is different. Same for server or console. Then - if your browser sends the request URL in cp1251 or utf8 makes another difference.

If you're just starting to play with PHP, you definitely should use ASCII for filenames, etc. When you learn more about how charset handling works at various places, you'll be able to configure it a correct way. Fe in this case i'd be rather doing filenames in ascii in any case, and then using some URL rewrite module to produce URLs like http://моя-страница/старт and to route them to a corresponding controller.

Thanks.

ah, and another factor is also whether your PHP source file itself were in the same charset as the filename you're trying to include :) Probably too much for a new comer. So really, you shouldn't over complicate much at the start ...

Thanks.

i'm not newcomer in sense of it. i'm zend certified in php5.3, i'm just started to play with non ascii chars in different places.

as i didn't see php threw me error of bad filename (non ascii chars), your statement "to use ascii filenames" is wrong. i hope you see my point.


about charset of content. content in my files is UTF-8 w/o BOM. php.ini contains defaults (so it is utf-8 too). 

Server cannot send request url in cp1251, because according to rfc3986 and rfc3629  URI is pure ASCII with encoding non ascii chars (maybe i'm wrong here). Url rewrite has nothing to do with PHP itself too.

also, i didn't find option to tell PHP what is my filesystem's codepage.


i don't really understand connection between file content encoding and filesystem codepage (in fact, encoding for filenames) you are trying to point me out.


so, i'll put it back to bug for one more answer


regards

Thanks for the further info. Now,

- the FS encoding is obviously single byte
- you pass UTF-8 encoded filename, convert it back and forth
- PHP throws some error mentioning your filename - the single byte cp1251
- your browser shows content in UTF-8, thus you see ??? for invalid charset

This is only one scenario from many where you can get an issue. Now also think about your cp1251 encoded filenames when they're moved onto some system with say ... japanese locale. It's a nightmare ... That's why I say you should use ASCII filenames and URL routing. But it's your choice after all :) 

This is definitely not an issue in PHP but about how you do it in your script. So please turn to some PHP support channel for the further assistance.

Thanks.

thanks ab for your time.

unfortunately we are in different dimensions. it mostly looks like same "feature" in mysql that almost killed our company. i get it. so i'll stick to your advice for production for sure.

no more distractions from me. it was last-last one. thanks for your time.


regards


p.s.
in comparison ASP.NET works as expected. utf-8 encoded file 'стартова.aspx' SHOWS and it shows readable error message in utf-8 response w/o mumbo-jumbo with codepage windows-1251 
 
- - - -
just for info
- - - -

i did a research and this stuff takes its root from the beginning and still exists, and exists  as "not a bug". so this is a "feature", i assume.

my point is, if PHP doesnt have access to recognize my system codepage then it must give an option to set it during its runtime. Because so far PHP mainly FAILS EVEN TO SHOW ERROR MESSAGE. it simply fails to do it for script files with non-ascii chars in their names. it's 2015y, right? it's php7. to use iconv on every FS function in PHP is not an option too. it simply doesn't help, it only mitigates some errrr, feature stuff, but throws error message is still not shown at all.

dev team needs to do is just convert filesystem names into script encoding when operating within script and vise versa when writing to FS, internally in PHP. and that's all. this 'not a bug' affects almost all FS functions i can remember and must be checked.

in short, this stuff leads to issues like:
- unreadable error messages (in fact, they are not visible at all)
- unreadable filenames in http response (until script's encoding matches FS codepage)
- inability to save files with readable filenames
- inability to include/require scripts
- no cross platform
- strlen() and other functions work with errors