Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm not able to run a PHP enabled web site under Apache on Windows XP if the path to DOCUMENT_ROOT contains accented letters. I'm not referring to the script file names themselves but to any folder in the path components.

I have this virtual host definition:

<VirtualHost *:80>
 ServerName foo.local
 DocumentRoot "E:/gonzález/sites/foo"

 ErrorLog logs/foo.local-error.log
 CustomLog logs/foo.local-access.log combined

 <Directory "E:/gonzález/sites/foo">
  AllowOverride All
  Options Indexes FollowSymLinks

  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>
  • If I save the file in ANSI I get a syntax error: DocumentRoot must be a directory
  • If I save the file in Unicode I get another syntax error: Invalid command '\xff\xfe#', perhaps misspelled or defined by a module not included in the server configuration (looks like it's complaining about the BOM)
  • If I save the file in BOM-less UTF-8 Apache works fine and it serves static files with no apparent issue...

... however, PHP complaints when loading any *.php file (even an empty one):

Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0
Fatal error:  Unknown: Failed opening required 'E:/gonzález/sites/foo/vacio.php' (include_path='.;C:\Archivos de programa\PHP\pear') in Unknown on line 0

I decided to try the 8+3 short name of the directory (just a test, I don't want to use such a workaround):

<VirtualHost *:80>
 ServerName foo.local
 DocumentRoot "E:/GONZLE~1/sites/foo"

 ErrorLog logs/foo.local-error.log
 CustomLog logs/foo.local-access.log combined

 <Directory "E:/GONZLE~1/sites/foo">
  AllowOverride All
  Options Indexes FollowSymLinks

  Order allow,deny
  Allow from all
 </Directory>
</VirtualHost>

But I get the same behaviour:

Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0

Fatal error:  Unknown: Failed opening required 'E:/gonzález/sites/foo/vacio.php' (include_path='.;C:\Archivos de programa\PHP\pear') in Unknown on line 0

While there're obvious workarounds (use plain ASCII in all directory names or create NTFS junctions to hide actual names) I can't believe that this cannot be done. Do you have more information about the subject?

My specs include 32 bit Windows XP Professional SP3, Apache/2.2.13 and PHP/5.2.11 running as Apache module (but I've noticed the same issue in another box with Windows Vista and PHP/5.3.1).

Update

I'm using NTFS and the Windows codepage is Win-1252 (it's a Spanish lang version of Windows). Perhaps it's relevant :-?

Update #2

I remark that I'm not having problems with PHP includes or requires, include_path or any other PHP piece of code. My problem is that the PHP interpreter will not find the PHP script itself, even if it's a static HTML document with *.php extension.

Update #3

Upon further reading, it appears the PHP does not use the double-byte functions provided by the Windows API. Unless I got it wrong, this seems to prove that what I want to do is just not possible.

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

It seems that Apache resolves the path to it's long version before passing it to PHP encoded in UTF-8. PHP file functions use the ANSI API of Windows and is unable to deal with Unicode in filenames.

I remember facing a similar problem with Apache/PHP. One solution would be to create some sort of NTFS symbolic link to your folder using a name that solely avoids Unicode characters.

eg.: E:\sites => E:\gonzález\sites

NTFS symbolic link on Wikipedia: http://en.wikipedia.org/wiki/NTFS_symbolic_link

You can get the mklink.exe utility from Microsoft to create such links from the command-line: http://technet.microsoft.com/en-us/library/cc753194(WS.10).aspx

You could try the following command:

mklink /D E:\sites E:\gonzález\sites

Link Shell Extension is a free software that integrates with Windows shell to manage symbolic links on NTFS volumes (you'll find the link in the Wikipedia article above, or you can lookup for "Link Shell Extension" on any good search engine).

share|improve this answer
    
This seems to be the naked truth: on Windows, non-ASCII characters in paths are simply not supported by mod_php (just like regular spaces were not supported in very old PHP versions if I recall correctly). Sorry for taking so long to tag as accepted, I could simply not believe it :) — BTW, the issue still exists on PHP/5.5.8. –  Álvaro G. Vicario Jan 31 at 13:33
add comment

Works fine for me with Apache/2.2.8 and PHP/5.2.5 in the UK, require() encoded in ANSI/UTF-8/UTF-8 +BOM.

I just copied your example (E:/gonzález/) from this page, created the test script (ANSI, worked OK) then tested the various encodings. Perhaps you could try the same method?

share|improve this answer
    
Although we don't seem to be testing the same thing (I'm not including files inside PHP, I just can't execute a blank *.php file) it looks like PHP does work for you under "E:/gonzález/" . Any idea of what the difference can be? What's your file system and Windows codepage? –  Álvaro G. Vicario Mar 17 '10 at 13:13
    
new cmd.exe > chcp gives me 850, although I'm not sure this is reliable. FS is NTFS. What happens if you repeat my test? If you pass then perhaps it's an apache setting somewhere. –  Andy Mar 18 '10 at 13:46
    
850 is the DOS code page (mine is the same). I cannot test require() since the PHP interpreter won't even find the main file. –  Álvaro G. Vicario Mar 18 '10 at 15:12
    
Change your apache documentroot to something that'll process, then try the full include path in the script –  Andy Mar 20 '10 at 0:08
    
I've set the DocumentRoot directory in the PHP include_path directive (I've tried both httpd.conf and php.ini) but it makes no difference. PHP does not use include_path to find scripts. –  Álvaro G. Vicario Mar 22 '10 at 8:41
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.