Комментарии 46
>Это извращение! Зачем хранить данные в разных кодировках???
Там, где этими вопросами занимаюсь я, у меня _всюду_ utf-8 и проблема просто не встаёт.
Но в некоторых случаях заказчик хочет странного.
Фреймворк используется далеко не только на моих личных ресурсах.
Так что хотелось бы не идеологию кодировок обсудить, а удобство тех или иных костылей :)
Там, где этими вопросами занимаюсь я, у меня _всюду_ utf-8 и проблема просто не встаёт.
Но в некоторых случаях заказчик хочет странного.
Фреймворк используется далеко не только на моих личных ресурсах.
Так что хотелось бы не идеологию кодировок обсудить, а удобство тех или иных костылей :)
СУБД крайне корректно работают с utf8. Используйте у себя везде utf-8, а кодировку базы пусть выбирает клиент.
Самое изощреннейшее решение: mb_string. И такие замечательнейшие функции как mb_substr, mb_strlen, mb_strtoupper и т.д. и т.п. Читайте мануал или, хотя бы, гуглом пользуйтесь.
Это вообще не в тему.
На системах, где есть mb_string, обычно никаких проблем с использованием internal_encoding == 'utf-8'. И проблемы нет как класса.
Вопрос же стоит именно на системах, где нет mb_string.
На системах, где есть mb_string, обычно никаких проблем с использованием internal_encoding == 'utf-8'. И проблемы нет как класса.
Вопрос же стоит именно на системах, где нет mb_string.
Что за системы без mb_string? PHP 3?
Напишите свои строковые функции для UTF-8. Там ничего сложного нет, посмотрите в Гугле как работает утф.
UTF-8 использовать надо хотя бы для того, чтобы забыть какой был зоопарк с кодировками. Это единственно правильная кодировка для нынешнего веба (и не только веба).
Срок жизни у него огромный, рассчитан на расширение. Так что если сейчас не перейдете на УТФ, через год будете жалеть. Или опять задумаетесь и через два будете жалеть еще больше.
Напишите свои строковые функции для UTF-8. Там ничего сложного нет, посмотрите в Гугле как работает утф.
UTF-8 использовать надо хотя бы для того, чтобы забыть какой был зоопарк с кодировками. Это единственно правильная кодировка для нынешнего веба (и не только веба).
Срок жизни у него огромный, рассчитан на расширение. Так что если сейчас не перейдете на УТФ, через год будете жалеть. Или опять задумаетесь и через два будете жалеть еще больше.
>Что за системы без mb_string? PHP 3?
Нет. Собранные без ./configure --enable mbstring
Только не говорите, что никогда не видели таких. Сегодня это едва ли не каждый второй недорогой виртуальный хостинг :)
Именно на таких системах я обычно разворачиваю фреймворк под windows-1251.
>Напишите свои строковые функции для UTF-8.
Это будет первый вариант из предложенных мной. Я пока больше ко второму склоняюсь. В первом случае больше переписывать и выше оверхед :)
>UTF-8 использовать надо хотя бы для того, чтобы забыть какой был зоопарк с кодировками.
Вот, не поленился найти тему: balancer.ru/support/2004/02/t25205--Perevod-Forumov-Aviabazy-na-UTF-8.html
Получается, что я уже пять лет, как перешёл на UTF-8 :) Так что не нужно мне доказывать очевидные вещи ;) _Я_ давно уже на utf-8 перешёл. Но не все _чужие_ проекты позволяют сделать это с лёгкостью.
Нет. Собранные без ./configure --enable mbstring
Только не говорите, что никогда не видели таких. Сегодня это едва ли не каждый второй недорогой виртуальный хостинг :)
Именно на таких системах я обычно разворачиваю фреймворк под windows-1251.
>Напишите свои строковые функции для UTF-8.
Это будет первый вариант из предложенных мной. Я пока больше ко второму склоняюсь. В первом случае больше переписывать и выше оверхед :)
>UTF-8 использовать надо хотя бы для того, чтобы забыть какой был зоопарк с кодировками.
Вот, не поленился найти тему: balancer.ru/support/2004/02/t25205--Perevod-Forumov-Aviabazy-na-UTF-8.html
Получается, что я уже пять лет, как перешёл на UTF-8 :) Так что не нужно мне доказывать очевидные вещи ;) _Я_ давно уже на utf-8 перешёл. Но не все _чужие_ проекты позволяют сделать это с лёгкостью.
ИМХО проще заплатить за хостинг на 1 доллар больше (взять нормальный) чем столько дописывать. Ведь в обоих случаях будет оверхед.
Выбираю не я.
Более того, я не хочу геморроя с выбором хостинга.
Ибо потом будут претензии «а у нас опять сайт недоступен, что ты за хостинг нам присоветовал»?
Мне проще поставить один раз на том, что они выбрали и забыть.
…
По существу вопроса, а не по идеологии, есть что-нибудь?
Более того, я не хочу геморроя с выбором хостинга.
Ибо потом будут претензии «а у нас опять сайт недоступен, что ты за хостинг нам присоветовал»?
Мне проще поставить один раз на том, что они выбрали и забыть.
…
По существу вопроса, а не по идеологии, есть что-нибудь?
Я бы выбрал первый вариант, переделывать придется не так много, но зато если вдруг появится mb_string — можно с легкостью перейти на него — вставить внутрь своих функций.
Накладных расходов больше. И переделывать пусть не намного больше, но зато по всему коду. А во втором варианте — фактически только в лоадере PHP-шаблонов и самих шаблонах, а их пока немного. Основная часть — на Smarty.
Из этих двух я больше склоняюсь к варианту второму.
Но хочется убедиться, что я не упускаю какой-то более простой третий.
А в тех случаях, когда потребуется переход на mb_string — проще будед сделать это через mbstring.func_overload
Из этих двух я больше склоняюсь к варианту второму.
Но хочется убедиться, что я не упускаю какой-то более простой третий.
А в тех случаях, когда потребуется переход на mb_string — проще будед сделать это через mbstring.func_overload
Полностью поддерживаю предыдущего оратора, Автор — ты сам себе враг © народная мудрость.
Хотелось бы услышить доводы, почему действительно не перевести весь проект на utf8?
«Позволяет система включить utf8 — отлично. Нет — не нам выбирать… » А кому если не нам, сейчас сложнее найти где нет utf… — так что это не аргумент.
А так же очень интересна предыстория «как так вышло», если можно с подробностями, заранее благодарю.
Хотелось бы услышить доводы, почему действительно не перевести весь проект на utf8?
«Позволяет система включить utf8 — отлично. Нет — не нам выбирать… » А кому если не нам, сейчас сложнее найти где нет utf… — так что это не аргумент.
А так же очень интересна предыстория «как так вышло», если можно с подробностями, заранее благодарю.
>Хотелось бы услышить доводы, почему действительно не перевести весь проект на utf8?
Потому что проектов _много_. И в очень разных условиях. И платформу я могу в общем случае выбирать сам только на своих проектах. Они — все в utf-8.
Потому что проектов _много_. И в очень разных условиях. И платформу я могу в общем случае выбирать сам только на своих проектах. Они — все в utf-8.
Объясняешь заказчику: выбранное вами — устарело\неэффективно\etc.
Да, я могу сделать, чтобы нормально работало в этих условиях. Но это дополнительное время, а следовательно, дополнительные деньги.
Моё время стоит столько-то.
Нормальный хостинг стоит столько-то.
При том: нормальный хостинг позволит в будущем избежать подобных же проблем.
При том: решение на чистом UTF-8 гораздо более перспективно (что ты будешь делать, когда настанет эпоха PHP6? Там ведь нативная кодировка UTF-8).
Заказчик далеко не всегда прав, хотя бы потому, что не является специалистом. И хороший специалист — это тот, который помимо прочего может объяснить заказчику, почему нужно так, а не иначе.
А совсем неадекватных заказчиков лучше избегать. Вот представь, некто захотел посмотреть твоё портфолио. Увидел свежие проекты в 1251, koi8 — закрыл портфолио со словами «некомпетентен, пользуется устаревшими технологиями». И кто виноват?
Впрочем, решение всё равно за тобой.
Да, я могу сделать, чтобы нормально работало в этих условиях. Но это дополнительное время, а следовательно, дополнительные деньги.
Моё время стоит столько-то.
Нормальный хостинг стоит столько-то.
При том: нормальный хостинг позволит в будущем избежать подобных же проблем.
При том: решение на чистом UTF-8 гораздо более перспективно (что ты будешь делать, когда настанет эпоха PHP6? Там ведь нативная кодировка UTF-8).
Заказчик далеко не всегда прав, хотя бы потому, что не является специалистом. И хороший специалист — это тот, который помимо прочего может объяснить заказчику, почему нужно так, а не иначе.
А совсем неадекватных заказчиков лучше избегать. Вот представь, некто захотел посмотреть твоё портфолио. Увидел свежие проекты в 1251, koi8 — закрыл портфолио со словами «некомпетентен, пользуется устаревшими технологиями». И кто виноват?
Впрочем, решение всё равно за тобой.
>Объясняешь заказчику: выбранное вами — устарело\неэффективно\etc.
Он прекрасно это понимает. (В случае с koi8-сервером). Поэтому старая система медленно, но верно переписывается на новый код, который сможет переключиться на utf8 потом одним параметром в конфиге.
Но объём кода и его разнообразие там такие, что процесс идёт уже два года. И продлится ещё с пол-года — год.
А вопрос решать нужно уже сегодня :)
…
Ну и про варианты с cp1251 я тоже уже указывал. Я не собираюсь за те же деньги ещё и ответственность в выборе хостера брать :)
>Вот представь, некто захотел посмотреть твоё портфолио.
Ну, это, слава Богу, давно не актуально. Уже много лет не я ищу заказчиков, а заказчики обращаются ко мне. И вопрос портфолио мне просто неинтересен :)
Он прекрасно это понимает. (В случае с koi8-сервером). Поэтому старая система медленно, но верно переписывается на новый код, который сможет переключиться на utf8 потом одним параметром в конфиге.
Но объём кода и его разнообразие там такие, что процесс идёт уже два года. И продлится ещё с пол-года — год.
А вопрос решать нужно уже сегодня :)
…
Ну и про варианты с cp1251 я тоже уже указывал. Я не собираюсь за те же деньги ещё и ответственность в выборе хостера брать :)
>Вот представь, некто захотел посмотреть твоё портфолио.
Ну, это, слава Богу, давно не актуально. Уже много лет не я ищу заказчиков, а заказчики обращаются ко мне. И вопрос портфолио мне просто неинтересен :)
кодировка ну PHP проекта ну никак не зависит от системы. Весь нынешний софт прекрасно работает с чистым UTF-8 даже если в самой системе нету локалей в UTF-8.
ставте mb_string, сделайте что бы mb_overload переопределял стандартные PHP функции и живите спокойно. Подстраиваться под всех и вся в итоге приведёт вас к разбитому корыту. Есть предел плясок с бубном. Мой последний небольшой проектик имеет жесткие рамки: PHP 5.2+ с mysqli (да да да, я не пользуюсь более устаревшей морально и физически mysql), MySQL 4.1+ (рекомендую 5-ку). Заказчику условия диктовать не позволяю. Хотят что-бы работало на чём-то старом — пусть доплачивают за гемморой, я не собираюсь работать с неподдерживаемыми более библиотеками и софтом.
ставте mb_string, сделайте что бы mb_overload переопределял стандартные PHP функции и живите спокойно. Подстраиваться под всех и вся в итоге приведёт вас к разбитому корыту. Есть предел плясок с бубном. Мой последний небольшой проектик имеет жесткие рамки: PHP 5.2+ с mysqli (да да да, я не пользуюсь более устаревшей морально и физически mysql), MySQL 4.1+ (рекомендую 5-ку). Заказчику условия диктовать не позволяю. Хотят что-бы работало на чём-то старом — пусть доплачивают за гемморой, я не собираюсь работать с неподдерживаемыми более библиотеками и софтом.
_У меня_ на сервере все проекты под php-5.2.8-r2, mysql-5.0.70-r1
utf-8 всюду ещё начиная с mysql-4.1.10-alpha, едва там появилась поддержка этой кодировки.
Вопрос в ином.
>Заказчику условия диктовать не позволяю.
Даже когда заказчик обеспечит тебе 50% твоего годового дохода при непыльной работе? :)
…
Кроме того, бывают чисто объективные случаи.
Только один пример.
Коммерческий высоко нагруженный сайт. Системная кодировка — koi8-r. Огромная масса старого, много лет назад написанного кода, который работает только в этой кодировки. Процесс неторопливого переписывания этого кода идёт уже более двух лет :) Как только всё будет переписано (а это — ещё с год работы), система перейдёт полностью на UTF-8. Пока же она не только работает в устаревшей кодировке, более того, она работает под FreeBSD 4(!) :) И ничего тут сходу не сделать. Далеко не все проекты пишутся с нуля или состоят из десятка страничек.
utf-8 всюду ещё начиная с mysql-4.1.10-alpha, едва там появилась поддержка этой кодировки.
Вопрос в ином.
>Заказчику условия диктовать не позволяю.
Даже когда заказчик обеспечит тебе 50% твоего годового дохода при непыльной работе? :)
…
Кроме того, бывают чисто объективные случаи.
Только один пример.
Коммерческий высоко нагруженный сайт. Системная кодировка — koi8-r. Огромная масса старого, много лет назад написанного кода, который работает только в этой кодировки. Процесс неторопливого переписывания этого кода идёт уже более двух лет :) Как только всё будет переписано (а это — ещё с год работы), система перейдёт полностью на UTF-8. Пока же она не только работает в устаревшей кодировке, более того, она работает под FreeBSD 4(!) :) И ничего тут сходу не сделать. Далеко не все проекты пишутся с нуля или состоят из десятка страничек.
Учитывая какой это гемморой и что один раз заказчику засвербит в одном месте — я такое делать отказываюсь всегда. Даже за большие деньги, пусть идут в нормальные компании, которые способны сделать это быстро и правильно. Мне моё спокойствие важнее. И разбираться в багах 5+ летней давности, многие из которых просто не лечатся без установки новых версий (а то и существенно более новых) я не хочу. Проще найти 2-х других заказчиков, от которых и так иногда покоя нету при всём при том что фрилансом занимаюсь по личному желанию иногда.
К сожалению, я не могу позволить себе отказываться от ряда подобных проектов :)
…
Давайте, всё же, попробуем обсудить не идеологию, ибо я итак понимаю, что к чему, а техническое решение.
…
Давайте, всё же, попробуем обсудить не идеологию, ибо я итак понимаю, что к чему, а техническое решение.
Базы как правило поддерживают utf-8, можно всё перевести на неё.
все файлы на FS можно перекодировать тем же iconv
В PHP ставим mb_string и включаем mb_func_overload: читать тут lv.php.net/manual/en/mbstring.overload.php
все файлы на FS можно перекодировать тем же iconv
В PHP ставим mb_string и включаем mb_func_overload: читать тут lv.php.net/manual/en/mbstring.overload.php
>Базы как правило поддерживают utf-8
Да. Но далеко не всегда. Как минимум пару раз в год я натыкаюсь на хостинги, например, с windows-1251-only. Вообще, с mysql-4.0, который не поддерживает utf-8.
>все файлы на FS можно перекодировать тем же iconv
Так и делается.
>В PHP ставим mb_string
Он на хостингах часто отсутствует. И мне в ряде случаев требуется интеграция со старым кодом в одном процессе. Со строковыми функциями, работающими по умолчанию в системной кодировке.
Да. Но далеко не всегда. Как минимум пару раз в год я натыкаюсь на хостинги, например, с windows-1251-only. Вообще, с mysql-4.0, который не поддерживает utf-8.
>все файлы на FS можно перекодировать тем же iconv
Так и делается.
>В PHP ставим mb_string
Он на хостингах часто отсутствует. И мне в ряде случаев требуется интеграция со старым кодом в одном процессе. Со строковыми функциями, работающими по умолчанию в системной кодировке.
>такие проекты переписывают с нуля
Да, если там сотня страниц десятка категорий :)
>Можно перенести данные… но зачем переносить старую логику?
Потому если сайт активно писался 6 лет, нельзя его переписать за неделю. Значит будет выбор:
1. Заниматься двойной работой, параллельно переписывая сайт с нуля и занимаясь поддержкой и непрерывным расширением чужого страшного кривого кода.
2. Сразу писать новые компоненты системы на новом коде, но обеспечивая их интероперабельность со старым, попутно переписывая старый код на новый по мере надобности в модификациях.
Я не люблю заниматься двойной работой и поддержкой чужого кода низкого качества и поэтому выбираю второй путь :)
Да, если там сотня страниц десятка категорий :)
>Можно перенести данные… но зачем переносить старую логику?
Потому если сайт активно писался 6 лет, нельзя его переписать за неделю. Значит будет выбор:
1. Заниматься двойной работой, параллельно переписывая сайт с нуля и занимаясь поддержкой и непрерывным расширением чужого страшного кривого кода.
2. Сразу писать новые компоненты системы на новом коде, но обеспечивая их интероперабельность со старым, попутно переписывая старый код на новый по мере надобности в модификациях.
Я не люблю заниматься двойной работой и поддержкой чужого кода низкого качества и поэтому выбираю второй путь :)
Я же написал — потому что старый тоже нужно поддерживать и расширять. Ни за неделю, ни за месяц такой проект не напишешь. Если ничем другим не заниматься — с полгода где-то.
Живой нагруженный проект полгода без поддержки и расширений — это нонсенс :)
Значит придётся в этом старом проекте (сложность которого, кстати, превысила возможности писавшего его программиста) разбираться и работать с ним. Параллельно с написанием нового.
Но это — во много раз больше работы (особенно — правка старого кода, представляющего из себя крайне нестройную систему костылей), чем если для старого проекта писать модули новой уже системы.
Во втором случае можно вообще лошадей не гнать, а заниматься понемногу сносом старых компонентов и заменой их на новые. И внедрением новых. Уже правильных и красивых :)
Живой нагруженный проект полгода без поддержки и расширений — это нонсенс :)
Значит придётся в этом старом проекте (сложность которого, кстати, превысила возможности писавшего его программиста) разбираться и работать с ним. Параллельно с написанием нового.
Но это — во много раз больше работы (особенно — правка старого кода, представляющего из себя крайне нестройную систему костылей), чем если для старого проекта писать модули новой уже системы.
Во втором случае можно вообще лошадей не гнать, а заниматься понемногу сносом старых компонентов и заменой их на новые. И внедрением новых. Уже правильных и красивых :)
Сказки венского леса прямо. Даже сложный проект можно было бы за два года 5 раз переписать целиком — а вы три требуете — такое ощущение, что вы просто доите клиента, разводя его на бабки.
>Даже сложный проект можно было бы за два года 5 раз переписать целиком
Да. Если заниматься только этим процессом и ничем более. А реально же приходится поддерживать/расширять и старый код и делать то же самое уже и для нового.
Неужели нет опыта постоянной поддержки и развития сложных живых проектов сроком хотя бы больше 2-3 лет? Принципы работы там будут совсем иные, чем в режиме — «написал, сдал, с глаз долой из сердца вон».
Да. Если заниматься только этим процессом и ничем более. А реально же приходится поддерживать/расширять и старый код и делать то же самое уже и для нового.
Неужели нет опыта постоянной поддержки и развития сложных живых проектов сроком хотя бы больше 2-3 лет? Принципы работы там будут совсем иные, чем в режиме — «написал, сдал, с глаз долой из сердца вон».
Где-то прочитал: «Единственной кодировкой должна быть UTF-8 а использование других следует приравнять к разжиганию межнациональной розни и карать соответствующей статьёй УК.»
получив подобный проект в руки, нужно просто волевым усилием убедить руководство в критической необходимости перевода проекта на единую кодировку (utf8 например), а потом перекодировать всю базу и все исходники, и будет вам счастье
а ваш «зоопарк с кодировками» это… это просто неправильно
а ваш «зоопарк с кодировками» это… это просто неправильно
>нужно просто волевым усилием убедить руководство в критической необходимости перевода проекта на единую кодировку
Увы, это далеко не всегда возможно.
Увы, это далеко не всегда возможно.
нет ничего невозможного )
а иначе, вы просто так и будете заниматься постоянным разгребанием багов с некорректной конвертацией одного в другое.
потому что нет единственного рабочего решения. есть только набор костылей, как у вас. которые можно сделать работоспособными, но при малейшей модификации системы, надо будет опять подставлять костыли.
а иначе, вы просто так и будете заниматься постоянным разгребанием багов с некорректной конвертацией одного в другое.
потому что нет единственного рабочего решения. есть только набор костылей, как у вас. которые можно сделать работоспособными, но при малейшей модификации системы, надо будет опять подставлять костыли.
>нет ничего невозможного )
Бывает и такое :) См., например, проект, упомянутый в bal.habrahabr.ru/blog/55973/#comment_1500835
Бывает, что даже в новых заказах проект разворачивается, скажем, на сервере, где есть только windows-1251 (ситуация достаточно частая).
>а иначе, вы просто так и будете заниматься постоянным разгребанием багов с некорректной конвертацией одного в другое.
А багов-то, как раз, и нет. Впорос в удобстве того или иного костыля :)
Бывает и такое :) См., например, проект, упомянутый в bal.habrahabr.ru/blog/55973/#comment_1500835
Бывает, что даже в новых заказах проект разворачивается, скажем, на сервере, где есть только windows-1251 (ситуация достаточно частая).
>а иначе, вы просто так и будете заниматься постоянным разгребанием багов с некорректной конвертацией одного в другое.
А багов-то, как раз, и нет. Впорос в удобстве того или иного костыля :)
Это может в системе нету локали на utf-8, но это ничуть не мешает использовать UTF-8 в скриптах и базе данных.
На упомянутом «koi8-r-проекте»:
1. mysql поддерживает utf8.
2. Настройки php приходится ориентировать не на мой код, который может адаптироваться, а на старый, который работает _только_ с koi8-r. Более того, приходится использовать смешанный код — и мне приходится делать include старого кода, и в старом коде часть костылей реализуется уже моим кодом.
3. Приходится использовать массу файловых данных в koi8-r.
…
Поверьте, я уже два года причёсываю эту систему, подготавливая к полному переходу на utf-8. Но _пока_ это невозможно.
У нас уже есть готовый новый сервер, весь из себя юникодны, который готов принять обновлённую систему. Но пока процесс не завершён.
1. mysql поддерживает utf8.
2. Настройки php приходится ориентировать не на мой код, который может адаптироваться, а на старый, который работает _только_ с koi8-r. Более того, приходится использовать смешанный код — и мне приходится делать include старого кода, и в старом коде часть костылей реализуется уже моим кодом.
3. Приходится использовать массу файловых данных в koi8-r.
…
Поверьте, я уже два года причёсываю эту систему, подготавливая к полному переходу на utf-8. Но _пока_ это невозможно.
У нас уже есть готовый новый сервер, весь из себя юникодны, который готов принять обновлённую систему. Но пока процесс не завершён.
под кат
автор кажется прикалуется над комментаторами и не взирая ни на что хочет чтоб все согласились с ним и решали проблему как он.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужен совет по кодировкам