- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Тут не в этом проблема
а в чем?
в чем преиущество утф8? почему стандартом стала?
в чем преиущество утф8? почему стандартом стала?
🙄 и я не знаю в чем преимущества? По мне вообще без разницы... правда это с точки зрения продвижения а не сайтостроения.
а в чем?
в чем преиущество утф8? почему стандартом стала?
Оно вроде как мировой стандарт.. Но я не программист, вам точнее объяснят другие.. ;)
в чем преиущество утф8? почему стандартом стала?
вам сжато или подробно?))
преимущество одно - она объединяет все языки, то есть универсальна, наверно поэтому и стала стандартом.
в чем преиущество утф8? почему стандартом стала?
Проблема заключается исключительно в неумении фронтэнд-программистов (вообще-то слишком громкое название для них) работать с AJAX и XMLHttpRequest .
С UTF-8 нет проблем, а с другими кодировками были. Ну и пошло-поехало.
Тема была бы актуальна 10 лет назад.
utf-8 - мультибайтовая кодировка. ПХП-шники решившие быстренько перепрыгнуть с win-1251 на utf-8 потому что это современно/модно/все так делают/универсально сразу получают жирную увесистую оплеуху от РHP вплоть до версий 5.x. Код начинает сыпаться, привычные (не mb_) функции работы со строками оказываются неработоспособными. Аналоги есть не все. Например функции mb_ucfirst() не существует, chr() и strlen() - работают некорректно, а обращаться к символу строки по его номеру как элементу массива уже нельзя. Но наконец вымучав мануалы и набив уйму шишек на лбу по мультибайтовым аналогам следует вторая крепкая оплеуха: "mb_" - функции катастрофически медленные. В PHP и доселе нет толковой реализации работы с мультибайтовыми строками.
Поэтому переход с win-1251 на utf-8 для неокрепшего молодого PHP-программиста может оставить навсегда психологическую травму в сознании. :)
Переход с utf-8 на win-1251 - нонсенс. Так вообще кто-то делал в своей практике?
по вашему MB будет затыком в производительности, а не, к примеру, БД?
по вашему MB будет затыком в производительности, а не, к примеру, БД?
Интересный вопрос. Производительность например поиска данных по UTF действительно выше чем у поиска по KOI8?
Проблема заключается исключительно в неумении фронтэнд-программистов работать с AJAX . С UTF-8 нет проблем, а с другими кодировками были. Ну и пошло-поехало.
Так все-таки в неумении или в проблемах? Или в том что проблемы были и в других технологиях - например в XML/XSLT?
по вашему MB будет затыком в производительности, а не, к примеру, БД?
Мы же не рассматриваем сейчас конкретный скрипт. Где-то узкое место может быть запросы к БД, где-то большой объем математических вычислений.
Но факт остается фактом. Мультибайтовые функции существенно медленнее своих однобайтовых аналогов. Для меня на практике это стало особенно заметно во время написания онлайн-читалки электронных книг одному из литературных проектов.
Ещё один камень в огород UTF-8 НЕ-латиница требует как минимум вдвое больше места для хранения.
Плюсы UTF-8 больше оценят конечные пользователи. Так как UTF-8 интернациональная универсальная кодировка, такой текст никогда не будет отображаться "кракозябрами". Пользователям не придется заморачиваться над выбором codepage, среди которых win-1251 - лишь часть целого семейства 125-X, каждый из которого отвечает за конкретный язык.