Tech Help
Base64 ಫೈಲ್ಗಳನ್ನು ಏಕೆ ದೊಡ್ಡದಾಗಿಸುತ್ತದೆ?
Base64 ಸಾಮಾನ್ಯವಾಗಿ ಬೈನರಿ ಡೇಟಾವನ್ನು ಸುಮಾರು ಮೂರನೇ ಒಂದು ಭಾಗ ದೊಡ್ಡದಾಗಿಸುತ್ತದೆ. 3 ಬೈಟ್ನಿಂದ 4 ಅಕ್ಷರದ ರಚನೆ, ಪ್ಯಾಡಿಂಗ್, Data URL ಹೆಚ್ಚುವರಿ ಭಾರ, ಆ ಗಾತ್ರ ಯಾವಾಗ ಯೋಗ್ಯ ಎಂದು ನೋಡಿ.
Base64 ಸಾಮಾನ್ಯವಾಗಿ ಬೈನರಿ ಡೇಟಾವನ್ನು ಸುಮಾರು ಮೂರನೇ ಒಂದು ಭಾಗ ದೊಡ್ಡದಾಗಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಪ್ರತಿ 3 ಬೈನರಿ ಬೈಟ್ಗಳನ್ನು 4 ಮುದ್ರಿಸಬಹುದಾದ Base64 ಅಕ್ಷರಗಳಿಂದ ತೋರಿಸುತ್ತದೆ.
ಇನ್ಪುಟ್ ಉದ್ದ 3ರ ನಿಖರ ಗುಣಕವಾಗಿಲ್ಲದಿದ್ದರೆ, ಪ್ಯಾಡ್ ಮಾಡಿದ ಪ್ರಮಾಣಿತ Base64 = ಅಕ್ಷರಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಎನ್ಕೋಡ್ ಉದ್ದ 4 × ceil(n / 3), ಇಲ್ಲಿ n ಮೂಲ ಬೈಟ್ ಉದ್ದ.
«ಸುಮಾರು 33%» ದೊಡ್ಡ ಇನ್ಪುಟ್ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಬಹಳ ಚಿಕ್ಕ ಇನ್ಪುಟ್ಗಳಲ್ಲಿ ಪ್ಯಾಡಿಂಗ್ನಿಂದ ಶೇಕಡಾ ಬಹಳ ದೊಡ್ಡದಾಗಿ ಕಾಣಬಹುದು. Base64 ಸಂಕೋಚನವಲ್ಲ. ಎನ್ಕೋಡಿಂಗ್ ವಿರುದ್ಧ ಎನ್ಕ್ರಿಪ್ಷನ್ಗೆ [Base64 ಎನ್ಕ್ರಿಪ್ಶನ ಅಲ್ಲ: ಇದು ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ](/kn/story/base64-is-not-encryption) ನೋಡಿ.
ಈ ಲೇಖನ 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 ಡೇಟಾವನ್ನು ಚಿಕ್ಕದಾಗಿಸಲು ವಿನ್ಯಾಸಗೊಂಡಿಲ್ಲ. ಬೈನರಿಯನ್ನು ಪಠ್ಯ-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ತೋರಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಬೆಲೆ ಹೆಚ್ಚುವರಿ ಗಾತ್ರ.
ಬ್ರೌಸರ್ನಲ್ಲಿ 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 ಯಾವಾಗಲೂ ತಪ್ಪಲ್ಲ.