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

Edit report at https://bugs.php.net/bug.php?id=70892&edit=1 ID: 70892 User updated by: y dot korotia at hotmail dot com 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 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 Previous Comments: ------------------------------------------------------------------------ [2015-11-17 23:24:29] ab@php.net 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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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