Здравствуйте, Shmj, Вы писали:
S>Сейчас все больше и больше юзают Base64. Уже даже картинки вставляют в этом формате (см. первый попавшийся стиль: https://userstyles.org/styles/31267/global-dark-style-changes-everything-to-dark).
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
S>И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
S>В примитивных текстовых редакторах преобразоывать в Base64, чтобы чел. мог редактировать как раньше. Но при сохранении, опять таки, вертать все взад. А в продвинутых редакторах отображать как BLOB с возможностью навести и отредактировать в любом формате, хоть в HEX хоть в BASE64 хоть файл вставить.
S>Гениально?
S>З.Ы. S>Наверное, еще придется добавить симфол для экранирования символа 2. Или же убрать символ 2 а после символа 1 обязать указывать длину бинарного текста.
Здравствуйте, Sinclair, Вы писали:
S>Попробуйте xml.zip — будете удивлены. Во-первых, меньше места будут занимать даже те XML, где нет никакого base64. Во-вторых, не нужно уговаривать ни Unicode Consortium, ни w3c, ни авторов редакторов для XML.
А почему же xml не архивируют каждый раз а обычно хранят в открытом виде Отож. Не удобно.
S>>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования). S>Непонятно, откуда возьмутся расширенные возможности редактирования. Ведь редактор ничего не знает про эти данные — то ли там музыка, то ли видео, то ли PNG.
Редактор предоставит возможность редактировать BLOB как Base64, как HEX или просто вставить из файла. Главеное что спец. символ однозначно дает понять что там участок с бинарными данными.
S>А если редактор — специализированный, то он и с base64 справится прекрасно. S>Вот, есть, например, такой широко известный специализированный редактор XML — Microsoft Word. Он отлично редактирует и текстовые и бинарные данные.
У меня не редактирует.
S>Низкоуровневому редактору вроде visual studio удобнее работать с текстом — т.к. там я хотя бы могу сделать copy-paste общегражданскими средствами.
Так XML и останется текстом, просто введут в Unicode управляющий символ, типа символа изменения направления текста слево-направо. copy-paste никуда не денется.
S>Ну, и не забываем про остальной тулчейн — например, XML-с-base64 отлично мёрджится стандартными средствами вроде TortoiseMerge и десятками других. S>Для полубинарного формата придётся отказаться от этих инструментов.
Придется выпустить новую версию или инструменты устареют.
Здравствуйте, Ops, Вы писали:
Ops>Кто мешает сделать то же самое с юникодом? Распечатать в шестнадцатиричном представлении и возить на оленях? А на месте вбить, и распечатать уже то, что он описывает?
Вы подменяете понянтия. Можно распечатать и в двоичном коде. Любые данные в том числе и unicode текст. Просто у base64 ниже избыточность. В base64 на 3 байта данных надо 4 символа, а в hex на 3 байта надо 6 символов.
Здравствуйте, kov_serg, Вы писали:
_>Вы подменяете понянтия. Можно распечатать и в двоичном коде. Любые данные в том числе и unicode текст. Просто у base64 ниже избыточность. В base64 на 3 байта данных надо 4 символа, а в hex на 3 байта надо 6 символов.
Нет, это ты подменяешь, выдавая какие-то мнимые преимущества base64. В каждом случае надо использовать свой инструмент. base64 хорош на низком уровне в слабо предсказуемой среде, которая может производить какие-то конвертации контента: в вебе, в емылах, и т.п., и только. А на бумаге, если не требуется читаемость человеком, куда разумнее использовать, например, QR.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Нет, это ты подменяешь, выдавая какие-то мнимые преимущества base64.
Я про преимущества не говорил. Ops>В каждом случае надо использовать свой инструмент.
Разве я против. Только за. Ops>base64 хорош на низком уровне в слабо предсказуемой среде, которая может производить какие-то конвертации контента: в вебе, в емылах, и т.п., и только.
Причем тут низкий уровень. Низкий уровень это описание как используется физическая среда для передачи информации. Ops>А на бумаге, если не требуется читаемость человеком, куда разумнее использовать, например, QR.
Вы явно ненавидите людей, читать qr код человеку еще то извращение https://habr.com/post/127197
Куда разумнее использовать сеть или съёмные накопители.
Здравствуйте, kov_serg, Вы писали:
Ops>>А на бумаге, если не требуется читаемость человеком, куда разумнее использовать, например, QR. _>Вы явно ненавидите людей, читать qr код человеку еще то извращение https://habr.com/post/127197
Тех, кто не умеет читать даже простой текст? Возможно. Выделил.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, kov_serg, Вы писали:
Ops>>>А на бумаге, если не требуется читаемость человеком, куда разумнее использовать, например, QR. _>>Вы явно ненавидите людей, читать qr код человеку еще то извращение https://habr.com/post/127197
Ops>Тех, кто не умеет читать даже простой текст? Возможно. Выделил.
Не разглядел. Темно — луну затмили облака.
Здравствуйте, Shmj, Вы писали:
S>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места.
В наше время пакуемых на лету потоков и файлов эта проблема не актуальна.
S>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования).
Продвинутым редакторам никто не мешает и base64 куски в виде ВLOB изображать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
S>>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места. E>В наше время пакуемых на лету потоков и файлов эта проблема не актуальна.
По факту все равно все хранят без всякой паковки, так что
S>>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования). E>Продвинутым редакторам никто не мешает и base64 куски в виде ВLOB изображать...
Нет таких редакторов, т.е. base64 не отличим от англ. текста.
Здравствуйте, kov_serg, Вы писали:
_>Например символ U+0419 (Й) можно записать как U+0418 + U+0306 ( Й ). _>\u0123 — это такой же юникод, как 0x123 и ģ и %01%23 или U+xxxxxx это просто варианты его кодирования когда отображать символы юникодом бессмысленно или не возможно.
И чего? Тебе легче будет, если U+0419 и U+0418 + U+0306 будут закодированы до кучи в base64? Тебя Шамжа покусал?
Здравствуйте, kov_serg, Вы писали:
S>>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования). _>А если редакторам понадобится оглавление, превью история изменений, мульти версионность, быстрая или частичная загрузка, стили, индексы для поиска и т.д, что тоже всё в юникод совать?
Это новая версия почтовика с математическими формулами
Здравствуйте, Shmj, Вы писали:
S>>>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места. E>>В наше время пакуемых на лету потоков и файлов эта проблема не актуальна.
S>По факту все равно все хранят без всякой паковки, так что
А это никого не парит, тащем-то. Кроме нищебродов, которые не могут купить себе диск побольше
Здравствуйте, Shmj, Вы писали:
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
S>И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
Юникод спроектирован так, что по любому символу можно определить, является он самостоятельным или частью комбинации. То есть ткнули наугад в середину строки, если попали на первый символ — хорошо, не попали — достаточно будет сдвинуться на несколько байтов влево или вправо.
А если в составе юникода будут бинарные данные, то парсить текст всегда придется только с самого начала. Ведь если ткнуть в середину, будет неизвестно, на что мы попали: является этот символ частью текста или частью бинарных данных?
Но сама идея правильная, нужная. Только не в стандартный юникод нужно пытаться бинарные данные пихать, а разработать новый стандарт (да-да, тут картинка про стандарты...) Юникод, имхо, неэффективен: часть битов в нем расходуется не на хранение данных, а на индикацию, какой частью они являются. А в новом стандарте от этого можно избавиться. Но, да, парсить всегда придется только с самого начала.
Здравствуйте, Marty, Вы писали:
S>>>>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места. E>>>В наше время пакуемых на лету потоков и файлов эта проблема не актуальна. S>>По факту все равно все хранят без всякой паковки, так что M>А это никого не парит, тащем-то. Кроме нищебродов, которые не могут купить себе диск побольше
Вы не правы. Нищебродам не до такой ерунды. У них другие проблемы, и во что бы то не стало нужен новый iphone.
Упаковка даёт помимо уменьшения объёма данных, увеличение скорости чтения(при той же пропускной способности), а так же контроль целостности данных.
Здравствуйте, Shmj, Вы писали:
S>Сейчас все больше и больше юзают Base64. Уже даже картинки вставляют в этом формате (см. первый попавшийся стиль: https://userstyles.org/styles/31267/global-dark-style-changes-everything-to-dark).
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
А что если в "бинарном тексте" содержаться символы "начало/конец бинарного текста"?
Отож. Не удобно.
