Жалобы/пожелания по работе форума

[CityAceE]

1. приаттаченные .png перестали отображаться как картинки:

Поправил (ещё вчера).

---------- Post added at 09:24 ---------- Previous post was at 09:19 ----------

Возможно, после перехода на юникодовскую кодировку испортились некоторые символы. Вот пример - http://zx-pk.ru/showpost.php?p=569715&postcount=3

Действительно. Но в базе всё хранится как нужно. Пока трогать не буду, а после переезда посмотрим. Может быть само уйдёт

[Advertiser]

[creator]

Может быть само уйдёт

Увы, само не уйдёт. На уникодных форумах при некоторых комбинациях русских букв/слов, появляются крокозябры. Вот например:
Бухгалтерия — всё хорошо,
Услуги+Бухгалтерия — всё хорошо,
Производство+Услуги+Бухгал терия — уже пробел какой-то вылез,
"Производство+Услуги+Бухга� �терия — всего лишь кавычку в начале добавил, а какой эффект!

На forum.ruboard.ru я этот эффект наблюдаю постоянно.

[CityAceE]

creator, спасибо за шаги воспроизведения данного бага! Попробую изучить вопрос.

[Epsilon]

Увы, само не уйдёт. На уникодных форумах при некоторых комбинациях русских букв/слов, появляются крокозябры. Вот например:
Бухгалтерия — всё хорошо,
Услуги+Бухгалтерия — всё хорошо,
Производство+Услуги+Бухгал терия — уже пробел какой-то вылез,
"Производство+Услуги+Бухга� �терия — всего лишь кавычку в начале добавил, а какой эффект!

На forum.ruboard.ru я этот эффект наблюдаю постоянно.

Сто лет пользуюсь phpBB, он юникодный, подобного бага не было никогда. Это персональный баг кривых рук девелоперов vBulletin.

[creator]

Что-то подозрение падает на "слишком длинные слова", ведь и в примере Титуса фраза интересная:
фона,символов,экрана,рабоч� �х

А если набрать по-человечески, то всё хорошо:
фона, символов, экрана, рабочих

[Epsilon]

Что-то подозрение падает на "слишком длинные слова", ведь и в примере Титуса фраза интересная:
фона,символов,экрана,рабоч� �х

А если набрать по-человечески, то всё хорошо:
фона, символов, экрана, рабочих

Баг попадает на 50й байт от начала строки. Это наводит на мысль о кривом алгоритме, который вставляет например "символ мягкости" * после каждого 50-го байта (чтобы слишком длинные строки не ломали вёрстку). Но поскольку вместо mb_strlen юзает обычный strlen, то иногда разбивает юникодные символы на две части (в отличие от обычных символов в utf-8 кириллические символы состоят из двух байтов).

---------- Post added at 05:24 ---------- Previous post was at 05:23 ----------

1234567890abcdefghij1234567890abcdefghij1234567890 abcdefghij1234567890abcdefghij

это длинная строка, посмотрим чем они её будут разбивать.

---------- Post added at 05:26 ---------- Previous post was at 05:24 ----------

Судя по HTML-коду, там просто 2 пробела вставляются.
Короче мне лень лезть в исходник vBulletin, надо искать split_string с параметром 50 и " " (два пробела в кавычках).

---------- Post added at 05:52 ---------- Previous post was at 05:26 ----------

Впрочем не факт, там может быть что-то типа preg_split или str_split или что-то такое.

---------- Post added at 06:09 ---------- Previous post was at 05:52 ----------

И если в базе данных этих битых символов нет, то надо лезть в функцию вывода страницы и искать там. А если символы битые уже в БД, то у нас большие проблемы.

[CityAceE]

Есть подозрение, что этот баг устранён в vB4. Давайте дождёмся переезда

---------- Post added at 15:04 ---------- Previous post was at 13:24 ----------

Увы, само не уйдёт.

Да, пришлось кое-что подкрутить в настойках.

[wl[illusion]]

Добавлю от себя, разрабы просто идиоты, этот баг и в vb5 есть, всё дело в preg_replace. Они его и в пятой версии используют для обрезки длинных слов.
зы неуглядел, в vb5 они отдельный класс для string сделали, так что там проверка есть.

[ZX_NOVOSIB]

разрабы просто идиоты

в этом собственно никто изначально даже и не сомневался как бы

[wl[illusion]]

в этом собственно никто изначально даже и не сомневался как бы

Давай я вкратце расскажу суть, чтобы ты оценил глубину.
Юникод уже не молодой, его ещё в далёком 98ом году пытались в ОС встроить (в том числе и винду), в вебе его встречали редко, но даже в 2004-2005 году он уже являлся стандартом. vB4 вышел 2009 году, и плотно разрабатывался с конца 2007 года. То есть, Юникод в западном сегменте уже был очень популярен. Теперь заглядываем в исходники vb4 (я брал последнюю доступную версию, которая датирована 2012 годом), везде проверка на мультибайт. У вас юникод? Отлично вот вам мультибайтовый mb_strlen! Строчку порезать? Хорошо, вот вам снова мультибайтовый mb_substr!
Отлично, разработчик думал о юникоде. А теперь сок, все, абсолютно все функции работы с регэкспами _не учитывают_ мультибайт! Нужно разбить строку на слова по длинне слов? Зачем нам мультибайт, ведь шанс того, что не мультибайтовый пробел совпадёт с каким-нибудь мультибайтовым символов не высок! Зачем нам обрезать строку регэкспами по мультибайтам? Ведь на экране это всегда 50 символов (так ведь, да), ну вот давайте отрежим эти русские 50 символов... oh shi... косячок, ну и пофигу.

То есть, кое-где разрабы очень хорошо сделали, но почему вот целый огромный кусок не работает с мультибайтом? О чём думали они в этот момент. Мне искренне очень интересно.