איך עיבוד קבצים מקומי בדפדפן עובד
אם שום דבר לא מועלה, מה בעצם עושה את העבודה — ואיפה?
מה “מקומי” אומר כאן
ממיר מקוון רגיל הוא אתר עם נקודת קצה להעלאה. הקובץ שלכם משודר למכונה שאינה בשליטתכם, מעובד שם, נשמר לפרק זמן כלשהו, ומוצע בחזרה כהורדה. עיבוד מקומי מוחק את האמצע של המשפט הזה: הקוד שקורא את הקובץ שלכם רץ בתוך לשונית הדפדפן שכבר פתוחה אצלכם, על המעבד שלכם, והתוצאה נכתבת בחזרה לדיסק שלכם.
האתר עדיין נטען דרך הרשת — HTML, גיליונות סגנון, סקריפטים ומודולי WebAssembly מגיעים כולם משרת, כמו בכל דף אינטרנט. ההבדל הוא בכיוון. קוד התוכנה יורד; הקובץ שלכם לא עולה.
הדפדפן כבר מכיל את החלקים
| יכולת | מה היא נותנת |
|---|---|
| File and Blob APIs | קריאת הבייטים של קובץ שהמשתמש בחר או גרר, בלי שליחת טופס |
| Web Workers | הרצת עבודה כבדה בתהליכון רקע כדי שהממשק ימשיך להגיב |
| WebAssembly | הרצת ספריות קודק מהודרות מ-C, מ-C++ או מ-Rust במהירות קרובה לזו של קוד מקורי |
| Canvas ו-OffscreenCanvas | פענוח, ציור, שינוי גודל וקידוד מחדש של תמונות |
| WebCodecs | גישה למקודדי ולמפענחי הווידאו של הדפדפן עצמו, עם האצת חומרה |
| WebGPU | הרצת הסקה של מודלים ועבודת פיקסלים מקבילית על המעבד הגרפי |
| File System Access | כתיבת התוצאה ישירות למיקום שהמשתמש בוחר, היכן שיש תמיכה |
אין בזה שום דבר אקזוטי. זו אותה פלטפורמה שמריצה גיליונות אלקטרוניים, כלי עיצוב ומשחקים בתוך לשונית. ההחלטה החריגה היחידה היא לסרב להוסיף לה שרת.
המסלול שקובץ עובר
- אתם בוחרים קובץ. הדפדפן מוסר לדף מזהה אליו — לא עותק, הפניה.
- הדף קורא את הבייטים הראשונים כדי לזהות את סוג הקובץ האמיתי מהחתימה שלו, במקום לסמוך על הסיומת.
- הוא מעריך כמה זיכרון המשימה דורשת, ומסרב לעבודה או מכניס אותה לתור אם זה חורג ממה שהמכשיר יכול לספק בבטחה.
- הבייטים מועברים לתוך Web Worker. העברה של ArrayBuffer מעבירה בעלות ולא מעתיקה, ולכן קובץ גדול לא קיים פעמיים בזיכרון.
- בתוך ה-Worker, קודק WebAssembly או ממשק של הפלטפורמה עושה את הפענוח והקידוד עצמם.
- התוצאה חוזרת כבייטים, נעטפת ב-Blob, ומוצעת לכם כהורדה או נכתבת למיקום שאתם בוחרים.
- כתובת ה-URL הזמנית של אותו Blob מבוטלת והבאפרים משוחררים.
למה WebAssembly הוא החלק ששינה את התמונה
קודקים לתמונה ולווידאו הם עשרות שנים של C מוקפד ומאופטם. שכתוב שלהם ב-JavaScript מעולם לא היה מציאותי. WebAssembly הוא פורמט הוראות בינארי נייד שדפדפנים מריצים בארגז חול במהירות קרובה לזו של קוד מקורי, ולכן אפשר להדר את הספריות הקיימות האלה ולשלוח אותן לדפדפן כמו שהן.
ארגז החול חשוב לא פחות מהמהירות. למודול WebAssembly אין גישה מובנית למערכת הקבצים שלכם, לרשת שלכם או ללשוניות האחרות שלכם. הוא רואה את הזיכרון שהדף מוסר לו ותו לא. קודק זדוני, או פשוט באגי, לא יכול לשוטט ולקרוא משהו שלא ניתן לו.
מה עדיין נוגע ברשת, ולמה זה לא הקובץ שלכם
שלושה דברים מגיעים דרך הרשת: הדף עצמו, המנוע של הכלי שפתחתם, ולהסרת רקע גם משקלי המודל. שלושתם הם נכסים סטטיים של FileSlimmer עצמו, שנטענים מהמקור של FileSlimmer לפני שנקרא ולו בייט אחד שלכם. הם הורדות, הם ניתנים לשמירה במטמון, ואחרי השימוש הראשון אפשר להגיש אותם מהמטמון של הדפדפן בלי רשת בכלל.
כל מה שאחרי הנקודה הזו הוא מקומי. המנועים מקבלים בייטים של קבצים רק דרך postMessage מהדף; לעולם לא נמסרת להם כתובת URL לשלוח אליה משהו, ומדיניות אבטחת תוכן מגבילה לאן הדף בכלל יכול להתחבר גם אם קוד כלשהו היה מנסה.
התמורות, בלשון פשוטה
| שיקול | בדפדפן שלכם | בשרת |
|---|---|---|
| לאן הקובץ שלכם הולך | לשום מקום | למכונה שאינה בשליטתכם |
| מהירות | כל מה שהמכשיר שלכם מסוגל לו | כל מה שהמפעיל שילם עליו |
| קבצים גדולים מאוד | חסומים בזיכרון הדפדפן | חסומים במגבלות של המפעיל |
| עובד לא מקוון | כן, אחרי שהמנוע נשמר במטמון | לא |
| פורמטים אקזוטיים | רק מה שמתהדר ל-WebAssembly | כל מה שהמפעיל מתקין |
| אצווה של אלף קבצים | מוגבלת במכשיר | בדרך כלל מתאים יותר |
עיבוד מקומי אינו טוב יותר תמיד. הוא טוב יותר כשהקובץ פרטי, כשהמכשיר מסוגל, וכשהעבודה נכנסת לזיכרון. שרת עדיף כשצריך לעבד הרבה יותר ממה שמכונה אחת יכולה להחזיק. להיות ברורים לגבי המצב שבו אתם נמצאים מועיל יותר מלהתעקש שגישה אחת מנצחת בכל מקום.
מה זה לא טוען
זו אמירה על מה שהאפליקציה הזו עושה. זו לא טענה לגבי הרחבות הדפדפן שלכם, שיכולות לקרוא את התוכן של כל דף שאתם פותחים, ולא לגבי מערכת ההפעלה שלכם, שיכולה לבחון כל קובץ שאתם נוגעים בו, ולא לגבי ספק הרשת שלכם, שיכול לראות שביקרתם באתר. אלה מחוץ להישג ידו של כל אתר, וכלי שאומר לכם אחרת מגזים בטענותיו.
הטענה צרה וניתנת לבדיקה: הקבצים שבחרתם מעובדים מקומית בדפדפן הזה ואינם מועלים על ידי FileSlimmer. המדריך הבא מסביר איך לוודא את זה בעצמכם במקום להאמין.
כלים למשימה הזו
מקורות
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs