LordNEVR пишет:
| quote: |
3) Страница бывает нормально отображается с заголовком слева.
А бывает в неправильной кодировке (заголовок слева нормальный), тогда приходиться менять.
Хотя стоит на автовыборе. Скрины прилагаю.
А бывает и заголовок абракадаброй. |
|
Да проблема с кодировкой там возможна, и она там вообще по самой сути есть… Ибо когда веб-браузер общается с сервером,
сервер по любому передает веб-браузеру в ответе в какой кодировке будут переданы данные.
В случае со страницей в Aml Pages в принципе таких данных нет. И тогда или устанавливать ручками, или определять
статистическими методами по самим данным (что и делает настройка "Автоматически определять кодировку").
Но если данные малы — то статистика может и ошибаться. Она хорошо работает только на больших данных.
Ну и вовсе статистика она и есть статистика — ошибки возможны всегда.
Вариантов там немного.
Либо при получении данных перекодировать их всегда в какую то конкретную кодировку и в ней и показывать. Но это может занимать более чем ощутимое время — что неприемлемо.
Либо давать пользователю самому выставлять кодировку, и ее запоминать в Aml Pages. И потом, если она есть, использовать именно ее. Но там тоже не всегда так просто.
а) толком в движке Internet Explorer нет события смены кодировки.
б) документация по движку Internet Explorer вообще мутная чуть более чем полностью. Есть метод SetCharset, расшифровка чего он делает полный вперед! Мол "Устанавливает кодировку". Ну прям откровение — это и по названию видно. А по сути то что?
Перекодирует данные впрямую, из текущей в устанавливаемую? Или не трогает данные, но просто воспринимает их как есть, но в другой кодировке (то бишь показывает иначе).
В общем, там совсем не просто сделать корректно. Поэтому Aml Pages и использует некий симбиоз. Если кодировка не задана, и выставлена настройка "Определять кодировку автоматически" — то она ее пытается завсегда определить автоматически.
Если пользователь выставил кодировку, то Aml Pages запоминает ее в данных страницы, и использует именно ее, предполагая, что последняя выставленная кодировка и была верной.
В общем та еще муть… Я было хотел прикрутить другой движок под HTML вроде той же HTMLayout, но там
а) только UTF8 везде и всегда — соответственно придется все импортируемые данные по любому перекодировать перед показом.
б) скрипты не поддерживаются вовсе
в) на некоторых модных и крутых страницах HTMLayout и вовсе ничего не может — верстка превращается вообще непонятно во что. Плывет всё и вся: фреймы, таблицы, CSS.
Были идеи попробовать прикрутить Sciter. Но там тоже те еще проблемы: JavaScript не будет работать. Прикручивать его сложно. Придется весьма мощную часть движка Plugin API самой Aml Pages приделывать, ибо впрямую Sciter туда не вставишь. Кое в чем c-smile (автор Sciter) погорячился в API самого Sciter`а. Начиналось как C-like, но кое чего он там впихнул и из C++ 11, причем именно в API, хотя можно было это оставить в начинке, а из из интерфейса убрать…
Так что вот такие проблемы с кодировкой… Ну я там посмотрю внимательно, что там в Assist`е с кодировкой заголовка можно сделать. По идее, если он правильно определяет кодировку самих данных после перетаскивания, то должен и правильно определить и заголовок.
А еще над лесом летал Аист… А еще и сами браузеры клали на официальную доку. Перетаскиваемый фрагмент должен содержать в данных и кодировку. Дык вот Internet Explorer всегда там держит кодировку исходной страницы, Firefox всегда перекодирует в UTF8, Google Chrome по разному в разных версиях… Так что такой зоопарк не очень то просто обрабатывать всегда корректно.
Супер. 
- user online
- user offline