function upper(s)
local str=""
for i=1,string.len(s) do
local byte=string.byte(s,i)
local char=string.char(byte)
if(byte>= 97)and(byte<=122)then char=string.char(byte-32) end -- Латинские буквы
if(byte>=224)and(byte<=255)then char=string.char(byte-32) end -- Русские буквы
if(byte==184) then char=string.char(byte-16) end -- Русская ё
str=str..char
end
return str
end
function string.upper ( str ) return str:gsub ( "([a-zа-я])", function ( c ) return string.char ( string.byte ( c ) - 32 ) end ) end
function string.lower ( str ) return str:gsub ( "([A-ZА-Я])", function ( c ) return string.char ( string.byte ( c ) + 32 ) end ) end
Классный способ, еще бы в нем русскую "ё" учитывать, было бы идеально.
Пользователь
Сообщений: Регистрация: 03.02.2021
05.05.2021 13:11:30
BlaZed, действительно, промах. Ну это в любом случае просто велосипединг. Правильный вариант - использовать системные функции и языковую локаль - первым ответом был предложен.
Код
function string.upper ( str ) return str:gsub ( "([a-zа-яё])", function ( c ) return string.char ( string.byte ( c ) - ( c == 'ё' and 16 or 32 ) ) end ) end
function string.lower ( str ) return str:gsub ( "([A-ZА-ЯЁ])", function ( c ) return string.char ( string.byte ( c ) + ( c == 'ё' and 16 or 32 ) ) end ) end
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
05.05.2021 18:28:39
Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
swerg написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
Да! Как тут тегнуть разработчиков Lua QUIK? Конечно они должны сделать нормально работающие РУССКИЕ БУКВЫ по умолчанию!
Пользователь
Сообщений: Регистрация: 30.01.2015
06.05.2021 23:03:35
Цитата
swerg написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
интерфейс у терминала не только русский, увы...
Пасхалочка для Алексея Иванникова:
Пользователь
Сообщений: Регистрация: 20.12.2020
06.05.2021 23:47:22
Цитата
написал:
Цитата
написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
интерфейс у терминала не только русский, увы...
И все же это ошибка
Запускать на только что запущенном квике, пока никакой скрипт локаль не установил еще
Как видно из примера, квик знает про нужную локаль, но почему то не устанавливает ее сам, хотя надо бы.
QUIK 8.13.1.16, интерфейс русский, Windows 10
Пользователь
Сообщений: Регистрация: 03.02.2021
07.05.2021 05:36:12
BlaZed, эта функция берет системную локаль. У вас системная локаль совпадает с требуемой, у меня - English_United States.1252 и на ней преобразование регистра кириллицы не работает (в ней кириллицы-то нет).
По-хорошему, решение тут это перекомпилировать квик с поддержкой юникода (давно пора!) и все эти проблемы отпадут сами собой. Заодно не нужно будет пердолиться с настройками чтобы квик показывал человеческие буквы а не неандертальские крякозябры.
В отсуствии юникода нужно ставить локаль. Такие вещи устанавливать автоматически на стороне программы это плохая практика, но с учётом того что поддерживается только одна-единснтвенная кодировка 1251 то имел бы смысл устанавливать соответствующую локаль автоматически.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.05.2021 10:14:23
Цитата
Артем написал: имел бы смысл устанавливать соответствующую локаль автоматически
Ага, не забыв при этом дать доступ на чтение символа разделителя дробной части числа (для строковых операций с числами). Сравните:
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
07.05.2021 10:17:41
Артем, Вот токо поддержки юникода Квику не хватало! Квик - это программа ДЛЯ ТОРГОВЛИ! И до тех пор, пока эта часть не заработает как часы, всю остальную херню вроде upper-lower надо вычищать отседова поганой метлой! Как я писал в своей книге (про JS):
Язык JavaScript. Количество никому не нужного мусора просто невероятное! Полное ощущение, что создатели языка ставили своей задачей поиздеваться над программистом и здравым смыслом. Методов-то, методов! В глазах рябит! Ну, очевидным образом anchor,big, blink, bold, fixed, fontcolor, fontsize, italics, lastIndexOf, link, small, strike, sub, sup отправляем на помойку. А charAt, indexOf, substring, toLowerCase, toUpperCase, возможно, ещё на что-то сгодятся. Кстати, у indexOf есть ещё пара нюансов, которые могут оказаться полезными: во-первых, искать может не только символ, но и подстроку и, во-вторых, может искать с определённой позиции (если задан второй аргумент).
Кошмарики с Date: getYear, getMonth, getDay, getHours, getMinutes, getSeconds, getTimezoneOffset, toGMTString, setSeconds и т.д. сведут с ума любого. И, главное – зачем?! Зачем это пользователю? Что, программисту заняться больше нечем?! Первое же из того, что нам действительно необходимо, повергает программиста в шок. Итак, прошу любить и жаловать – метод charAt: возвращает символ из строки. Синтаксис: StringName.charAt(index); Нет, позвольте – какой ещё «метод»?! Это же всего лишь строка! У всех нормальных людей принято: Symbol=StringName[index]. Так я и думал вначале. Поверил же я в происходящее, когда увидел радостный вопль в учебнике: отныне можно var s=new String("a") – ура, товарищи! Это было реальное потрясение: что же ещё насовали в несчастную строку?
Украденный синтаксис языка С используется приблизительно в том же смысле, и лишь незначительно изуродован. Впрочем, в противном случае JS не просуществовал бы и недели. Самое ужасное, что JS при этом при всём – это всё-таки лучшее из того, что есть на клиенте!
Как оказалось, JS не способен интерпретировать функций, тела которых расположены в переменных – они должны быть явно прописаны в теле страницы. Убей, не понимаю, какая разница – но делать нечего: базовый набор функций придется подгружать на морду путём генерации тела функций из переменных во фреймы виртуальных страниц. Опера не умеет перерисовывать группу фреймов, а Сафари – наоборот: только группу и может. Лиса прекрасно всё рисует, но… только в том случае, если страничка будет иметь расширение SVG. Если переименовать её в HTM – девственно чистый лист! После редактирования браузер quot втихаря заменяет на кавычки. Вот кто тебя просил?! Кавычка (как метаданные) предназначена для конкретного интерпретатора, и тут их сразу пять штук! Кавычка, которую должен увидеть юзер на экране – это вовсе не та кавычка, которую должен увидеть браузер как ограничитель параметра тега. И вовсе не та кавычка, которую должен увидеть интерпретатор JS, для которого она часть тела функции. И вовсе не та кавычка, которую должен увидеть монитор, для которого она разделитель параметров очереди. И вовсе не та кавычка, которую должен увидеть SPS, запихивающий все остальные кавычки на морду, кроме тех, которые он опознает как свои, и интерпретирует соответствующим образом. Проблема вовсе не загнать кавычку в строку, проблема не перепутать их разными итерпретаторами! А тут ещё «интеллектуальный» браузер гадит…
Вам хочется и здесь огрести подобного говна, господа? Мало того, что есть, ещё хочется?
Пользователь
Сообщений: Регистрация: 23.01.2021
07.05.2021 10:58:44
Цитата
Старатель написал: не забыв при этом дать доступ на чтение символа разделителя дробной части числа (для строковых операций с числами).
Да, я тож переживал на тему смены "американской десятичной точки 0.5" на "русскую десятичную запятую 0,5", но вроде норм -- старый код работает в математических выражениях типа
Код
os.setlocale('Russian_Russia.1251') --'ru_RU.CP1251' для FreeBSD, 'rus_RUS.CP1251' для линукса, 'Russian_Russia.1251' для Windows
b = 1
a = b + 0.5
message(tostring(a))
1,5 таки получается -- я переживал, что сглючит, распознав десятичную точку как разделитель тысяч или ещё как и будет математическая ошибка -- но вроде всё норм. Продолжаем в коде писать десятичную точку, хотя во внешнем выводе видим десятичную запятую :-) Потому что если написать
Код
os.setlocale('Russian_Russia.1251') --'ru_RU.CP1251' для FreeBSD, 'rus_RUS.CP1251' для линукса, 'Russian_Russia.1251' для Windows
b = 1
a = b + 0,5
message(tostring(a))
1 будет :-)
Пользователь
Сообщений: Регистрация: 03.02.2021
07.05.2021 11:11:34
Юрий Волошин, локаль влияет только на работу строковых функций, на сам язык никак не влияет. Можно задать регион применения локали: "collate", "ctype", "monetary", "numeric", "time".
Владимир, юникод это стандарт, который надо соблюдать; кодовым страницам место на помойке, равно как и их преверженцам.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.05.2021 11:15:38
Цитата
Юрий Волошин написал: во внешнем выводе видим десятичную запятую
При сохранении результатов в файл, особенно сериализации таблиц, это надо учитывать.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
07.05.2021 12:12:00
Артем, НА КОЙ ХРЕН "этот стандарт надо соблюдать"? Кодировка 1251 (как и DOS, ISO, KOI и прочая хрень) - это ТОЖЕ стандарты! И у них, по крайней мере, ОДИН байт на символ! Что могут сотворить нынешние криворукие со стандартом с переменным числом байт на символ, можно только догадываться. К тому же, шрифты к этим стандартам всё равно необходимы! Ну, и как Вы будете воспроизводить японские иероглифы или арабскую вязь? Не занимайтесь ХЕРНЁЙ, господа! ДАВИТЬ надо подобные инициативы! В зародыше! Лично я рассматриваю их как источник дополнительных потенциальных глюков, и ТОЛЬКО так! То со сраной запятой вместо точки не могут разобраться, то со сраной датой, представленной в виде строки... Вот и засирают язык всяким говном. Керниган с Ричи даже printf из языка выбросили! Керниган рассказывал, что хотели включить, мучились, но всё-таки выбросили. Молодцы! Потому-то С и есть ВЕЧНЫЙ язык, что написан гениями, а не тупорылыми пидарасами, которые каждую вдарившую в их головожопу пое... как это в нормативной лексике... каждую лабуду стараются впендюрить в язык. "Творческий вклад", панимаш!
Пользователь
Сообщений: Регистрация: 03.02.2021
07.05.2021 14:27:31
Владимир, ну чего тогда мелочиться, собсна - давайте поддержку русского языка вырежем, только английский оставим. Кому надо тот выучит, чо.
Пользователь
Сообщений: Регистрация: 25.09.2020
07.05.2021 18:19:17
Артем, Если она после этого будет нормально торговать - давайте вырежем! Руками и ногами ЗА! Это торговая система, и она не обязана обслуживать выкрутасы страдальцев по букве ё или по регистру символов. А то загадят софт всяким говном, а потом ещё удивляются, что глючит.
Пользователь
Сообщений: Регистрация: 03.02.2021
08.05.2021 06:32:23
Владимир, ну по итогу мы имеем что смена регистра в Lua решается средствами самого Lua и программисты арки тут ни при чём.
А поддержка языков просто решается: создаются такого рода файлы и из них читаются строчки. Если в файле строчки нет - ворнинг в консоль и подставить стандартный текст. Тут программисты-то не нужны, любую макаку со словарем можно посадить это делать.
Артем, А я и не обвиняю программистов арки, я даже говорю, что если бы они и были "при чём", всё равно делать ничего не надо.
Я когда-то делал мультиязычные интерфейсы и конвертер из разных кодировок друг в друга, но все они были однобайтовыми (DOS, WIN, KOI, ISO, MAC), а UTF тогда ещё в природе не существовало (или, по крайней мере, никто про него не слышал). И там немало подводных камней! Например, горячие клавиши в меню на другом языке могут быть совершенно другими. Как и размеры строк и самих меню. И я совсем не уверен, что после "макаки" мы не напоремся на какие-нибудь крупные неприятности.
Пользователь
Сообщений: Регистрация: 03.02.2021
08.05.2021 12:19:52
Владимир, кодовые страницы вымерли вместе с динозаврами, все адекватные люди уже работают только с юникодом и там таких проблем нет.
Пользователь
Сообщений: Регистрация: 25.09.2020
08.05.2021 12:45:03
Артем, Кодовые страницы В ПРИНЦИПЕ не могут вымереть - это КЛАССИЧЕСКОЕ программирование данными, и ничего более простого и эффективного придумать просто НЕЛЬЗЯ. Что до "адекватных людей" - так я тыщу раз видел, как эта шобла кидалась всем кагалом на очередное нововведение типа "плоского мира" (тогда ещё 32-разрядного) или того же юникода или нейросетей, после чего переписывала всю свою "современную" математику на очередную "блестящую идею". КАКИХ там "таких проблем нет"? Огласите весь список, пжалста! На любом программистском форуме, включая этот, идёт сплошной скулёж о проблемах, почти все из которых просто смехотворные. И нет этому конца - программисты вымерли "вместе с динозаврами".
Пользователь
Сообщений: Регистрация: 03.02.2021
08.05.2021 14:41:58
Владимир, как раз таки программистам с мозгами юникод проблем не создает никаких, а какая польза с универсального формата должно быть очевидно даже слепому.
Пользователь
Сообщений: Регистрация: 25.09.2020
08.05.2021 15:05:05
Артем, Лапуль, программисты прошлого В МИЛЛИОН РАЗ лучше нынешнего стада баранов умели пользоваться мозгами по назначению. Это именно НЫНЕШНЕМУ стаду "польза с универсального формата должно быть очевидно даже слепому", а тогда никто подобными "проблемами" вообще не заморачивался - были задачи поважнее.
А вот такой вопрос к стаду "зрячих" КАКОЙ ИМЕННО "универсальный формат" использовать предлагаете? Что, срочно хлебала захлопнули, умники хреновы? UTF-8? UTF-16? Ещё какой-то? А как насчёт ГРАФИЧЕСКИХ форматов? Их же ВАЩЕ НЕМЕРЯНО! А ну, где ваш "универсальный"? Правильно, В ЖОПЕ!
Между прочим, я встречался с Кеном Томпсоном примерно в то время (где-то в районе 1995 года). И он ни слова не говорил об "универсальном формате"! Ибо для него (как и для любого нормального программиста) это была рядовая задача, довольно занудная и не требующая мозгов вообще. А у вас-то откуда взялись мозги, господа? Я что-то не припомню случая, когда вы их использовали.
Пользователь
Сообщений: Регистрация: 21.02.2015
11.05.2021 10:21:37
Владимир, Прими таблетки и успокойся. Весь форум уже заспамил. Когда тебя уже забанят?
Пользователь
Сообщений: Регистрация: 25.09.2020
11.05.2021 10:34:52
Александр, А за что меня банить, лапуль? Я ведь не спамлю, я как раз наоборот, спамящих вытравливаю. И тыщу раз уж говорил: я спокоен как фараон в пирамиде!
Пользователь
Сообщений: Регистрация: 02.09.2020
11.06.2021 07:00:46
Добрый день!
Действительно, по умолчанию строковые функции работают только с asci таблицей. Мы добавим умолчательную поддержку cp1251 в будущих версиях ПО.
Пользователь
Сообщений: Регистрация: 23.01.2021
11.06.2021 14:35:55
Цитата
Roman Azarov написал: Мы добавим умолчательную поддержку cp1251 в будущих версиях ПО.