Base64 ഫയലുകൾ വലുതാക്കുന്നത് എന്തുകൊണ്ട്?

ഈ ലേഖനം Base64 ഔട്ട്പുട്ട് യഥാർഥ ബൈറ്റുകളെക്കാൾ വലുതായിരിക്കുന്നത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കുന്നു. ഇതൊരു സുരക്ഷാ ഗൈഡല്ല. എൻകോഡിംഗ് വേഴ്സസ് എൻക്രിപ്ഷൻ വേണമെങ്കിൽ Base64 എന്ക്രിപ്ശന അല്ല: ഇതു യഥാര്ഥത്തില എന്തു ചെയ്യുന്നു ഉപയോഗിക്കുക.

Base64ന് കൂടുതൽ ഇടം എന്തിന്?

3 ബൈറ്റ് 24 ബിറ്റാണ്. Base64 ആ 24 ബിറ്റിനെ 6 ബിറ്റിന്റെ 4 ഗ്രൂപ്പുകളായി വിഭജിക്കുന്നു. ഓരോ ഗ്രൂപ്പും ഒരു Base64 അക്ഷരത്തിലേക്ക് മാപ്പ് ചെയ്യുന്നതിനാൽ 3 ഇൻപുട്ട് ബൈറ്റ് 4 ഔട്ട്പുട്ട് അക്ഷരമാകുന്നു. ASCII അക്ഷരത്തിന് 1 ബൈറ്റായി സൂക്ഷിച്ചാൽ അത് 4 / 3 ≈ 1.333 — ഏകദേശം 33.3% വർധന.

• 3 ബൈറ്റ് (24 ബിറ്റ്)
• ↓
• 6 ബിറ്റിന്റെ 4 ഗ്രൂപ്പുകളായി വിഭജിക്കുക
• ഓരോ ഗ്രൂപ്പും → ഒരു Base64 അക്ഷരം
• ↓
• 4 അക്ഷരങ്ങൾ (പലപ്പോഴും 4 പാഠ ബൈറ്റ്)

ലളിതവും പരിശോധിക്കാവുന്നതുമായ ഉദാഹരണം

ഈ എൻകോഡിംഗുകൾ പാഡ് ചെയ്ത സ്റ്റാൻഡേഡ് Base64നോട് യോജിക്കുന്നു.

Man

Man

Base64

TWFu

Man എന്നത് 3 UTF-8/ASCII ബൈറ്റാണ്. TWFu 4 അക്ഷരം: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello 5 ബൈറ്റാണ്. SGVsbG8= 8 അക്ഷരം, ഒരു = ഉൾപ്പെടെ. ചെറിയ ഡാറ്റയിൽ പാഡിംഗ് ശതമാനത്തെ 33%നെക്കാൾ വലുതായി കാണിക്കുന്നു.

Base64 വലുപ്പം എങ്ങനെ കണക്കാക്കാം?

പാഡ് ചെയ്ത സ്റ്റാൻഡേഡ് Base64ന്, encodedLength = 4 × ceil(originalBytes / 3).

യഥാർഥ ബൈറ്റുകൾ	Base64 അക്ഷരങ്ങൾ
1	4
2	4
3	4
4	8
5	8
6	8

1 അല്ലെങ്കിൽ 2 ബൈറ്റും ഇപ്പോഴും 4 അക്ഷരം തരും. സൂത്രം ഉപയോഗിക്കുക, നിശ്ചിത 33% അല്ല.

«=» പാഡിംഗ് എന്താണ് അർഥമാക്കുന്നത്?

= അടയാളം അവസാന 3-ബൈറ്റ് ബ്ലോക്ക് നിറഞ്ഞില്ലെന്ന് കാണിക്കുന്നു. 1 ഇൻപുട്ട് ബൈറ്റ് രണ്ട് = അക്ഷരം ഉപയോഗിക്കുന്നു; 2 ബൈറ്റ് ഒന്ന്; 3 ബൈറ്റ് ഒന്നുമില്ല. പാഡിംഗ് എൻക്രിപ്ഷനല്ല, സുരക്ഷാ സവിശേഷതയുമല്ല.

