Помощь с сайтом

Цена договорная
  • Закрыто для предложений
  • 144 просмотра
  • Создано
  • Дизайн
  • Задание № 120753
Адрес
Виртуальное задание
Начать
, 20:26
Бюджет
Не знаю, предлагайте ваши цены
Нужно
Сделали сайт, все работает, все хорошо, НО, человек, т.е. сисадмин, который выкладывает его на сервер присылает проблемы, которые мы решить не знаем как. Вот то что он пишит: файлы опять приехали в виндовом utf-8 и неправильном формате. Сервер конечно это обрабатывает, но мусорит мне в статистику своими сообщениями об ошибках. То, что выделено красным - это заголовок виндового UTF-8, т.к. только виндовс идет поперек всех стандартов и в кодировку UTF-8 вставляет заголовок. В RFC по стандарту UTF-8 заголовка нет и быть не должно. ниже (в конце письма) я приложу то, что написал в прошлый раз, но не отправил, тебе, т.к. расчитывал что люди правильно поймут мои фразы (письмо от 25-01-2014 22:32): "2. Файлы приехали не переконвертированные cr-lf -> cr" "3. В части файлов в начале файлов битовый мусор (коды \357\273\277). Селя ви." Надо понимать, что речь там идет о файлах присланных ранее, но в новых это тоже есть. Приложил фотки как у меня открывается на компе Основная причина этого: наличие тех самых lf->cr в js скриптах. Для html это фигня, но вот для js скриптов - разная реакция в разных браузерах. Ниже пример из свежего файла service.html (но это не единственный пример). Красным выделен виндовый заголовок BOM, зеленым просто виндовые хвосты (это п.2 из цитаты выше). Цитата из неотправленного: "Кажется у меня пришло понимание того, что произошло с кодировками. Ранее я писал, что часть файлов имела битовый мусор. Рассмотрев внимательно содержимое присланного тобой архива сайта (т.е. исходников) я пришел к поразительному выводу: Уж не знаю на какой программе создавались изначально файлы, но это было сделано с БОЛЬШИМИ косяками. Очень возможно что это было сделано вообще руками. Что является полной глупостью, т.к. тупое изменение заголовка файла не ведет к автоматической установке бита в каждом имеющемся символе файла. К сожалению нужно знать азы битового счисления прежде чем так поступать. В пользу этой версии говорит простая вещь: . Есть в юникоде такая вещь как BOM (Byte Order Mark) . BOM вставляется в BOF (Begin Of File), т.е. в заголовок файла. . BOM бывает разных видов FEFF, FFFE, EF BB BF (это не все) . Самих кодировок несколько: самая первая UTF-32, вторая сокращенная UTF-16, третья еще раз сокращенная UTF-8 . Третья версия универсальная, ее можно "растягивать" по битам до 16-ой или 32-ой. . Третья версия по стандарту НЕ ИМЕЕТ маркера BOM . Третья версия позволяет перекодировать только "расширение" языка, т.е. английский пишет в ANSI, а русский уже в UTF . Майкрософт как всегда выделился и в своих системах он ввел BOM для UTF-8 . Заголовок файла UTF кодировки всегда должен начинаться с 0хE(EFE) последовательности (на русских машинах мы видим это как два символа "яю", "юя" и т.д.). . В таблице коды фразы "test utf" на английском, нажат "Enter" (т.е. LF+CR) и "тест utf" на русском ANSI (classic) 0000000000: 74 65 73 74 20 75 74 66 │ 0D 0A F2 E5 F1 F2 20 75 test utf♪◙тест u 0000000010: 74 66 │ tf UTF (ms) 0000000000: EF BB BF 74 65 73 74 20 │ 75 74 66 0D 0A D1 82 D0 п>їtest utf♪◙С'Р 0000000010: B5 D1 81 D1 82 20 75 74 │ 66 чС_С' utf Unicode 16 (ms) 0000000000: FE FF 00 74 00 65 00 73 │ 00 74 00 20 00 75 00 74 юя t e s t u t 0000000010: 00 66 00 0D 00 0A 04 42 │ 04 35 04 41 04 42 00 20 f ♪ ◙♦B♦5♦A♦B 0000000020: 00 75 00 74 00 66 │ u t f Unicode 32 (ms) 0000000000: FF FE 74 00 65 00 73 00 │ 74 00 20 00 75 00 74 00 яюt e s t u t 0000000010: 66 00 0D 00 0A 00 42 04 │ 35 04 41 04 42 04 20 00 f ♪ ◙ B♦5♦A♦B♦ 0000000020: 75 00 74 00 66 00 │ u t f . Видим что в юникоде есть заголовок, а сами символы написаны через 'пробел' "t e s t u t f " . Вернемся к исходникам. К примеру файл info.html Первая строка содержит BOM (EF BB BF) 0000000000: EF BB BF 3C 21 44 4F 43 │ 54 59 50 45 20 68 74 6D п>ї<!DOCTYPE htm 0000000010: 6C 20 50 55 42 4C 49 43 │ 20 22 2D 2F 2F 57 33 43 l PUBLIC "-//W3C 0000000020: 2F 2F 44 54 44 20 58 48 │ 54 4D 4C 20 31 2E 30 20 //DTD XHTML 1.0 0000000030: 53 74 72 69 63 74 2F 2F │ 45 4E 22 20 22 68 74 74 Strict//EN" "htt 0000000040: 70 3A 2F 2F 77 77 77 2E │ 77 33 2E 6F 72 67 2F 54 p://www.w3.org/T 0000000050: 52 2F 78 68 74 6D 6C 31 │ 2F 44 54 44 2F 78 68 74 R/xhtml1/DTD/xht 0000000060: 6D 6C 31 2D 73 74 72 69 │ 63 74 2E 64 74 64 22 3E ml1-strict.dtd"> Находим в фaйле любой кусок с русским языком (например с адресом 00000005E0): 00000005E0: 69 3E 3C 61 20 68 72 65 │ 66 3D 22 76 61 63 61 6E i><a href="vacan 00000005F0: 63 79 2E 68 74 6D 6C 22 │ 3E D0 92 D0 90 D0 9A D0 cy.html">Р'Р_Р_Р 0000000600: 90 D0 9D D0 A1 D0 98 D0 │ 98 3C 2F 61 3E 3C 2F 6C _Р_РЎР_Р_</a></l 0000000610: 69 3E 0D 0A 09 09 3C 6C │ 69 3E 3C 61 20 68 72 65 i>♪◙○○<li><a hre Видим есть BOM, но видим что написаны символы слитно, например "DOCTYPE", а не "D O C T Y P E ". А в куске (например с адресом 00000005E0) видим: 00000005E0: 3E69 613C 6820 6572 │ 3D66 7622 6361 6E61 00000005F0: 7963 682E 6D74 226C │ D03E D092 D090 D09A 0000000600: D090 D09D D0A1 D098 │ 3C98 612F 3C3E 6C2F 0000000610: 3E69 0A0D 0909 6C3C │ 3E69 613C 6820 6572 Раз есть BOM и слитные символы, это UTF-8 от всеми "любимого" MS. Собственно в чем косяк-то? А в том, что заголовок файла от одной системы кодировки, в фактические символы в другой системе... Т.е. программа получив заголовок файла "включает" конкретную кодировку, а сами-то символы вообще в другой кодировке. Как-то слабо верится, что такую ахинею могли сделать програмисты программы "блокнот". Собственно когда я получил файлы, посмотрел их, увидел, что это какой-то кошмар, но раз сказали "работало", то забил на это. Потом полезли косяки с двойной перекодировкой, вылечил вылизыванием заголовков файлов. И только потом я догадался, что надо еще раз переконвертировать, после этого все вернулось на круги своя. Собственно поэтому я и написал "выглядело как битовый мусор". http://ktonanovenkogo.ru/vokrug-da-okolo/kodirovka-teksta-krakozyabry-ascii-yunikod-utf-8-rasshirennaya-ascii-windows-1251-cp866-koi8-r-problemy-s-kodirovkoj.html Есть и ещё одна причина: при использовании кодировки Unicode, которая приобретает всё большую популярность, а со временем займёт доминирующее положение в веб, волшебные кавычки могут попросту испортить текст, приняв часть мультибайтной строки за спецсимвол." Вобщем, нужен человек который поможет решить все проблемы с сайтом, побыстрее и подешевле....

Последние задания

Заказчик этого задания
Бэла К.

24 года Санкт-Петербург

Отзывы: 14 1
Не нашли ответа на свой вопрос?
Звоните нам: +7 (495) 668 65 33 в Москве и +7 (812) 402 02 33 в Санкт-Петербурге.
Служба поддержки YouDo работает с 9:00 до 23:00 в будни и с 9:00 до 21:00 в выходные дни. Будем рады помочь.
Случайные отзывы