Так вот. А что если принудь консорциум Unicode ввести 2 символа:
1. Начало бинарного текста.
2. Конец бинарного текста.
И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
В примитивных текстовых редакторах преобразоывать в Base64, чтобы чел. мог редактировать как раньше. Но при сохранении, опять таки, вертать все взад. А в продвинутых редакторах отображать как BLOB с возможностью навести и отредактировать в любом формате, хоть в HEX хоть в BASE64 хоть файл вставить.
Гениально?
З.Ы.
Наверное, еще придется добавить симфол для экранирования символа 2. Или же убрать символ 2 а после символа 1 обязать указывать длину бинарного текста.
Здравствуйте, Shmj, Вы писали:
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
Я предлагаю сразу ввести ASN.1 в новый стандарт Unicode.
Здравствуйте, Shmj, Вы писали:
S>И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
В Microsoft от такого подхода наоборот отказались для rtf (Rich Text Format). То есть в rtf всё ещё есть тег binN, и современный rich edit control в windows вполне нормально его читает, но при записи заменяет на какой-нибудь не бинарный аналог. Зато файл с не бинарными данными можно открывать и править в любом текстовом редакторе не опасаясь, что какая-нибудь замена пробелов на табуляции (или что-то подобное) всё поломает.
Здравствуйте, Shmj, Вы писали:
S>Сейчас все больше и больше юзают Base64. Уже даже картинки вставляют в этом формате (см. первый попавшийся стиль: https://userstyles.org/styles/31267/global-dark-style-changes-everything-to-dark).
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
А что если в "бинарном тексте" содержаться символы "начало/конец бинарного текста"?
Здравствуйте, kov_serg, Вы писали:
_>Hex и Base64 может быть набрана на клавиатуре, _>а вот попробуйте однозначно воспроизвести unicode с распечатанного текста.
Я же написал — в примитивных редакторах отображать бинарный текст как Base64. Ну и добавить типа символ B> и <B или только один.
_>И зачем изобретать новый стандарт? _>https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
Здравствуйте, Shmj, Вы писали:
S>Гениально?
Эмм, а можно пояснить — зачем этот троллейбус из буханки?
Какую проблему решает это нововведение? S>З.Ы. S>Наверное, еще придется добавить симфол для экранирования символа 2. Или же убрать символ 2 а после символа 1 обязать указывать длину бинарного текста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kov_serg, Вы писали:
_>Hex и Base64 может быть набрана на клавиатуре, _>а вот попробуйте однозначно воспроизвести unicode с распечатанного текста.
Здравствуйте, Sinclair, Вы писали:
S>>Гениально? S>Эмм, а можно пояснить — зачем этот троллейбус из буханки? S>Какую проблему решает это нововведение?
1. Текстовые файлы с элементами бинарных данных будут занимать меньше места.
2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования).
Здравствуйте, Shmj, Вы писали:
S>>Какую проблему решает это нововведение?
S>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места.
Глупости. textfile.txt.gz занимает в 10 раз меньше места и не требует дополнительных нововведений.
и работать с ним легко zcat textfile.txt.gz | grep foobar | head S>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования).
А если редакторам понадобится оглавление, превью история изменений, мульти версионность, быстрая или частичная загрузка, стили, индексы для поиска и т.д, что тоже всё в юникод совать?
Здравствуйте, kov_serg, Вы писали:
_>Бред™. Попробуй русскую букву O отличить от латинской O или от греческой Ο или полуширинный пробел от пробела который нельзя переносить, не говоря уже о направления вывода текста и всяких модификаторах. _>А в base64 вы 4 байтами однозначно кодируете 3 байта, при этом символы всё же можно различить визуально и набрать на обычной клавиатуре.
Ты про бумагу начал. Если на бумаге простой текст, то ты в уме никуда его не закодируешь, и с переводом разноязычных букв у тебя будут те же проблемы и в base64. А если он на бумаге уже кодированный, то какая разница, какой вводить? У юникода разве что побольше знаков будет.
Не надо придумывать разные условия для разных кодировок.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, kov_serg, Вы писали:
_>Глупости. textfile.txt.gz занимает в 10 раз меньше места и не требует дополнительных нововведений. _>и работать с ним легко zcat textfile.txt.gz | grep foobar | head
Можно вообще ничего не делать — диски дешево стоят. Архивирование туда-обратно не всегда удобно, лучше не плодить сущности.
S>>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования). _>А если редакторам понадобится оглавление, превью история изменений, мульти версионность, быстрая или частичная загрузка, стили, индексы для поиска и т.д, что тоже всё в юникод совать?
Речь же о человеко-машинно-читаемых форматах, как CSS, JSON, XML и пр.
Здравствуйте, Shmj, Вы писали: S>1. Текстовые файлы с элементами бинарных данных будут занимать меньше места.
Попробуйте xml.zip — будете удивлены. Во-первых, меньше места будут занимать даже те XML, где нет никакого base64. Во-вторых, не нужно уговаривать ни Unicode Consortium, ни w3c, ни авторов редакторов для XML. S>2. Появится возможность в продвинутых редакторах более удобной работы с нечитаемыми человеком бинарными данными (отображать их в виде символа BLOB и добавить расширенные возможности для редактирования).
Непонятно, откуда возьмутся расширенные возможности редактирования. Ведь редактор ничего не знает про эти данные — то ли там музыка, то ли видео, то ли PNG.
А если редактор — специализированный, то он и с base64 справится прекрасно.
Вот, есть, например, такой широко известный специализированный редактор XML — Microsoft Word. Он отлично редактирует и текстовые и бинарные данные.
Низкоуровневому редактору вроде visual studio удобнее работать с текстом — т.к. там я хотя бы могу сделать copy-paste общегражданскими средствами.
Ну, и не забываем про остальной тулчейн — например, XML-с-base64 отлично мёрджится стандартными средствами вроде TortoiseMerge и десятками других.
Для полубинарного формата придётся отказаться от этих инструментов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ops, Вы писали:
Ops>Ты про бумагу начал.
base64 решает другие задачи. он кодирует бинарные данные печатными символами как и UUE Ops>Если на бумаге простой текст, то ты в уме никуда его не закодируешь,
Причем тут "в уме" если надо в уме то hex или number sequence, assembler или яп ... Ops> и с переводом разноязычных букв у тебя будут те же проблемы и в base64.
С какого бодунища? Там A-Za-z0-9 и еще 2 символа. Какие проблеммы? Нет контрольных сумм и таблиц востановления?
Не нравится intel hex еще есть
Ops> А если он на бумаге уже кодированный, то какая разница, какой вводить? У юникода разве что побольше знаков будет.
Именно невозможно однозначно юникодный текст ввести с клавиатуры.
Вот попробуйте выделить или скопировать кусок unicode текста или ввести такое с клавиатуры
cat abc.txt
Здравствуйте, kov_serg, Вы писали:
Ops>> А если он на бумаге уже кодированный, то какая разница, какой вводить? У юникода разве что побольше знаков будет. _>Именно невозможно однозначно юникодный текст ввести с клавиатуры.
\u0123\u0124\u0125
Такое же нечитаемое как base64, и легко вводимое
Не надо придумывать разные условия для разных кодировок. На бумаге оно будет или в виде нормального текста, или такое нечитаемое, для обоих случаев.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, kov_serg, Вы писали:
Ops>>> А если он на бумаге уже кодированный, то какая разница, какой вводить? У юникода разве что побольше знаков будет. _>>Именно невозможно однозначно юникодный текст ввести с клавиатуры. Ops>\u0123\u0124\u0125 Ops>Такое же нечитаемое как base64, и легко вводимое
Не путайте мягкое с тёплым. unicode текст и варианты его кодирования.
unicode используется для отображения текстов разных народов с их за_бами и плюс кучи другого гавнища. Но он не предназначен для передачи данных 1 в 1.
В нём заложена лютая неоднозначность. Ops>Не надо придумывать разные условия для разных кодировок. На бумаге оно будет или в виде нормального текста, или такое нечитаемое, для обоих случаев.
Вы видимо думаете о чем-то своём. Я говорю про то что unicode текст не всегда можно даже выделить и скопировать 1 в 1 из одного редактора в другой, не то что набрать с клавиатуры смотря на изображения этого текста.
Например символ U+0419 (Й) можно записать как U+0418 + U+0306 ( Й ).
\u0123 — это такой же юникод, как 0x123 и ģ и %01%23 или U+xxxxxx это просто варианты его кодирования когда отображать символы юникодом бессмысленно или не возможно.
Здравствуйте, kov_serg, Вы писали:
_>Вы видимо думаете о чем-то своём. Я говорю про то что unicode текст не всегда можно даже выделить и скопировать 1 в 1 из одного редактора в другой, не то что набрать с клавиатуры смотря на изображения этого текста.
В Base64 точно так же невозможно для символов не из ASCII — нужна информация о кодировке, которой он сам не содержит.
_>Например символ U+0419 (Й) можно записать как U+0418 + U+0306 ( Й ). _>\u0123 — это такой же юникод, как 0x123 и ģ и %01%23 или U+xxxxxx это просто варианты его кодирования когда отображать символы юникодом бессмысленно или не возможно.
Так Base64 — это тоже способ представления.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>В Base64 точно так же невозможно для символов не из ASCII — нужна информация о кодировке, которой он сам не содержит.
??? Накой. base64 представляет бинарные данные (любые бинарнае данные хоть видео хоть текст хоть exe-шник) в виде печатных ASCII символов A-Za-z0-9 и еще 2х типа + /, так чтоб их потом можно было отправить email, через чат или напечатать на бумаге, перепечатать на пишущей машинке под диктовку по телефону и отправить почтой россии на оленях, что бы потом набрать с ручками и преобразовать обратно в бинарный файл.
_>>Например символ U+0419 (Й) можно записать как U+0418 + U+0306 ( Й ). _>>\u0123 — это такой же юникод, как 0x123 и ģ и %01%23 или U+xxxxxx это просто варианты его кодирования когда отображать символы юникодом бессмысленно или не возможно. Ops>Так Base64 — это тоже способ представления.
Нет это способ кодирования бинарных данных.
Здравствуйте, kov_serg, Вы писали:
_>??? Накой. base64 представляет бинарные данные (любые бинарнае данные хоть видео хоть текст хоть exe-шник) в виде печатных ASCII символов A-Za-z0-9 и еще 2х типа + /, так чтоб их потом можно было отправить email, через чат или напечатать на бумаге, перепечатать на пишущей машинке под диктовку по телефону и отправить почтой россии на оленях, что бы потом набрать с ручками и преобразовать обратно в бинарный файл.
Кто мешает сделать то же самое с юникодом? Распечатать в шестнадцатиричном представлении и возить на оленях? А на месте вбить, и распечатать уже то, что он описывает?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, 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.
Упаковка даёт помимо уменьшения объёма данных, увеличение скорости чтения(при той же пропускной способности), а так же контроль целостности данных.
Отож. Не удобно.
