А кодировка юникода в два байта с дорисовыванием нулей называется utf16

А кодировка юникода в два байта с дорисовыванием нулей называется utf16

Внезапно!

Смысл в том, что код поинты подряд нельзя однозначно декодировать

а ниче, что в utf-8 один символ может жрать от 1 до 4 байт?

Там я ж не про ютф, а про юникод поинты. Или там тоже так?

Вопрос знатокам юникода. Допустим, unicode code point русской буквы Б - 0411 (в hex). Та же буква Б, закодированная в UTF-8 - d091. Так вот вопрос, зачем собственно UTF-8, если можно слать сразу байты юникода, без кодировки? ?

UTF8 может занимать от 1 до чётырех байтов. К тому же первые 256 символов совпадают с кодировкой ASCII, что очень удобно

Я ща без конкретных примеров потому что в таблицу смотреть не могу

Но если ты на стороне приема, ты не знаешь, это двухьайтовый код поинт буквы Б, начало трехбайтового код поинта, или два однобайтовых

Но если ты на стороне приема, ты не знаешь, это двухьайтовый код поинт буквы Б, начало трехбайтового код поинта, или два однобайтовых

во, спасибо, хотел то же самое сказать, но не подобрал слова

А юникод кодировки, в тч утф8, решают эту проблему

Хмм, а в UTF-8 знаешь? Хитроо

Хмм, а в UTF-8 знаешь? Хитроо

Т.е. википедию не почитал?

Не читал, каюсь. Решил сразу чатик загрузить

Не читал, каюсь. Решил сразу чатик загрузить

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Можно. Положить каждому символу 4 байта и слать

Вот кажется понял. Можно слать и юникодпоинты (с нулями), и всё раскодируется норм. Но ютф экономит место

ютф это кодировка

а юникод стандарт кодирования символов

кодировок дохрена

ютф это кодировка

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

скажи это тамильцам каким-нибудь с их 8-ми байтными представлениями символов

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

Нет

Давай еще попытку, зачем нужна кодировка

Теперь на примере UCS-4

Теперь на примере UCS-4

Непонятно. Почитал вики - это почти то же самое, что слать юникодпоинты напрямую. Вообще бесполезная вещь ?

Кто-нибудь знает есть ли чат ubuntu или linux?

народ, яндекс танк кто-нибудь юзал?

народ, яндекс танк кто-нибудь юзал?

???

Яндекс.Танк ru.wikipedia.org Инструмент для проведения нагрузочного тестирования, разрабатываемый в российской компании Яндекс. Первоначально инструмент не был доступен публично, и использовался только внутри компании Яндекс, но в июле 2012 года был предоставлен в открытый доступ под лицензией LGPL.

да, именно он

этот кусок дерьма не хочет работать

да, он очень прихотлив) Давно разбирался с ним. Он, если не ошибаюсь, через корутины работает. И через какой-то древний аналог tornado. Но более ничего полезного сказать не могу.

эта дичь еще и ансибл юзает

Какими образами можно очистить текст перед инсертом в бд, дабы инъекцию не словить?

в большинстве либ есть экранирование всякого г-на

Какими образами можно очистить текст перед инсертом в бд, дабы инъекцию не словить?

не проще инсерт безопасный сделать?

+

не проще инсерт безопасный сделать?

Как?

пользоваться нормальными инструментами

чем пользуешься для вставки?

в документации всегда описаны примеры

обычно это execute("insert into table values (?, ?, ?)", 'foo', 'bar', 'baz')

обычный execute у драйвера умеет экранировать жи

Orm уже не в теме?

Orm уже не в теме?

В теме

Алхимию возьми, она самая гибкая, хоть и кода много

Просто экранировать запросы а 2х17

Алхимию возьми, она самая гибкая, хоть и кода много

Но тут нафиг надо

Это пиздец

Но тут нафиг надо

откуда ты знаешь, надо или нет

Просто экранировать запросы а 2х17

Да лол

Просто экранировать запросы а 2х17

ты упоролся?

А тащить модуль норм в 2к17

драйвера сами все экранируют

откуда ты знаешь, надо или нет

Оттуда откуда и он знает что нужно алхимию))

если человек делает "INSERT INTO .. {} {} {}".format() вместо того, чтоб нормально пользоваться драйвером - это не значит, что ему нужна алхимия

это значит, что ему надо хотя бы объяснить, как правильно хуячить запросы

