-
-
Попробуй очистить кеш в браузере и ребутнуть комп.
-
-
> RusSun © (03.09.11 11:50) [1] > Попробуй очистить кеш в браузере и ребутнуть комп.
Кэш чистил - не помогло, хоть я и заранее знал, что не поможет, так как адрес блокируется не только в GoogleChrome, но также и в Opera и в Firefox и (даже :) в InternetExplorer Компьютер на ночь выключал - т.е. ребутнул :) - эффекта тоже нет. > RusSun © (03.09.11 11:53) [2] > http://forum.ucoz.ru/forum/45-36045-1
Прочитал все сообщения - не понял смысла этой ссылки... :( Вобщем добавил я сайт kolmck.net в исключения nod32, скриншот: http://s013.radikal.ru/i322/1109/08/c56a3ad868a9.jpgСайт стал открываться, но теперь другая проблема: не отображаются русские буквы, скриншот: http://s41.radikal.ru/i093/1109/3b/851e1ccaa8af.jpgОпять же проблема не в GoogleChrome - также не отображаются русские буквы и в других браузерах: Opera, скриншот: http://s011.radikal.ru/i317/1109/33/4c28bf5db549.jpgFirefox, скриншот: http://i080.radikal.ru/1109/a1/65687af2da9b.jpgInternetExplorer, скриншот: http://s014.radikal.ru/i328/1109/98/d118664ac48d.jpgПравда при этом nod32 блокирует какой-то u3020.54.spylog.com - скорее всего счётчик, но это не может служить причиной неотображения русских букв, зато это может быть причиной того что адрес kolmck.net попал в список блокируемых сайтов (в этот список попадают не только те сайты которые действительно содержат вирусы, но и те которые ссылаются на теоретически-вирусные объекты с других сайтов). А в подтверждение того, что блокировка счётчика не является причиной "поломки" русских букв могу сказать, что русские буквы не отображаются даже если зайти на kolmck.net через zend2.com , который шифрует все интернет-адреса и поэтому любые "чёрные списки" не срабатывают, скриншот: http://s013.radikal.ru/i322/1109/88/a6157da4e7a5.jpgКроме того, к счастью, помогает переключение кодировки из автоопределения в принудительное "Windows-1251". Но причина естественно не может быть во всех браузерах одновременно, да и на других рускоязычных сайтах эта проблема не наблюдается...
-
Я тоже меняю вручную меняю Вид - Кодировка с (Unicod UTF-8) на Вид - Кодировка (Windows -1251)
-
> RusSun © (04.09.11 17:30) [4] > Я тоже меняю вручную меняю Вид - Кодировка с (Unicod UTF- > 8) на > Вид - Кодировка (Windows -1251)
Значит на сайте kolmck.net что-то изменилось, потому что раньше я нормально заходил на его рускоязычную часть без необходимости явного указания кодировки... Да и в чёрном списке антивирусных компаний он не числился... :(
-
> Я тоже меняю вручную меняю Вид - Кодировка с (Unicod UTF-8)
Дык сервер отдаёт: Content-Type: text/html; charset=utf-8 а в страницах прописано windows-1251. Согласовать надо.
-
The site is clean. VERY clean. I do not understand what's the problem. This has nothing to do with russian hosting, as suggested. The site kolmck.net is hosted in the Netherlands and owned by me. If there was really a problem, someone of the "old guard" or Vladimir would have warned me.
I will double check every file.
Sometimes people do not like kol executables. Especially some "virus" un- professionals.
I will check it out.
-
Follow up: I am discussing this with the ESET lab. I also have my hosting provider scan the whole server. It is clean. Probably again some wrong signatures - on the librarycode - because some stupid users use kol to write malware. There is NO malware on kolmck.net and both me and Vladimir have nothing to do with malware whatsoever. (Are you reading this ESET?, just like AVG and Norton in the past?) For every executable all the sourcecode is included. If you compile it with sysdcuXX replacements and Delphi5 or Delphi7 you will get sometimes false positives because they fingerprint the librarycode instead of the virus itself. Reproducable. Really unprofessional if you ask me. This is not the first time this happened.
-
solved?
-
-
Anyone can reproduce this? I can not.
-
I fixed this. The problem was in .htaccess file in the root directory, it contained directive
AddDefaultCharset utf-8
I replaced it with
AddDefaultCharset windows-1251 . It seems was troubling only IE, my Opera showed all normally when at Saturday, 8 Oct I removed all ambigous directives from the top of all Russian versioned htmls. Don't know about fox, chrome - I just do use only Opera (and IE is installed on XP w/o ability to remove it totally - so I could test it too). Thanks All.
-
-
поздно обновил страницу так что ссылка уже не нужна
-
This has nothing to do with the server but is DNS related. (Which is actually worrying me more, means the DNS system in your area is hacked!) ESET has confirmed this and will remove the blocking of my server IP as soon as possible in the updates.
Again,
kolmck.net is clean and contains no virussus or malware.
-
email:
-------------------------- Dear Customer,
I got a reply from our Malware Research Laboratory in which they say the domain kolmck.net will be unblocked in a virus database update.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Please do not reply to this email, it doesn't have assigned ticket number and nobody would receive your answer. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Kind regards, Tomáš Petrík ESET Customer Service Aupark Tower, 16th floor, 851 01 Bratislava, Slovak Republic www.eset.eu
-
>I replaced it with AddDefaultCharset windows-1251
You should not have led to cp1251, it was necessary to the contrary, all the same a priori standard.
-
May be you don't know but windows-1251 is the standard de-facto for web pages in Russia (as well as koi-8 is the standard for e-mail). Just because the most of workstations are Windows XP and 7. And still I edit pages using FrontPage and notepad, it is convnient to use the same encoding. Also, utf-8 gives more then twice larger pages written in Russian.
-
Владимир, я достаточно длительное время занимаюсь веб-версткой и как человек, понимающий что существует помимо винды жизнь - всегда придерживаясь стандартов, в том числе при интернациализации использовать юникод. Так как проблемы в декодировании приложениями utf-8 давно решены, а старые однобайтовые карты кодировок уходят в прошлое, почему бы не использовать этот самый utf-8, который и является сейчас стандартом де-факто? Если и это не убедило, попробуем представить себе, например, финляндца, который решил скачать что-либо с сайта, но он как настоящий пользователь, к примеру, дженты (или хакинтоша?) решил избавиться от всего лишнего из своей машины. В том числе поддержки cp1251, связанной с ней локалью, кодировок...
-
Финляндец воспользуется английской версией страницы.
-
-
где проблемы с кодировками? это у меня будут проблемы, если я не смогу страницу в нотепаде поправить. сыр-бор с кодировками начался, как я понимаю, во-1, из-за настройки всего сайта, и во-2, из-за тупизма браузеров. Если в самом html файле уже прописана кодировка, так какого лешего они эту настройку игнорят, и берут ее откуда-то еще.
-
> Vladimir Kladov © (15.10.11 13:29) [22]
Это не тупизм, а протокол HTTP.
> Если в самом html файле уже прописана кодировка, так какого лешего они эту настройку игнорят
Чтобы прочитать этот html (в том числе информацию о кодировке в head), надо знать, в какой кодировке он пришел.
> это у меня будут проблемы, если я не смогу страницу в нотепаде поправить.
Notepad++ давно стал стандартом де-факто для правки скриптов и страниц. Он прекрасно дружит со всеми кодировками и типами переводов строк. Чего не скажешь о виндовом нотпаде.
> где проблемы с кодировками?
Пока нигде. Но если, к примеру, захотите сделать многоязычный форму, то советую выбрать utf-8, чтобы потом не получить эти самые проблемы. Или если захотите прикрутить ajax..
Я просто высказал своё мнение относительно выбора кодировки для сайта. Это не наезд на kolmck.net - там сейчас всё нормально с кодировкой.
-
>Чтобы прочитать этот html (в том числе информацию о кодировке в head), надо знать, в какой кодировке он пришел.Ну, прочитали, допустим. Дальше-то почему не применяется? Как агент пользователя узнает, какая использовалась кодировка символов? Эту информацию предоставляет сервер. Лучшим способом проинформировать агента пользователя о кодировке символов документа - использовать параметр "charset" в поле заголовка "Content-Type" протокола HTTP ([RFC2068], разделы 3.4 и 14.18) Например, следующий заголовок HTTP объявляет, что используется кодировка EUC-JP: Content-Type: text/html; charset=EUC-JPВзято отсюда: http://hydromet.ru/docs.rus/html4/charset.htmlЭто, конечно, интерпретация, и я не проверял, насколько точно она соответствует указанному протоколу rfc. Но даже из обычной обывательской логики следует, что все так и должно быть. Но браузеры (проблемы были с IE, Opera, Fox) не хотят ничего слушать. Даже интересно стало, как вдруг мозги удалось вправить Опере, удалив как раз из документа строку Content-type с явным указанием кодировки. Правильную строку. При том, что у него в этом случае оставалась только информация от сервера. Т.е. дальше он чисто на эвристике кодировку подбирал. Уже невзирая на то, что там сервер написал. Нет, notepad++ не мой выбор. Тем более что страницы генерируются программно, и мне только иногда пару буковок подправить надо. Мне иногда нужен поиск по всей странице текста. Не знаю, понимает notepad++ поиск по директории или нет, но есть еще и другие надобности. Например, иногда я правлю страницы и выполняю поиск в Delphi. Причем в старом, он utf8 точно не понимает. Удобно мне так. Многоязычную форму я вряд ли буду делать, хотя бы потому, что языков-то знаю - всего полтора (человеческих).
-
Ну ладно. Коли уж KOL - суть минимализм, то пусть и кодировки будут однобайтные ))
|