Описание Rest Api

[lufthanseat]

Я не совсем администрация а разработчик, но подозреваю, что отношение у администрации к истерическим заявлениям типа Вашего как минимум нейтральное, поэтому ваш вопрос администрация скорее всего проигнорирует. Мне не совсем понятны Ваши претензии к работе API. Есть масса успешных проектов использующих наш API. Есть АДЕКВАТНЫЕ И ВМЕНЯЕМЫЕ предложения. Если у вас что-то не получается, то вы либо не совсем одаренный программист, либо являетесь олицетворением статистического термина "грубый промах" в социальном плане который обозначает 3% постоянно озлобленных и всегда недовольных индивидуумов либо Вы от конкурентов...

 

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

А по - поводу этого что вы написали

Есть масса успешных проектов использующих наш API. Есть АДЕКВАТНЫЕ И ВМЕНЯЕМЫЕ предложения.

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

ОБ остальном лучше промолчать...

Изменено 16 марта 2011 пользователем lufthanseat

[apodolsk]

...Основная мысль ввода ограничений - не дать возможности "долбить" приставкам и приложениям ресурсоемкие сервисы API.

Какие приставки используют API?

 

 

[barmalej]

vod_list что-то не совсем пашет, первые 10 фильмов показывает, а потом "Untitled volume". или это у меня только?

[Alexvrs]

Итак. Прежде всего прошу прощения за задержку в ответах. Долгое время отсутствовал.

 

@Alexvrs

Насчет предложения отдать EPG сразу на день - отрицательно. Во-первых объем. Это больше 100 каналов с примерно 30 программ с описанием ~ около 1 мегабайта текста. Во вторых - генерировать такой текст тоже непросто для сервера. Если при разработке этих проблем не видно, то они всплывают при промышленных нагрузках. Поэтому - грузим столько сколько надо. И только нужные каналы. /epg3 задумывалась для организации просмотра телепрограммы на подобии http://tv.yahoo.com/listings

 

В целом о кешировании - отличная вещь! Но использовать ее необходимо грамотно. "1-2 запроса кешированных на сервере" - не совсем так. Вы не учитываете многих параметров как таймзоны, разновидности пакетов и т.п. пару запросами никак не обойдется.

 

С возвращением

 

Тут с Вами не соглашусь:

 

1. Интересует выдача не на ОДИН день а сразу на все каналы на все дни одним файлом, и ваши доводы мне кажутся не убедительными - это основано на предположении, что ЕПГ вы храните в какой либо БД?

 

2. Если предположение верно или близко к верному, то о каких ресурсах мы ведем речь, ведь сформировать из БД файл размером 15 мег, занимает 1-2 секунды (и даже если и 1-2 минуты), это конечно в рамках тысяч запросов много, но они не требуются, так как ЕПГ обновляется гораздо реже, гипотетически раз в сутки, и потратить такое время для формирования одного общего файла для всех не проблема для любого сервера (это все равно что сделать бакап БД, что думаю вы регулярно исполняете)

 

3. Теперь вернемся к вопросу учета таймзоны, в указанном выше варианте даже если генерировать 24 файла для каждой таймзоны, то раз в сутки с точки зрения нагрузки это так же не о чем (объяснения выше) но если это для вашего сервера промышленного маштаба уже напряжно, то и не надо, так как приставки сами в состоянии скорректировать тайм зону (если об этом будут знать разработчики )

 

4. Учитывая вышесказанное этот файл забираться будет приставками 1 раз в сутки, что наоборот снизит а не повысит нагрузку на ваш сервер API, а командой к считыванию (при обновлении ЕПГ) будет служить флаг передаваемый в списке каналов и при авторизации

 

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

 

6. И наконец для компании извлекающей прибыль будет не лишне для этих целей даже поставить отдельный сервер

 

