რატომ ხდის Base64 ფაილებს უფრო დიდს?

ეს სტატია ხსნის, რატომ არის 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 ფაილებისთვის».

რატომ არის Base64 გავრცელებული JSON API-ებში?

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 უნდა გამოვიყენო?

მხოლოდ თუ ტექსტი გჭირდება. დიდ ან ხშირ გადაცემებზე ორობითი გზა ხშირად უფრო პატარაა. Base64 API-ებში ყოველთვის არასწორი არ არის.