Защо прикаченият файл и съобщението имат различен размер
При изпращане се увеличава преди всичко размерът на съобщението, в което е включен твоят PDF файл. Първоначално електронната поща е създадена за текст. Затова пощенската ти програма включва прикачените файлове във формат MIME и обикновено преобразува двоичните данни в обикновени текстови знаци чрез Base64. При това всеки 3 байта от файла се превръщат в 4 знака, а тези знаци се разпределят по редове със знаци за край на ред. Самото Base64 кодиране е обратимо: при декодирането се възстановяват точно първоначалните байтове. Към готовото съобщение се добавят още заглавни полета, текстът на съобщението и разделителите между отделните части.
Така едно съобщение може да е значително по-голямо от избрания прикачен файл. В немскоезичен форум някой попитал защо PDF файл от 20,1 MB се е превърнал в изпратен имейл от 27,5 MB. Ако въведеш 20 100 000 байта в този калкулатор с пренасяне на нов ред и без допълнителни байтове, ще получиш 26 800 000 байта Base64 данни и 705 264 байта за знаци за край на ред. Това прави общо 27 505 264 байта, или около 27,51 MB. Изчислението показва как се получава такъв порядък на размера. То е моделно изчисление, а не анализ на онзи конкретен имейл.
Как се формира приблизителната оценка
Всеки файл се въвежда на отделен ред, защото всеки прикачен файл се кодира поотделно. Можеш да задаваш размери например в B, KB, MB, GB, MiB или GiB. Калкулаторът използва десетичното определение за MB — 1 000 000 байта, и двоичното за MiB — 1 048 576 байта. След преобразуване трябва да се получи цяло число байтове. При въвеждане имай предвид следната особеност: запетаята и точката са десетични разделители, така че 1.000 означава едно. За хиляда въведи 1000 или 1 000. Не добавяй мерната единица в числовото поле.
- Оригинален размер: общият размер на прикачените ти файлове в байтове. Той е началната стойност и служи за сравнение с лимит за прикачени файлове.
- Base64 данни: прикачен файл с n байта се превръща в 4 × закръгляне нагоре(n ÷ 3) знака. Ако остатъкът накрая не е достатъчен за пълна тройка, допълващи знаци запълват последната четворка.
- Знаци за край на ред: при включено пренасяне на нов ред, което е настройката по подразбиране, калкулаторът разделя знаците на всеки прикачен файл на редове с най-много 76 знака. За всеки ред той отчита 2 байта за край на ред CRLF, включително за последния.
- Допълнителни байтове: зададена от теб стойност за текст, заглавни полета и други части на съобщението. Стойността по подразбиране е 0.
- Приблизителна оценка: Base64 данните и знаците за край на ред на всички прикачени файлове плюс допълнителните байтове.
Base64 винаги ли увеличава размера точно с една трета?
Само приблизително. При големи файлове съотношението от 3 байта към 4 знака се доближава до увеличение от 33⅓ %. Без пренасяне на нов ред 10 000 000 байта стават точно 13 333 336 байта, тоест с около 33,33 % повече. Минималното отклонение от точната една трета се дължи на допълващите знаци. Със знаците за край на ред размерът е 13 684 214 байта, с около 36,8 % повече. Следователно практическите ориентири от около 37 % описват кодирани данни с пренасяния на нов ред. Те зависят от дължината на реда и знаците за край на ред и не включват нито заглавни полета, нито текст.
При малки файлове фиксираният коефициент изобщо не е подходящ. Прикачен файл с 1 байт се превръща в 4 Base64 знака плюс 2 байта за край на ред, тоест общо в 6 байта. Затова калкулаторът изчислява всеки прикачен файл точно, вместо да умножава всичко по една обща стойност.
Няколко прикачени файла: всеки файл поотделно
Прикачените файлове не се обединяват в един голям блок, а се кодират поотделно. Затова всеки файл има свои допълващи знаци и свой последен край на ред. Това се вижда най-ясно в граничния случай с два файла от по 1 байт.
При един голям PDF файл тези няколко байта почти нямат значение. При много малки файлове обаче те се натрупват.
Дължината от 76 знака е максималната дължина, предвидена в стандарта MIME за Base64 редове. Отчитането на CRLF и след последния ред е правило на този калкулатор. Пощенски програми с по-къси редове или с различно оформен край дават малко по-различни стойности. Още едно разпространено недоразумение: Base64 не шифрова нищо. Това е само кодиране, което може да се обърне без ключ и не защитава съдържанието на прикачения ти файл.
Сравнение с правилния лимит за размер
Лимитът за размер ти дава число, но невинаги уточнява за какво се отнася то. Някои правила ограничават общия размер на оригиналните прикачени файлове, тоест размерите на файловете, които показва пощенската ти програма. Други ограничават цялото съобщение с кодираните прикачени файлове, текста и заглавните полета. Затова в калкулатора избираш с какво да се сравнява лимитът. Предварително попълнената стойност от 25 MB е само начална стойност, а не изискване на определен доставчик. При резултат точно на лимита ограничението се счита за спазено.
Затова един и същ файл може да отговаря на едното правило и да не отговаря на другото, без в това да има противоречие.
Две действителни правила с различен обхват
- Gmail: Според немскоезичната помощ на Gmail за прикачени файлове (прегледана на 13 октомври 2026) при лични профили прикачените файлове могат да са с общ размер 25 MB. Става дума за общия размер на прикачените файлове, така че тук е подходящо сравнението с оригиналните прикачени файлове. При профили в Google Workspace ограниченията се определят от администратора. Ако общият размер е по-голям, прикаченият файл се заменя с връзка към Google Drive.
- RRZE на Университета Ерланген–Нюрнберг: Указанията за ограничението на размера на прикачените файлове в имейли (прегледани на 13 октомври 2026) посочват максимум 20 MB за целия имейл при входящи и изходящи съобщения на сървърите на RRZE. Тук сравняваш с приблизителния размер на съобщението и е разумно да въведеш и допълнителни байтове.
И двете правила важат само в собствения си обхват и могат да се променят. За твоето изпращане е важно правилото на твоя профил, независимо дали е личен, или се управлява от работодател, училище или висше учебно заведение. Също толкова важно е правилото на пощенската кутия на получателя. Ако знаеш изискването на получателя, включи го в сравнението според това за какво точно се отнася. Ако доставчикът автоматично изпраща големи файлове като връзка, файлът вече не е прикачен към съобщението. Дали получателят може и има право да отвори тази връзка, тогава е отделен въпрос.
Какво още липсва за пълно съобщение
Сам по себе си кодираният прикачен файл все още не е имейл. Готовото съобщение включва заглавни полета с подател, получатели, тема и технически данни. Добавят се текстът на съобщението, често едновременно като обикновен текст и като HTML, разделителните редове между MIME частите и вградените изображения, например лого в подписа. Колко място заема всичко това, зависи от пощенската ти програма, текста и получателите.
Какви допълнителни байтове можеш да въведеш
Няма универсално правилна стойност. При 0 допълнителни байта калкулаторът показва само кодираните прикачени файлове със знаците за край на ред, тоест моделна стойност без текст и заглавни полета. Затова въведи собствено допускане, което съответства на твоя имейл. Кратък текст без изображения заема малко място, а HTML имейл с вградени графики — значително повече. Стойности от примери с други имейли важат само за точно тези имейли. Ако резултатът ти е малко под лимита, пробвай изчисление с по-голяма стойност. Ако ограничението остане спазено и тогава, имаш резерв. Ако вече е надвишено, си близо до границата.
Ако имейлът се върне въпреки успешното сравнение
- Съобщението е съдържало повече данни, отколкото си предвидил като допълнителни байтове, или пощенската ти програма кодира с друга дължина на редовете.
- Сървърът на получателя допуска по-малък размер от твоя профил.
- Лимитът се е отнасял за цялото съобщение, а ти си сравнявал с оригиналните прикачени файлове. Или за твоя профил важи различно правило от приетото.
- Получателят не допуска определени типове файлове, например документи с макроси или изпълними програми, и ги задържа независимо от размера им.
Калкулаторът сравнява само избраната от теб числова стойност. Той не изпраща нищо, не тества доставянето и не проверява нито файлови формати, нито правила за сигурност. При бюлетините има и ограничения за показването: някои пощенски кутии показват дълги HTML имейли само в съкратен вид. Това е отделна тема от размера на прикачените файлове и също не се изчислява тук.
Твърде голям размер: следващи стъпки с готовия PDF файл
Ако приблизителната оценка е над лимита, имаш две възможности: да намалиш броя байтове на самия файл или да избереш друг начин вместо прикачен файл. Ако получателят изрично очаква прикачен файл, действай така:
- Компресирай PDF преди изпращане или, ако знаеш точната граница, намали PDF файл до определен лимит за размер. С колко ще се намали един файл, зависи от съдържанието му. Целевият размер не може да се постигне във всеки случай.
- Отвори резултата и провери дали документът все още е добре четим.
- Въведи тук отново размера на изтегления файл. Определящ е готовият файл, а не очакваното намаление.
- Ако приблизителната оценка се вмества в лимита, изпрати имейла. Ако не се вмества, обсъди с получателя друг начин.
Връзка за споделяне чрез облачна услуга или услуга за файлове може да бъде алтернатива, ако получателят приема връзки и правата за достъп и защитата на личните данни са подходящи за твоя документ. Сам избираш услугата. Този калкулатор работи само с въведените числа и не съхранява или изпраща файлове. ZIP архивът обаче не е надежден заместител на по-малък PDF файл: той не намалява непременно размера на PDF, а получател, който изрично изисква PDF файлове, може да не приеме архив.
Ако файлът няма да се изпраща по имейл, а ще се качва в портал, можеш да провериш ограниченията за качване на PDF и предварително да изчислиш приблизителното време за качване на файла.