По поводу картинки - все правильно. Все как раз потому что нет универсального формата и достичь его на сейчас вот прям нельзя. Возможно когда-нибудь вычислительные мощности вырастут настолько, что не будут обращать внимание ни на время разбора ни на занимаемый объем. Тогда будет какой-нибудь уникальный формат для пихания туда всего и вся. На данный момент ограничения пока есть и потому приходится использовать специализированные форматы для достижения наибольшей эффективности либо для соблюдения еще каких-то требований.
У меня тоталкомандр открывает. Да и есть ряд блокнотов которые так умеют.
Редакторы в этих Лазарусах и Дельфи открывают исходники в том месте, где Вы в последний раз работали. Думаю и в других ИДЕшках ничем не хуже.
Мы хорошо видим это только при существенных объемах. Опять же Вы не учитываете сколько и каких там похожих знаков.
Проблема не в этом, а в том что знаки начинают становится сильно похожими при увеличении их кол-ва.
Уверен, что надо пробовать, а не утверждать. Второе - локально решить проблему можно, если сделать отличными только русские буквы. В любом случае здесь есть варианты. Третье - задействовать тяжелую артиллерию - менять цвета, размеры и т.д. В совокупности характеристик будет видно.
И пользователи привыкли к некоторому их стандартному виду (строго определенных шрифтам) - отличия будут их сразу же раздражать.
Если в тексте нет смесей (а именно для того чтобы это распознать и есть смысл нововведения), то все смотрится культурно. Проблемы будут когда в текстах идет попытка подмены - тогда это будет видно и будет раздражать, все правильно. Так и задумано.
1. Отличия будут видны плохо при существенных объемах.
Жульничество обычно используется в небольших объемах - именах, паролях, номерах контракта и т.д.
2. Существует и еще долго будет миллиард пользователей без этих шрифтов, которых можно эксплуатировать, т.е. шрифт вообще ничего не даст.
Существует и миллиард пользователей без Интернета Юникода. В этом и есть сила эволюции 
, как Вы не поймете. У людей есть право выбора, которым они пользуются для принятия управленческих решений. И инстинкты самосохранения обычно принуждают их делать оптимальные (или близкие к ним) решения. Вообще что за привычка решать за других? Есть такая хорошая поговорка - Благими намерениями вымощена дорога в ад. И таких благодетелей человеческих просто тьма. Последним из известных был знаменитый художник Адольф Алозич. Помните он там ради арийцев чуть полмира не нагнул? А ведь помыслы его (если читать его бред и смотреть его рисование) были чисты и благородны. Поймите вместо тоталитаризма (решить за другого) нужно дать людям право выбора. Дайте возможность все испортить самим людям, тогда и вина за их ошибки будет лежать на них. А эволюция сама расставит все по местам.
Но они уже должны будут учитывать его спецификацию. А существующие - не смогут.
Это вообще какой-то детский лепет. Ну не сможет Экзель открывать Ваш формат, что это меняет-то? Человек идет в Инет - скачать программу для работы с .ххх Какие проблемы-то? Ваше решение вопроса безопасности устраняется за несколько минут. Классный отмазон - текст можно вскрыть потому что есть Блокнот, а мой супер формат нельзя, потому что для этого нужно будет скачать отдельно программу, которая не входит в состав операционной системы . Ни у кого же нет Интернета.
А существующие - не смогут.
А существующие понаделают плагинов и обновлений, проблема-то? Те же программы для работы с XML (не Блокнот, а специализированные, с дополнительными операциями над структурой) и будут открывать еще дополнительно и Ваш формат в довесок.
Т-щ Джавадов давно написал, что данные по куче файлов - это безусловный ужас.
Если звезды зажигаются, значит это кому-то нужно. Иными словами, так делали не просто так, а потому что были причины, например, скорость обработки. Или простота реализации, или надежность.
Я уже писал и снова напишу - Вы хотите уместить в одно взаимоисключающие параметры.
Насколько дороже и почему? Увеличение кода вдвое против масштабируемости в тысячу или миллион раз?
Все потому же - ложки нет и нельзя обьять необъятное. Вот персоналка плохо масштабируется и стоит дешево. Вот сервер обалденно масштабируется и посмотрите его цену. Масштабируемое решение стоит от полумиллиона рубликов.
И файлы по 4Гб не проблема. На многие носители больше и не войдет.
Проблема. На носитель-то войдет. А операционка даст Вам работать с объектом в 4ГБ? Не с его частью, а с файлом? Воот, ни каждая птица долетит до середины Днепра. Поэтому пока имеется какой-то неудобный процент старого хлама (а в банках терминалы хлам, например) так будет. Я еще раз говорю Вам, да, Экзель споткнется на csv в миллион записей. Но он споткнется в миллион записей и своего родного не текстового экзелевского формата. Понимаете? Это не проблема текста - миллион записей. На данный момент это общая проблема - наше программное обеспечение как-то не готово к миллионам записям в обычной работе.
JPG далеко не всегда эффективен для картинок, скорее для снимков, а MP3 - хорош для музыки, но не всегда для звука.
Поэтому и нету идеального формата и не будет его еще долго. Теперь Вы понимаете почему такой хаос и разврат?
Где какие-то доказательства оптимальности?
Очевидно же - идеального формата нет это раз. То решение к которому Вы пришли (нарожать оптимальных форматов) есть и сейчас - существует куча форматов на вкус и цвет это два.
Протоколов очень много - не может один человек их все знать
Ему и не нужно. Я тоже не знаю стандартов цифрового телевидения, я просто использую интерфейс "пульт дистанционного управления" и нисколько не страдаю от этого.
Хотелось бы споров по существу
Так изначально целесообразность процесса поставлена под сомнение. Вы наступаете на текстовые форматы, претендующие на мелкую автоматизацию в силу универсальности, но при этом доказательств крутости бинарных форматов и нет. Те же базы данных абсолютно не мобильны. Остальные форматы не универсальны. Они не безопасны. По крайней мере в сравнении с текстовыми данными не обладают никаким преимуществом. У них есть тоже всякие траблы. Например, те же БД имеют ограниченный набор записей. Это число достаточно велико (сколько там в 4 байта умещается?), но оно конечно. В XML такого ограничения нет. Конечно никакая программа не откроет Вам XML с количеством записей величиной с гугол (10 в 100 степени). Но в спецификации XML количество узлов не ограничено. Поэтому тут наверно нужно сравнительные таблицы строить для наглядности - во-первых, за что Вы ратуете? За БД? Потому что других универсальных я не знаю, может и есть какой-нибудь. Ну, а чего? Rar тоже универсальный контейнер . Во-вторых, нужно построить недостатки и достоинства универсальных текстовых форматов (а их больше. чем XML) или выбранного двоичного способа хранения информации.
Хорошо, вот Вам новая претензия - посмотрите на БДшный софт. XML парсер может быть где угодно, даже на стороннем сервере. Разнесчастный Интернет Эксплорер через задницу, но все же умеет парсить XML. Для того чтобы работать с БД часто нужно создать много геморроя. Типа сервис установить, службу запусть, порт подавай свободный и т.д. И далеко не все и не всегда это настраивается автоматически (потому что 10-ке не нравится открыть порт, если это не MS SQL Server ). Я уже молчу о проектировании БД, а размеры программного обеспечения и СУБД и средств разработки тоже превосходят XMLные инструменты. Вот Вам объективная оптимальность бинарного формата. Далее, теория реляционных БД намного сложней спецификации XML. И хотя там тоже книжица в 700 страниц, но чтобы забабахать по-быстрому на коленке хватит и пару дней чтения (узлы и атрибуты, без валидации и схем).
почему мы должны использовать JSON вместо XML
Только потому что Javascript умеет его передавать по сети "изкаропки".
а не потому что так у кого-то где-то, они же умные, а мы, значит дураки
Вопрос стоит не так. Вопрос тут даже не в изобретении велосипеда, а в изобретении колеса. Вы же толком сами ничего про бинарники не сказали. Где сам формат-то? БД или что это? Я вот указал на проблему - укажите мне как Вы будете обходить проблему с конечностей количества записей в бинарном формате?
Мы не можем отказаться от файлов
Мы никогда не сможем от них отказаться. Файл это поименнованная область в общем виде. Обычно поименнованная область данных на внешнем носителе информации, но это не точно. Если уходить в философию - разницы между файлом и переменной особой нету. Есть детали реализации и эксплуатации.
Отредактировано utkin (2019-03-27 10:51:32)
