OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 18 Ноябрь, 2019 11:14

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 105 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 12 Апрель, 2019 10:44 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1283
Откуда: Украина, Киев
Rifat писал(а):
Мне кажется, что все равно всем не угодишь. Даже, если ё будет стоять на своём месте, возникнет вопрос о расположении разных специальных символов и о том, в каком порядке должны сортироваться строки: "aaa", "a_a", "a.a", "a a", "a-a" и т.д. Все равно нужно будет использовать специальную функцию, которая будет задавать определенную очередность (возможно, не совпадающую с номером символа в таблице) для сортировки в соответствие с нашими требованиями.
Вот, здравое направление мысли. Вообще-то во всех 8-ми битных таблицах спец.символы находятся в первой половине таблицы и во всех таблицах эта первая половина совпадает. Эта часть соответствует символам ASCII. А ASCII изначально вообще была 7-ми битной - это пришло из телеграфии.
Другое дело, что там нет всех необходимых спец. символов, например, знаков валют (рубля, евро, гривни и т.д.). Далее, возьмите любой маломальски сложный научный или технический текст... Там уже потребуются некоторые символы греческого алфавита. Допустим, можно выкинуть символы псевдографики... Но они нужны, если мы будем эмулировать, например, экраны каких-то технологических устройств. Такое было в моей личной практике.
В конце-концов, мы прийдём тому, что 8-ми битной кодовой таблицы недостаточно! :mrgreen:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 11:09 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Ярослав Романченко писал(а):
budden писал(а):
Да, при желании - это ключевое слово здесь, или при возможности.
Вот, вы вынули шашку и размахиваете тут... А KOI-8 вообще не решает проблему сортировки и буква ё, кстати, тоже на отшибе где-то торчит. Так зачем всё-таки KOI-8???

Да не, не размахиваю. Просто хотел быть понятым. У меня нет и не предвидится ресурсов заниматься A2, даже при наличии желания. KOI-8 - не догма, просто, раз 8-разрядные кодировки уже поддерживались, я думал, что их можно быстро починить и получить решённую задачу-минимум - т.е. полноценную и без глюков поддержку русского языка. Честно сказать, сейчас время прошло и я даже не особо помню ни то, что я выяснил о статусе поддержки РЯ в А2, ни то, что я сам починил. Возможно, что KOI и CP тоже не фонтан, но ведь их все сделали в одной и той же стране, которая считает нашу страну недружественной. Тактика 1000 уколов и т.п. Возможно, кто-то меня осудит за то, что я перевожу вопрос кодировок в политическую плоскость, но если смотреть сверху, то он именно таким и является, и если бы я не чувствовал, что наша страна в опасности из-за компьютерных технологий, я бы вообще занимался совершенно другим - есть более интересные вещи для хобби.

Так же и Китай для США является той страной, которую нужно сдерживать. Поэтому следует ожидать (и почти наверное это так), Китай не может быть удовлетворён качеством американских стандартов представления текста. Тогда напрашивается вопрос о том, что рано или поздно будут приняты другие стандарты. Хоть тут не все из России и не знаю, насколько дружественно относятся, но для России важно вовремя поставить этот вопрос.

Потому что инструменты сдерживания и просто закладки могут быть и на уровне "международных стандартов", которые по сути являются стандартами США. Россия же не переводит свои войска на стандарты НАТО. Тогда почему компьютеры, которые для безопасности значат не меньше, работают по стандартам НАТО?

