 | | | | |
| Base64 для не продвинутых. |
Полный текст материала
Другие публикации автора: Александр Терехов
Цитата или краткий комментарий: | «... ...Поэтому появилась необходимость каким-то образом преобразовать двоичный файл в текстовый. Вообще-то способ такого преобразования уже имел место - это UUE кодирование. Но появился еще один - base64. Этот способ используется в спецификации MIME (RFC2045-2049).
...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 11 | 84.6% | | | | | Ничего особенно нового и интересного | | [2] | 1 | 7.7% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 1 | 7.7% | |
Всего проголосовали: 13 | | | | Все понятно, материал читается легко | | [1] | 8 | 80% | | | | | Есть неясности в изложении | | [2] | 2 | 20% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 10 |
[Спецификации RFC] [Кодирование данных]
Отслеживать это обсуждение 
Всего сообщений: 2119-02-2017 06:58| Замечательное последнее сообщение от анонимного автора. И как я смогу использовать эту ссылку в своей программе на Delphi?! :-) |
|
17-02-2017 05:13
17-03-2014 06:43Поправьте, пожалуйста ссылки на файлы (ни один не скачивается)
http://www.gunsmoker.ru/2010/05/blog-post_25.html
Начнём с этого(http://www.delphi3000.com/articles/article_3404.asp) - всем
известная реализация Base64 на http://www.delphi3000.com/ от Daniel
Wischnewski из Delphi-PRAXiS - далеко не "noname" товарищ. Исходник имеет
рейтинг 9/10. Разошёлся по многим FAQ и используется в куче программ (в том
числе, он использовался в EurekaLog).
Казалось бы, что может пойти не так?
Оказывается, что эта реализация вообще не работает (под этим
подразумевается, что она не работает корректно, иными словами, не должна
работать вообще). Конкретно: этот код содержит memory corruption bug. Ещё
конкретнее: в Base64Encode, третья строка "mov EAX, EBX" - какой-такой ещё
EBX? Он неопределён. Правильный вариант выглядит так: "mov EAX, InSize"
(как это и сделано в Base64Decode).
Столкнулся я с этим в поддержке EurekaLog. Мы получили баг-отчёт с memory
corruption на ровном месте. К счастью была предоставлена воспроизводимая
демка, и я по ней вышел на этот код, который когда-то был взят с Delphi3000
и встроен в EurekaLog. Вместе с багом. Удивительно, что это работало
несколько лет. Ещё удивительнее, что никто, использующий этот код или его
копии из FAQ, за 7 лет не нашёл этой ошибки. Окей, наверняка кто-то
сталкивался с загадочными багами, но причину найти не могли. Вот она, сила
Copy&Paste.
Конкретно в варианте с EurekaLog EBX наследовался из вызывающего, где он
оказывался равен OutSize из Base64EncodeStr (вместо InSize; InSize <=
OutSize). Соответственно, Base64Encode кодировала больше данных, чем было
нужно (заодно портя память, т.к. выходной буфер был предназначен только для
содержания кодированных InSize байт, а не OutSize байт). Например, вместо
взятия, скажем, 11-ти байт с входного буфера и записи их в 16-ти байтный
выходной буфер, эта функция брала 16 байт из исходного буфера (ага, шанс на
AV не сработал) и записывала 24 байта в выходной буфер (который имел размер
16 байт). Да, алгоритм работал, да он выполнял кодирование/декодирование.
Но работал неверно - он портил память. Но это работало. В 99.9% случаев всё
"просто работало" и не было никаких ошибок или вылетов. Но иногда ваше
приложение вылетало. Причём в месте, совершенно никак не связанным с
исходной проблемой. Это был какой-то совершенно другой код.
Ситуацию в этом случае усложняет то, что пример написан на ассемблере, что
затрудняет его чтение и анализ.
Вот корректный вариант реализации Base64, который использует только Паскаль
и, более того, работает быстрее вышеуказанной ассемблерной реализации:
|
|
17-03-2014 03:45| Поправьте, пожалуйста ссылки на файлы (ни один не скачивается) |
|
15-10-2009 19:24| Да-а-а... Так не внимательно описывать свои мысли... Нет, на картинках все правильно, а вот "конвейер"... Что SHR автору, что SHL ... один фиг ... Вернее это ,скорее всего, от "программирования методом копирования". Ну это ладно. А вот начинающим предлагать такой "конвейер" вместо нормальных "накладываем маску на 1 байт - есть первый символ, накладываем маску на первый байт, сдвигаем, накладываем маску на второй байт, сдвигаем, складываем полученное - есть второй символ....ну и т.д. Быстро, правда не очень наглядно, зато "начинающие" быстрее становятся "продвинутыми". |
|
03-06-2009 22:27
16-04-2008 09:12| Отличная статья. Все понятно. Побольше бы таких. Респект автору ;) |
|
16-04-2008 00:49| Большая просьба, можно поправить ссылки на файлы? |
|
11-07-2007 14:47Отличная статья.
Нашел ее в поисках ответа на такой вопрос: если в алфавите присутствуют символы "#" и ".", и алфавит кажется "перемешанным", то как восстановить справедливость и выполнить декодирование?
Похоже, что попалась нестандартная реализация base64.
Идеи очень прошу на inbox (сoбaкa) god.su |
|
04-12-2006 02:07| 404 по всем ссылкам Сообщение не подписано |
|
25-05-2005 08:42Сорри, при ссылке на base64unit.pas приходит 404 с сообщением :
"В каталоге сервера не найден запрошенный материал""
|
|
02-07-2003 14:18| на самом деле очень простой и подробный материал! большое спасибо за проделанную работу :) |
|
28-06-2003 17:11| RESPECT!!! Сообщение не подписано |
|
09-04-2003 13:22Прошу пардону. На самом деле правильно - 57, а не 58.
И 76, а не 72.
Я как обычно тупил %))) |
|
09-04-2003 10:42Соратники! Я допускаю, что "72" - это опечатка, на самом деле - 76. Но! 76*6/8=57 а не 58. Кусочек скрипта:
while (read(FILE, $buf, 58)) {foo(encode_base64($buf));}
где encode_base64 - библиотечная ф-ция.
Если в буфер читать по 58 - работает верно. Если по 57 - бинарник с некоторой строки порется. ПОЧЕМУ 58? |
|
08-04-2003 17:18Товарищи! Я последние мозги себе сломал, пытаясь понять,- почему
для кодирования берем по х58 байт, а так же почему в статье говорится о 72-символьных строках, когда мы можем невооруженным глазом в области аттача наблюдать 76-символьную строку..:(
Будте добре - растолкуйте! |
|
07-03-2003 08:48А вот такой вопрос:
я уже несколько дней ищу пример, как можно в коде HTML странички использовать MIME, чтоб картинки хранились в тексте HTML и когда их много и они маленькие, объем передаваймой инфы уменьшился за счет конкретного уменьшения числа новых транзакций.
Пару лет назад видел такой пример, но теперь не могу вспомнить где.
Может, у автора статьи есть подобный рабочий пример? |
|
03-03-2003 08:38| Спасибо, доходчиво растолковали. А можно о 644 также? |
|
12-02-2003 02:52
18-10-2002 15:32
17-10-2002 15:12Хорррошая статья.
Жаль я не читал. |
|
|
|
