cyrillic validateForm

[Aleksey Barabanov]

Если в форме не заполнить все необходимые поля (напрмер в боттоме данного форума , то выводится алерт, в котором искажаются кириллические символы из-за неправильной цепочки кодирования cp1251-> rawurlencode-> unescape-> Latin-1. И даже, как это видно на этом сайте, не помогает перевод на utf-8. Проблема решается модификаций текста этой самой validateForm. Но решение становится не универсальным, для cp1251 одна функция перекодировки, для utf-8 другая... Да и поскольку сама эта функция не вынесена в TS объекты, то манипулировать ею можно только путем прямого патчирования.

Вопрос. Кто-то решал это кардинально ?

[Andreas Schwarzkopf]

Насколько я понимаю, этот вопрос обсуждался на днях в форуме разработчиков, там же есть рекомендации, как исправить проблему:

http://typo3.org/documentation/mailing-lists/dev-list-archive/thread/59339/?tx_maillisttofaq_pi1%5Bpointer%5D=1&tx_maillistto faq_pi1%5Bmode%5D=1
и
http://typo3.org/documentation/mailing-lists/dev-list-archive/thread/61202/?tx_maillisttofaq_pi1%5Bmode%5D=1

[Aleksey Barabanov]

Спасибо.

Первый тред конечно заполнен всякого рода ламеризмами. Но вот по второй ссылке Мартин дает точную формулировку этой ситуации.

Но там нет рекомендаций. Там есть точно такой-же вопрос.

[Andreas Schwarzkopf]

Алекесей, я не занимался этой темой детально и мало могу сказать по существу. Но мне кажется, возможные пути уже показаны в последнем сообщении первого треда:

Solution one for newer browsers:

* encodeURIComponent() -> urldecode(); cs->conv($str,'utf-8',$cs)
* cs->conv($str,$cs,'utf-8); urlencode() -> decodeURIComponent()

Solution one for \"all\" browsers:

* escape() -> cs->unescapeJS($cs,$unicode,$str)
* cs->escapeJS($cs,$unicode,$str) -> unescape()

Может быть это еще не все, но я думаю, стоит попробовать.

[Aleksey Barabanov]

Вы не совсем правы. Там далее:
Of course the JS-style conversion functions have to be written yet.

В обшем то я сделал простенькое решение - свой перекодировшик в js.

И я пробовал всевозможные комбинации. Но дело в том, что php преобразует cp1251, причем как его не проси, а js расшифровывает Latin1, что тоже без вариантов. Т.е. все комбинации с конвертацией типа cs->conv вообще не имеют смысла. Т.к. на входе их должен быть корректный код, а для js он после php уже \"ломанный\". Если только не заменить одну из встроенных функций php или js на самописный кодировщик.

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

И еще, я думаю в любом случае в js ПРИДЕТСЯ делать перекодировку согласно выбранной кодовой страницы, поскольку в js используется utf-8 или Latin-1 и без конвертации в локальную кодировку там не обойтись. Поэтому чтобы не править с двух сторон, лучше править только js.

[Andreas Schwarzkopf]

Мартин опубликовал новое расширение masi_utf8fe36
Может быть он там исправил и эту ошибку?

[Aleksey Barabanov]

Да, я в курсе.

Это расширение расширяет фронтэнд и вставляет ряд хуков так, чтобы использовать utf-8 в качестве ядра для всех преобразований символов. Т.е. не строить кросстаблицы, а все делать через промежуточное преобразование в utf-8.

Сейчас вышла версия 0.2.0, которая полностью исправляет проблему с upper для кириллицы. По крайней мере для cp1251. Теперь можно не блокировать преобразование авторских имен в upper в новостях и гостевой книге. Все работает.

Но обсуждаемую проблему это не решает.

Как написал сам Мартин, у него есть уже корректный заменитель для встроенных конверторов php. Но проблема в том, что есть JS старого стиля и новые в соответствии с ECMA.

Как мне кажется все завершится модификацией серверной части, т.е. php, где от типа броузера будут строиться соответстующие кодированные строки для JS.