слегка хакерский вопрос
 

Допустим на сайте я использую кодировку виндовс 1251.
соответственно в полях типа инпут текстэрия будет использоваться эта кодировка..
ну и непосредственно сам вопрос-есть ли возможность подменить кодировку во время(до) после передачи данных на сервер на сайте-тоесть страница использует 1251 а передать в утф 8?
вариант изменения исходного кода страницы на клиенте вручную а потом посылки запроса из изменённой(как раньше проходило в контакте тож рассматриваю.и интересно какие есть варианты защиты от этого
понимаю что это прозвучит вообще тупо-теоретически можно ли задать части символов строки передаваемой любым из методов post \get свою кодировку? да и без передачи возможно ли это для части строки?интересует клиентская сторона.
слепить строку из двух строк в разных с разными кодировками возможно?

зачем?
какова конечная цель, чтобы мог понадобится такой хак?

цель проста. если это невозможно в принципе то возможно сделать защиту от инъекций абсолютно другого уровня чем те что сейчас используются и широко известны.какой всёравно есть sql инекции (вне зависимостиот их рода)в передаваемых данных.

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

PS исходный вопрос мне кажется возможным.
То есть, можно отправить данные в проивзольной кодировке
но проводить полномасштабное исследование по этому поводу мне немного лень.

Gvozd,
тоже ничего не нашел по этому поводу.но нашел только что всё в юникоде отправляется.по ходу в любом случае при отправке всё перекодируется в юникод.момент не в найти уязвимости сайта а в защите баз от инъекций
как? скажу. сейчас защита от иньекций базируеться на проверке типа данных да экранировании кавычек в основном.
но чтобы инъекция не сработала-достаточно в полученных данных заменить все пробелы и кавычки-на какие нибудь ничего не значащие последовательности символов. соответственно-эти данные будут без вопросов заноситься в базу(если типы для данных в таблице будут выставлены соответствующие). ну а при выборке их из базы их соответственно менять на те что были до замены и передавать на клиент.
да таблицы при этом получаются более громоздкие-но и полностью защищённые
ну а если склепать строку нельзя из строк с разными кодировками-то проверить кодировку строки на предмет попыток завязать лишнее труда не составит-да и смысла нет никакого в этом если есть юникод.

А зачем таки эти надмозги? Экранирование ещё никого не подводило.

Aetae,
не спорю. но тем не менее-средняя защита это порядка 10-15 строк.
эта занимает-4 при при записи и 4 при извлечении из бд.
да и те кто пропагандирует экранирование+доп защиту-всёравно делают упор на то что универсальной защиты нет.
в этой я пока минусов не вижу кроме размера б.д

фигня какая-то.
где вы собираетесь заменять кавычки и пробелы на "особые символы"?
на клиенте? легко подделать.
на сервере? чем это отличается от обычного экранирования кавычек?
*Пожалуйста очень хочу увидеть ответы на эти вопросы, для лучшего понимания вашей мысли

В поддержание этой не сильно нормальной идеи:
вы спокойно можете перекодировать вашу строку в любой кодировке в base64, к примеру. в нем не бывает кавычек и прочего.
Но, и это ничем по сути не отличается от обычной защиты
вы вызываете функцию, которая приводит данные к нужному безопасному типу

на сервере
в принципе да,но здесь вопрос что больше сервер загрузит перекодировка в base64 или подобная замена?
а если в передаваемой информации есть и кавычки и слова такиеже как опраторы mysql и последовательность кавычек важна также как и их количество ?
экранирование кавычек применяется совместно с другими методами.
одно экранирование не спасает от инъекций
для чего?чем больше вариантов защит в природе тем меньше вероятность что сломают.
аналогия -все замки выполняют одну и туже функцию. но подо все замки разные ключи и различные варианты замков есть-а не один вид

да и экранирование в моём случае только во вред

\вы вызываете функцию, которая приводит данные к нужному безопасному типу\ согласен полностью-но в тех вариантах защит что встречал,использование их грозило потерей части данных
изза чего это-задача информация должна быть удобочитаема как с базы так и с панели управления

ну а так (как я вижу) вероятность взлома инъекциями минимальная-точнее полное отсутствие таковой. сохраняется последовательность кавычек и их количество. в отличие от кодирования в base64 информация из в базе остаётся удобночитаемая
создал тему -интересовало можно ли принудительно заставить видеть часть строки в одной кодировке часть в другой

Сам факт того что при выводе надо делать доп. преобразования сразу отправляет идею в утиль.(не говоря об общей бредовости концепции)
Ибо данные в вебе в основном добавляются один раз, а читается миллионы.