Исследователи из Кембриджского университета опубликовали новую технику незаметной подстановки вредоносного кода в рецензируемые исходные тексты. Подготовленный метод атаки (CVE-2021-42574) представлен под именем Trojan Source и базируется на формировании текста по разному выглядящего для компилятора/интерпретатора и человека, просматривающего код. Примеры применения метода продемонстрированы для различных компиляторов и интерпретаторов, поставляемых для языков C, C++, C#, JavaScript, Java, Rust, Go и Python...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56083
o_O
Три раза прочитал на превьюхе Satan прежде чем понял, что это Safari. Возможно, из-за его околонулевой популярности )А по сабжекту - ну, ждём патчей для Студии.
> Возможно, из-за его околонулевой популярности )Лол, это с учётом того, что он в 6 раз популярнее Firefox?
Вынужденно :(
Среди попу'лярных.
Это где, на 15% яфончиков, где запрещено ставить нормальные браузеры?
Большинство из тех, доя кого он популярен, даже не подозревают о существовании "сафари", для них он " айфон".
>>доя когоОчень правильная опечатка, ящитаю :D.
В макси - сафари топовый браузер.
Впрочем гнутым с их корявыми поделками с ужасными шрифтами не понять
когда привыкаешь к никакующему хитингу глифов в макоси тогда для тебя все остальное кажется инородным угу.
Да тут речь не о топовости и шрифтах... впрочем единственной прямой извилиной это не понять.
Для большинства яблоюзеров
Сафари - просто интернет
100500 раз слышал ответ
на вопрос "каким ты браузером пользуешся?" )))
Так у них там и chrome - это safari. Никакой разницы)
Переходите на Notepad++. Там уже это реализовано..
Не баг а фича.
Особенно для раста с его крейтами из онлайн-хранилищ.
Раст уже починили (добавили опцию соответствующую), и все крейты проверили.
Да и вообще, вредоносный код можно подхватить, где угодно. И его надёжность от способа распространения не зависит. Но тебе же надо было в очередной раз прогазифицировать лужу зачем-то.
Ну так делай тогда вывод: Раст такой же небезопасный как и все языки.
ТОлько со значительно большим гиммором в системном программировании.
Каждому языку свое применение.
Есть языки у которых нет реального применения.
> Есть языки у которых нет реального применения.Если язык появился - значит у него БЫЛО, но сплыло применение. Эволюция однако. ..опой чтоли думаете когда пишете такие комменты?
Какое у брейнфака или у yoptascript было применение и куда оно спыло? Такое ощущение что ты в каждой ерунды ищешь скрытый смысл, которого нет.
Мозги развивать.
Попробуй, возможно тебе понравится.Например, тривиальная задача - написать на брейнфаке (машине тьюринга) умножение двух беззнаковых 8-битных чисел. А если покажется слишком легкой - то написать брейнфак на брейнфаке.
Лучшей физкультуры для ума вряд ли придумаешь.
Брейнфак не с целью развития мозгов создавался.)) Это простейшая и минимальная виртуальная машина для тьюринг-полного языка. Челендж такой был у создателя, и он его достиг своим компилятором в 240 байт. Никакого практического, или идейного смысла "программирование на брейнфаке" не несет. Впрочем, его можно выдумать, что ты и сделал. С растом та же фигня.))
Судя по твоему комментарию и смайлам - для тебя таки не несет.А для остальных - несет, да еще как. С его помощью наглядно можно показать саму идею вычислительного устройства (упомянутая уже машина тьюринга), на коей базируются все без исключения вычислители.
> Ну так делай тогда вывод: Раст такой же небезопасный как и все
> языки.Раст был такой же небезопасный как и все языки в отношении данного CVE.
Как всегда vim победил, а говно-перделки на электроне где-то в жопе
Кафирный вим не даёт читать на языке правоверных.А по делу. Это ж как надо кодревью проводить что бы игнорировать сомнительные комментарии.
> Как всегда vim победил,*смотрит на точно такой же результат SublimeText*
Но только в фантазиях вимеров.
Где vim победил, фантазер?Показывает криво, также как и emacs, увы. Проверял на их питоновских тестах.
C код: 8.2.3455 -- показывает **без** перекрытия. То есть видно, что будет "видно" компилятору. На python'овских тестах не смотрел.
Безопасный язык это как безопасная бензопила что-то из области фантастики.
Самое забавное в этом комментарии - "+29" оценка.Учитывая, что вим точно так же подвержен, это наглядно показывает, что любители вима сами вимом не пользуются.
Скорее ты вообще не врубаешься кто и зачем тут ставит плюсики. )
Хакер и солонка, 100500я серия...
Эх, как же нрацца это шоу.
То скрипты-плагины в хоме объявят главным мировым злом, то юникод обплюют за RTL и символы разных алфавитов, так похожие на латиницу...
Гарсон, еще попкорна!
> в современном текстовом редакторе, web-интерфейсе или IDE:q!
ZQ надо
killall -9 vim
sudo rm -f /sbin/vim
ZQ надоДурацкий вим. Лет 5 уже не пользуюсь, но машинально через каждые 10 секунд нажимаю esc
Звучит реально неприятно. Как ОКР какое-то...
Обычная мышечная память. Как выключатель на кухне, если заходишь в другую кухню всё равно свет пытаешься включить так как запомнил.
Надо продолжать пользоваться -- тогда все ESC пригодятся и проблем не будет.
А я не могу выйти из nano :(
Всегда думал что у пользователей, в первый раз зашедших в vim без подготовки, должно быть лицо к этот "смайлик".
Смайлик :q символизирует либо облизывание, либо закусывание языка от интенсивного труда. Почему-то мне кажется, что в здесь актуальнее второе )
C-c C-qА вот гитхабчик, кстати, показывает "This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below."
багофича
В Rust уже пофиксили: https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html
> В Rust уже пофиксили: https://blog.rust-lang.org/2021/11/01/cve-2021-42574.htmlА для Си CVE? Нету? То-то! Очередная расто-дырка!
Выкусите, растаманы!
Ваще-то это во всех компиляторах
Просто С/С++ имеет далеко не один компилятор.
А в случае с крестами там ещё коммитет бездельников есть, который будет натужно думать не сломает ли такое поведение что то.
О да запретить комментарии на иврите и арабском это же так просто и точно ничего не сломает. Лол ржу в голос.
Как такое вообще могло быть в самом безопасном языке в галактике? Ой так нифига он небезопасный язык как язык на уровне Nim.
Что такое Nim?
Это современный, безопасный язык системного программирования.
Безопасность - это не состояние, а процесс. Nim до Rust как до Луны.
В раст снова быстро влепили какую-то заплатку, не относящуюся напрямую к языку. Аджаааааааайл!А-ха-ха-ха-ха-ха-ха.
А проверку времени перехода на зимнее/летнее время и правильный цвет носков программиста туда еще не добавили?
Я уже обновил компилятор своего языка с исправлением, а ты своего?
А я пишу на лиспе и мне как-то все равно.
Нет, не пофиксили, всё ещё работает.
рили? за такой код нужно нещадно бить по рукам!во-первых, код должен быть самодокументируемым.
во-вторых, если без комментариев совсем никак -- только многострочные, только с новой строки.
> во-первых, код должен быть самодокументируемым.Мамкин погромист писал что-то сложнее хеллоуворлда?
> только многострочные, только с новой строки
Это не поможет, если я правильно понимаю метод.
>> во-первых, код должен быть самодокументируемым.
>Мамкин погромист писал что-то сложнее хеллоуворлда?Понять содержимое метода обычно нетрудно. Все ведь умеют читать! Но это только при условии, что документация на каждую функцию и структуру есть в .html/info. Комментарии внутри функций как правило бесполезны, если там какой-нибудь WARNING/TODO/HACK не написан. Право на жизнь имеют только псевдокомментарии для автоматического генератора документации, но если она локализирванна и требует юникода, то этот код будут хейтить все программисты мира.
>>> во-первых, код должен быть самодокументируемым.
>>Мамкин погромист писал что-то сложнее хеллоуворлда?
> Понять содержимое метода обычно нетрудно. Все ведь умеют читать!На, читай:
https://www.researchgate.net/publication/221564800_On_factor...Буржуинский-то хоть знаешь, гуру? :)
> Право на жизнь имеют только псевдокомментарии для автоматического генератора
> документации, но если она локализирванна и требует юникода, то этот код
> будут хейтить все программисты мира.Такое впечатление, будто все "программисты мира" (тм) (r) сидят в каких-то допотопных
консолях с шириной экрана в 80 символов и ASCII. Вот только прокрутку в Linux-консоли
поддерживать почему-то было некому...
А тебе не приходило в голову что это не из-за консоли, а из-за того что так просто удобнее читать код. Нет? ну подумай об этом на досуге. Заодно о своём стайлгайде как ты думаешь почему твой разорви экранный код удобно читать только тебе?
> А тебе не приходило в голову что это не из-за консоли, а
> из-за того что так просто удобнее читать код. Нет?Тебе вот что удобнее было бы читать? alpha или α? А если
формула с однобуквенными обозначениями
один-в-один совпадет с тем, что написано в статье, а всякие
alpha, beta, гаммы - сделают ее на пяток строк, вместо одной?> Заодно о своём стайлгайде как ты думаешь
> почему твой разорви экранный код удобно читать только тебе?На основании чего ты так подумал?
> На основании чего ты так подумал?Есть такая штука она называется "Логика" погугли на досуге, но до тебя она точно не дойдет.
Логика, мой дорогой юный друг, не может работать без некоторой базы фактов и правил. Какова она в твоем случае?
>Тебе вот что удобнее было бы читать? alpha или α?Мне удобнее «альфа», а не латинизированное алпха. И?
"альфа" - в ASCII не влазит, тоже харам. И размер формулы вряд-ли сильно скукожит.> И?
Да ничего. Главное, чтоб ндравилось.
>"альфа" - в ASCII не влазитИ чо? Значит аски — не нужен.
> А тебе не приходило в голову что это не из-за консоли, а из-за того что так просто удобнее читать код.Приходило. Но как показывают исследования, программисты читают комментарии. eye-tracker'ом следили за программистом, изучающим код, и чётко показали, что программисты читают комментарии. Если бы комментарии только мешали, они бы не читали их.
Тут я могу встречный вопрос задать: а тебе не приходило в голову, что комментарии могут быть полезны? И если приходило, то какие действия ты предпринимал, чтобы найти ответ на этот вопрос?
Ты сам пишешь выше:
> Комментарии внутри функций как правило бесполезны, если там какой-нибудь WARNING/TODO/HACK не написан
> как правилоДа, как правило. Но это одно из тех правил, которые выполняются в 95% случаев, и всегда остаются неустранимые 5% других случаев, когда комментарии нужны.
> какой-нибудь WARNING/TODO/HACK
Во-во, например в этих случаях. Или, скажем, когда ты используешь какой-нибудь совсем не очевидный алгоритм. Из тех, которые ты вычитал в статье по мотивам диссертации на PhD, и два дня переваривал статью, чтобы понять, как вообще это работает. И после этого, ты реализовал алгоритм оттуда на выбранном языке программирования, добавил в начало кода ссылку на статью, дал краткое, упрощённое объяснение основной идеи алгоритма, а потом ещё в своей реализации расставил комменты вида "тут мы используем адаптированный баблсорт, потому что массив почти отсортирован (максимум два элемента могут быть не на месте), и баблсорт в таком случае порвёт все квиксорты" или "этот цикл соответствует врезке кода 3.2 из статьи".
Код надо писать так, чтобы когда ты через полгода будешь читать этот код, ты бы смог разобраться в нём минимумом усилий. Не гадать почём зря "а не будет ли здесь квиксорт быстрее", или о том "что это за хрень такая, и где об этом в статье написано".
Хочешь ещё примеров, когда комменты внезапно оказываются нужны? Неочевидный edge-case, ради которого тут надо поставить проверку, и совершить пару дополнительных телодвижений, или наоборот прервать работу раньше времени. Иногда проверка на неочевидный edge-case делает edge-case очевидным, но не всегда. В некоторых случаях это выглядит бессмыслицей: "ну и что, что node->depth % 3 == 2"? Чем нам ноды с глубиной равной двум по модулю три не угодили? Тебе не приходилось сталкиваться с таким? Когда одна дурацкая непонятная проверка требовала остановиться, и десять минут сочинять такой случай, когда она сработает, и потом ещё полчаса думать, почему в этом случае надо досрочно завершать работу алгоритма с ошибкой? Гайды по работе с кодом, часто в таком случае рекомендуют, разобравшись в случае, проконсультироваться с другими о том, правильно ли ты понял, и дописать в код комментарий, изложив вкратце свои находки, с тем чтобы следующий, кто будет читать этот код, не тратил бы столько времени на понимание.
Или, скажем, коммент вида "здесь нет нужды проверять всю эту кучу указателей на NULL, а индексы на выход за границы, потому что..." и далее следует какое-то объяснение этому.
Или тебе всё это вышесказанное ни о чём не говорит? Твоё мышление догматично, и ты слепо веришь признанным авторитетам? Ок, давай зайдём с этой стороны. Для тебе Торвальдс авторитет? Открой CodingStyle linux и почитай там, что написано о комментах. И ты увидишь там что-то типа (я по памяти, сорри): комменты нужны на top-level'е, перед функцией, и они должны отвечать на вопрос "что?" -- что функция делает; комменты в теле функции нежелательны, но если они есть, они должны отвечать на вопрос "как?" -- как функция делает то, что она делает; комменты внутри нежелательны, потому что код должен быть самоописательным, но иногда это невозможно -- есть семантический разрыв между кодом и задумкой программиста, и его не всегда можно устранить переписав код иначе, и в таких случаях, комменты нужны. CodingStyle linux не запрещает комменты, более того явно разрешает, оговариваясь при этом, что по-возможности надо писать так, чтобы комменты были бы не нужны.
Но догматизм или нет, CodingStyle linux'а заточен под C и 80x25 окно текстового редактора. Первое просто не обсуждается, а второе -- технические ограничения из 90-х. (Если ты почитаешь внимательно этот CodingStyle, то увидишь прямые отсылки к этим самым техническим ограничениям). Сегодня эти технические ограничения неактульны (глянь на это[1], например), а C используется не во всех проектах. В C++, например, 80 строк -- это дурацкое ограничение которое не работает, потому что строчки длинее, там может быть что-нибудь типа for(auto iter = my_collection.begin(); iter != my_collection.end(); iter ++), и это что-то может оказаться на два-три уровня идентации сдвинуто. Отчасти это забарывают отказом от табов шириной в 8 пробелов, но даже этого часто недостаточно. И ежели ты сегодня начинаешь новый проект, я тебе очень серьёзно рекомендую подумать о том, чтобы ограничить ширину строки значением побольше -- чем-нибудь из диапазона 90..110.
[1] https://blog.immersed.team/working-from-orbit-39bf95a6d385?g... Если лень читать эту стену текста, то поиском по странице поищи "glance" и позырь на скриншот. 80x25? Хаха.
Вы прослушали короткую вырезку из "Стив Макконел. Совершенный код".
А я использую редактор кода, а не less.
И в нем есть комбинация 'Alt+Z', которая включает автоматический перевод слишком длинных строк.Удобно! Попробуй.
Самое прикольное, что эта техника применяется хакерами как миниум лет 5.
Кто анализироавл взломы, то наверняка сталкивались с чудесами в сырцах на пыхе, питоне благодаря этим "вперед/назад" спецсимволам...
> Самое прикольное, что эта техника применяется хакерами как миниум лет 5.Еще лет 10 назад так (RLO - Right to Left Override) прятали палевные окончания scr,exe и (т.д.) для малвари.
даже 20 лет назад применяли непечатаемые символы в экселе и всё работало.
Почти 40 лет назад, еще на ZxSpectrum применяли нечитаемый или частично скрытый исходник.
Все теми те способами, управляющие символы в исходном коде. :)
А потому что нехер пропихивать в utf8 (и юникод в целом) всякое дерьмо. Сюда же современные opentypeвые шрифты, которые уже стали мини программами - сливания в лигатуры и прочая-прочая. Реально хочется огородиться в koi8r.
Фу!
Только ASCI!
>>ASCIASCII же.
Лови предателя!
Ну, тогда опеннет для тебя один из последних островков счастья.
> А потому что нехер пропихивать в utf8 (и юникод в целом) всякое дерьмо.Вы антисемит?!
Я не против даже 2байтовых кодировок, когда мой Я против кодов модификаторов. Еле-еле устаканилились концы строк CR+LF, а тут изощренность в квадрате. Это просто источник бездны ошибок в реализации, неочевидной техники применения, приводящей к неожиданным эффектам.
Всё равно, что сказать человеку, чтобы тот обходил зимой озеро по берегу, а не шлёпал по льду, потому что видите ли у него снегоступы и вообще всё продумано. На раз 20ый провалится.
Дебилы, б..дь (с) Лавров, б..дь.
>Я не против даже 2байтовых кодировок, когда мойкогда мой текст будет занимать в 2, 4, да хоть 8 раз больше против условных 7ми-, 8битных кодировок.
Что мне делать, если в середине ответа я пожелаю таки обматерить тебя на иврите?
Обматерить меня на иврите с начала новой строки? Я могу придумать применение смены направления письма по середине строки, но как по мне, всё это очень не консистентно и усложняет коммуникацию больше, чем решает проблем.
Мат (на любом языке) порой катастрофически упрощает коммуникацию. Это я вам говорю.
Я не против мата.
Люди виноваты что не могут писать все 256-ю символами. Напридумывали языков, шрифтов, написаний вот гады.
А нечего было Вавилонскую башню строить.
Пусть своими языками на заборе пишут, а в исходниках ASCII.
Реально видел на заборе слово БНАПНЯ (sic!). Использование заборов от проблем с кодировками не спасает, увы.
Расскажи это емодзи с модификаторами на цвет кожи. Математика, cjk символы и прочие текстовые прелести, естественно, я не предлагаю резать ради того, чтобы уложится в 8 бит, допустим.
Это косяки программ редакторов. Текст с направлением справа налево должен просто печататься задом наперед, но не должен залазить на предыдущий тескт. А про всякие буковки это мы и так знаем. Они прямо америку открыли. О нормализации юникода никогда не слышали?
А как именно Misrendered в vim в Linux? Кодировка что ли кривая и вопросик показывает?
А, виноват, слепой - это в Windows. Тогда нет вопросов.
>>>предложен ещё один вариант атаки (CVE-2021-42694), связанный с использованием омоглифовДень 96-ой
Директор покупает специально спроектированные солонки с кодовым замком. Посетители столовой чувствуют, что они в этой жизни чего-то не понимают.
Поэтому и появился язык Ада. Он в том числе разрабатывался для точной читаемости кода.
Вот здесь http://rosettacode.org/wiki/Category:Ada куча готовых решений различных небольших (и больших) задач на Ada.
Например, обычный бинарный поиск http://rosettacode.org/wiki/Binary_search#AdaНе сказал бы, что там такая уж "точная читаемость кода" - паскаль паскалем.
Соотношение сигнал/шум традиционно ужасное.
> опубликовали новую техникуСкуяли она новая? Детский баян конца 80-х - 90-х годов.
#include <stdio.h>\b\b\b\b\b\b\b\b\b /*\b\b "stdio.h" */\b\b
Препроцессор видел как: #include "stdio.h"Бэкспейсы естественно в гексах.
MS Word под DOS, или Нортон Командер из первых, бэкспейсы в сишниках (*.с, *.h, ...) игнорили
и отображали как пробелы. В Дельфи тоже было, в Борланде...Самой "технике" уже 3000-4000 лет....
Да чо там, Ильич на нарах писал молоком. )))
> Ильич на нарах писал молокомХотел спетросянить, но чудом удержался.
Вопрос был описан на Хабре лет несколько назад (давно уже). После чего я добавил в CudaText лечение - все эти символы показываются теперь явно хекс-кодами...., да и до этого наложения там не было, просто символы пропускались при рендере. Из того поста на русском никакого CVE никто не соорудил. В комментах хабра пожевали тему, пожевали, и разошлись по норкам....
> Вопрос был описан на Хабре лет несколько назад[censored]
Что сказать то хотел? :)
> Что сказать то хотел? :)Там (18+) ))
Для контента и там текстов ресурсов Unicode - штука незаменимая, но в исходниках не нужно и стоило бы на входе в компиляторы просто ставить какой-то фильтр.
> на входе в компиляторы просто ставить какой-то фильтр.Компилятор компилит то, что в него суют.
Конктретно в Cи, UTF-8/16/32 ещё надо уметь пропихнуть через wchar,
printf("%s\n", "我動搖了你"); не везде прокатит ))
По идее линтер не должен такоеьпропучкать.
И по подсветке кода можно увидеть что что-то не так.
По идее спелчекер тоже не должен пропускать всяческие "такоеьпропучкать", а поди ж ты.
>> В качестве меры для защиты рекомендуется реализовать в компиляторах, интерпретаторах и сборочных инструментах, поддерживающих Unicode-символы, вывод ошибки или предупреждения при наличии в комментариях, строковых литералах или идентификаторах непарных управляющих символов, меняющих направление выводаА писать на RTL-языках такие запреты не помешают?
Национальные символы в исходниках должны быть только в файлах .po
За все остальное пороть на конюшне.
Не. Символ "троеточие" - который юзается на концах строк меню - юникодный.
Запишешь кодом символа. Юзеру всё равно, а у тебя читабельный текст.
А еще есть непечатаемые символы. Вот где не паханое поле для злоупотреблений.
Нет. Они просто пропускаются при рендере или там например накладывают один глиф на следующий.
А кое где они часть языка, прикинь?
Данный троян используется с расчётом на невнимательность программиста. Просто надо либо //, котрый работает до конца строки, либо /* за которым может быть только 2 символа */.Старый трюк. Например, шрифт в терминалах должен визуально отличать символы: "латинский эл" и "цифра единица". Букву "о" от "цифры ноль".
Всегда ли программист просматривает уже отлаженные исходные коды перед сборкой, особенно если проект достаточно крупный? Вопрос риторический.И второй вопрос. Не является ли хранение исходных текстов на внешних сервисах благоприятным фактором для реализации сабжа, особенно если взлом может быть не зафиксирован длительное время?
Это делает борроф чекер
Вот чем чем, конкретно этим борроу чекер точно не занимается. В Visual Studio например этим может заниматься c++ core check. И в него же добавить правила про юникондные символы.
>Вопрос риторический.Не знаю, как в других языках. У чистых сишников принято преверять глазами исходные коды.
>Всегда ли программист просматривает уже отлаженные исходные коды перед сборкой, особенно если проект достаточно крупный?Так эта техника против тех, кто _смотрит_ код. Против тех, кто не смотрит, можно просто вносить правки, не опасаясь обнаружения.
анализатор сравнения набранных символов к отправляемым?
сравнениие сумм файла?
запись/чтение в изолированном окружении?
велосипед?
Обкуреный бред программиста, который не может выразить мысль.
Хиленько.
Сначала запихивали все что можно в юникод, а теперь удивляемся что там больше чем хотелось бы. Накину еще - символы (или их комбинация) не поддерживаемые конкретной либой, символы неотличимые визуально от других символов (впрочем сабж), разные пробельные символы которые парсятся одной либой, но другой считаются за непробельные.
То что ты "накинул еще", не дает проблем с секурити, не дает CVE.
> То что ты "накинул еще", не дает проблем с секурити, не дает
> CVE.Не дает но предрасполагает, что в реальном мире фактически дарит эти проблемы.
Так то если ты все везде будешь правильно проверять и обрабатывать то и Trojan Source для тебя невозможен, но дефакто вот он в новости.
На Юникод не наезжай, это правильная технология, он тут не причём. Ты как маленький виноваты все, но не ты сам.
Что ж в этом правильного?
1) Что-то много стандартов кодировок. Надоело! Давайте сделаем одну, пускай и медленную, но со всем фаршем! А нет, что-то не идет. Давайте еще к ней еще наклепаем пару кодировок! Да! UTF-8. А давайте еще UTF-16! А еще UTF-32! А еще 2 вида BOM добавим! А еще кривую реализацию для винды! Больше кодировок юникода! Больше!
2) Давайте кодировать как можно компактнее? Не, бред какой-то лучше давайте каждый символ, даже очень похожий будет кодироваться по отдельности? Ну чтобы различать эти символы. Разработчики железа уже за нас заплатили, гулять так гулять. Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А? А польское А это английское А? Ммм... логично? Не очень. Просто живи с этим. Но в большинстве других символов это не так. Мы сделаем тебе несколько одинаковых крестиков с разными кодировками.
3) А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо http://unicode.org/charts/PDF/Unicode-7.0/U70-10350.pdf! Ну и еще бесконечные эмодзи (эти хотя бы как-то используются, но имхо это довольно костыльно).
4) Так давайте добавим символы заставляющие текст писать справа налево (ха-ха, посмотрите на этих жалких разработчиков библиотек для нашей кодировки), но не добавим символов чтобы писать сверху вниз и снизу верх! Ок, все равно я никогда не любил китайцев.
5) Так, у нас столько всего есть, а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело. Встретимся через пару-десятков лет когда научишься хотя бы тестировать юникод.
6) Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...
7) А помните мы решили для каждого символа сделать свою кодировку? Что-то пошло не так, хакеры выдают xn--ggle-55da.com (о русская) за google.com за google.com.
Ну и что мы имеем? Гору библиотек разной степени безопасности, кривизны, функционала и производительности, несколько видов самого протокола, множество проблем как при его использовании, так и при работе с ним, и все равно есть проблемы с локализацией условного канадского диалекта французского.Итого семейство юникода худшее семейство кодировок:
Производительный: нет
Компактный: нет
Простой: нет
Безопасный для копирования: нет
Безопасный для приложения: нет
Решил проблему с языками: нет
Поддерживается шрифтами: нет
Специализирован: нет
Стал всемирным стандартом-горцем: нет
Можно добавить свой символ за мешок денег: да
Придется вам жить с этим: да> Ты как маленький виноваты все, но не ты сам.
Я просто вижу очевидные проблемы и говорю о них. Немного грустно что пришли к такому !@#$%, но искать виноватых я не намерен. И уж тем более мне не понятно в чем моя вина. Вот если бы заткнулся и восхвалял очевидно проблемную кодировку, то тут можно было меня обвинить в апатии.
>Что ж в этом правильного?Юникод рационален, поэтому правилен.
>Что-то много стандартов кодировок. Надоело! Давайте сделаем одну, пускай и медленную, но со всем фаршем! А нет, что-то не идет. Давайте еще к ней еще наклепаем пару кодировок
Флуд. А если по делу, то UTF-8 придумали отцы юниксоиды специально для англоговорящих стран, в нём неиспользуемые, или же малоиспользуемые символы кириллицы кодируются дополняющимися битами. Китайцы выбрали UTF-16 и UTF-32 потому-что их иероглифы не помещаются в 8 бит.
>А еще 2 вида BOM добавим!
Ты ошибся адресом, Юникод тут не причём. Отправляй претензию программистам текстовых редакторов.
>А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо
Что предлагаешь? Исследователям и учёным вместо символов векторные картинки всталять, ты серъёзно?
>Так давайте добавим символы заставляющие текст писать справа налево
Арабский мир щемишь? Они же с лева направо пишут.
Ты видимо решил процитировать всю Википедию? Ешё раз тебе говорю, Юникод - дна из самых лучших вещей, которое сделало человечество.
>>Что ж в этом правильного?
> Юникод рационален, поэтому правилен.От того что вы называете его рациональным, рациональнее он не становится.
> Флуд. А если по делу, то UTF-8 придумали отцы юниксоиды специально для
> англоговорящих стран, в нём неиспользуемые, или же малоиспользуемые символы кириллицы
> кодируются дополняющимися битами. Китайцы выбрали UTF-16 и UTF-32 потому-что их иероглифы
> не помещаются в 8 бит.И что это меняет? У нас есть 3 довольно сильно отличающихся кодировки и еще 4 вариации с различным BOM.
Как мы можем определить длину последовательности?
1) Зафиксировать длину (быстро, не расширяемо)
2) Обозначить динамически символом (зато все поместится)
Что делает юникод? Он для толстого UTF-32 ФИКСИРУЕТ длину кода, а для UTF-8 и UTF-16 НЕ ФИКСИРУЕТ длину кода. Так что и в микроконтроллеры не засунешь и гигабайты текста не сэкономишь на суперкомпьютере. И не быстрый (потому что диакритические знаки, парные символы, регистр превращает в другой символ, вот это все) и не ультимативно функциональный (потому что что-то недопихали) и не простой (потому что фарша гораздо больше чем может переварить большинство разработчиков).Немного про нейминг:
UTF-8 с динамической длинной кодирования 8 бит (вообще-то больше, но потом его ограничили. зачем?)
UTF-16 с динамической длинной кодирования 16 бит
UTF-32 с фиксированной длинной кодирования в 32 бит. WHAT? Почему же он называется также как и UTF-8 и UTF-16? Я могу решить что он тоже с динамической длиной.Также и с BOM напрашивается 2 стратегии:
1) всегда один и тот же BOM (хорошо для стандартизации и обмена)
2) для разных архитектур разный BOM (хорошо для производительности на некоторых архитектурах, плохо для всего остального)
Что делает Юникод для UTF-16 и UTF-32? Правильно не стандартизирует и не претендует на скорость. Т.е. худшее из двух миров.Зачем вообще нужен UTF-32 если он и не быстрый и все алфавиты не покрывает, но включает много чего ненужного? Да никто не знает. Он просто есть.
>>А еще 2 вида BOM добавим!
> Ты ошибся адресом, Юникод тут не причём. Отправляй претензию программистам текстовых редакторов.Не знаю повлияли ли как то на это текстовые редакторы, но виды BOM зафиксированы в стандартах юникода. Если их не под пытками добавили, то я по адресу.
>>А давайте запихнем в юникод знаки вымершей цивилизации, алхимические знаки, древнеегипетский или древнепермское письмо
> Что предлагаешь? Исследователям и учёным вместо символов векторные картинки всталять,
> ты серъёзно?А ты серьезно предлагаешь сначала на основании недостаточной длины кодирования символа придумать новые кодировки (UTF-16, 32), а потом забивать пространство "кодировки 21 века" плохоизученным древнегипетским? Завтра откопают альтарь ктулху, его символы тоже будешь добавлять? А что насчет графиков? Их тоже векторными картинками вставлять? Зачем такие полумеры? Может тогда сразу к растру перейдем - как кодируется, так и рисуется? Кроме того я не видел в научных кругах никого кто писал бы формулы юникодом (и ты тоже так не делаешь).
>>Так давайте добавим символы заставляющие текст писать справа налево
> Арабский мир щемишь? Они же с лева направо пишут.Нет, китайцев. Они же сверху вниз пишут и для них ничего такого нет. Или древних ливийцев. Логично что для кого-то есть а для кого-то нет?
> Ты видимо решил процитировать всю Википедию? Ешё раз тебе говорю, Юникод -
> дна из самых лучших вещей, которое сделало человечество.Повторяй это почаще.
Арабский мир пишет справа налево (только цифры слева направо)
Начать надо с того, что вы не отличаете понятия "кодовая страница" и "кодировка".Чтобы было понятнее, считайте, что UTF-8, UTF-16 и все они - это аналог ZIP, RAR, ARJ для обычного бинарного кода (юникода). И сразу часть претензий снимается, ибо они относятся не к юникоду, а вашим заблуждениям относительно него.
Далее, вы не в курсе, что поляки пишут латиницей. Тоже претензия снимается, хотя выглядит довольно забавно.
-- cut ---------
> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?Потому, что и русская и сербская - кирилличная.
> А польское А это английское А?
Польский алфавит, на секундочку, латинский. Потому, что латинская.
> Ммм... логично?
ДА!
> Просто живи с этим.
Хы.
--------- cut --> А давайте запихнем в юникод знаки вымершей цивилизации
Да, давайте. Мне нравится писать на древнеегипетском и я теперь могу это спокойно делать. А еще на нем можно программировать.
> Так давайте добавим символы заставляющие текст писать справа налево
Евреи тоже люди, как ни странно, и тоже хотят спокойно писать как привыкли.
> но не добавим символов чтобы писать сверху вниз и снизу верх
Да, хорошо было бы добавить.
> а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело.
Да, не их. С понятием RFC, я так понимаю, вы не знакомы?
> Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...
https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.
А вообще юзай Anonymous Pro - прекрасный программерский фонт с кириллицей.
> А помните мы решили для каждого символа сделать свою кодировку?
Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
> несколько видов самого протокола
О, откуда то всплыл какой-то протокол. Вы еще и что такое "протокол" не в курсе?
--------------------------------------------------------------------------------
Итого:
> Немного грустно что пришли к такому !@#$%, но искать виноватых я не намерен.Я вам помогу - нету тут виноватых. Просто потому, что никто к такому "!@#$%" не приходил.
Это все ваши голые фантазии, основанные на незнании и ошибочных представлениях о мире.
> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
>> несколько видов самого протокола
> О, откуда то всплыл какой-то протокол. Вы еще и что такое "протокол"
> не в курсе?Мб я и не писал корректно термины в 2 часа ночи, но сути это не меняет. Как были проблемы, так они и остались, а ваши ответы сводятся к "вы назвали отверстие дыркой".
> Начать надо с того, что вы не отличаете понятия "кодовая страница" и
> "кодировка".В контексте не принципиально.
> Чтобы было понятнее, считайте, что UTF-8, UTF-16 и все они - это
> аналог ZIP, RAR, ARJ для обычного бинарного кода (юникода). И сразу
> часть претензий снимается, ибо они относятся не к юникоду, а вашим
> заблуждениям относительно него.Спасибо, я в курсе, только проблем это не решает. Нам по-прежнему нужно это учитывать, по-прежнему нужно переформатировать кодировку под разный софт(потому что он не ожидает например unicode с BOM), по-прежнему нужно досконально выбирать либы. Проблем не сильно меньше чем с наличием совершенно разных кодировок. Почему претензии должны быть сняты не понятно.
> Далее, вы не в курсе, что поляки пишут латиницей. Тоже претензия снимается,
> хотя выглядит довольно забавно.
> -- cut ---------
>> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?
> Потому, что и русская и сербская - кирилличная.
>> А польское А это английское А?
> Польский алфавит, на секундочку, латинский. Потому, что латинская.Но претензия была не к польскому, а к различию подходов для разных символов.
Напрашивается очевидные 2 стратегии:
1) похожие символы кодировать одним значением экономя байты (и бонусом есть шанс что пользователь различит 0 от о).
2) каждый символ кодировать своим значением, обеспечивая 100% идентификацию каждого символа и немного упрощая жизнь разработчиков, позволяя например в парсере ограничить русский язык просто фильтруя все что не входит в диапазон русского языка (и для русского в юникоде так и работает, но не для всех языков).
Но юникод СМЕШИВАЕТ оба подхода, нивелирует плюсы и получает минусы от обоих>> Минуточку, а почему сербская А КОДИРУЕТСЯ как русская А?
> Потому, что и русская и сербская - кирилличная.По такой логике и кириллическая А это латиница.
>> А давайте запихнем в юникод знаки вымершей цивилизации
> Да, давайте. Мне нравится писать на древнеегипетском и я теперь могу это
> спокойно делать. А еще на нем можно программировать.Сам пошутил, сам посмеялся. Надеюсь для программирования вы не используете Модификатор эмодзи для шкалы Фицпатрика тип-4 или Заполнитель хангыль чхосон (что это вообще такое?).
Кстати о программировании - в юникоде есть вариантные селекторы что теоритически удобно для программирования, но на практике их никто не использует (по-крайней мере я не знаю об этом).
>> Так давайте добавим символы заставляющие текст писать справа налево
> Евреи тоже люди, как ни странно, и тоже хотят спокойно писать как
> привыкли.
>> но не добавим символов чтобы писать сверху вниз и снизу верх
> Да, хорошо было бы добавить.Вот и я про то же: кто-то люди, кто-то не люди, зато вы можете на древнеегипетском писать.
>> а где взять библиотеки чтобы это отобразить? Удачи, это не наше дело.
> Да, не их. С понятием RFC, я так понимаю, вы не знакомы?Почему то многие забывают что стандарты надо писать чтобы им следовали, а не чтобы их написать. Наличие RFC не делает из мифического вечного двигателя решение проблем с получением энергии. И юникод забывает про это больше остальных.
>> Подскажите шрифт для юникода? Для латиницы вот эти, для русского вот этот, вот этот для математических символов...
> https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.Но он только для части юникода. Я же не хочу чтобы часть символов у меня была одни шрифтом, а часть другим (это если вообще либа так умеет, сочувствую разработчикам что ее писали).
>> А помните мы решили для каждого символа сделать свою кодировку?
> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
>> несколько видов самого протоколаУход от ответа.
Вот вам добавка: коллизии повышения и понижения регистра когда символ из одного алфавита после смены регистра становится ДРУГИМ символом и обратно его не восстановить! БЕСКОНЕЧНО БОЛЬШАЯ СТРОКА КОТОРУЮ НЕЛЬЗЯ РАЗДЕЛЯТЬ потому что она состоит из кучи диакритических знаков, отсутствие(например удаление) каждого меняет букву(ы).
> Я вам помогу - нету тут виноватых. Просто потому, что никто к
> такому "!@#$%" не приходил.
> Это все ваши голые фантазии, основанные на незнании и ошибочных представлениях о
> мире.Ну да, проблем с юникодом нет, сам стандарт совершенно не переусложнен, каждый второй студент знает его наизусть как ASCII, проблем с его отображением, редактированием нет, для использования уже давно достаточно не парясь подключить какую-нибудь бибилиотеку, каждые полгода не всплывает никаких новостей что приложение N опять можно положить прислав строку на иврите, а сабжевая новость это розыгрыш к следующему 1 апреля. Успокаивайте себя дальше.
> Но претензия была не к польскому, а к различию подходов для разных символов.Я вам только что показал, что подход совершенно одинаковый.
Польское "А" - это латинское "А". У поляков письмо - латиница(!). Поэтому их "А" - это английское "А", немецкое "А", фрацузское "А".
Сербское "А" - это кирилличное "А". У сербов письмо - кириллица(!). Поэтому их "А" - это русское "А", болгарское "А", белорусское "А".
Подход - одинаковый. И правильный.
> По такой логике и кириллическая А это латиница.
Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы". Думайте.
> каждый символ кодировать своим значением, обеспечивая 100% идентификацию каждого символа
Оно так и есть. Кирилличная "А" вне зависимости от языка кодируется как кирилличная "А". И даже если какая-нибудь донская область внезапно объявит себя Донской Республикой со своим, Донским Языком (вернет в язык букву ѣ), всем программистам мира не придется переделывать таблицу юникода.
> и немного упрощая жизнь разработчиков, позволяя например в парсере ограничить русский язык просто фильтруя все что не входит в диапазон русского языка (и для русского в юникоде так и работает, но не для всех языков).
Какого именно русского языка - до реформы 1918 или после? Вы предлагаете менять таблицу кодов под каждое изменение национальных правил, заставляя переписывать все парсеры?
Языки, напомню, развиваются. В них появляются и исчезают даже буквы (украинцы вернули букву ґ, например - совершенно непонятно зачем, но закон есть закон). Теперь что, всю украинскую кодировку после "г" сдвигать и все переписывать? А как насчет русской "ё", которая то есть, то нет (гляньте на википедии, там статья почти как война и мир по размеру)?И, в конце-концов, вам так сложно в парсере сделать бинарный поиск по собственной таблице допустимых национальных символов? Это будет почти так же быстро, как и проверка x <= y <= z,
У меня парсер, например, так и делает. Он даже умеет приводить буквы любого языка из нижнего в верхний регистр - когда выходит обновление таблицы юникода, куда включают новые языки (или меняют правила для уже существующих) я запускаю скрипт, который парсит последнюю редакцию CaseFolding.txt из https://www.unicode.org/Public/ и генерирует мне простую табличку, сложность поиска по которой составляет log(n).
>> Вы путаете понятия character и letter. Вы путаете понятия "кодирование" и "кодировка".
> Уход от ответа.Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.
> коллизии повышения и понижения регистра когда символ из одного алфавита после смены регистра становится ДРУГИМ символом и обратно его не восстановить!
Это особенности естественных языков. Юникод им только следует, не более того.
Да, греческую "ᾙ" действительно можно приводить либо к "ᾑ" либо к "ἡι" - это особенности правописания. И эти особенности отражены в юникоде.Так что, теперь еще человеческие языки переделывать, вот прям с Плутарха начиная? Для вашего удобства?
Ого как замахнулись.>> https://en.wikipedia.org/wiki/GNU_Unifont - 60691 глиф.
> Но он только для части юникода.Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
Цитирую:The Unicode Basic Multilingual Plane covers 216 (65,536) code points. Of this number, 2,048 are reserved for special use as UTF-16 surrogate pairs and 6,400 are reserved for private use. This leaves 57,088 code points to which glyphs can be assigned. Some of these code points are special values that do not have an assigned glyph, but most do have assigned glyphs.
GNU Unifont покрывает ВСЕ ваши потребности в юникоде, причем с запасом. 60691 глифов против 57088 предлагаемых.
> сам стандарт совершенно не переусложнен
Стандарт прост как два байта. Что может быть проще таблицы всех человеческих букв/рун/символов письма?
> каждый второй студент знает его наизусть как ASCII
Я уверен, 999999 ил 1000000 тысяч студентов не скажут код буквы "ё" в любой из кириллических кодировок. Да даже код ETX или SYN из ASCII не скажут, как и вы.
Так что даже тут вы, мягко говоря, облажались.
--
На этом, надеюсь, все? Можете сделать выводы из написанного и немножечко дообразоваться? Или будете просто глупо упираться в свои заблеждения, как всегда делают 95% народонаселения.
> Подход - одинаковый. И правильный.
> Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы".Если по происхождению формировать блоки, то по вашей логике кириллица должна использовать глаголицу и например ь в русском должен быть U2C13 а не U042C. Но в юникоде это не так. Т.е. как сделано в юникоде все равно не логично, а если бы и было сделано по такой логике то это все равно был бы кусок !@#$%%^, т.к. логика сводить к историческим причинам крайне не надежно - что там было в древности никто не знает, исторические представления неоднократно переписывались и что делать если на язык воздействовало сразу два языка с одинаковым символом и какой из них оказал большее влияние - не понятно.
> Оно так и есть. Кирилличная "А" вне зависимости от языка кодируется как кирилличная "А". И даже если какая-нибудь донская область внезапно объявит себя Донской Республикой со своим, Донским Языком (вернет в язык букву ѣ), всем программистам мира не придется переделывать таблицу юникода.
Сами юникодовцы придумали проблему - кодировать символы, а не глифы, сами же от нее отказались делая такое "наследование" между схожими алфавитами, сами же придумали планы и разделение внутри планов, самим же пришлось тусовать планы как придется без всякой логики.
Просто кодируйте глифы и не надо никаких заморочек с алфавитами, историей и т.д..>Какого именно русского языка - до реформы 1918 или после? Вы предлагаете менять таблицу кодов под каждое изменение национальных правил, заставляя переписывать все парсеры?
> Языки, напомню, развиваются. В них появляются и исчезают даже буквы (украинцы вернули букву ґ, например - совершенно непонятно зачем, но закон есть закон). Теперь что, всю украинскую кодировку после "г" сдвигать и все переписывать? А как насчет русской "ё", которая то есть, то нет (гляньте на википедии, там статья почти как война и мир по размеру)?Я то как раз против разделения по семантике (за глифы и там таких проблем нет принципиально и бнз маппинга принципиально не обойтись). А юникодовцы сами себе проблемы придумали разбивать по блокам и теперь тасуют и блоки как придется и вроде как и не глифы но вроде как и не совсем семантика.
> Это будет почти так же быстро, как и проверка x <= y <= z,
Почти также быстро это логарифмическая сложность против константной? Вы это серьезно?
> Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.
Ошибка весьма условная и в кругу дотошных филологов можно долго выяснять что значит кодировка на русском, charset на английском и что они значили до юникода. Все всё поняли, но снобы все равно посмеялись чтобы потешить ЧСВ. Вы же называете логарифмическую сложность почти такой же быстрой как и константную и это уже не смешно.
>Это особенности естественных языков. Юникод им только следует, не более того.
> Да, греческую "ᾙ" действительно можно приводить либо к "ᾑ" либо к "ἡι" - это особенности правописания. И эти особенности отражены в юникоде.Это особенность семантического разделения. Или недосемантического как в юникоде.
> Стандарт прост как два байта.
Ну да, ну да. Видимо в этой https://www.oreilly.com/library/view/unicode-explained/05961.../ книге первые 10 страниц рассказывается как все просто, а оставшиеся 670 страниц пустые. И в других книгах https://www.unicode.org/announcements/books.html то же самое. И документация только core specification на 1000+ страниц просто была рассчитана на альтернативное использование в виде топки, а не распухла из-за излишней сложности. А бесконечное статьи от опытных разработчиков про проблемы с юникодом это затянувшиеся на несколько лет первоапрельские розыгрыши.
> Что может быть проще таблицы всех человеческих букв/рун/символов письма?
О нет, это до юникода кодировки в основном были таблицами (которые юникод должен был устранить и как раз он первый из популярных перестал отображать конкретный символ в конкретную последовательность бит), а юникод это еще и гигантское количество правил для отображения и в них вся загвоздка.
>Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
>Цитирую:
>The Unicode Basic Multilingual Plane covers 216 (65,536) code points. Of this number, 2,048 are reserved for special use as UTF-16 surrogate pairs and 6,400 are reserved for private use. This leaves 57,088 code points to which glyphs can be assigned. Some of these code points are special values that do not have an assigned glyph, but most do have assigned glyphs.
>GNU Unifont покрывает ВСЕ ваши потребности в юникоде, причем с запасом. 60691 глифов против 57088 предлагаемых.Тогда почитайте получше потому что в цитате вы упустили _Basic_Plane, что значит что шрифт покрывает только базовый план и еще на сайте http://unifoundry.com/unifont/index.html они указывают что поддерживают 12613 глифов plan1, а всего их планов 16 и пускай большая часть не заполнена, но как миниум plan2 в unifont'е нет, а значит и всей поддержки юникода тоже нет.
>Перечитайте то, что я написал выше. Погуглите "кириллица" и "история появления кириллицы". Думайте.
>Слив засчитан. Будем считать, что вы поняли ошибку но решили ее просто замять, ибо слишком позорно.
>Так что, теперь еще человеческие языки переделывать, вот прям с Плутарха начиная? Для вашего удобства?
>Ого как замахнулись.
> Вы на английском читать не умеете? Ну тогда понятно откуда такое желание все взять и переделать.
> На этом, надеюсь, все? Можете сделать выводы из написанного и немножечко дообразоваться? Или будете просто глупо упираться в свои заблеждения, как всегда делают 95% народонаселения.По делу сказано не много и много неправильного, но спеси как от всех гениев человечества вместе взятых.
Великий Расс Биг Кок из го-тимы уже уничтожил этот "баг" и заодно всю раст-тиму https://research.swtch.com/trojan
Что же, если раст-тима уничтожена, то значит теперь никаких новостей и разговоров про Rust на опеннете не будет? А если будет, значит ли это, что вы просто трясете своими текстами в бессильной злобе, потому что с растом не происходит того, что вы ему желаете?
КМК, если уж мы за мульти…генд^W направленность текста, надо добиваться корректной отрисовки. При подобном методе "зачистки", исходные символы должны бы обзавестись подозрительной "лапшой".С другой стороны, сам факт смены направления "inline" заслуживает некой пометки. Это ж практически UB: дальше нужно как-то выяснить с какого места "канвы" продолжать чтение.
Фиксить компилятор. Омайнгад. Тока растоманы могли до этого додуматься.))
Простейший фикс - пересохранить файл как кои-8 или cp866.
Безумный, безумный, безумный мир
Вместо того, чтобы приносить пользу, код приносит вред
Это ещё раз доказывает, какие ДE6ИЛЫ проектировали юникод. Маялись маялись, 1 байта им мало, ASCII им мало, так на тебе ТРИ стандарта юникода, да ещё вот эта идиотия прямо в стандарте символов(!!!) написание слева направо - разве это не забота операционной системы?!?! Символ - это значок, ни больше, ни меньше. Ублюдство юникода ещё долго будет канифолить нам мозг (как и USB).
Это они от добра хотели, чтобы в одном файле были и левые английские тексты, и правая вязь...
Нет. Правильное отображение текста справа-налево зависит от его смысла. В простом тексте смысл выражается особыми символами.
>Это ещё раз доказывает, какие ДE6ИЛЫ проектировали юникод ...
>Ублюдство юникода ещё долго будет канифолить нам мозг (как и USB).И это русский педагог? Мда, когда русский человек внезапно поносит технологию, это может означать одно - он просто её не осилил и не понял. Gogi свои сообщением полностью раскрыл загадочную русскую душу.
if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {Чушь какая-то. Мой slickedit никак на такое не реагирует -- все зависит от кодировки. Если у Вас utf8, мусор из utf16 просто не распознается -- "stray in code".
это вот так внедрили системди получается?