Base64 към изображение

Base64 към изображение е безплатен инструмент, който преобразува кодирани с Base64 данни обратно в изображение.

Как Base64 представя изображение?

Base64 представя изображението, като преобразува двоичните му байтове в ограничен набор от печатни текстови знаци. Този начин на кодиране се използва, защото някои системи са предназначени да пренасят текст, а не необработени двоични данни. Така байтовете могат по-лесно да се включват в имейли, JSON, HTML и други текстови формати.

Стандартната Base64 азбука съдържа главни и малки латински букви, цифри, знаци плюс и наклонени черти. В края може да има знак за равенство, използван за допълване. Обикновено всеки три входни байта се превръщат в четири Base64 знака, затова кодираният вариант е с около една трета по-голям от оригиналните данни.

Един кратък текстов пример показва ясно как работи това:

• Оригинални байтове, интерпретирани като текст: Man
• Резултат в Base64: TWFu

При изображенията процесът е същият, но оригиналните байтове описват PNG, JPEG, GIF, WebP или друг графичен формат, а не четим текст. Необработените Base64 данни сами по себе си не посочват типа на изображението. Тази информация може да присъства в URL адрес за данни или да бъде разпозната по сигнатурата на декодирания файл.

Как да преобразувам Base64 обратно в изображение?

Постави Base64 данните на изображението в инструмента и ги изпрати за преобразуване. Полученият резултат ще бъде изображение. Преди това провери дали стойността е необработен Base64, или пълен URL адрес за данни.

1. Намери кодираната стойност и я копирай без ограждащите кавички от JSON, CSS или изходния код.
2. Провери за префикс на URL адрес за данни, например data:image/png;base64,. Същинските Base64 данни започват след запетаята.
3. Ако пълният URL адрес за данни бъде отхвърлен, премахни префикса и изпрати само кодираното съдържание. Различните декодери невинаги приемат тази обвивка.
4. Преди да използваш изображението другаде, провери дали съдържанието, размерите и форматът му отговарят на очакваното.

Понякога в стойността се появяват интервали и нови редове, когато програма за електронна поща пренася дълъг Base64 низ. Някои декодери пренебрегват тези празни знаци, а по-строгите ги отхвърлят. Не добавяй пунктуация или обяснителен текст към кодираните данни. Цифрите са валидни Base64 знаци, но низ, съставен само от допустими знаци, не е непременно изображение.

Празната Base64 стойност не представя никакви байтове и следователно не може да създаде използваемо изображение. Много дългите стойности също са обемни, защото Base64 увеличава размера на оригиналните данни, а обработката изисква целият кодиран низ да бъде прехвърлен и декодиран.

Защо Base64 изображението не се декодира?

Base64 изображението обикновено не се декодира, когато данните са повредени или непълни, използват грешна азбука или не съдържат байтове на изображение. Причината може да е и двойно кодиране, ако източникът е кодирал данните повече от веднъж. Мястото и видът на грешката могат да помогнат да установиш проблема.

• Съкратени входни данни. При копиране от регистрационни файлове, програми за преглед на бази данни или системи за съобщения краят на дългата стойност може да бъде отрязан. Липсващите знаци обикновено водят до непълни декодирани байтове.
• Грешен вариант или азбука. Стандартният Base64 използва + и /, докато Base64url обикновено използва - и _. Декодер, който очаква другия вариант, може да отхвърли входните данни.
• Липсващо допълване. Base64 стойностите могат да завършват с един или два знака за равенство. Някои системи пропускат това допълване, а някои декодери го възстановяват, но строгите реализации може да го изискват.
• Двоични данни, които не са изображение. Base64 може да представя PDF файл, архив, шрифт или произволни други байтове. Следователно валидният Base64 не гарантира валидно изображение.
• Объркване при кодирането на текст. Буквите с диакритични знаци, емоджитата и знаците извън латиницата не са част от Base64 азбуката. Преди кодиране с Base64 те трябва да бъдат представени като байтове, обикновено чрез UTF-8.
• Двойно кодиране. Ако първото декодиране даде друг дълъг низ, съдържащ само Base64 знаци, източникът може да е бил кодиран два пъти. Декодирай междинната стойност още веднъж само ако произходът ѝ потвърждава, че това е очаквано.

