Я специально для вас написал, что iconv() на символе, которого нет в целевой кодировке, перестает конвертить. Причем в php нет возможности изменить это поведение, в отличие от утилиты командной строки iconv.
Мне было бы интересно услышать мнение тех, кто реально это делал, а не теорию вопроса.
Хотя сейчас уточнил, к джаве линуксовый copy-on-write не имеет отношения, только к порождению процессов. К тому же не в ту сторону прочитал цифры линукс vs виндоус.
Ну так это же надо правильно делать: сохранили старый error_reporting, убрали ненужный уровень препреждений (не помню, notice это или варнинг), вернули старый. Всё это выделяется в отдельный класс.
Классы в PEAR достаточно хорошо протестены, у меня лично в основном выдают сообщение о том, что запрещено создавать объекты с помощью =&new, который, тем не менее, работает для обратной совместимости. Поэтому пока свежие классы в стадии альфы (как тот же Http_Request2), старыми можно пользоваться, а сообщения давить с помощью изменения error_reporting.
Другие более-менее проработанные библиотеки всё равно зачастую пишутся под PHP4. Например, для создания форм ничего приличного и свежего не найти.
Кэшна, было бы лучше использовать компоненты из Zend_Framework, если бы они, проклятые, не тормозили как старые клячи.
Ещё добавлю, что кроме E_ALL стоит использовать PHP_Exceptionizer от Котерова (придется чуть допилить для PHP 5.3). Таким макаром, мимо нотиса не удастся пройти, даже если он случился перед перенаправлением на другую страницу.
Насчет cp1251 спорный момент. Например, накодили вы интернет-магазин, и тут выяснилось, что Яндекс.Маркет принимает только виндовую кодировку. Потсоны, подскажите, как выкручиваетесь в таких случаях? На кого сваливаете ответственность за левые символы в описаниях продуктов, которые из утф в 1251 не перекодируются, особенно учитывая, что iconv, встретив такой символ, объявляет забастовку?
Я бы ещё добавил, что сайтец phpclasses ни в коем случае нельзя использовать, есть вы не уверены, что уже поискали все более адекватные альтернативы и взвесили за и против использования кода с phpclasses против написания собственного. И то, если вы берете класс с phpclasses, нужно сразу лезть внутрь, читать его и править, и дальше держать как свою собственную библиотеку, хоть и основанную на чужом коде.
Искать готовые решения в сто раз лучше в Гугл Директори, чем на phpclasses.
Ещё сразу отмечу, что оператор @ можно использовать. Например, та же функция parse_url выкидывает варнинг, если не смогла разобрать, что ей подсунули. Вам это надо? У меня, например, все варнинги валятся на почту. Отсюда мораль — варнинг давить с помощью @, правильность парсинга проверять сравнением ===false.
Друже, во-первых, лучше переводы оформлять как переводы, в этом случае у читателя будет меньше вопросов «что за дурацкий слог». Лично я на предложении «Вся работа и никаких игр растягивается на недели, месяца или проекты» понял, что читаю пословный переклад неформального английского текста, который, к несчастью для переводчика, включает устойчивые выражения.
К тому же в предложении «All work and no play makes for a dull week, month, or project» вы, увлекшись пересказом идиомы, потеряли важную смысловую часть про «makes for a dull».
Тем не менее, я могу увидеть в валидаторе, что единственное что изменилось — это автокомплит. А если я с самого начала не заморачивался валидацией, то этот инструмент мне и не поможет: было в нем 52 предупреждения, а стало 78 — ну так кто ж следит-то за ними? Так что изначально всё-таки нужно страницу довести до ума.
Кстати, для автора текста в фф'овском расширении HTML Validate пригодилась бы опция «забить на эту ошибку», она бы ему позволила не париться о своих спецатрибутах, но проверять другие траблы.
Это понятно, но смысла тратить процессорное время на такую операцию особого не вижу. Дублированные картинки — наверное, актуальны только для очень популярных хостингов, а для них время ещё дороже.
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.
Мне было бы интересно услышать мнение тех, кто реально это делал, а не теорию вопроса.
Другие более-менее проработанные библиотеки всё равно зачастую пишутся под PHP4. Например, для создания форм ничего приличного и свежего не найти.
Кэшна, было бы лучше использовать компоненты из Zend_Framework, если бы они, проклятые, не тормозили как старые клячи.
Насчет cp1251 спорный момент. Например, накодили вы интернет-магазин, и тут выяснилось, что Яндекс.Маркет принимает только виндовую кодировку. Потсоны, подскажите, как выкручиваетесь в таких случаях? На кого сваливаете ответственность за левые символы в описаниях продуктов, которые из утф в 1251 не перекодируются, особенно учитывая, что iconv, встретив такой символ, объявляет забастовку?
Искать готовые решения в сто раз лучше в Гугл Директори, чем на phpclasses.
Ещё сразу отмечу, что оператор @ можно использовать. Например, та же функция parse_url выкидывает варнинг, если не смогла разобрать, что ей подсунули. Вам это надо? У меня, например, все варнинги валятся на почту. Отсюда мораль — варнинг давить с помощью @, правильность парсинга проверять сравнением ===false.
P.S. Интересно, что окошко про «Вы не можете комментировать чаще, чем 1 раз в 5 минут» имеет заголовок «Хабрахабр — Голосования».
К тому же в предложении «All work and no play makes for a dull week, month, or project» вы, увлекшись пересказом идиомы, потеряли важную смысловую часть про «makes for a dull».
Кстати, для автора текста в фф'овском расширении HTML Validate пригодилась бы опция «забить на эту ошибку», она бы ему позволила не париться о своих спецатрибутах, но проверять другие траблы.
Интересно, сколько принципов было выкинуто и сколько подверглось перефразированию ради названия метода?
Хотя при масштабах в десятки серверов, наверное, уже и не особо важно, всё равно окупается.