Bug #70892 [Nab]: does not show error text

Edit report at https://bugs.php.net/bug.php?id=70892&edit=1 ID: 70892 Updated by: ab@php.net Reported by: y dot korotia at hotmail dot com Summary: does not show error text Status: Not a bug Type: Bug Package: Filesystem function related Operating System: Win 8.1 x64 PHP Version: 5.6.15 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2015-11-13 15:15:59] y dot korotia at hotmail dot com 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 ------------------------------------------------------------------------ [2015-11-11 17:04:32] ab@php.net 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. ------------------------------------------------------------------------ [2015-11-11 17:01:07] ab@php.net 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. ------------------------------------------------------------------------ [2015-11-11 16:43:54] y dot korotia at hotmail dot com 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 ------------------------------------------------------------------------ [2015-11-11 16:24:30] y dot korotia at hotmail dot com 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=70892 -- Edit this bug report at https://bugs.php.net/bug.php?id=70892&edit=1