7. То как у Вас задумывалось использование API мне прекрасно понятно, но это было "давно" когда Ваш сервис только начинал свое развитие, но ВРЕМЯ идет и теперь вашим сервисом пользуются люди при помощи многофункциональных спутниковых ресиверов на которых ЕПГ выдается не порциями а мгновенно (предварительно кешированное из потока со спутника) и у нас есть возможность предоставить им аналогичный сервис к которому они привыкли!!!! Разве это не повышает конкурентно способность Вашего сервиса? Разьве я не прав? Или все же аксиома "Поэтому - грузим столько сколько надо." и ожидаем каждого запроса от перегруженных серверов API?

 

Думаю для начала дискуссии доводов достаточно, теперь Ваш ход

 

 

 

[mariman]

Какие приставки используют API?

Dune HD на 100% использует наш API. Все документированные функции.

Частично Maxibox и SIG используют API.

Есть еще такие замечательные приложения, как VLC Record... плагин к XBMC который успешно может работать на AppleTV

Думаю достаточно чтобы убедить в стабильной работе API.

[mariman]

... Интересует выдача не на ОДИН день а сразу на все каналы на все дни одним файлом ...

 

По большому счету вся дискуссия сводится к этому моменту. Реализация тут особого значения не имеет. Даже если рассмотреть момент, что лежит в кеше уже генерированный файл, этот файл будет достаточно объемным. При старте ваше приложение будет "задумываться" на ощутимо продолжительное время.

Но вопрос в другом: Это потенциально "тонкое" место. Можно допустить ошибку программирования и запрашивать подобный файл на каждое обращение к EPG. Подобный запрос может вызвать "паразитическую нагрузку". Что не есть "хорошо". Думаю правильным будет ввести другое ограничение... Ограничение на количество получения EPG. В вашем случае, EPG на неделю будет возможно получить (допустим) не более трех раз за неделю...

Что-то вроде "не более N запросов EPG на задаваемый период P". Если это необходимо для кеширования на заданный период, то такое условие как бы избыточное.

 

[Alexvrs]

... Интересует выдача не на ОДИН день а сразу на все каналы на все дни одним файлом ...

 

По большому счету вся дискуссия сводится к этому моменту. Реализация тут особого значения не имеет. Даже если рассмотреть момент, что лежит в кеше уже генерированный файл, этот файл будет достаточно объемным. При старте ваше приложение будет "задумываться" на ощутимо продолжительное время.

 

не совсем так, подгрузка (обновление) ЕПГ организовывается в другом потоке (новейшие модели обладают 2-х ядерными процессорами) и/или по таймеру в ночное время

 

 

Но вопрос в другом: Это потенциально "тонкое" место. Можно допустить ошибку программирования и запрашивать подобный файл на каждое обращение к EPG. Подобный запрос может вызвать "паразитическую нагрузку". Что не есть "хорошо". Думаю правильным будет ввести другое ограничение... Ограничение на количество получения EPG. В вашем случае, EPG на неделю будет возможно получить (допустим) не более трех раз за неделю...

Что-то вроде "не более N запросов EPG на задаваемый период P". Если это необходимо для кеширования на заданный период, то такое условие как бы избыточное.

 

1. ИМХО ограничение такое будет не уместным, например в случае если произошел сбой и пользователь вынужден перегрузить ПО, очистив кешь и ему необходимо обновить ЕПГ!

 

2. для ошибок программистов есть более эффективный метод, который применяется ведущими мировыми компаниями (у них есть чему поучиться) - необходимо ввести в API понятие персональный индентификатор разработчика (например такой есть у Last.FM, google и т.д.) этот индентификатор выдается каждому разработчику и регламинтируется лицензионным соглашением, а также в случае не корректной работы приложения у вас появляется персональная обратная связь (e-mail) и однозначная индентификация этого разработчика + появляется цевилизованный механизм блокировки доступа приложения избранного разработчика, в случае возникновения нештатной ситуации до решения проблеммы (и/или выдача разработчику нового индентификатора, если необходимо отсечь не обновленное не корректно работающее ПО)

 

[apodolsk]

Какие приставки используют API?

Dune HD на 100% использует наш API. Все документированные функции.

Частично Maxibox и SIG используют API.

Есть еще такие замечательные приложения, как VLC Record... плагин к XBMC который успешно может работать на AppleTV

