Edit report at https://bugs.php.net/bug.php?id=63769&edit=1

 ID:                 63769
 Comment by:         anon at anon dot anon
 Reported by:        hanskrentel at yahoo dot de
 Summary:            file:// protocol does not support percent-encoded
                     characters
 Status:             Not a bug
 Type:               Bug
 Package:            Streams related
 Operating System:   Windows
 PHP Version:        5.4.9
 Block user comment: N
 Private report:     N

 New Comment:

>You would have wanted to access it via 'file:///C:/temp/catalog%%25202.xml'

Actually, 'catalog%25202.xml', but I know, I'm agreeing with you. I'm just 
pointing out that this erroneous behavior may be depended on somewhere in some 
PHP script, where the author, in good faith, did whatever made things work. I 
assume you're going to pass your path through urldecode (or not encode it in 
the first place), and then you'll be one of them.

In any case, you're unlikely to get any support here. The reviewers here don't 
do much except dismiss things as 'Not a bug' and once they've successfully done 
that they lose interest. C'est le PHP.


Previous Comments:
------------------------------------------------------------------------
[2013-01-06 01:29:30] hanskrentel at yahoo dot de

If you would create a file named

    catalog%202.xml.

You would have wanted to access it via:

    'file:///C:/temp/catalog%%25202.xml'

which as well does not work. I'm not doing a bug report here to be treated like 
an idiot. I better suggest you piss completely off 
instead of leaving such an idiotic comment. My 2 cents.

------------------------------------------------------------------------
[2012-12-20 16:27:43] anon at anon dot anon

>The path "file:///C:/temp/catalog%202.xml" (without the quotes) does *not* 
>work.

Unfortunately it does work, if you create a file literally named 
catalog%202.xml. PHP's behavior is broken but it's impossible to alter it 
without breaking compatibility.

------------------------------------------------------------------------
[2012-12-17 14:55:51] hanskrentel at yahoo dot de

I beg your pardon, but if both are perfectly valid filenames, the fs function 
behaviour is broken (and not correct), because it does not work with both 
perfectly valid filenames:

The path "file:///C:/temp/catalog%202.xml" (without the quotes) does *not* work.

The request is to remove this shortcoming and have it work. I thought this was 
clear from the initial report. Please let me know how I can further assist with 
this.

------------------------------------------------------------------------
[2012-12-15 11:12:14] a...@php.net

Since both "catalog%202.xml" and "catalog 2.xml" are perfectly valid filenames, 
the fs function behaviour is correct. The user can decide where it's needed url 
encoded and where it's not.

------------------------------------------------------------------------
[2012-12-14 15:51:57] hanskrentel at yahoo dot de

Description:
------------
Using a file-URI containing characters that are percent-encoded (one byte/octet 
is encoded as a character triplet, e.g. Space -> %20) do not work. The URI is 
not properly decoded.

Consider the following file on disk:

c:\temp\catalog 2.xml

PHP is able to find it existing via:

is_file('file:///C:/temp/catalog 2.xml');

However, commonly that file is written as:

file:///C:/temp/catalog%202.xml

And using that filename in PHP via:

is_file('file:///C:/temp/catalog%202.xml');

gives FALSE.

(Example is a libxml catalog file, properly specified for libxml)

When you're looking into this, it might be worth to also look for + as encoding 
for space - just not that this case gets overlooked.




Test script:
---------------
<?php
touch($name = 'catalog 2.xml');
$uri = sprintf('file:///%s/%s', strtr(__DIR__, ['\\' => '/', ' ' => '%20']), 
rawurlencode($name));
printf('%s - %s (%d)', is_file($uri) ? 'OK' : 'FAIL', $uri, unlink($name));

Expected result:
----------------
OK - file:///C:/temp/catalog%202.xml (1)

Actual result:
--------------
FAIL - file:///C:/temp/catalog%202.xml (1)


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=63769&edit=1

Reply via email to