И еще раз о переходе на UTF

[Василий М.]

Ох, какое увлекательное занятие - сижу и ищу аналоги функций, только с префиксом mb_*
Тупо копипащу с интернета. Не правильно работает функция-аналог? Не беда - найду другую. Или прикажете самому писать? Жизни не хватит.

Библиотека, написанная под аски, не работает под UTF и соответственно наоборот.

Нет, конечно очень хочется, что бы текст был в UTF, можно без мнемоник обходиться. А еще с аякс-джон-енкоде работает.

А по факту? Какие приемущества? Кроме всего этого геморроя?

 

[HORO]

мультиязычность и всякие красивые символы )
а вообще интересно, неужели так много строковых функций и тп? Я свой "каркас" примерно за час перевел...ну и тестов пара часов, перед боем

 

[Василий М.]

да не много функций, но блин.. они есть!

ребята, но это говнище полное, тотальное говнище. я рыдаю. мне нужен mb_strtr. В интернете нашел аналог, но он с 3 обязательными параметрами, хотя оригинал допускает 2 аргумента.

ну какой урод написал и выложил в сеть эту функцию, не соответствующую оригиналу? ну это же жесть просто, дно, днище.

я рыдаю.

 

[hell0w0rd]

http://php.net/manual/en/function.mb-strstr.php - вроде 2 параметра обязательны, не?

 

[Василий М.]

strtr!

кстати, а как вконтакте отдает 1251, а по факту можно UTF вставлять??

 

[Василий М.]

STRTR

 

[HORO]

как вариант - написать самому (для варианта со строками в аргументах)...

 

[MiksIr]

strtr во второй форме (с массивом) должна работать без проблем с utf-8

 

[Василий М.]

strtr во второй форме (с массивом) должна работать без проблем с utf-8

она работает, да. но мне это все категорически не нравится.
для 3 аргументов - одна функция, для двух - другая.


Я на самом деле просто не знаю что делать - переходить на UTF или сделать откат и писать все как раньше. Ну очень много потенциально опасных мест, самописных функций-заплаток и прочего. Совсем это все не радует, совсем.

 

[damner2]

Я на самом деле просто не знаю что делать - переходить на UTF или сделать откат и писать все как раньше. Ну очень много потенциально опасных мест, самописных функций-заплаток и прочего. Совсем это все не радует, совсем.

Предлагаю ход конём - перевести всё на koi8-r.

 

[Василий М.]

умный очень?

 

[HORO]

переходить честно говоря, я хз откуда столько проблем и всяких функций заплаток... вроде пока 2 момента насчитал - mb_strtr и работа со строками как с массивом.
Ps. youtube.com/watch?v=RirqnBUQTEU вспомнилось...

 

[С.]

Я на самом деле просто не знаю что делать - переходить на UTF или сделать откат и писать все как раньше. Ну очень много потенциально опасных мест, самописных функций-заплаток и прочего. Совсем это все не радует, совсем.

Сколько лет работаю с UTF и ни разу не понадобились mb_* функции. Наверное я что-то делаю не так.

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

 

[AnrDaemon]

Я писал программу рассылки. Мне надо было закодировать UTF-8 строку в base64 и разделить на кусочки по 76 байт c учётом длины заголовка. Пришлось писать собственную функцию. НИ ОДНА функция стандартных библиотек не делает этого так, как требует RFC.
Это только пример, с которым я провозился дольше всего. Есть ещё много всяких мелких проблем. То же посимвольное чтение строки (для транслитерации, например).

 

[С.]

Не ясно, зачем что-то особое нужно для кодирования UTF-8 строку в base64 и затем разделения ее на кусочки по 76 байт.
Не знаю, в курсе ли ты, но str_replace() делает рус-анг транслитерацию без всяких заморочек.

Вообще я не спорю, что можно придумать или привести реальные редкие экзотические кейсы использования UTF. Но тут ТС только решается (еще сомневается!) перейти на UTF, а уже ноги сбил в поисках многобайтных строковых функций. Ну смешно ведь!

 

[AnrDaemon]

Попробуй сам, возьми строку слов на 15, добавь адрес почты и напиши код, формирующий из этой пары корректную конструкцию "To:".

 

[С.]

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

To: [email protected]

А прочую ересь выкинул бы оттуда, поскольку она там нафиг не нужна.

 

[fixxxer]

Надо не копипастить, а подумать, в чем заключается unicode safety и каких функций это касается, а каких нет.

Например, strtr в форме strtr ( string $str , array $replace_pairs ) вполне безопасен, в отличие от strtr ( string $str , string $from , string $to ). Если непонятно почему - открой текстовый файл в hex-редакторе и включай голову.

она работает, да. но мне это все категорически не нравится.

Думать каждый раз надо, да?
Ну сделай class StringTools, типа

class StringTools {
    public static function toLowerCase($str) {
        return mb_strtolower($str);
    }
    public static function tr($str, array $replacements) {
        return strtr($str, $replacements);
    }
   ....
}

Подумать надо будет 1 раз.

 

[AnrDaemon]

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

To: [email protected]

А прочую ересь выкинул бы оттуда, поскольку она там нафиг не нужна.

В результате получатель (я, например) удалит письмо на полном автомате, не читая. Потому что прислано на голый емейл = спам.

 

[Василий М.]

Надо не копипастить, а подумать, в чем заключается unicode safety и каких функций это касается, а каких нет.

Например, strtr в форме strtr ( string $str , array $replace_pairs ) вполне безопасен, в отличие от strtr ( string $str , string $from , string $to ). Если непонятно почему - открой текстовый файл в hex-редакторе и включай голову.

. я реально не понимаю. функция - черный ящик. как я могу что-то там определять-угадывать?