Думаю достаточно чтобы убедить в стабильной работе API.

Да,поведение некоторых приставок при старте и другие проблемы, о которых буквально кричали обладатели приставок, явно совпало по времени с введением Вашего ограничения.

Почитайте Форум - многие пишут "Два года все было хорошо, а сейчас..."

Раньше я считал это просто совпадением,предполагая, что приставки совсем не используют АРI. Независимо от этого, подобного рода ограничения практически всегда ведут не к снижению, а к увеличению нагрузки на сервер.

Предположим, обычный клиент. Программа или приставка - все равно. Конечная цель такой программы - чтобы пользователю было удобно. Минимум, как с телевизором, а лучше- еще удобнее. Я надеюсь, у Вас такая же цель, а сервер, API, ресурсы и их защита - лишь средства достижения этой цели.

Такая программа при старте сделает Login, установит Bitrate, установит Timemeshift, спросит список каналов, список фаворитов, EPG на один из каналов, сделает запрос на канал. Посчитайте количество запятых - и Вы получите количество запросов при старте,не считая Login. У меня получилось 6. Если Ваш сервер в этот момент еще _не_ загружен и отвечает достаточно быстро, то вероятность, что 4 из 6 запросов вложатся в одну секунду весьма велика.Получив в этом случае "ошибку", клиент может начать все сначала и будет, как Вы говорите, "долбать" Ваш сервер, пока он не замедлится настолько, что в секунду будет только 3 ответа. До этого момента клиент(приставка) будет "висеть".

 

Конечно, это все только сценарий - у пользователей всегда слишком мало информации, чтобы абсолютно точно диагностировать проблему.Я исходил из того, что Вы ограничили частоту любых запросов на ресурсы API. Если Вы ограничили только повтор запроса одного типа или что-то в этом роде, то эффект, конечно будет другим.

 

Вы часто обосновываете свои серверные решения как защиту от ошибок клиентских приложений.

Это понятно и, наверное, правильно. Частично. Поэтому почитайте, пожалуйста, Форум(хотя бы то, что модераторы еще не успели удалить) и посмотрите на свой Сервис глазами телезрителей.

Даже если клиентов много, а сервер один.

Успехов.

Изменено 17 марта 2011 пользователем apodolsk

[mariman]

не совсем так, подгрузка (обновление) ЕПГ организовывается в другом потоке (новейшие модели обладают 2-х ядерными процессорами) и/или по таймеру в ночное время

Имелось в виду задержка при загрузки файла.

 

1. ИМХО ограничение такое будет не уместным, например в случае если произошел сбой и пользователь вынужден перегрузить ПО, очистив кешь и ему необходимо обновить ЕПГ!

 

2. для ошибок программистов есть более эффективный метод, который применяется ведущими мировыми компаниями (у них есть чему поучиться) - необходимо ввести в API понятие персональный индентификатор разработчика (например такой есть у Last.FM, google и т.д.) этот индентификатор выдается каждому разработчику и регламинтируется лицензионным соглашением, а также в случае не корректной работы приложения у вас появляется персональная обратная связь (e-mail) и однозначная индентификация этого разработчика + появляется цевилизованный механизм блокировки доступа приложения избранного разработчика, в случае возникновения нештатной ситуации до решения проблеммы (и/или выдача разработчику нового индентификатора, если необходимо отсечь не обновленное не корректно работающее ПО)

 

1. Согласен. Достаточно жесткое ограничение. Но и вообще без ограничения - нельзя. Для того и дискутируем чтобы прийти к компромиссу по ограничениям.

 

2. Опять согласен. На этапе планирования архитектуры API рассматривали этот момент и решили "не усложнять". Возможно вернемся к подобной практике, но ключ не для разработчика а для устройства, как вариант, только для тех кто не шлет UserAgent в http-запросах. Нам важно тип приложения отключить... а не разработчика. Если, допустим, ошибка в новой версии - чтобы все остальные версии приложения работали... Поэтому еще и версия.

 

[mariman]

Почитайте Форум - многие пишут "Два года все было хорошо, а сейчас..."

 

