для чего "заставлять" браузер? Файл ведь выгружается в соответствии с каким-то протоколом для определенной цели и должен правильно обрабатываться "на другой стороне". И вряд-ли этой "другой стороной" является браузер...
Ну я об этом тоже думал... Я хотел бы предотвратить возможные ошибки. Например если клиент предпочитает не скачивать файл и работать с ним у себя на машине, а, например, парсить напрямую из браузера (аля работать с файлом на сервере) - то у него ничего не получится.. (Добавление)
В общем сервер по дефолту открывает все страницы в UTF-8. Если в ручную через настройки браузера поставить Кириллицу Windows-1251, То ошибок нет и файл корректно открывается.
Соответственно как сделать так, чтобы файл по умолчанию открывался в нужной кодировке? (Добавление)
Я просто не совсем пойму как мне задать конкретные заголовки при прямом обращении к XML файлу (Добавление)
Мелкий пишет:
Может там идёт content-type с utf8, и браузер верит заголовку, а не самому xml
Так скорей всего и есть (я вообще не вижу заголовка с кодировкой) - значит используется дефолтный (utf-8). Так как заставить читать windows-1251 (в конкретном случае) ?
This page contains the following errors:
error on line 2 at column 1: Encoding error
Below is a rendering of the page up to the first error.
Эту ошибку выдает браузер при попытке открыть файл на сервере (файл во вложении), там всего 2 строчки.
Из наблюдений:
1. Если этот файл открыть на локальном сервере - то никаких ошибок нет.
2. Если на сервере вместо русских букв написать латиницу - то файл открывается без ошибок.
То появляется ошибка "Invalid Character Error" (Добавление)
И все равно больше всего смущает разное поведение на сервере и на локалке... Может надо что-то где-то настроить в самом конфиге сервера?
А если страниц будет много, например, 10 к и более, запрос же будет долго выполняться...
Ну а в JoomlaSEF разве не по такой же логике работает?
Я, конечно, не знаю, что у вас за велосипед и какие задачи он(а) должна решать... Но я бы для удобства использования таблиц - использовал отдельное поле для хранения GET в виде json, отдельно ЧПУ линк, отдельно линк без ЧПУ. + может какие-то служебные данные типа кастомных мета-данных или еще что-либо... И конечно кэшировал бы всё, что существенно влияло бы на скорость обработки таких url.
Палка о 2 концах: либо используйте БД (но тогда будут просадки при большом кол-ве страниц), и JoomlaSEF не застрахована от этого как и любое приложение работающее с ЧПУ через БД. (а сама реализация - уже дело вашей фантазии)
Либо использовать правила роутинга для вашей CMS (будет выигрывать в скорости перед БД) (Добавление)
А у вас получается задача:
Хочу чтобы сайт грузился за 1 сек, при этом там 5 слайдров с неограниченным числом картинок с разрешением в 4к, и все это работало на бесплатном хостинге при посещении 100к уников
Ну в общем аллегорию вы поняли...
1. POST доступен только если он был передан на конкретную страницу
2. GET доступен аналогично (но тогда рушится сам ЧПУ). Т.е. будет site.ru/catalog/page?id=3¶m=somedata&...
3. Чтобы избежать проблем в пункте 2 нужно создать с вой роутинг с правилами. Я могу расписать пример работу роутинга J! может это наведет вас на какие-то идеи, касательно вашей CMS.
Итак,
-При выключенном ЧПУ в url содержится весь GET запрос страницы и ее параметров.
-При включенном ЧПУ подключается файл router.php который переопределяется для каждого компонента.
А. Если такого файла нет, то действует стандартный J! роутинг.
В. Если нет пунктам меню (ItemID в GET), то первой частью url будет /component/
С. Далее (точно не помню) подставляется значения option из GET /option/
Д. Затем значение view из GET
Е. Все остальные GET переменные либо обрабатываются согласно правилам router.php либо идут как обычные GET параметры (как я описал выше в п.2)
Если надо отправить POST- то ничего общего с роутингом он не имеет. Есть опредленные правила парсинга переменных. Если в POST есть option и task разделенный точкой, то это значит, что запрос пойдет на контроллер с именем (первая часть task (до точки)) компонента option и вызовет там метод task (после точки).
Для наглядности
в action можно также подставить строку index.php?option=com_test&task=user.create - а в метод добавить переменную отвечающую за способ отправки get/post. И таким образом, если будет выбран get, то функционировать код не перестанет.
Но возвращаясь к описанию:
будет вызван метод create контроллера user.php из компонента com_test. Вот и все)
В Joomla 1.0 есть такой замечательный компонент JoomSEF, который позволяет делать именно подобное, в нём можно настроить переадресацию, в поле "Внутренняя сылка" занести любой внутренний URL с GET параметрами, а в поле "Новая SEF-ссылка" занести произвольный ЧПУ URL, и при обращении по этому произвольному ЧПУ URL в компоненте будут доступны те самые GET параметры.
1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)
nooblamer пишет:
в своей самописной CMS
А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?
nooblamer пишет:
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))
А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД
1. Нужно экранировать все значения.
2. Числа можно не экранировать, если есть уверенность, что должен прийти интеджер в определенное поле - я бы вместо экранирования использовал жесткое приведение типа (int) (Добавление)
И кстати для проверки коррректности SQL запроса - можно просто скопировать строчку и вставить в SQL-запрос через phpMyAdmin - если ошибок нет, значит ошибка не в SQL.
А пока что я вижу явные ошибки в SQL, а PHP кода не вижу вообще.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 394