Ако универсален Base64 декодер покаже неразбираеми знаци, това не означава непременно, че декодирането е неуспешно. Байтовете на изображенията са двоични и не се очаква да изглеждат като четим текст. Използвай Base64 декодер, когато трябва да прегледаш съдържание, което не е изображение, и Изображение към Base64, когато искаш да извършиш обратното преобразуване.

Къде се използват изображения, кодирани с Base64?

Base64 данни за изображения се използват навсякъде, където двоични файлове трябва да бъдат пренесени чрез поле или документ, предназначени за текст. Типични примери са вградени изображения в URL адреси за данни в HTML или CSS, свойства за изображения в JSON заявки към API и MIME части на имейли.

Такива данни могат да се срещнат и в низове със заявки, където анализаторите на приложението понякога обработват неправилно стандартните Base64 знаци. Това важи особено за анализатори на формуляри, които приемат знаците плюс за интервали или знаците за равенство за разделители. Base64url заменя проблемните знаци от азбуката и често пропуска допълването, което го прави по-подходящ за URL адреси и токени.

Интернационализираните имена на домейни не използват Base64. В системата IDNA ASCII етикетите остават непроменени, а U-label етикетите с не-ASCII знаци могат да бъдат представени като A-label етикети чрез Punycode. Base64 стойност може да присъства на друго място в URL адреса, например в низа със заявката. Това разграничение е важно, когато проверяваш стойност, копирана от адресната лента на браузър.

JSON няма собствен тип за двоични данни, затова API интерфейсите понякога поставят Base64 съдържанието на изображението в низ, ограден с кавички. Това е удобно при обмен на текстови данни, но увеличава размера на заявката. За големи или чести качвания обикновено е по-подходящо стандартно качване на двоичен файл.

Base64 кодиране, поверителност и обработка на сървъра

Base64 е кодиране, а не шифроване, и не осигурява поверителност. Всеки, който разполага със стойността, може да я декодира без парола или ключ. Затова данни за достъп, лични снимки и поверителни документи не бива да се защитават само чрез преобразуване в Base64.

При този инструмент обработката се извършва на сървъра. Въведените данни се изпращат до него чрез HTTPS и не се съхраняват. HTTPS защитава връзката при преноса, но не превръща Base64 стойността в шифровано съдържание и не прави ненадеждния източник безопасен.

Декодирането също не проверява дали изображението е безопасно. Отнасяй се към изображенията, декодирани от Base64 стойности, получени от неизвестни податели, със същото внимание като към останалите изтеглени изображения.

Често задавани въпроси

Мога ли да разпозная формата на изображението само по Base64 данните?

Понякога, но самата Base64 азбука не посочва формат. Декодираните файлове съдържат сигнатури, често наричани магически байтове, чрез които софтуерът може да различава формати като PNG, JPEG и GIF. URL адресът за данни също може да посочва медиен тип, но този етикет може да е грешен и не бива да има предимство пред действителните байтове.

Декодирането от Base64 намалява ли качеството на изображението?

Не. Правилното декодиране от Base64 възстановява оригиналните байтове и не компресира изображението повторно. Качеството, цветовите данни и вградените метаданни остават непроменени, освен ако друга програма впоследствие не редактира или преобразува декодирания файл.

Може ли Base64 да съдържа SVG изображение?

Да, SVG данните могат да бъдат кодирани с Base64, макар че показването им зависи от поддръжката в приемащия софтуер. SVG е формат, базиран на XML, и може да съдържа скриптове, връзки или външни препратки. Затова не приемай, че SVG файл, кодиран с Base64 и получен от неизвестен източник, е безопасен за отваряне.

Защо Base64 изображението е по-голямо от оригиналния файл?

Base64 създава четири текстови знака за всеки три байта от изходните данни, а последният блок може да съдържа допълване. RFC 4648 изисква допълване, освен ако съответната спецификация изрично не позволява то да бъде пропуснато. Затова резултатът е с около една трета по-голям, още преди да бъдат добавени префиксът на URL адреса за данни, кавичките в JSON или допълнителните данни за пренос. Когато системата приема обикновено качване на файлове, изпращането на оригиналното двоично изображение обикновено използва по-малко данни.