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
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
Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
swerg написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
Да! Как тут тегнуть разработчиков Lua QUIK? Конечно они должны сделать нормально работающие РУССКИЕ БУКВЫ по умолчанию!
swerg написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
swerg написал: Считаю это ошибкой, которую разработчики QUIK должны исправить. Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.
интерфейс у терминала не только русский, увы...
И все же это ошибка
Запускать на только что запущенном квике, пока никакой скрипт локаль не установил еще
BlaZed, эта функция берет системную локаль. У вас системная локаль совпадает с требуемой, у меня - English_United States.1252 и на ней преобразование регистра кириллицы не работает (в ней кириллицы-то нет).
По-хорошему, решение тут это перекомпилировать квик с поддержкой юникода (давно пора!) и все эти проблемы отпадут сами собой. Заодно не нужно будет пердолиться с настройками чтобы квик показывал человеческие буквы а не неандертальские крякозябры.
В отсуствии юникода нужно ставить локаль. Такие вещи устанавливать автоматически на стороне программы это плохая практика, но с учётом того что поддерживается только одна-единснтвенная кодировка 1251 то имел бы смысл устанавливать соответствующую локаль автоматически.
Артем, Вот токо поддержки юникода Квику не хватало! Квик - это программа ДЛЯ ТОРГОВЛИ! И до тех пор, пока эта часть не заработает как часы, всю остальную херню вроде 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, запихивающий все остальные кавычки на морду, кроме тех, которые он опознает как свои, и интерпретирует соответствующим образом. Проблема вовсе не загнать кавычку в строку, проблема не перепутать их разными итерпретаторами! А тут ещё «интеллектуальный» браузер гадит…
Вам хочется и здесь огрести подобного говна, господа? Мало того, что есть, ещё хочется?
Старатель написал: не забыв при этом дать доступ на чтение символа разделителя дробной части числа (для строковых операций с числами).
Да, я тож переживал на тему смены "американской десятичной точки 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))
Юрий Волошин, локаль влияет только на работу строковых функций, на сам язык никак не влияет. Можно задать регион применения локали: "collate", "ctype", "monetary", "numeric", "time".
Владимир, юникод это стандарт, который надо соблюдать; кодовым страницам место на помойке, равно как и их преверженцам.
Артем, НА КОЙ ХРЕН "этот стандарт надо соблюдать"? Кодировка 1251 (как и DOS, ISO, KOI и прочая хрень) - это ТОЖЕ стандарты! И у них, по крайней мере, ОДИН байт на символ! Что могут сотворить нынешние криворукие со стандартом с переменным числом байт на символ, можно только догадываться. К тому же, шрифты к этим стандартам всё равно необходимы! Ну, и как Вы будете воспроизводить японские иероглифы или арабскую вязь? Не занимайтесь ХЕРНЁЙ, господа! ДАВИТЬ надо подобные инициативы! В зародыше! Лично я рассматриваю их как источник дополнительных потенциальных глюков, и ТОЛЬКО так! То со сраной запятой вместо точки не могут разобраться, то со сраной датой, представленной в виде строки... Вот и засирают язык всяким говном. Керниган с Ричи даже printf из языка выбросили! Керниган рассказывал, что хотели включить, мучились, но всё-таки выбросили. Молодцы! Потому-то С и есть ВЕЧНЫЙ язык, что написан гениями, а не тупорылыми пидарасами, которые каждую вдарившую в их головожопу пое... как это в нормативной лексике... каждую лабуду стараются впендюрить в язык. "Творческий вклад", панимаш!
Артем, Если она после этого будет нормально торговать - давайте вырежем! Руками и ногами ЗА! Это торговая система, и она не обязана обслуживать выкрутасы страдальцев по букве ё или по регистру символов. А то загадят софт всяким говном, а потом ещё удивляются, что глючит.
Владимир, ну по итогу мы имеем что смена регистра в Lua решается средствами самого Lua и программисты арки тут ни при чём.
А поддержка языков просто решается: создаются такого рода файлы и из них читаются строчки. Если в файле строчки нет - ворнинг в консоль и подставить стандартный текст. Тут программисты-то не нужны, любую макаку со словарем можно посадить это делать.
Артем, А я и не обвиняю программистов арки, я даже говорю, что если бы они и были "при чём", всё равно делать ничего не надо.
Я когда-то делал мультиязычные интерфейсы и конвертер из разных кодировок друг в друга, но все они были однобайтовыми (DOS, WIN, KOI, ISO, MAC), а UTF тогда ещё в природе не существовало (или, по крайней мере, никто про него не слышал). И там немало подводных камней! Например, горячие клавиши в меню на другом языке могут быть совершенно другими. Как и размеры строк и самих меню. И я совсем не уверен, что после "макаки" мы не напоремся на какие-нибудь крупные неприятности.
Артем, Кодовые страницы В ПРИНЦИПЕ не могут вымереть - это КЛАССИЧЕСКОЕ программирование данными, и ничего более простого и эффективного придумать просто НЕЛЬЗЯ. Что до "адекватных людей" - так я тыщу раз видел, как эта шобла кидалась всем кагалом на очередное нововведение типа "плоского мира" (тогда ещё 32-разрядного) или того же юникода или нейросетей, после чего переписывала всю свою "современную" математику на очередную "блестящую идею". КАКИХ там "таких проблем нет"? Огласите весь список, пжалста! На любом программистском форуме, включая этот, идёт сплошной скулёж о проблемах, почти все из которых просто смехотворные. И нет этому конца - программисты вымерли "вместе с динозаврами".
Владимир, как раз таки программистам с мозгами юникод проблем не создает никаких, а какая польза с универсального формата должно быть очевидно даже слепому.
Артем, Лапуль, программисты прошлого В МИЛЛИОН РАЗ лучше нынешнего стада баранов умели пользоваться мозгами по назначению. Это именно НЫНЕШНЕМУ стаду "польза с универсального формата должно быть очевидно даже слепому", а тогда никто подобными "проблемами" вообще не заморачивался - были задачи поважнее.
А вот такой вопрос к стаду "зрячих" КАКОЙ ИМЕННО "универсальный формат" использовать предлагаете? Что, срочно хлебала захлопнули, умники хреновы? UTF-8? UTF-16? Ещё какой-то? А как насчёт ГРАФИЧЕСКИХ форматов? Их же ВАЩЕ НЕМЕРЯНО! А ну, где ваш "универсальный"? Правильно, В ЖОПЕ!
Между прочим, я встречался с Кеном Томпсоном примерно в то время (где-то в районе 1995 года). И он ни слова не говорил об "универсальном формате"! Ибо для него (как и для любого нормального программиста) это была рядовая задача, довольно занудная и не требующая мозгов вообще. А у вас-то откуда взялись мозги, господа? Я что-то не припомню случая, когда вы их использовали.
Александр, А за что меня банить, лапуль? Я ведь не спамлю, я как раз наоборот, спамящих вытравливаю. И тыщу раз уж говорил: я спокоен как фараон в пирамиде!