Форум читаем, даже имеем статистику как по отказам так и по нормальной работе. Видим все со стороны сервера... Сами являемся своими же клиентами (извините за тавтологию...) Даже хуже - нашими клиентами являются наши тещи, жены которые могут требовать похлеще некоторых клиентов на форуме...

 

Посчитайте количество запятых - и Вы получите количество запросов при старте,не считая Login. У меня получилось 6.

 

Еще раз: ограничение в 4 запроса в секунду на протяжении 5 секунд. (!!!) для одной клиентской сессии. Таким образом реальное ограничение равно 20 запросам. И еще раз повторюсь - это значение выведено эмпирически, то есть опытным путем. Это означает что мы анализировали накопленную статистику по запросам и пришли к вот такой вот цифре. При этом ограничении все имеющиеся приставки и сервисы работают отлично. Проверено. Поэтому непонятно ваше явное недовольство введенными ограничениями.

 

Кстати, для MaxiBox и PeerTV (он же SIG) API использовали частично. А именно в работе с Видеотекой и механизмом установки клиентских настроек. На вещание, проблемы с пропаданием DNS и выходом из режима Standby это НИКАК не влияет.

 

Вы часто обосновываете свои серверные решения как защиту от ошибок клиентских приложений.

Это понятно и, наверное, правильно. Частично. Поэтому почитайте, пожалуйста, Форум(хотя бы то, что модераторы еще не успели удалить) и посмотрите на свой Сервис глазами телезрителей.

Даже если клиентов много, а сервер один.

Успехов.

 

Форум читаем. С саппортом общаемся. По проблемам в курсе.

Ограничения введены были тоже не на ровном месте. Были прецеденты НЕОДНОКРАТНО, после которых пришлось пойти на подобные меры. Иначе сервис бы уже не работал.

[apodolsk]

Еще раз: ограничение в 4 запроса в секунду на протяжении 5 секунд. (!!!) для одной клиентской сессии. Таким образом реальное ограничение равно 20 запросам.

Давайте быть последовательными и точными.

В Вашем первом сообщении никакого упоминания о пяти секундах не было. Означает это, что условия _тогда_ не было или это просто небрежность в описании?

Далее, что должно означать Ваше теперешнее уточнение? Среднее, измеренное за 5с? Или более 5с в каждой из которых больше 4 запросов? Или еще что-то?

Чтобы облегчить Вам ответ, пожалуйста, просто вставьте букву Е в том месте, где сработает Ваше ограничение, или ОК в конце каждой последовательности запросов в секунду.

A:7,0,7,3,2,7,2,0,0,0

B:19,1,0,0,0,19,1,0,0,1

C:4,4,4,4,3,5,4,5

Заранее спасибо.

При этом ограничении все имеющиеся приставки и сервисы работают отлично. Проверено. Поэтому непонятно ваше явное недовольство введенными ограничениями.

Поскольку в оценке моего отношения(оффтопик кстати!) Вы явно ошиблись, может стоит задуматься о точности или, по-крайней мере, уместности оценок собственных продуктов?

Ограничения введены были тоже не на ровном месте. Были прецеденты НЕОДНОКРАТНО, после которых пришлось пойти на подобные меры. Иначе сервис бы уже не работал.

Если сервер мог выйти строя без этих ограничений,...это,конечно, показатель качества разработки.

Еще раз спасибо за Ваши ответы.

Изменено 18 марта 2011 пользователем apodolsk

[mariman]

В Вашем первом сообщении никакого упоминания о пяти секундах не было.

 

А не взболтнул ли я чего лишнего...

 

A:7,0,7,3,2,7,2,0,0,0 - 7+3+2+7+2 = 21 - Error#31

B:19,1,0,0,0,19,1,0,0,1 - 19+1+0+0+1 = 21 - Error#31

C:4,4,4,4,3,5,4,5 - 4+3+5+4+5 = 21 - Error#31

 

...

 

Если сервер мог выйти строя без этих ограничений,...это,конечно, показатель качества разработки.

Еще раз спасибо за Ваши ответы.

 

