Я столкнулся с той же проблемой, провел некоторое исследование и пришел к следующему выводу. Это для php5 в Windows; это, вероятно, верно для других платформ, но я не проверял.
ВСЕ функции файловой системы php (dir, is_dir, is_file, file, filemtime, sizes, file_exists и т. д.) принимают и возвращают только имена файлов в ISO-8859-1, независимо от набора default_charset в программе или ini файлах.
Если имя файла содержит символ Юникода, dir-> read вернет его как соответствующий ISO- 8859-1 символ, если он есть, иначе он заменит вопросительный знак.
При ссылке на файл, например, в is_file или файле, если вы передадите имя файла UTF-8, файл не будет найден, если имя содержит любые двухбайтовые или более символы. Однако is_file (utf8_decode ($ filename)) и т. Д. Будет работать при условии, что символ UTF-8 представлен в ISO-8859-1.
Другими словами, PHP5 не может обращаться к файлам с многобайтовыми символами в их именах.
Если запрашивается URL-адрес UTF-8 с многобайтовыми символами и он соответствует непосредственно файлу, PHP выиграет t иметь возможность открыть файл, потому что он не может адресовать его.
Если вам просто нужны красивые URL-адреса на вашем языке, предложение использовать mod_rewrite кажется хорошим.
Но если вы сохраняете и извлекаете файлы, загруженные и загруженные пользователями, эта проблема должна быть решена. Один из способов - использовать произвольное (не UTF-8) имя файла, такое как увеличивающееся число, на сервере и индексировать файлы в базе данных или XML-файле или в каком-либо подобном. Другой способ - хранить файлы в самой базе данных как BLOB. Другой способ (который, возможно, легче увидеть, что происходит, и который не вызывает проблем, если ваш индекс будет поврежден), - это самостоятельно закодировать имена файлов - хороший метод - urlencode (sic) всех ваших входящих имен файлов при хранении на сервере. disk и urldecode их перед установкой имени файла в mime-заголовке для загрузки.
Я знаю для факта, сам PHP может работать с URL Unicode, потому что я попытался использовать названия страницы Unicode в MediaWiki (основанный на PHP, также Википедия выполнений), и это действительно работает. Например, URL такой как/index.php/Page_name©. Таким образом, PHP может обработать его. Но это может быть проблема с Apache, находящим файл, где исходный файл имеет имя UTF-8.
Установка PHP.ini для кодировки символов не должна влиять на это; это - задание веб-сервера, чтобы найти определенный ресурс и затем назвать PHP, после того как это полно решимости быть файлом PHP. Это будет означать, что веб-сервер и сама базовая файловая система, должны смочь иметь дело с именами файлов UTF-8.
Это работает без правила mod_rewrite? Т.е., если Вы отключаете переписать механизм с RewriteEngine прочь и затем запрашиваете va.in/utf_dir/utf_file.php? Если так, затем это может быть проблема конфигурации mod_rewrite или проблема с правилом.
Unicode в URL не может правильно поддерживаться в некоторых браузерах, когда Вы просто вводите адрес, такой как более старые браузеры. Более старые браузеры могут пропустить шаг кодировки UTF-8. Это не должно препятствовать тому, чтобы он работал, если Вы переходите по ссылке на странице, где та страница является закодированным UTF-8, все же.
Просто, потому что набор символов является UTF-8, не означает, что он поддерживает все более высокие символы Unicode.
Поддержка Unicode является одним из основных дополнений, происходящих в PHP 6, и PHP 5 является nutorious для недостатка unicode поддержка.
Если Ваш Сценарий PHP генерирует ссылку, это может быть другой вопрос, чем если бы апач интерпретирует URL непосредственно и перенаправляет его.