Base64URL കുറഞ്ഞ ഇടം ഉപയോഗിക്കുന്നുണ്ടോ?

Base64URL +നെ - ആയും /നെ _ ആയും മാറ്റുന്നു, കൂടാതെ Base64 എൻകോഡ് എൻകോഡിൽ അവസാന = ഒഴിവാക്കുന്നു. ആ = അക്ഷരങ്ങൾക്ക് സ്ട്രിംഗ് ചെറുതാകാം. 3 ബൈറ്റ് → 4 അക്ഷര ഘടന അതേപടി നിലനിൽക്കുന്നു, അതിനാൽ Base64URL കൂടുതൽ ഇടം-കാര്യക്ഷമമായ ബൈനറി ഫോർമാറ്റല്ല.

ചെറിയ ഇൻപുട്ട് 33%നെക്കാൾ കൂടുതൽ വളരുന്നത് എന്തുകൊണ്ട്?

1 ബൈറ്റ് → 4 അക്ഷരം നീളത്തിൽ 300% വർധന. 2 ബൈറ്റ് → 4 എന്നത് 100%. 3 ബൈറ്റ് → 4 ഏകദേശം 33.3%. n വളരുമ്പോൾ പാഡിംഗ് പ്രാധാന്യം കുറയുകയും അധികഭാരം ഏകദേശം 33% അടുത്തെത്തുകയും ചെയ്യും. Base64 എപ്പോഴും കൃത്യമായി 33% വലുതല്ല.

Base64 Data URL ഇനിയും വലുതായിരിക്കുന്നത് എന്തുകൊണ്ട്?

Data URL പേലോഡിന് മുമ്പ് data:image/png;base64, പോലുള്ള ഉപസർഗം ചേർക്കുന്നു. വളരെ ചെറിയ ഫയലിൽ ആ ഉപസർഗം ശതമാനത്തെ ആധിപത്യം ചെയ്യാം. Base64 എൻകോഡ് അസംസ്കൃത Base64 അല്ലെങ്കിൽ Data URL നൽകാം; Data URL ഔട്ട്പുട്ട് സ്റ്റാൻഡേഡ് അക്ഷരമാല ഉപയോഗിക്കുന്നു.

Base64 വേഴ്സസ് ബൈനറി: ഏതാണ് ചെറുത്?

അസംസ്കൃത ബൈനറി ഗതാഗതത്തിനും സംഭരണത്തിനും ഇടത്തിൽ കൂടുതൽ കാര്യക്ഷമം. Base64 വലുതാണ്, പക്ഷേ JSON, ഇമെയിൽ, മറ്റ് പാഠ-മാത്ര പാതകളിൽ പാഠ-സുരക്ഷിതം. ഇത് ബൈനറിയിൽ നിന്ന് പാഠത്തിലേക്കുള്ള എൻകോഡിംഗാണ്, ചുരുക്കലല്ല.

Base64 ഫയലുകൾ ചുരുക്കുന്നുണ്ടോ?

ഇല്ല. Base64 ചുരുക്കൽ ഫോർമാറ്റല്ല. എൻകോഡ് ചെയ്ത പാഠം സാധാരണ യഥാർഥ ബൈറ്റുകളെക്കാൾ വലുതാണ്. പിന്നീട് ആ പാഠത്തിന് gzip അല്ലെങ്കിൽ Brotli പ്രയോഗിച്ചാൽ ചില ആവർത്തനം ചുരുങ്ങാം—ഫലം ഡാറ്റയെയും ചുരുക്കിയെയും ആശ്രയിക്കുന്നു. gzip Base64 അധികഭാരം പൂർണമായി നീക്കുന്നില്ല.

Base64ന് gzip പ്രയോഗിച്ചാൽ എന്ത് സംഭവിക്കും?