Просьба привести пример где реально могла бы возникнуть ситуация с подобным количеством запросов?

 

О качестве разработки: Лишь тот не ошибается, кто ничего не делает.

Каким по Вашему мнению должен быть достойный и качественный продукт?

 

Всегда рад помочь.

[Eugene]

Далее, что должно означать Ваше теперешнее уточнение? Среднее, измеренное за 5с? Или более 5с в каждой из которых больше 4 запросов? Или еще что-то?

насколько я понимаю, эти ограничения обрабатываются на уровне балансера, и как это работает описано тут

 

если я прав, то как раз пример из документации и используется

[Eugene]

mariman, можно ли расширить функционал vod_list? был бы полезен mode=full (или типа того) который будет возвращать полный список содержимого Видеотеки, включая информацию из vod_info

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

 

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

+ нагрузка на сервер будет существенно снижена

Изменено 25 марта 2011 пользователем Eugene

[mariman]

mariman, можно ли расширить функционал vod_list? был бы полезен mode=full (или типа того) который будет возвращать полный список содержимого Видеотеки, включая информацию из vod_info

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

 

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

+ нагрузка на сервер будет существенно снижена

 

Очень тяжелый файл получится... Особенно когда там будет 1000+ фильмов (к чему и стремимся). Собственно, по этой причине специально и разделили на vod_list и vod_info. Если бить по страницам, то как решить проблему новых фильмов?

Встречный вопрос: можно подробнее про "индексацию"? Зачем она вам? Если для поиска, то чем не устраивает mode=text ?

[Eugene]

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

 

Встречный вопрос: можно подробнее про "индексацию"? Зачем она вам? Если для поиска, то чем не устраивает mode=text ?

через несколько дней обязательно покажу. кое-чего довести до ума надо..

[Eugene]

mariman, а какова закономерность значения в поле dt_modify из vod_list?

как-то шибко часто они обновляются (сотнями за день)

+ время используется серверное? потому что у меня эти даты изменения приходят из будущего..

 

или можно игнорировать это поле и предположить, что единожды появившийся в видеотеке фильм не обновляется?

[mariman]

или можно игнорировать это поле и предположить, что единожды появившийся в видеотеке фильм не обновляется?

 

Да. это поле нужно игнорировать. Это служебное поле. Оно не документировано.

Появившийся фильм может меняться но не значительно. Мелкие косметические изменения.

 

[apodolsk]

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

Моя жена хотела бы искать в программе передачи по произвольным словам. Например, фильм+куценко. Причем поиск должен быть не только на один канал/одну дату, а глобальным по всем ресурсам, включая видеотеку. После некоторых уговоров(типа: там фильмов пока кот наплакал) согласилась только на TB и архив. Но предупредила- Mariman сказал, что будет 1000+1 фильм - тогда поговорим еще...

Вообще она у меня не привередливая, согласна получить списочек, записать на бумажке, а потом самостоятельно кнопочки понажимать...

Ну я обрадовался, бегом на главную страницу Картины - видел там кнопочку "Программа передач". Послала меня эта кнопочка на многообещающе звучащий сайт "Все TB". Есть там и поиск, но весь в будущем-без архива, да и ищет как-то странно. В общем, не стал я жене про эту кнопочку говорить...

Почитал еще раз Rest API от Marimana. Просили добры молодцы у него целиком Программу - не дает, тяжеловата ноша,говорит, будет. Можно, конечно, выкачать у него все, пока он спит. Только делать это нужно нежно, по 4 запроса в секунду, чтобы не потревожить дитятко его, сервер, нагрузкой непосильною.

А не попросить ли помощи у него самого? Вот и пригодится его обещание.

Всегда рад помочь.

Изменено 29 марта 2011 пользователем apodolsk

[Eugene]

Встречный вопрос: можно подробнее про "индексацию"? Зачем она вам? Если для поиска, то чем не устраивает mode=text ?

через несколько дней обязательно покажу. кое-чего довести до ума надо..

ну, как бы, вот что получилось

[AlexTitoff]

Есть ли путь к картикам логотипа каналов?

