Проблемы с потоками при закачке страниц

← →
DVM © (2012-12-30 23:55) [80]

> Pcrepair © (30.12.12 23:48) [79]

> и какую же кодировку указать?

> оне часто не совпадают

Более того они обе могут быть и неправильными. А ты от Indy хочешь чтоб она правильно перекодировала.

Вообще сначала надо смотреть кодировку страницы и если она не указана то брать кодировку сервера

← →
DVM © (2012-12-30 23:58) [81]

>
> > Pcrepair © (30.12.12 23:48) [79]

и Indy не парсит HTML - это не его дело, кодировку он оттуда не достает по любому!!!

← →
Pcrepair © (2012-12-31 00:05) [82]

значит берет из ответа сервера, отсюда и бывают иногда кракозябры, когда кодировка указанная в коде страницы не сооответствут данным от сервера.
но перекодировку ИНДИ 10.5.9.0 точно делает
это видно. если один и тот же код загрузчика откомпилировать в РАД2010 и ХЕ3 то одна и та же страница(1251) в одном случае кракозябры(рад2010) в другом правильная кодировка

← →
Styx (2012-12-31 00:09) [83]

Это ещё не показатель... Возможно, у них запросы отличаются, а сервер в ответ на эти разные запросы отдаёт контент в разной кодировке...

← →
DVM © (2012-12-31 00:13) [84]

> Pcrepair © (31.12.12 00:05) [82]

> но перекодировку ИНДИ 10.5.9.0 точно делает

Да и не отрицаю нигде этого. Я говорю, что на это полагаться нельзя, т.к. Indy в отличие от тебя не парсит HTML, а ты парсишь, так не лучше ли самому с кодировкой определяться? Надежнее по любому.

← →
DVM © (2012-12-31 00:13) [85]

← →
bems © (2012-12-31 00:17) [86]

DVM, почему IdHttp должен игнорировать кодировку? http это не текстовый протокол же. и как пользовательский код должен отличать скажем UTF-16BE от UTF-16LE, если с ними двумя даже нельзя нормально прочитать что там указано для кодировки в html-коде

← →
Pcrepair © (2012-12-31 00:18) [87]

> так не лучше ли самому с кодировкой определяться? Надежнее
> по любому.

ну это не простой вопрос. даже Mlang, а там наворочено куча доп. модулей и то не всегда точно определяет(лично пробовал). так что приходтся идти на компромис: приемлемый результат - время затраты на решение возможно не решаемой задачи.
критерия то выбора способа перекодировки 100% достоверного нет

← →
bems © (2012-12-31 00:20) [88]

> http это не текстовый протокол же

ну вы поняли ,что я имел в виду

← →
DVM © (2012-12-31 00:30) [89]

> bems © (31.12.12 00:17) [86]
> DVM, почему IdHttp должен игнорировать кодировку?

а почему он собственно должен?

> http это не текстовый протокол же

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

> и как пользовательский код должен отличать скажем UTF-16BE
> от UTF-16LE, если с ними двумя даже нельзя нормально прочитать
> что там указано для кодировки в html-коде
>
>

там должен быть BOM

← →
bems © (2012-12-31 00:42) [90]

> Непонятно, почему для типа контента текст должно делаться
> исключение и он должен перекодироваться в удобный пользователю
> вид?
ну потому что метод Get возвращает тело ответа, и не возвращает хидеры (я говорю про ту версию что без стрима). соответственно этот метод должен возвращать тело в виде с которым можно работать

> там должен быть BOM
он только для UTF-16, а при UTF-16BE и UTF-16LE BOM искать нельзя
да и в случае UTF-16 пользователь должен знать что там двухбайтный символ, чтобы сделать вывод что нельзя просто читать подмножество ascii которое везде одинаково
вариант метода возвращающий данные в стриме не должен перекодировать, тут я согласен

← →
DVM © (2012-12-31 00:48) [91]

> bems © (31.12.12 00:42) [90]

> ну потому что метод Get возвращает тело ответа, и не возвращает
> хидеры (я говорю про ту версию что без стрима).

ну хидеры то у нас всегда есть, аж два раза один рас в событии TidHTTP до загрузки, второй раз, в объекте Response.

> соответственно этот метод должен возвращать тело в виде
> с которым можно работать

Но это невозможно на 100%, не разбирая HTML, сам же понимаешь.
Этот метод он для элементарных случаев.

Кстати, кто-то хоть раз видел сайт со страницами в кодировках UTF16?

> он только для UTF-16, а при UTF-16BE и UTF-16LE BOM искать
> нельзя

КАК ТАК?

UTF-8
EF BB BF
UTF-16BE
FE FF
UTF-16LE
FF FE
UTF-32BE
00 00 FE FF
UTF-32LE
FF FE 00 00

← →
DVM © (2012-12-31 00:52) [92]

> bems ©

я не понимаю, в чем проблема определения кодировки если есть BOM? Если BOM нет, то кодировка должна быть такой, чтобы само название кодировки хотя бы можно было прочитать, если же и это не соблюдается, то тут уж не поможет ничто и настолько криворуко сделанный сайт проще игнорировать.

← →
bems © (2012-12-31 00:53) [93]

> Но это невозможно на 100%, не разбирая HTML, сам же понимаешь.
я имею в виду только анализ хидеров. потому что без него нельзя начать и разбор html

> КАК ТАК?
а вот так. rfc 2781:
Text labelled "UTF-16BE" can always be interpreted as being big-
endian. The detection of an initial BOM does not affect de-
serialization of text labelled as UTF-16BE. Finding 0xFF followed by
0xFE is an error since there is no Unicode character 0xFFFE.

если порядок байт указан явно, то первые байты должны считаться первым символом текста, даже когда олни похожи на BOM

← →
Styx (2012-12-31 00:56) [94]

Какой BOM, Вы о чём тут вообще? Хоть один сайт отдаёт BOM??? Я попробовал в UTF-8 отдавать - так половина браузеров мне его в виде квадратика рисовало...

мы тут о стандартах, если я правильно понимаю нить разговора

> bems © (31.12.12 00:53) [93]
>

в любом случае есть статистические методы определения кодировки, и уж точно Indy их не станет использовать. Это задача клиентского приложения.

полной правильной перекодировки я и не жду от него. но если в хидере указано что это UTF-16BE, и если тип String, в котором юзер получает тело ответа состоит из двухбайтовых символов, то я думаю юзер в праве ожидать что порядок байт в widechar"e будет соответствовать тому что используется в типе string а не тому что получено от сервера

> Styx (31.12.12 00:56) [94]
> Какой BOM, Вы о чём тут вообще? Хоть один сайт отдаёт BOM?
> ?? Я попробовал в UTF-8 отдавать - так половина браузеров
> мне его в виде квадратика рисовало...

насколько я понимаю, браузеры прибегают к поиску BOM в последнем случае, если иными методами определить кодировку не удалось, большинство сайтов отдают кодировку так как положено в заголовка HTTP и HTML

> bems © (31.12.12 01:05) [97]
> полной правильной перекодировки я и не жду от него. но если
> в хидере указано что это UTF-16BE, и если тип String, в
> котором юзер получает тело ответа состоит из двухбайтовых
> символов, то я думаю юзер в праве ожидать что порядок байт
> в widechar"e будет соответствовать тому что используется
> в типе string а не тому что получено от сервера

Ну так оно сейчас так и есть, но только если с HTTP хидером все в порядке и кодировка страницы действительно такая как в хидере указано.

Проблемы с потоками при закачке страниц Найти похожие ветки