Составляя примѣръ файла Markdown, приложенный к предшествующему сообщению, я неминуемо должен был обнаружить себя в том положении, когда ужé начинаешь набирать адрес по стандарту RFC 2397: data:image/avif;base64, и опосля этой запятой осталось только вставить содержимое файла, кодированное в base64. В эту-то минуту я и вспомнил, что в моём распоряжении есть сразу нѣсколько средств, способных кодировать в base64: есть команда «certutil -encode имяФайла имяРезультата», а есть и диалоговое окно в файловом менеджере — но что всѣ средства этѣ создают код base64 разбитым на строки (по семьдесят с небольшим сѵмволовъ), чтобы было удобно засовывать его въ электронныя письма, да ещё и снабжают своей шапкою и хвостом, чтобы ѿмѣтить начало и конец кода. Всякий раз убирать шапку и хвост, а затѣмъ устранять и разбиение на строки (пусть и не руками устранять, а автоматическим поиском и замѣною) — это утомительно. Вмѣсто того захотѣлось сочинить такую команду для командной строки, которая первым параметром принимает имя кодируемого файла (и содержимое того файла кодирует одной длинной строкою base64), а во втором параметре вообще не нуждается, потому что результат свой выводит не в файл (как его выводила бы команда certutil, напримѣръ), а сразу въ буферъ обмѣна, откуда его останется только вставить в Markdown, нажав обычное сочетание клавиш, вставку запускающее (то есть Ctrl+V или Shift+Ins). И сочинил вот какóй однострочный бáтник (пакетный файл), вызывающий NodeJS: node -e "process.stdout.write( fs.readFileSync(process.argv[1]).toString('base64') )" %1 | clip Я также подумал и о том, как будет выглядѣть послѣдняя из мыслей предшествующаго сообщения (идея адресовать иллюстрации внутри Телеграма), если «аппетит придёт во время ѣды» и захочется адресовать не одни только такие иллюстрации, которые лежат в том альбоме файлов, в котором и иллюстрируемый ими файл Markdown, но и иллюстрации в другом альбоме или даже в другом канале. Возможно ли адаптировать под такое пожелание существующую адресацию, в которой адреса на https://t.me/ начинаются? Возможно, но совмѣстимость ея со внѣшними просмотрщиками окажется иллюзорною: Telegram не позволяет смотрѣть файлы без регистрации — слѣдовательно, сёрвер Телеграма, даже если к нему по адресу https://t.me/ReadMithgol/1175/screenshot.png обратиться, файл с иллюстрациею не отдаст (хотя и сообщение https://t.me/ReadMithgol/1175 существует, и файл screenshot.png в нём лежит); да и внутренний по отношению к Телеграму просмотрщик (в Telegram под Android) должен будет научиться самостоятельно (внутрителеграмным способом) добывать файлы, руководясь адресами, имѣющими такой вид, и затѣмъ скармливать их в качестве иллюстраций в просмотрщик файлов Markdown, такие адреса содержащих. Но всё равно это лучше, чѣмъ адаптировать внѣWWWшную схему URLoв tg://, в которой аналогом адреса https://t.me/имяКанала/номерСообщения становится громоздкое выражение tg://resolve?domain=имяКанала&post=номерСообщения (и имя файла туда также придётся прибавлять не через косую черту, а через ещё один именованный параметр). И лучше, чѣмъ создавать ещё одну — менѣе громоздкую, но не менѣе внѣWWWшную — схему URLов. Отчего лучше? — оттого, что иллюзорную возможность внѣшняго просмотра файлов Telegram ещё сможет по своему усмотрению сдѣлать неиллюзорною, когда пожелает (скажем, для файлов меньше опредѣлённаго объёма), тогда как внѣWWWшную схему URLoв ужé никогда не удастся сдѣлать непосредственно обрабатываемою нетелеграмными просмотрщиками файлов Markdown. Никогда, никогда! (Если же не непосредственно, а опосредованно, то понадобится гейтование. Так получилось с гейтами, ведущими в гипертекстовый Фидонет. Или с гейтами, ведущими въ P2P-распредѣлённую файловую систему IPFS — эти поддерживают не только преобразование адресов ipfs:// или ipns:// в адреса https://, начинающиеся именами гейтов, но и обратное преобразование. Но это потребовало наперёд продумать не только схему адресации файловой системы, но и схему гейтования адресов — и даже формат TXT-полей в DNS-записях, чтобы опознавать гейты в момент обращения к ним по именам!)
Mithgol the Webmaster
Subscribers
1.8K
tracking since 13 Nov
Reach per post (ERR)
45.1%789 avg views
Posting
4.7/week
last 17 hours ago
Reactions per 1K views
14.4
❤ 💯 🤣
Views over time
| When | Views |
|---|---|
| 18 May 2026, 04:58 | 0 |
| 13 Nov 2026, 19:16 | 892 |
Who shared this post
Posts in other channels we index that link to this one. (Forwards with a hidden source can't be traced.)
Nobody yet.