HTTP ചുരുക്കൽ Base64 പാഠത്തിലെ ചില ആവർത്തിത മാതൃകകൾ കുറയ്ക്കാം. JPEG, PNG അല്ലെങ്കിൽ ZIP അസംസ്കൃത ബൈറ്റായും പലപ്പോഴും മോശമായി ചുരുങ്ങും, Base64-ശേഷം-gzip ഇപ്പോഴും കേസിനെ ആശ്രയിച്ചിരിക്കുന്നു. gzip ശേഷം സാർവത്രിക അധിക ശതമാനമില്ല.

ഫയലുകൾ Base64 ആയി സൂക്ഷിക്കണോ?

Base64 ബൈനറിയെ JSON ഫീൽഡ്, ചെറിയ ഇൻലൈൻ അസറ്റ്, പാഠ-മാത്ര API, കോപ്പി/പേസ്റ്റ്, അല്ലെങ്കിൽ Data URL-ൽ ഇരുത്താം. വലിയ ഫയലുകളിൽ സംഭരണം, മെമ്മറി, പേലോഡ് വലുപ്പം എല്ലാം വളരും. അതിനർഥം «ഫയലുകൾക്ക് Base64 ഒരിക്കലും ഉപയോഗിക്കരുത്» എന്നല്ല.

JSON APIകളിൽ Base64 സാധാരണമായത് എന്തുകൊണ്ട്?

JSONന് സ്വാഭാവിക അസംസ്കൃത-ബൈനറി തരമില്ല, അതിനാൽ APIകൾ പലപ്പോഴും ബൈറ്റുകൾ Base64 സ്ട്രിംഗിൽ വയ്ക്കുന്നു. വലിയ ഫയലുകൾക്ക് multipart/form-data, ഒബ്ജക്റ്റ് സംഭരണം, അല്ലെങ്കിൽ നേരിട്ടുള്ള ബൈനറി അപ്‌ലോഡ് കൂടുതൽ യോജിക്കാം. ഒരു തിരഞ്ഞെടുപ്പും എപ്പോഴും മികച്ചതല്ല.

ഇമെയിലിൽ Base64 ഉപയോഗിക്കുന്നത് എന്തുകൊണ്ട്?

MIME ഒരു ബൈനറി അറ്റാച്ച്മെന്റ് പാഠ-സുരക്ഷിത അക്ഷരങ്ങളായി യാത്ര ചെയ്യാൻ Base64 ഉപയോഗിക്കാം. അതേ വലുപ്പ അധികഭാരം ഇപ്പോഴും ബാധകമാണ്. ഇത് ഗതാഗത പ്രതിനിധാനമാണ്, ചെറിയ ഫയലല്ല.

അധിക വലുപ്പം എപ്പോൾ മൂല്യമുള്ളത്?

ബൈനറി പാഠത്തിനുള്ളിൽ ഇരിക്കണം, പേലോഡ് ചെറുതാണ്, API Base64 ആവശ്യപ്പെടുന്നു, അല്ലെങ്കിൽ Data URL വേണം എങ്കിൽ അധിക വലുപ്പം മൂല്യമുള്ളതാകാം. വലിയ മീഡിയയ്ക്ക് സിസ്റ്റം അനുവദിക്കുമ്പോൾ അസംസ്കൃത ബൈനറി തിരഞ്ഞെടുക്കുക.

Base64 എപ്പോൾ ഒഴിവാക്കണം?

വലിയ ഫയലുകൾ, ഇറുകിയ ബാൻഡ്‌വിഡ്ത്ത്, ഇടയ്ക്കിടെയുള്ള കൈമാറ്റം, അല്ലെങ്കിൽ ബൈനറി പാത ഇപ്പോൾതന്നെ ഉണ്ടെങ്കിൽ ഒഴിവാക്കുക—സാഹചര്യാധിഷ്ഠിതം, «Base64 മോശം രീതി» അല്ല.

നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന പാഡ് Base64 നീളങ്ങൾ

യഥാർഥ ബൈറ്റ് എണ്ണങ്ങളും പാഡ് ചെയ്ത സ്റ്റാൻഡേഡ് Base64 അക്ഷര എണ്ണങ്ങളും:

യഥാർഥ ബൈറ്റുകൾ	Base64 അക്ഷരങ്ങൾ
1	4
2	4
3	4
10	16
100	136
1,000	1,336

എല്ലാ വരികളും 4 × ceil(n / 3) പാലിക്കുന്നു. ഇവ Base64 അക്ഷര എണ്ണങ്ങളാണ്.

ഉദാഹരണം: 1,000 ബൈറ്റ് ഫയൽ എത്ര വലുതാകും?

4 × ceil(1000 / 3). ceil(333.333…) = 334, ഒപ്പം 4 × 334 = 1336. അതിനാൽ 1,000 ബൈറ്റ് 1,336 Base64 അക്ഷരമാകുന്നു. UTF-8/ASCII ആയി സൂക്ഷിച്ചാൽ ഓരോ അക്ഷരവും സാധാരണ 1 ബൈറ്റ്—1,336നെ മെമ്മറിയിലെ കൃത്യമായ ബൈറ്റ് എണ്ണമായി കാണരുത്.

Base64 ഫയൽ വലുപ്പം സൂചിപ്പിക്കുന്നതിലധികം മെമ്മറി ഉപയോഗിക്കുമോ?

ചില റൺടൈമുകൾ സ്ട്രിംഗിനെ അക്ഷരത്തിന് 1 ബൈറ്റിലധികം സൂക്ഷിക്കുന്നു, എൻകോഡ്/ഡികോഡ് ബഫറും സ്ട്രിംഗും ഒരുമിച്ച് വയ്ക്കാം. മെമ്മറി ഉപയോഗം കൃത്യമായി അക്ഷര നീളമല്ല.

വലുപ്പത്തിനുള്ള ലളിത തീരുമാന മാർഗനിർദേശം

സിസ്റ്റം അസംസ്കൃത ബൈനറി സ്വീകരിക്കുന്നുവെങ്കിൽ വലുപ്പത്തിന് അത് തിരഞ്ഞെടുക്കുക. പാഠം മാത്രം അനുവദിച്ചാൽ Base64 യോജിച്ചേക്കാം. വലിയ പേലോഡിന് ബൈനറി അപ്‌ലോഡ് പാത നോക്കുക. URL-സുരക്ഷിത പാഠത്തിന് Base64URL പരിഗണിക്കുക—3ൽ നിന്ന് 4 വികാസം നിലനിൽക്കും.

• ബൈനറി ഡാറ്റ അയയ്ക്കണം
• ↓
• അസംസ്കൃത ബൈനറി അനുവദനീയമോ? വലുപ്പത്തിന് ബൈനറി തിരഞ്ഞെടുക്കുക
• പാഠ-മാത്ര ഫീൽഡ്? Base64 ഉചിതമായേക്കാം
• വലിയ പേലോഡ്? ബൈനറി അപ്‌ലോഡ് പാത നോക്കുക
• URL-സുരക്ഷിത പാഠം വേണോ? Base64URL പരിഗണിക്കുക
• ↓
• വലിയ ഇൻപുട്ടിൽ ഏകദേശം 33% കൂടുതൽ പാഠം പ്രതീക്ഷിക്കുക

ബ്രൗസറിൽ Base64 എൻകോഡ് അല്ലെങ്കിൽ ഡികോഡ് ചെയ്യുക

NEXNARA Base64 എൻകോഡ് പാഠം എൻകോഡ് ചെയ്യുകയും ഡികോഡ് ചെയ്യുകയും ചെയ്യുന്നു, ഫയലിനെ Base64 അല്ലെങ്കിൽ Data URL ആക്കാം, Base64നെ ഫയലിലേക്ക് തിരിച്ചാക്കാം.