то что нашел http://iptv.kartina.tv/img/ico/24/{id}.gif - слишком маленькие.

[bellorusha]

Mozhet bit' glupiy vopros, no ya pitayus' napisat' app dlya iphona, i pitayus' ispol'zovat' json, no vidaet mne vot takie sivoli

 

{"groups":[{"id":1,"name":"\u041e\u0431\u0449\u0438\u0435","color":"Silver","channels":[{"id":2,"name":"\u041f\u0435\u0440\u0432\u044b\u0439","stream_params":[{"rate":"1500","ts":"0"},{"rate":"900","ts":"0"},{"rate":"1500","ts":"1"},{"rate":"1500","ts":"2"},{"rate":"1500","ts":"3"},{"rate":"1500","ts":"4"},{"rate":"1500","ts":"8"},{"rate":"1500","ts":"9"},{"rate":"1500","ts":"10"},{"rate":"1500","ts":"11"}],"is_video":1,"have_archive":1,"icon":"\/img\/ico\/2.gif","epg_progname":"\"\u0423\u041a\u0420\u041e\u0429\u0415\u041d\u0418\u0415 \u041e\u0413\u041d\u042f\"\n- \u043a\u0438\u043d\u043e\u0440\u043e\u043c\u0430\u043d. \u0412 \u0440\u043e\u043b\u044f\u0445: \u041a\u0438\u0440\u0438\u043b\u043b \u041b\u0430\u0432\u0440\u043e\u0432, \u0410\u0434\u0430 \u0420\u043e\u0433\u043e\u0432\u0446\u0435\u0432\u0430, \u0418\u0433\u043e\u0440\u044c \u0413\u043e\u0440\u0431\u0430\u0447\u0435\u0432, \u0410\u043d\u0434\u0440\u0435\u0439 \u041f\u043e\u043f\u043e\u0432, \u0418\u0433\u043e\u0440\u044c \u0412\u043b\u0430\u0434\u0438\u043c\u0438\u0440\u043e\u0432. 1972 \u041a \u044e\u0431\u0438\u043b\u0435\u044e \u043f\u0435\u0440\u0432\u043e\u0433\u043e \u043f\u043e\u043b\u0435\u0442\u0430 \u0432 \u043a\u043e\u0441\u043c\u043e\u0441","epg_start":1302435000,

 

mozhete podskazat' chto eto za simvoli?

[bellorusha]

pod simvolami ya konechno imel vvidu eti simvoli

 

 

\u0423\u041a\u0420\u041e\u0429\u0415\u041d\u0418\u0415 \u041e\u0413\u041d\u042f\"\n- \u043a\u0438\u043d\u043e\u0440\u043e\u043c\u0430\u043d. \u0412 \u0440\u043e\u043b\u044f\u0445: \u041a\u0438\u0440\u0438\u043b\u043b \u041b\u0430\u0432\u0440\u043e\u0432, \u0410\u0434\u0430 \u0420\u043e\u0433\u043e\u0432\u0446\u0435\u0432\u0430, \u0418\u0433\u043e\u0440\u044c \u0413\u043e\u0440\u0431\u0430\u0447\u0435\u0432, \u0410\u043d\u0434\u0440\u0435\u0439 \u041f\u043e\u043f\u043e\u0432, \u0418\u0433\u043e\u0440\u044c \u0412\u043b\u0430\u0434\u0438\u043c\u0438\u0440\u043e\u0432. 1972 \u041a \u044e\u0431\u0438\u043b\u0435\u044e \u043f\u0435\u0440\u0432\u043e\u0433\u043e \u043f\u043e\u043b\u0435\u0442\u0430 \u0432 \u043a\u043e\u0441\u043c\u043e\u0441

Изменено 11 апреля 2011 пользователем User7
Предупреждение за транслит! Не нарушайте правила форума, пользуйтесь русским алфавитом для общения. -Модератор

[Задавака]

уникод?

[AlexTitoff]

уникод?

Погугли unicode_escape. это юникод в escape последовательности. В питоне декодирутся так

 

 

strn=unicode(strn).decode('unicode_escape')