Так вот. А что если принудь консорциум Unicode ввести 2 символа:
1. Начало бинарного текста.
2. Конец бинарного текста.
И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
В примитивных текстовых редакторах преобразоывать в Base64, чтобы чел. мог редактировать как раньше. Но при сохранении, опять таки, вертать все взад. А в продвинутых редакторах отображать как BLOB с возможностью навести и отредактировать в любом формате, хоть в HEX хоть в BASE64 хоть файл вставить.
Гениально?
З.Ы.
Наверное, еще придется добавить симфол для экранирования символа 2. Или же убрать символ 2 а после символа 1 обязать указывать длину бинарного текста.
Здравствуйте, kov_serg, Вы писали:
_>Hex и Base64 может быть набрана на клавиатуре, _>а вот попробуйте однозначно воспроизвести unicode с распечатанного текста.
Я же написал — в примитивных редакторах отображать бинарный текст как Base64. Ну и добавить типа символ B> и <B или только один.
_>И зачем изобретать новый стандарт? _>https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
Здравствуйте, Shmj, Вы писали:
S>И тогда при сохранении в текстовый файл или при передаче по сети — бинарные данные передавались бы как есть — без преобразования в Base64.
В Microsoft от такого подхода наоборот отказались для rtf (Rich Text Format). То есть в rtf всё ещё есть тег binN, и современный rich edit control в windows вполне нормально его читает, но при записи заменяет на какой-нибудь не бинарный аналог. Зато файл с не бинарными данными можно открывать и править в любом текстовом редакторе не опасаясь, что какая-нибудь замена пробелов на табуляции (или что-то подобное) всё поломает.
Здравствуйте, Shmj, Вы писали:
S>Гениально?
Эмм, а можно пояснить — зачем этот троллейбус из буханки?
Какую проблему решает это нововведение? S>З.Ы. S>Наверное, еще придется добавить симфол для экранирования символа 2. Или же убрать символ 2 а после символа 1 обязать указывать длину бинарного текста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kov_serg, Вы писали:
_>Hex и Base64 может быть набрана на клавиатуре, _>а вот попробуйте однозначно воспроизвести unicode с распечатанного текста.
Здравствуйте, Shmj, Вы писали:
S>Так вот. А что если принудь консорциум Unicode ввести 2 символа:
S>1. Начало бинарного текста. S>2. Конец бинарного текста.
Я предлагаю сразу ввести ASN.1 в новый стандарт 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, через чат или напечатать на бумаге, перепечатать на пишущей машинке под диктовку по телефону и отправить почтой россии на оленях, что бы потом набрать с ручками и преобразовать обратно в бинарный файл.
Кто мешает сделать то же самое с юникодом? Распечатать в шестнадцатиричном представлении и возить на оленях? А на месте вбить, и распечатать уже то, что он описывает?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
