Предположим, что у нас есть файл, содержащий в названии кириллические символы и нам нужно хранить имя этого файла в базе данных. Причем хранить его имя в базе данных нужно в кодировке самой базы данных. Например, для того, чтобы выводить это имя на HTML-страницу или осуществлять поиск по подстроке в этом имени файла.

Допустим, база данных у нас для универсальности в кодировке UTF-8, а файловая система в кодировке CP-1251 (Windows версии до Vista). Налицо проблема: если не знать заранее в какой кодировке файловая система, то нельзя корректно ни отобразить имя файла, ни обратиться к нему, зная его имя в своей внутренней кодировке.

Хотелось бы, чтобы эту самую кодировку можно было получать как-то в runtime из PHP-скрипта, чтобы он был легко портируем с одной операционной системы на другую без каких-либо правок в конфигурации, касающихся этого аспекта.

Paul Yanchenko писал(а):

Налицо проблема: если не знать заранее в какой кодировке файловая система,

бредовая проблема...
НЕ НАДО придумывать проблем и будет счастье

Paul Yanchenko, легко: кладешь в комплект скрипта файл с эталонным кириллическим именем. Дальше понятно?

fStrange, -3. За грубость и не понимание сути проблемы.

Crazy, во-первых, такой способ не элегантен -- таскать внутри, допустим, коробочного ПО пустой файл с эталонным именем не круто.

Во-вторых, для 100% точного определения кодировки необходимо, чтобы эталонный файл содержал достаточно большой набор символов, позволяющий отличить, например, KOI8-r от KOI8-u.

В-третьих, кодировку файловой системы при таком подходе можно получить только перебором, а это уже сразу говорит об ограниченности и неоптимальности решения.

В-четвертых, в идеале хотелось бы не ограничиваться кириллическими кодировками. Например, под той же виндой в зависимости от региональных настроек может использоваться не CP1251, а CP125x. Все эти кодировки легко конвертируются в UTF-8 и обратно, поэтому не хотелось бы от этого отказываться.

Ну и в-пятых, нет вобщем-то 100%-ной гарантии, что эталонный файл представлен в той же кодировке, что и файловая система. Если дистрибутив заливали например по FTP, выставив неверно кодировку, то определим мы в этом случае ту самую неправильно выставленную кодировку.

Учитывая все это, мне видится всяко более элегантным решением хранить кодировку файловой системы в файле конфигурации. Хоть это и требует некоторой настройки при переносе, но это лучше, чем таскать с собой файл и каждый раз определять кодировку его имени... Хотя, я создал эту тему с целью проверить: может быть есть какая-то системная функция, пусть может быть не кросс-платформенная или различная в разных ОС, которую можно было бы использовать для автоматического детекта кодировки ФС?

Paul Yanchenko писал(а):

Ну и в-пятых, нет вобщем-то 100%-ной гарантии, что эталонный файл представлен в той же кодировке, что и файловая система. Если дистрибутив заливали например по FTP, выставив неверно кодировку, то определим мы в этом случае ту самую неправильно выставленную кодировку.

Варианты "а скрипт криво поставили" мне принципиально неинтересны. Поскольку они глушат абсолютно любое решение. Был у меня клиент-маньяк, одержимый идеей "чтобы все работало, даже если случайно стереть один любой файл".

Далее: ты просил решение для кириллических файлов. Для них, навскидку, длина файла с нужным набором символов составит до 10-15. И "перебор" будет представлять собой 2-4 сравнения символов на каждое исполнение.

И тем не менее, мне способ с файлом не нравится, ищу системную функцию...

Скрипт криво не ставили. Задайся вопросом, стал бы ты специально выставлять какую-то кодировку на FTP клиенте, если бы заливал на свой хостинг, к примеру, какой-нибудь форум? Вряд ли.

В моем понимании серверное приложение не должно содержать в названии имен файлов расширенные символы. В противном случае это муветон.

Про сохранение работоспособности при удалении любого файла -- естественно бред. Хотя решение возможно, если все файлы хранить в двух экземплярах, т.е. использовать зеркальный каталог, путь к которому также прописан в PHP include_path.

Paul Yanchenko писал(а):

И тем не менее, мне способ с файлом не нравится, ищу системную функцию...

"Во-первых, у нас не было пороха" (c)

У меня есть ответы на поскипанные вопросы. Но поскольку ты принципиально ищешь другой способ -- не считаю нужным тратить время на их вбивание в сообщение.

Видать не совсем я понял суть проблемы, но разве схватив название файла нельзя его перевести в utf-8 и записать в базу? ну и хранить оригинал как есть, если надо для каких то действий.
я о Multibyte String.

умный в гору не пойдет, умный гору обойдет

зачем, собсснно, русские имена файлов? Не проще переводить из в транслит? тогда и проблемы с кодировкой исчезнут сами собой.

Paul Yanchenko писал(а):

-3. За грубость и не понимание сути проблемы.

попроси 111 человек, пусть будет -333 , не жалко


узковато на траблему смотришь... сразу ограничил себя одним решением, тогда зачем тебе советы вообще?

1. почему не транслитерировать название (с) базиль? или вообще не дать мд5 имя а реалнэйм хранить в базе
тем более что судя по следующим постам ты предполагаешь что кодировок тысячи

2. допустим имя в кириллице(японнице, эстоннице, хохлокацапнице) хрен с ним, цитирую...

Paul Yanchenko писал(а):

хранить его имя в базе данных нужно в кодировке самой базы данных. Например, для того, чтобы выводить это имя на HTML-страницу или осуществлять поиск по подстроке в этом имени файла.

а что функции перекодировки типа iconv кто то отменил?

fStrange, ты либо меня не понимаешь, либо не хочешь понять. Я не ограничиваю себя одним решением, я ищу варианты решения проблемы. Вариант решения предложенный Crazy меня не удовлетворил, поэтому я продолжаю поиск.

Вариант представления, что проблемы нет -- не вариант.

Вариант перекодировать все в транслитеру, во-первых, тоже не вариант (иногда нельзя ничего переименовать и приходится работать с тем, что есть), во-вторых, опять же чтобы транслитерировать -- нужно знать исходную кодировку, а это как раз то, ответ на что я и ищу. Поймите, работа с файлами в PHP не ограничивается функцией Upload на сервер. Я может вообще консольное приложение на PHP пишу... И меня интересует решение этой проблемы в общем, а не в частности.

Функции перекодировки iconv никто не отменял, но повторюсь, чтобы ей пользоваться нужно знать исходную кодировку, о чем и речь.

bE(o0L писал(а):

Видать не совсем я понял суть проблемы, но разве схватив название файла нельзя его перевести в utf-8 и записать в базу? ну и хранить оригинал как есть, если надо для каких то действий. я о Multibyte String.

Что-то меня никто не понимает... Вот представь ситуацию. Тебе нужно прочитать список файлов в некоторой заданной директории и сохранить его в таблице базы данных. Ты делаешь к примеру opendir() и в цикле гоняешь readdir() и делаешь insert в базу на каждом файле. Да только вот не задача. Под Windows XP функция readdir() вернет тебе имя файла в виндовой кодировке (для русской локали это CP-1251), а допустим в линуксе в зависимости от версии тебе имя файла может придти как в кодировке KOI8-R, так и в UTF-8 (бывают также и другие кодировки, линукс в этом плане гибче винды).

А тебе все это для сохранения в БД нужно привести к универсальной кодировке UTF-8. Так вот, чтобы воспользоваться функцией iconv() нужно знать исходную кодировку файловой системы. В том как ее получить и состоит мой вопрос.

Paul Yanchenko писал(а):

Поймите, работа с файлами в PHP не ограничивается функцией Upload на сервер. Я может вообще консольное приложение на PHP пишу... И меня интересует решение этой проблемы в общем, а не в частности.

а.… так это чисто теоретическое изыскание... Мог бы сразу сказать -- лично я бы вообще не напрягался.

Paul Yanchenko, multibyte string. [+ красный цвет и буквы с полэкрана]
mb_detect_encoding($filename) -> должна помочь тебе определить какая кодировка используется в имени файла.

bE(o0L, эта функция работает только на мультибайтных кодировках, то есть она не позволяет определить cp1251 или koi8-r, да и это в общем случае в принципе не возможно.