പാഠം UTF-8 ബൈറ്റ് പിന്നെ Base64—ASCII മാത്രമല്ല. Standard അല്ലെങ്കിൽ Base64URL തിരഞ്ഞെടുക്കുക. ഫയൽ ഔട്ട്പുട്ട് അസംസ്കൃത Base64 അല്ലെങ്കിൽ Data URL ആകാം (സ്റ്റാൻഡേഡ് അക്ഷരമാല). അസാധുവായ ഇൻപുട്ട് നിരസിക്കപ്പെടും. UTF-8 അല്ലാത്ത ബൈറ്റിന് ഫയൽ വേണം, പാഠ ഡികോഡ് അല്ല.

10 MB മുകളിലുള്ള ഫയലുകൾ ടാബ് മന്ദഗതിയാക്കാം (മുന്നറിയിപ്പ്). 32 MB മുകളിലുള്ള ഫയലുകൾ തടയപ്പെടും.

എൻകോഡിംഗും ഡികോഡിംഗും നിങ്ങളുടെ ബ്രൗസറിൽ നടക്കുന്നു. ഈ ഉപകരണത്തിന് ഫയൽ NEXNARA സെർവറിലേക്ക് അയയ്ക്കുന്നില്ല. പരസ്യങ്ങളും മറ്റ് സൈറ്റ് സവിശേഷതകളും ഇപ്പോഴും ശൃംഖല ഉപയോഗിക്കുന്നു.

Base64 എൻകോഡ്ൽ പാഠമോ ഫയലോ ഒട്ടിച്ച് യഥാർഥ ബൈറ്റുകളെ എൻകോഡ് നീളവുമായി താരതമ്യം ചെയ്യുക.

FAQ

Base64 ഫയൽ വലുപ്പം വർധിപ്പിക്കുന്നത് എന്തുകൊണ്ട്?

ഇത് 3 ബൈറ്റിനെ (24 ബിറ്റ്) 4 അക്ഷരത്തിലേക്ക് (4 × 6 ബിറ്റ്) മാപ്പ് ചെയ്യുന്നു. പാഠമായി സൂക്ഷിച്ചാൽ വലിയ ഇൻപുട്ടിൽ ഏകദേശം മൂന്നിലൊന്ന് കൂടുതൽ.

Base64 എപ്പോഴും 33% വലുതാണോ?

ഇല്ല. വലിയ ഇൻപുട്ടുകൾ ഏകദേശം 33.3% അടുത്തെത്തും. വളരെ ചെറിയ ഇൻപുട്ടുകൾ പാഡിംഗ് മൂലം കൂടുതൽ വളരാം. 4 × ceil(n / 3) ഉപയോഗിക്കുക.

Base64 ബൈനറിയെക്കാൾ എത്ര വലുത്?

സ്റ്റാൻഡേഡ് പാഡ് നീളം 4 × ceil(n / 3) അക്ഷരമാണ്. Data URL ഉപസർഗം കൂടുതൽ ചേർക്കുന്നു.

Base64 ചുരുക്കൽ ഫയൽ വലുപ്പം കുറയ്ക്കുമോ?

Base64 ചുരുക്കുന്നില്ല. എൻകോഡ് ചെയ്ത പാഠത്തിൽ gzip അല്ലെങ്കിൽ Brotli ചിലത് ചുരുക്കാം; എല്ലാ കേസിലും അധികഭാരം മായ്ക്കുന്നില്ല.

Base64URL കുറഞ്ഞ ഇടം ഉപയോഗിക്കുന്നുണ്ടോ?

ഇത് = പാഡിംഗ് ഒഴിവാക്കാം, അതിനാൽ സ്ട്രിംഗ് 0–2 അക്ഷരം ചെറുതാകാം. 3ൽ നിന്ന് 4 എൻകോഡിംഗ് ഘടന അതുതന്നെ.

വലിയ ഫയലുകൾക്ക് Base64 ഉപയോഗിക്കണോ?

പാഠം വേണമെങ്കിൽ മാത്രം. വലിയതോ ഇടയ്ക്കിടെയുള്ളതോ ആയ കൈമാറ്റത്തിന് ബൈനറി പാത പലപ്പോഴും ചെറുതാണ്. APIകൾക്ക് Base64 എപ്പോഴും തെറ്റല്ല.