если человек делает "INSERT INTO .. {} {} {}".format() вместо того, чтоб нормально пользоваться драйвером - это не значит, что ему нужна алхимия

Я это имел в виду)

если человек делает "INSERT INTO .. {} {} {}".format() вместо того, чтоб нормально пользоваться драйвером - это не значит, что ему нужна алхимия

кажется делать так - плохая идея

очень плохая

это значит, что ему надо хотя бы объяснить, как правильно хуячить запросы

Ну вообще в оффдоке написано...

как делать? .format()? да, плохая. я этом и сказал.

А писать на питоне и использовать только драйвер? Ахахха

Ну вообще в оффдоке написано...

написано. но почему-то большинство людей что здесь, что в бегиннерсах, категорически не умеют ни в чтение документации, и в гугл.

Вы упоротые

как делать? .format()? да, плохая. я этом и сказал.

таких по кругу надо пускать:)

Вы упоротые

а у тебя орм головного мозга

ERROR: S client not available

Вы упоротые

Что? Назови хоть одну причину юзать орм для этой задачи

таких по кругу надо пускать:)

Понять и простить))

ОРМ это просто обертка. Вам надо использовать подготовленные выражения.

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

Подготовленные выражения - готовятся внутри самой БД и вызываются потом через execute.

https://postgrespro.ru/docs/postgrespro/9.6/sql-execute

https://postgrespro.ru/docs/postgrespro/9.6/sql-prepare.html

Например: PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2; EXECUTE usrrptplan(1, current_date);

А на частых однотипных запросах еще и ускоритесь неплохо за счет того, что пропустите часть SQL анализа

Если учиться, то как по мне лучше вообще что то типо Django orm юзать, что бы не заморачиватся над сырым sql

Если учиться, то как по мне лучше вообще что то типо Django orm юзать, что бы не заморачиватся над сырым sql

Эээээ

Если учиться, то как по мне лучше вообще что то типо Django orm юзать, что бы не заморачиватся над сырым sql

а теперь прикинь, что чувак пишет консольную приложуху какую-нибудь, или телеграм бота, или еще чего, а ты ему в ответ джангу советуешь

В итоге получаем человека который не понимает как у него бд работает

Если учиться, то как по мне лучше вообще что то типо Django orm юзать, что бы не заморачиватся над сырым sql

вот за это я бы руки открывал.

надо понимать что такое SQL.

и что под капотом

Просто некоторые думают, что SQL - это только select, insert, delete и update. Ну может CREATE) а это, дай Бог, 5% от SQL )

и не понимают, что происходит внутри.

и потом колом ставят продуктовую базу.

Просто некоторые думают, что SQL - это только select, insert, delete и update. Ну может CREATE) а это, дай Бог, 5% от SQL )

Справедливости ради этих операторов хватает на >50% работы

Чёт вы тупите, лучше начат с высокоуровневых абстракций

Чем копаться в чистом

Справедливости ради этих операторов хватает на >50% работы

не спорю. Думаю даже на большее количестов задач. Но надо понимать как их использовать. А не бездумно тыкать. Django - это хорошо и полезно и помогает избежать рутинных операций. Но только тогда, когда ты понимаешь что происходит. А не потому что ты не понимаешь и пытаешься нивилировать свое невежество через фреймворки.

Чёт вы тупите, лучше начат с высокоуровневых абстракций

эти высокоуровневые операции очень ограничивают возможности

Чёт вы тупите, лучше начат с высокоуровневых абстракций

А Django - это разве высокоуровневая абстрация?) Python и SQL - вот высокоуровневые абрстракции. Никто не советует начинать с Ассемблера.

после голого sql намного проще будет генерить те же фильтры с каунтами в джанге

эти высокоуровневые операции очень ограничивают возможности

Согласен. А для начинающего - еще и мозги зашоривают. Уж лучше потратить недельку, другую на изучение SQL и многое станет понятным)

после голого sql намного проще будет генерить те же фильтры с каунтами в джанге

А потом офигеть, от того, что для подсчетка количества страниц Django делает SELECT COUNT(*) и получить адские тормоза)

Чёт вы тупите, лучше начат с высокоуровневых абстракций

>чёт вы тупите >ты что, априори прав?

Django - это хорошо и надо использовать. Но надо понимать что и как ты используешь. Грубо говоря, надо знать свой инструмент)

Джанга это как пример, бери алхимию и получай гибкость

Я просто говорю что новичка в питон не знающего sql лучше использовать абстракцию питона, чем учить sql