Как-то так.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 12:48 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Почти наверное в данном случае это не ответ. Если бы у вас были ресурсы, вы более строго бы подходили к вопросу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 14:22 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1283
Откуда: Украина, Киев
budden писал(а):
Сняв таким образом аксиому о приверженности стандартам, можно решить задачу по-нормальному. Но, поскольку я сам ничего не делаю, то никого ни к чему не призываю, просто озвучил свои мысли.
Я вас услышал. Политика политикой, а стандарты есть стандарты. Пока существующие стандарты хоть как-то поддержку языков решают нам остаётся лишь им следовать. Если Россия разработает какой-то лучший стандарт, который будет решать эти проблемы лучше, перейдём на него.
Ключевая мысль тут - стандарт должен быть. Иначе будет бедлам и хаос. И хаос привносить не нужно, какими благими намерениями это не прикрывалось бы.
Кстати, если китайцев возможно таки ужать в двух-байтовую кодировку... На уровне ощущений, что большей частью иероглифов они не пользуются :D
Вспоминается фраза из фильма "Кунг-Фу суета", произнесённая китаянкой... "Он что-то начертил по-китайски, я не понимаю" :lol:
Вполне возможно, что большая часть их иероглифов по-сути - мёртвая часть языка, которой никто давно не пользуется и которая осталась лишь на каких-то старых папирусах в храмах.
Двухбайтовая кодировка была-бы оптимальна для всех применений. Пока такой фокус не удаётся, только 4 байта...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 18:52 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Ладно, мнениями обменялись, на этом можно и остановиться пока. Спасибо за беседу!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 19:26 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
Ярослав Романченко писал(а):
Кстати, если китайцев возможно таки ужать в двух-байтовую кодировку... На уровне ощущений, что большей частью иероглифов они не пользуются :D
Если память не глючит, что уже возможно:
Очень хорошо гуманитарно-образованный китаец знает до 40К иероглифов.
Современная литература -- тыщ 20.
Но вообще их -- всяких старинных и вариантов -- страшная сила, включая уникальные в фамилиях и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Апрель, 2019 19:56 

Зарегистрирован: Пятница, 13 Март, 2015 16:40
Сообщения: 357
Цитата:
"a.a", "a a"

Терминаторы ж в середине... Ж8-///


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 00:58 

Зарегистрирован: Воскресенье, 09 Декабрь, 2018 15:14
Сообщения: 54
Откуда: Equestria
Ярослав Романченко писал(а):
А альтернатива вразумительная Юникоду есть?
Насколько известно - нет. И не похоже что в ближайшее время что-то появится.
Но для внутреннего использования можно запилить велосипед удобный для обработки текста.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 08:11 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1283
Откуда: Украина, Киев
SovietPony писал(а):
Ярослав Романченко писал(а):
А альтернатива вразумительная Юникоду есть?
Насколько известно - нет. И не похоже что в ближайшее время что-то появится.
Но для внутреннего использования можно запилить велосипед удобный для обработки текста.
Зачем велосипед? Кодеки все есть. Получаем объект кодека и через него строку в любой нужной кодировке :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 09:23 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Ну ладно, раз уж тема приобретает хронический характер, давайте посмотрим на голанг опять же. Там принят utf-8, который можно за одно приведение типа превратить в "массив рун", где руной является code point.

Вот мой код для операции trim, упрощённый вот из этого:
https://github.com/budden/rqr/blob/mast ... ted.go#L15
Код:
func trimToTheNumberOfRunes(s string, n int) (res string) {
   r := []rune(s)
   len := len(r)
   if n < 0 {
      panic("Negative n")
   } else if len <= n {
      res = s
   } else {
      res = string(r[0:n])
   }
   return
}

Что на самом деле делает внутри строчка r := []rune(s)? А не так уж мало. Она создаёт новый массив для чего-то типа int32 (опа, мы уже попали на выделение данных переменного размера - нагрузили сборщик мусора, а теперь ищем по форуму сообщения людей, которые специально пишут код так, чтобы сборщик мусора вообще не использовался, встаём на их место и уже начинаем плакать). Какого размера? Думаю, размер будет равен длине изначальной строчки байт (в которой записан текст в кодировке utf-8). Т.е., если у нас было N байт занято латиницей, то мы выделяем ещё 4N. Далее строчка парсится и записывается в массив. При этом utf-8 может оказаться невалидным - эти места записываются как специальная буква "ошибочный utf-8", а дальше, видимо, чтение восстанавливается. Замечательно здесь даже то, что процесс восстановления в данном случае находится вне нашего контроля, но допустим, если надо, мы можем навелосипедить своё.

