VolCh

Лучше так не делать вообще - карма портится.

Указано "под Windows у которой кодировка CP1251" (это какая, кстати, 95-ая? ), а не под "веб-сервером". Да и проблема к локали демона или сервиса веб-сервера никакого отношения не имеет. Есть четыре субъекта (ОС, веб-сервер, php, сторонний софт типа ftp-сервер) и один объект (файловая система). ОС только задает дефолтные локали для веб-сервера, php и ftp-сервера, веб-сервер в проблеме не участвует, файловая система Windows хранит имена файлов в UTF-16LE (по факту в любой двубайтовой кодировке, но это вообще экзотика), если пользователь работает с другой, то задача стороннего приложения конвертировать имя файла перед записью в UTF-16LE. Если же стороннее приложение не хочет этого делать, а нашему приложению (php в нашем случае) нужно корректно показывать пользователю файлы, то наше приложение должно как-то догадаться о том, какая кодировка использовалась для записи и переконвертировать его (если вообще получится прочитать) в ту, которую отдаёт пользователю. Если в каталог пишут разные приложения, использующие разные кодировки, то единственный выход - эвристики, но нужно понимать, что 100% угадывания они могут не давать, особенно на коротких строках, которыми обычно являются имена файлов. Если же известно что сторонние приложения пишут в одной известной кодировке, то лучше и нашему приложению писать в ней же.

Нет обычно такого понятия как "кодировка файловой системы". Имя файла для ОС (ядра, драйвера, ФС) - набор байтов, программы сами решают в какой кодировке показывать или отображать. Если нужно показать пользователю имя файла, записанного неизвестной программой, с большой вероятностью не следующей соглашениям о кодировках, то нужно или знать в какой кодировке пишется, либо спрашивать у пользователя, либо применять эвристики для определения кодировки. Но на коротких именах эвристики часто очень плохо работают, если не стоит выбор лишь из двух кодировок. В любом случае при использовании больше одной кодировки в предполагаемом окружении все операции с файлом нужно приводить к одному внутреннему представлению, обычно какому-нибудь варианту Unicode, а перекодировку осуществлять в обёртке над физическим уровнем, и пользоваться исключительно ею - физические вызовы API ОС осуществлять исключительно в обёртке. Вообще это хорошая практика для любых действий с файлами и прочим вводом-выводом - в любой момент может потребоваться расширение (типа логирования), изменения (типа перенаправления) или отмены деволтного поведения дефолтной ОС с дефолтной файловой или иной системы хранения.

Сначала нужно определиться какой именно областью разработки каких именно сайтов хочется заниматься. Сейчас это слишком обширная область чтобы быть специалистом по разработке сайтов вообще. Даже если ограничиться исключительно вёрсткой (не говоря о полноценной фронт-енд разработке), то набор технологий и методологий слишком обширен, чтобы на приемлемом уровне владеть ими всеми. Если основной мотив возврата в разработку - желание зарабатывать, то начинать нужно с анализа вакансий/фриланс-заказов, что в них требуется, то и изучать.

Во-первых, при загрузке файлов больше указанного в upload_max_filesize размера устанавливается ошибка $_FILES['fileToUpload']['error'] === UPLOAD_ERR_INI_SIZE. Во-вторых, при размере формы большей post_max_size переменные $_POST и $_FILES вообще пустые. То есть проверка должна быть вроде <?phpif (strtoupper($_SERVER['REQUEST_METHOD']) === 'POST') { if (empty($_FILES) && empty($_POST)) { exit ("Form size more than " . ini_get('post_max_size')); } if ($_FILES['fileToUpload']['error'] !== UPLOAD_ERR_OK) { if ($_FILES['fileToUpload']['error'] === UPLOAD_ERR_INI_SIZE) { exit ("File size more than " . ini_get('upload_max_filesize')); } else { exit ("Some file upload error: " . $_FILES['fileToUpload']['error']); } } // обработка загрузки} else {// обработка не POST-запроса}

Всё-не всё, но очень многое делают на пхп в фэйсбуке и в вконтакте. Мало того, что те, что другие, разрабатывают свои реализации пхп-транслятора. На днях наткнулся на статистику: больше всего востребованы в мире среди программистов джависты и пехепешники. Но это чисто количественно - качества вакансий, например зарплаты, статистика не отражала. И конкуренцию тоже. А так, лучше всего писать на том, что нравится - нормальный спец без хлеба с маслом не останется. ЧТо касается питона, то субъективно сложно найти на нём работу не имея опыта, с пехепе это проще. А, главное, не забываете, что программируем мы не на языке, а с помощью языка.

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

Смущает эта строка. Вроде сервер её всегда формирует, просто она может быть пустой, что в итоге и получается. Сравнивайте не только что её нет, но и что она пустая (равна "" или длина равна нулю, или первый байт равен 0x00).

Быстрее по ресурсам - может быть. Проще - точно нет. Написать регулярку выбирающую хотя бы какой-то один тег (аналог css-селектора tag) ой как не просто - только навскидку нужно учесть: комментарии, скрипты и CDATA.

Неправильно парсить html регулярками, используйте работу с DOM.

Запустите файл <?phpphpinfo();

Основное назначение функции htmlspecialchars - обработка сырых данных перед выводом пользователю. Считали сырые данные из базы, файла, входных параметров - перед выводом в html обрабатываем их htmlspecialchars, если не уверены, что считали готовый html. В базу можно (и нужно) смело писать без htmlspecialchars почти всегда. Хранить в базе html обычно плохая идея.