Для того чтобы быстро перенести текст из консоли или браузера на смартфон,
можно воспользоваться QR-кодом: сконвертировать текст в консоли в QR-код,
а потом сконвертировать его обратно в текст на смартфоне.Это делается так:
$ curl qrenco.de/Текст_который_нужно_сконвертировать
В консоли будет показан QR-код. Его можно сфотографировать телефоном
или вставить в текстовый файл.[[IMG /opennews/pics_base/0_1497552612.png]]
Сконвертировать фрагмент текста в QR-код можно прямо в Vim.
Для этого нужно выделить текст (shift V и стрелки)
и нажать:!curl -F-=\\<- qrenco.de
Аналогичным образом, если добавить в браузере к URL слева qrenco.de/ ,
URL сконвертируется в QR-код.Для создания QR-кодов сервис qrenco.de использует библиотеку libqrencode.
Если библиотека в системе установлена, сгенерировать QR-код можно командой:echo Текст_который_нужно_сконвертировать | qrencode -t UTF-8
URL: https://github.com/chubin/qrenco.de
Обсуждается: http://www.opennet.me/tips/info/3020.shtml
о, утащу-ка я к себе в новый релиз.
дык, давно было уже.
QR-коды на сервере, http-server в init'е, бинарные логи...
вот это вот всё.
пруф или не было(на сервере в консоли, а не просто на сервере)
а в Убунте вместо UTF-8 просит UTF8
в Федоре тоже !
Это что, содержимое консоли предлагается конвертировать на сайте http://qrenco.de/ ?
Ну-ну.
> Это что, содержимое консоли предлагается конвертировать на сайте http://qrenco.de/ ?
> Ну-ну.Не всем же дано qrencode установить, а как же еще пароли/ключи передать?!.. Только через АНБ/ФСБ/ФБР, а то "пацаны не поймут!" :)
>> Это что, содержимое консоли предлагается конвертировать на сайте http://qrenco.de/ ?
>> Ну-ну.
> Не всем же дано qrencode установить, а как же еще пароли/ключи передать?!..
> Только через АНБ/ФСБ/ФБР, а то "пацаны не поймут!" :)А пароли тут при чём?
А зачем пароли/ключи вообще конвертировать в QR-код? Вы их кому-то показывать в таком виде собрались?
Вопрос 1:В чём принципиальное отличие с точки зрения безопасности (я так понимаю, что речь тут об этом) конвертации текста из консоли/редактора с помощью сервиса,
от публикации некого текста с помощью ix.io, sprunge.us, ptpb.pw?Вопрос 2:
qrenco.de и libqrencode это опенсоурсный код, его можно поставить в локальной сети
и пользоваться им не публикую данных в инете (и вообще никак не пересылая их за пределы собственной сети). Какие угрозы безопасности существуют в этом случае?
Затем что такие дети цветов всё подвязывают на онлайн тулзы и как только сеть ляжет, то вся серверная инфраструктура моментально превращается в тыкву.
Понятно
Да уж, быстрых разумом невтонов нам не занимать!
Был у нас бог API прослоек иринат, теперь в пантеон можно добавить бога консольных веб-сервисов.
> Да уж, быстрых разумом невтонов нам не занимать!
> Был у нас бог API прослоек иринат, теперь в пантеон можно добавить
> бога консольных веб-сервисов.К сожалению, прошло мимо меня.
Нормальные вещи делал или ничего интересного? Можно посмотреть на его magnum opus?
Вообще, где про них можно почитать?
Без всякой иронии говорю, если что.
Делает полезные вещи, народ пользуется. apulse, fresh player, вот это вот все.
https://github.com/i-rinat
> Без всякой иронии говорю, если что.
> Делает полезные вещи, народ пользуется. apulse, fresh player, вот это вот все.
> https://github.com/i-rinatТогда почему же был?
Значит был, есть и (будем надеяться) будетДа, действительно очень хорошие вещи делает товарищ.
Спасибо за сравнение и за наводку
А почему бы это не офромить обычным скриптом?
Зачем это делать именно как веб сервис?
> А почему бы это не офромить обычным скриптом?
> Зачем это делать именно как веб сервис?Так ведь скрипт получается слишком сложный, аж целых 3 команды: 'cat text_file|qrencode -o qr_file;gqview qr_file'
Чукча такой "неасилит"! :)
2 команды:
echo "text_string" | qrencode -t UTF8 -o -
1 команда:
qrencode -t UTF8 < text_file
> 1 команда:
> qrencode -t UTF8 < text_fileqrencode надо инсталлировать, это единственный минус,
а так qrencode, конечно же, лучше
>> 1 команда:
>> qrencode -t UTF8 < text_file
> qrencode надо инсталлировать, это единственный минус,
> а так qrencode, конечно же, лучшеcurl тоже надо инсталлить
curl/wget/fetch/httpie есть в системе в 99.99% (наверное, в 100%, если не брать embedded-системы) случаев
> curl/wget/fetch/httpie есть в системе в 99.99% (наверное, в 100%, если не брать
> embedded-системы) случаевУ вас тяга к внешним зависимостям? Синдром спихивания ответственности на "партнеров" ? Похоже современная религия ДЕВОПС приносит первые плоды.
>> curl/wget/fetch/httpie есть в системе в 99.99% (наверное, в 100%, если не брать
>> embedded-системы) случаев
> У вас тяга к внешним зависимостям? Синдром спихивания ответственности на "партнеров" ?
> Похоже современная религия ДЕВОПС приносит первые плоды.Понятно
>> А почему бы это не офромить обычным скриптом?
>> Зачем это делать именно как веб сервис?
> Так ведь скрипт получается слишком сложный, аж целых 3 команды: 'cat text_file|qrencode
> -o qr_file;gqview qr_file'
> Чукча такой "неасилит"! :)Зачем gqview, это же консольная версия. Расстраиваете
>>> А почему бы это не офромить обычным скриптом?
>>> Зачем это делать именно как веб сервис?
>> Так ведь скрипт получается слишком сложный, аж целых 3 команды: 'cat text_file|qrencode
>> -o qr_file;gqview qr_file'
>> Чукча такой "неасилит"! :)
> Зачем gqview, это же консольная версия. РасстраиваетеДля "посмотреть"!
Ибо предполагалась чистая консоль без псевдографических и ФБ примесей... :)
а что такое ФБ?Собственно, это уже достаточно чистая консоль,
я не знаю в каком терминале оно не будет работать,
шрифт должен как-то сильно уже урезанным быть, на практике не встречал ни разу
> А почему бы это не офромить обычным скриптом?потому что "обычный скрипт" остался дома, и тебе хочется унести с собой на память длинный url (или вовсе не урл, а строку параметров чего-то нетривиального), открытый на компьютере приятеля. И нет, он нормальный человек, нетаката у него тоже нет.
А там где у меня есть скрипты и неткаты, мне нафиг не нужны qr-коды, я строку текста и так могу в нужное место скопировать (в том числе в сообщение, отправленное на телефон, без гемора с фотографированием экрана)
>> А почему бы это не офромить обычным скриптом?
> потому что "обычный скрипт" остался дома, и тебе хочется унести с собой
> на память длинный url (или вовсе не урл, а строку параметров
> чего-то нетривиального), открытый на компьютере приятеля. И нет, он нормальный человек,
> нетаката у него тоже нет.
> А там где у меня есть скрипты и неткаты, мне нафиг не
> нужны qr-коды, я строку текста и так могу в нужное место
> скопировать (в том числе в сообщение, отправленное на телефон, без гемора
> с фотографированием экрана)И почты, конечно же, у него тоже нет! :)
>>> А почему бы это не офромить обычным скриптом?
>> потому что "обычный скрипт" остался дома, и тебе хочется унести с собой
>> на память длинный url (или вовсе не урл, а строку параметров
>> чего-то нетривиального), открытый на компьютере приятеля. И нет, он нормальный человек,
>> нетаката у него тоже нет.
>> А там где у меня есть скрипты и неткаты, мне нафиг не
>> нужны qr-коды, я строку текста и так могу в нужное место
>> скопировать (в том числе в сообщение, отправленное на телефон, без гемора
>> с фотографированием экрана)
> И почты, конечно же, у него тоже нет! :)Почты может не быть на телефоне (у меня нет, например),
как и прочих мессенджеров
> А там где у меня есть скрипты и неткаты, мне нафиг не
> нужны qr-коды, я строку текста и так могу в нужное место
> скопировать (в том числе в сообщение, отправленное на телефон, без гемора
> с фотографированием экрана)Расскажите, пожалуйста, как (если у вас есть скрипты и неткаты, но нет никаких сконфигурированных аккаунтов типа почты, джаббера, слака или твиттера)?
То есть считаем, что вы просто находитесь на неком сервере в инете.
У вас есть на нём nc, curl и т.д., всё что вам надо.
Вам нужно быстро перенести строчку (допустим 100 символов) на телефон.
Как это сделать?Я не говорю, что это невозможно, просто хочу сравнить ваш способ с генерацией QR-кода с помощью libqrencode
Мои предложения:
использовать ix.io, sprunge.us, ptpb.pw для расшаривания текста;
получить URL; вбить URL на телефоне; выделить скопированный текст в браузере.(это намного медленнее чем использовать qrenco.de/libqrencode + оставляет след в инете, а libqrencode нет)
Какие есть более быстрые варианты?
> Расскажите, пожалуйста, как (если у вас есть скрипты и неткаты, но нет
> никаких сконфигурированных аккаунтов типа почты, джаббера, слака или твиттера)?pushbullet, google keep и т.д.
А вот вам реальный кейс - на сервере нет интернета.
И все, ваш сервис недоступен.
>> Расскажите, пожалуйста, как (если у вас есть скрипты и неткаты, но нет
>> никаких сконфигурированных аккаунтов типа почты, джаббера, слака или твиттера)?
> pushbullet, google keep и т.д.мы договорились без аккаунтов, эти примеры ничем не лучше джаббера,
но даже и с ним qr-код быстрее> А вот вам реальный кейс - на сервере нет интернета.
> И все, ваш сервис недоступен.тогда только libqrencode
> мы договорились без аккаунтов, эти примеры ничем не лучше джаббера,Боюсь, это вы договорились с самим собой. Просто придумали экзотический пример.
> но даже и с ним qr-код быстрее
Кстати, на телефоне должна быть программа для распознавания qr кодов. По дефолту её нет.
Я предложил вопрос, вы на него ответили. Я предположил, что вы приняли условия задачи.То есть, если есть на этом хосте сконфигурированный менеджер (и на смартфоне он тоже есть), то соизмеримо по скорости и удобству будет воспользоваться им. Если нет — то QR-код (сервис или программа).
И такой уж это экзотический пример?
Разве на всех хостах есть сконфигурированный мессенджер?
Ну вот правда?Про то что программы по дефолту нет:
На старых смартфонах да, на новых уже камера это поддерживает, как правило, сама. В будущем, я так думаю, что на большинстве смартфонов будет распознавание QR-кода встроено
s/менеджер/мессенджер/
Автор, зачем писать что-то типа многопоточное-событийное, если в результате оно запускает бинарник в системе? Не использует биндинг (как тут http://search.cpan.org/~kurihara/Text-QRCode-0.01/lib/Text/Q...), а именно запускает процесс и читает его вывод.Не проще ли сразу в inetd прописать? Убрать ненужный здесь http. Открывать сокет, пишешь туда что нужно закодировать, читать обратно. И все. В качестве клиента неткат или телнет. Было бы более портабельно, чем курл.
1. Установить qrencode и xinetd.2. Создать файлик /etc/xinetd.d/qrencode с содержимым:
service qrencode
{
disable = no
socket_type = stream
user = user
wait = no
port = 9009
protocol = tcp
server = /usr/bin/qrencode
server_args = -t UTF8 -o -
}3. Добавить в /etc/services
qrencode 9009/tcp user # qrencode server4. Не забыть перезапустить xinetd
/etc/init.d/xinetd restart5. Использование:
echo foo | nc 127.0.0.1 9009
> Автор, зачем писать что-то типа многопоточное-событийное, если в результате оно запускает
> бинарник в системе? Не использует биндинг (как тут http://search.cpan.org/~kurihara/Text-QRCode-0.01/lib/Text/Q...),
> а именно запускает процесс и читает его вывод.
> Не проще ли сразу в inetd прописать? Убрать ненужный здесь http. Открывать
> сокет, пишешь туда что нужно закодировать, читать обратно. И все. В
> качестве клиента неткат или телнет. Было бы более портабельно, чем курл.В данном случае стоит действительно использовать вызов библиотеки, а не запускать напрямую
Про xinetd — нет, не пойдёт, потому что нужно ещё поддерживать браузеры, а не только консольные клиенты. + xinetd, напомню, это TCP, а не HTTP.
А про библиотечный вызов правильно совершенно, полностью с вами согласен.
Почему этого нет? Потому что используется generic-код, предназначенный для запуска любых процессов, а с потерями на внешние вызовы при незначительно количестве обращений (как в данном случае) можно смириться. Хотя если писать реально правильно, то форки тут совершенно ни к чему
Для задачи "кодировать строку из консольки в QR код" HTTP нафиг не нужен. Да и поверх xinetd тривиально дописывается обертка на sed, которая выдернет строку из запроса.Будет интересно сравнить производительность конфигурации на xinetd (вместе с оберткой) и оригинальной поделки. Ожидаю разницу в 2-5 раз.
Оберткаhead -n1 |
grep -oP '(?<=GET \/)(.*?)(?= )' |
qrencode -t UTF8 -o -Остальная требуха аналогична. Я гарантирую, что это быстрее, чем питон.
И меньше места занимает!
Это прорывКак насчёт поддержки embedded PNG-объектов (<img src='png.qrenco.de/.../'>), опций запроса, виртуальных хостов, HTTPS, прокси, различного поведения для различных user-agent'ов,
которые есть в оригинальной версии?Вообще ничего не виже в плохого в попытках заменить питоновский werkzeug shell'ом (и nginx заменить xinetd), только понимаю, что работать это будет если HTTP свести до уровня TCP, и с каждой добавляемой функцией типа виртуальных хостов или аргументов URL-строки, сложность кода будет увеличиваться экспоненциально.
Я не nginx заменил, а питон с кучей тормозного барахла. Если вы не заметили.
Nginx можно поставить перед xinetd и я бы даже так и сделал, если бы захотел выставить Http версию в интернет.
Моя поделка из трех строк имеет 99% функциональности оригинальной и при этом не содержит ни строчки программного кода.
PNG генерировать - на слабо берете? Могу хоть потоковое видео вывести. И обертка будет не сложнее.
nginx там и так стоит перед сервисом (если мы про qrenco.de говорим).Я немножко о другом хотел сказать,
я сейчас не говорю о сервисе qrenco.de как таковом, это просто незначительный частный случай, но он интересен поскольку он позволяет сделать наши рассуждения из абстрактных более конкретным.Вы предложили заменить полноценную имплементацию HTTP-протокола (которая есть в nginx и в стоящим за ним werkzeug) его простой имплементацией поверх xinetd, по большому счёту просто заменить чистым TCP.
Какие минусы и плюсы имеет это решение?
1. (+) Простота, надёжность, отсутствие ошибок, скорость
2. (-) Экспоненциальный рост сложности, изобретение велосипеда (HTTP) при появлении новых требований; требование знания дополнительной информации (пара "хост:порт" в случае TCP, против "хост" в случае HTTP).То есть, если нас не интересуют дополнительные приятные возможности HTTP, мы вполне можем обойтись одним TCP (xinetd) как простым, надёжным и быстрым решением, но как только мы хотим дополнительных возможностей, мы очень быстро приходим к тому, что нам нужно полноценно работать с HTTP (а не сводить работу с ним к работе с "TCP с фиксированным портом").
Какие возможности HTTP я имею в виду?
1. Стандартное кодирование данных (GET + POST);
2. Шифрование из коробки;
3. Заголовки (например, язык и другие; не так важно в данном сервисе, но в других важно);
4. Content-Type ответа (пример с PNG).Можно ли это всё реализовать на xinetd? Конечно же да. Просто добавить HTTP-враппер вокруг вашего скрипта, который всё это дело правильно распарсит и представит вашему скрипту, но в конечном итоге вы быстро придёте к реализации nginx с помощью xinetd.
Можно ли всё это реализовать на голом TCP (xinetd + netcat), не переходя на уровень HTTP? Да, можно, но в итоге вы начнёте изобретать свой собственный HTTP, не имеющий своей экосистемы (ни клиентов, ни серверов). То есть, лучше, конечно, использовать HTTP.
В целом считаю ваш подход очень здравым (там где он применим, а именно — где входом сервиса является одна только строка, и выходом тоже одна строка).
Я так же полностью согласен с вами в том, что неоправданное усложнение кода (серверной части) бессмысленно и даже очень вредно. Одна строка на шелле всегда лучше одной страницы кода на питоне или программы на Си (за исключением случаев, где важна производительность или есть другие существенные причины).
Так что предлагаю разделить дискуссию на две:
1. (интерфейс) TCP (netcat) против HTTP (curl) при создании консольных сервисов.
2. (имплементация) Кривизна сервиса qrenco.de и его слабые стороны (например: ненужный форк там где можно использовать библиотечный вызов).Я считаю, что дискуссия по первой теме представляет значительно больший интерес для сообщества чем вторая (там и так всё понятно; простейшая werkzeug/flask обёртка с очевидными плюсами и минусами; хотя и по второй теме может быть интересно — например, как реализовать аналогичный сервис (не урезанную netcat-замену!) средствами nginx + shell).
В общем, очень интересные темы вы поднимаете
Я здесь в сущности отказываюсь от некритичных вещей и за счет этого значительно все упрощаю.
HTTP на уровне примитивных GET запросов вполне можно "делать" регулярками на коленке.
Если расширять требования и делать их специфичными, довольно быстро перестанет хватать HTTP и поверх вырастет какой-нибудь JSON-RPC протокол. И так далее сложность будет увеличиваться до бесконечности.Я в обертке забыл сделать корректный HTTP ответ :)
head -n1 |
grep -oP '(?<=GET \/)(.*?)(?= )' |
( qr=`qrencode -t UTF8 -o -` ;\
echo "HTTP/1.0 200 OK" ;\
echo "Content-Type: text-plain" ;\
echo "Content-Length: "$(echo "$qr" | wc -c ) ;\
echo "" ;\
echo "$qr" )HTTP достаточно простой, особенно 1.0.
1. Для консоли TCP сокет однозначно роднее, чем HTTP API, сколь угодно хорошее. Легче интегрировать в пайп и меньше накладухи. Гибкости можно достичь, развесив дополнительные варианты сервиса по разным портам ( практически аналогия микросервисов против монолитных приложений).
2. В форках не вижу проблемы. Расход памяти на qrencode очень маленький и время жизни процесса мало. Это совсем не то же, когда копируется огромное приложение и работает по несколько секунд.
Вижу проблему в не самом удачном для написания сетевых сервисов языке. Кроме очевидной проблемы (необходимости) доверия к такому сервису.
Насчёт доверия это не так критично как кажется. Сервисы pastebin, sprunge.us, ix.io прекрасно используются, просто, конечно, никто не пересылает через них чувствительную информацию.Вообще, этот отдельно взятый сервис никакого принципиального значения не имеет. Это просто пример сервиса для консоли (для человека, работающего в консоли). Можно взять для примера какой-нибудь другой, давайте возьмём wttr.in.
Мне кажется, что использование TCP-интерфейса (netcat) наряду с HTTP очень важно для таких сервисов. Выбрасывать HTTP неправильно, но и ограничиваться HTTP тоже нельзя.
Другое дело, что при использовании голого TCP встают такие вопросы, как:
* как передавать параметры;
* как передавать заголовки;
* как передавать виртуальные адреса.Эти все вопросы открыты.
Например, с помощью http всё это сделать легко:
curl ru.wttr.in/Москва
вы получаете прогноз погоды по москве на русском языке.
Как это сделать с помощью netcat?
echo Москва | nc wttr.in 1024
Неплохо, но нет языка.
Тогда так:
echo ru.wttr.in/Москва | nc wttr.in 1024
получается по сути реализация HTTP-протокола заново.
Моё решение здесь: отказаться от передачи параметров (использовать дефолтные):
echo Москва | nc wttr.in 1024
или, для определения положения по IP-адресу,
nc wttr.in 1024
(кстати, вот вам интересная загадка: как на серверной стороне распознать,
собирается клиент передавать ему какие-то данные или нет; грубо говоря
как сделать так чтобы оба вышепреведённых варианта работали).TCP-вариант хорош (по сравнению с HTTP-вариантом) ещё и тем, что вообще не требует
никаких клиентов. То есть, работать будет и так:cat < /dev/tcp/wttr.in/1024
(пока что TCP-интерфейс ещё не реализован, поэтому тест этот не отработает).
Вообще, почему я об этом так много пишу (здесь в комментах и вообще), потому что считаю, что направление консольных сервисов незаслуженно забыто человечеством в настоящий момент, и у них есть потенциал
>Например, с помощью http всё это сделать легко:
>Как это сделать с помощью netcat?На мой взгляд не нужно это делать через неткат. Http для погоды оптимален.
Можно выгружать по TCP grepable текст с прогнозом по всем городам, чтобы юзер мог сам выдернуть нужные данные.
Или интерактивный телнет-интерфейс с обработкой набора команд.>(кстати, вот вам интересная загадка: как на серверной стороне распознать,
>собирается клиент передавать ему какие-то данные или нет; грубо говоря
>как сделать так чтобы оба вышепреведённых варианта работали).По таймеру - если сразу ничего не пришло, обрабатывать отсутствие ввода.
Насчет потенциала консольных сервисов - согласен. В мире консолепанка у них огромное будущее!
В нашем вряд ли, так как очень мало активных пользователей консоли, предпочитающих текстовые интерфейсы.Вот определитель IP.
service myip
{
disable = no
socket_type = stream
user = user
wait = no
port = 9999
protocol = tcp
server = /usr/local/bin/myip
}#!/bin/sh
echo "$REMOTE_HOST"cat < /dev/tcp/127.0.0.1/9999
cat < /dev/tcp/xhost/myip
Я так понимаю без интернетов это не работает
libqrencode работает (только если проинсталлировать локально),
qrenco.de работает только, если проинсталлировать на серваке где-то локально,
и внешний сервис работает, если не инсталлировать, но только с инетом, иначе нет
qrencode -o qr.png -t png <<<"Только локально!" ; feh qr.png
Что только не придумают, лишь бы KDE Connect не ставить.
про передачу данных на телефон - регаемся на sms.ru, кладём рубъ, и далее
wget https://sms.ru/sms/send?api_id=[зарегистрируйтесь, чтобы получить api_id]&to=[мой номер телефона]&msg=hello+world&json=1
и до пяти смс в день на свой номер бесплатно, свыше - немного копеек...
Классный сервис, но:1. Размер SMS сильно ограничен + время доставки SMS + зависимость от сети
2. Поддерживается ли Unicode, переводы строк, спецсимволы?
я его в основном для сигнализации о проблемах сети и серверов использую...
по размеру - можно через вабер до килобайта текста http://sms.ru/api/viber, хотя если ставить клиента, то и джабер можно с ботом поднять...
про юникод - судя по документации вайбером поддерживается https://support.viber.com/customer/en/portal/articles/263225...
а про смс - судя по википедии национальный шрифт передаётся в смс в кодировке utf-16, со всеми вытекающими из этого последствиями...
> я его в основном для сигнализации о проблемах сети и серверов использую...
> по размеру - можно через вабер до килобайта текста http://sms.ru/api/viber, хотя если
> ставить клиента, то и джабер можно с ботом поднять...
> про юникод - судя по документации вайбером поддерживается https://support.viber.com/customer/en/portal/articles/263225...
> а про смс - судя по википедии национальный шрифт передаётся в смс
> в кодировке utf-16, со всеми вытекающими из этого последствиями...Да, для оповещений, конечно, не подходит QR-код никак.
А для переноса текста на смартфон, как по мне, он выигрывает viber/whatsup/etc с большим отрывом.
Всегда раньше относился к QR-коду с презрением, пока меня не осенило,
насколько это удобно
данные переносить лучше морзянкой :)
мигаем на экране белым квадратом текст, а на телефоне камерой его смотрим и декодируем... так же и с мигающего экрана смарта через вебкамеру в комп... или через оптический сенсор мышки, положив её на экран, на котором изображаем двигающиюся в разные стороны поверхность :)да и модемную модуляцию можно вспомнить, и о том, что у телефона есть микрофон, а у компа динамик/спикер... :)
А кстати с морзянкой вы очень правы, только переносить не на смартфон, а в мозг человеку (не шутка). Мозг привыкает и начинает воспринимать просто как обычный текст. Хорошо работает в сочетании с вибрацией или другими способами передачи информации, когда нет возможности читать/слушать
не каждый радиолюбитель хочет свой мозг к морзянке приучать, не говоря уже о простых людях... да и проблемы со скоростью, особенно у тех, у кого слух не самый лучший и ему напевы проговаривать приходится...
По-моему до 100 знаков в минуту довольно реально дойти простому человеку,
а 200 после некоторой тренировки.
Почти что скорость чтения аудиокниги
В среднем - до 120 знаков (в СССР, насколько помню, это был 1 разряд мужской) вполне может любой натаскаться, символы заменяются скорописью. Дальше - тяжело, но до 170, как минимум, можно.
Никто не пробовал это в браузер запихать таким образом чтобы не чистый текст от сервера к клиенту шёл, а qr-коды сыпались?! Если прокачать мысль, то можно сделать бытовую стеганографию.
Так работает же в браузере