После этого, слава Богу, мы получаем некий текст длины, как я надеюсь <= len(исходный массив байт). Т.к. что будет при ошибках чтения - я просто не знаю. Затем мы делаем trim массива и затем преобразуем обратно в string.

В случае же 8-разрядной, или 32-разрядной кодировки trim - это просто обрезание массива до нужной длины. Это различие между O(1) и O(N) позволяет, например, заспамить наш сервер гигантскими URL-ами, разбор которых вызовет замедление работы. Т.е. вот так, на ровном месте, опять получили уязвимость.

Вот тут есть живой пример с этой функцией: https://play.golang.org/p/_9GORMo2FTG
Можете убедиться, что хой превратился в хои (кривое и-краткое я взял отсюда https://play.golang.org/p/7N_sYD6FAIo)

И это представляет из себя угрозу безопасности даже.
Кроме того, посмотрите, как безобразно визуализируется в журнале []runes - "конь" печатается как [1082 1086 1085 1100].

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 10:21 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1026
Info21 писал(а):
Но вообще их -- всяких старинных и вариантов -- страшная сила, включая уникальные в фамилиях и т.п.

Не того надо бояться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 10:48 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Прекрасен, конечно, и сам факт, что в 1994 году в Клиппере у меня была функция TRIM, а в 2019 я должен писать её сам. Прогресс налицо. Зато международные стандарты ;)


Последний раз редактировалось budden Суббота, 13 Апрель, 2019 10:52, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 10:52 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Да, и ещё. Очень легко по ошибке решить, что можно применить обычное обрезание массива байт, содержащего строку в utf-8. И для латиницы это даже будет работать. tcl/tk и скайп так и делают, поэтому они являются глючными программами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 11:11 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1283
Откуда: Украина, Киев
budden писал(а):
Прекрасен, конечно, и сам факт, что в 1994 году в Клиппере у меня была функция TRIM, а в 2019 я должен писать её сам. Прогресс налицо. Зато международные стандарты ;)
Ну, это немножко смешение тёплого с мягким :) Это расплата за код переменной длины всего-лишь. Кто вам мешает на входе преобразовать все строки в руны, дальше обрезать руны как хочется, потом уже при выводе преобразовать в UTF-8 обратно...
И, кстати, проблему со шрифтами в А2 я уже решил, не прибегая к кодированию :roll: viewtopic.php?p=107380#p107380


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 11:25 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Ярослав Романченко писал(а):
Кто вам мешает на входе преобразовать все строки в руны, дальше обрезать руны как хочется, потом уже при выводе преобразовать в UTF-8 обратно...

Мешает то, что библиотекам сплошь и рядом нужны не руны, а строки. Например, регулярные выражения: https://golang.org/pkg/regexp/#Compile
Также мешает то, что массив рун не печатается строкой - его ещё нужно преобразовывать при абсолютно любом выводе, что, конечно же, очень неудобно.
Цитата:
И, кстати, проблему со шрифтами в А2 я уже решил, не прибегая к кодированию :roll: viewtopic.php?p=107380#p107380

Хорошо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 12:07 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Нда, что-то я про всё это думаю и начинаю сомневаться, что мне вообще нужен голанг. "Такая корова самому не нужна". Потому что есть та же Java, где, по слухам, со строками всё нормально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 16:31 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4336
Откуда: Россия, Орёл
budden писал(а):
Потому что есть та же Java, где, по слухам, со строками всё нормально.

Ага. Точно как и в КП.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 13 Апрель, 2019 16:49 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
Хорошая шутка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2019 09:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
budden писал(а):
Хорошая шутка.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 14 Апрель, 2019 11:33 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 623
А, понял смысл высказывания. Тогда получается, что в Java не всё нормально со строками - просто я некритично прочитал какую-то статью то ли на Хабре, то ли где-то ещё, где рассматривался подход к строкам в разных ЯП и Яву хвалили за тоталитарность её решений. Вообще похоже на то, что несколько строковых типов в полноценном (системного уровня) языке неизбежны. То, что мы видим в Windows - то правильно. Потому что есть не только внешние системы в сети, но и подключаемые устройства со своими понятиями о том, что такое строка.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 105 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB