จุดเริ่มต้นของการใช้ Base64 URI ในเบาวเซอร์ เอ้อร์ เอ้อร์ และ Blob Protocol (Blob URLs)

เริ่มตั้งแต่ที่มาของ standard นี้ก่อนกันดีกว่า ที่มาของ data tag Base64 เกิดจาก L. Masinter ซึ่งได้ เปิด RFC 2397 (Request for Comments (RFC) คือเอกสารที่เป็นข้อมูลของมาตรฐานต่างๆในอินเตอร์เน็ต ผลิตภัณฑ์ต่างๆ ไม่ว่าจะเป็นเชิงพาณิชย์หรือฟรีแวร์ใดๆก็ตาม ที่ต้องการสื่อสารกับชาวโลกก็จะต้องปฏิบัติตามมาตรฐานนี้) เมื่อเดือน สิงหาคม 1998 หรือ เมื่อประมาณ 20 ปีที่แล้ว

โดยจุดประสงค์ของ Standard นี้คือ เพื่อให้ Browser สามารถมี embed data ได้โดยไม่จำเป็นต้องโหลด Resource แยกต่างหาก เพื่อให้เกิดความเร็ว ในการใช้งานซึ่งจะมี Format ดังนี้ data:[<mediatype>][;base64],<data>

มาถึงตรงนี้แล้ว ก็เริ่มสงสัยว่า เจ้าแรกๆ ที่ Support Protocol นี้ คือใครกันหนอ ให้ลองเดาเลย จาก 4 ค่ายใหญ่ Internet Explorer, Safari, Chrome และ Firefox

ใครที่เดาว่า IE เป็นเจ้าแรกนั้น อาจจะต้องคิดใหม่ เพราะว่า Browser เจ้าแรกที่ทำให้ Support Standard นี้ คือ Firefox 2 ใน ตุลาคม 2006
ถัดมาปีประมาณ ปีครึ่ง Safari 3.1 ก็เริ่ม Support ใน มีนาคม 2008 
ถัดมาอีก 1 ปี IE 8 ใน มีนาคม 2009 แต่มีข้อจำกัดเรื่องความยาวของ data รองรับได้แต่ 32 KB หรือเท่ากับ 32768 Bytes และในปีถัดมา Chrome 4 ก็ support ในเดือน มกราคม 2010 เท่านี้ก็เป็น นิมิตรหมายที่ดีที่ ทุก Web หลังจากนี้ หากจะใช้ Standard นี้ จะมี Browser รองรับไว้ส่วนใหญ่แล้ว วงเล็บ โหใช้เวลา 1 รอบนักษัตร กว่าจะเป็นมาตรฐาน เวลา 12 ปีนั้น ช่างเป็นอะไรที่ค่อนข้างนานเลยทีเดียว แต่ว่าใช้ว่า Browser support แล้ว Developer จะเริ่มทำฟีเจอร์ด้านนี้ทันที ก็ต้องรอ Market Product อีกประมาณนึงจนมาถึง ยุคปัจจุบัน

ปัจจุบัน

มี Browser มากมายที่ Support มาตรฐานตัวนี้ และความนิยมการใช้งานฟีเจอร์นี้บน Browser สามารถระบุออกมาเป็น รูปเบื้องล่าง ซึ่งจะเป็น Stat การใช้งานในปัจจุบัน

Stat การใช้งานในปัจจุบัน https://caniuse.com/#feat=datauri

โดย browser ที่มีคนใช้งานฟีเจอร์นี้มากที่สุด หากเข้าไปในลิงค์ จะพบว่าแชมป์ของ Catergory นี้เป็น Chrome Browser นะครับ 😁

หลักการทำงาน

ถัดมา หลักการทำงานก็ไม่ได้ยุ่งยาก เพราะทุกๆเบราเซอร์ สามารถใช้งานเหมือนกันหมด หากมองเป็นภาพ Abstract (ภาพหยาบๆ แบบไม่ละเอียด) ละก็

ขอเล่าแบบนี้ คือ มันก็จะคล้ายๆ กับการทำงานของ href แหละ ซึ่งเวลาปกติที่ href ทำงาน browser ก็จะเปิด request connection ไปยัง url ที่ set ไว้ เพื่อไปเอาข้อมูลตาม url นั้นออกมา แล้วก็รอจนกว่า Content ที่ได้มา ได้มาครบแล้วยัง ถ้าได้ครบแล้วก็จะแสดงผล ส่วนการทำงานแบบ Data URI จะต่างตรงที่ ข้อมูลมาพร้อมกับ tag html เลย ซึ่งมี format ของข้อมูลมาด้วย เมื่อเข้าหน้าแล้ว browser ก็จะสามารถนำ data ที่อยู่ใน tag นำมาแสดงผลได้ทันทีไม่ต้องไป reqong request ให้เสียเวลา ซึ่งจะช่วยลด Latency time (เวลาหน่วง) ในการ Get File ได้

โดยส่วนตัวแล้วชอบวิธีการนี้มากๆ เพราะประหยัดพลังงานและประหยัดเวลา แต่ทั้งนี้ ทั้งนั้นด้วยความคิดสร้างสรรค์ของชุมชนนักพัฒนา ก็ทำให้มีอีกอย่างนึงที่ใส่เพิ่มเข้าไป เพื่อเป็น Protocol ไว้บอกว่านี้คือ resource นะ 
นั่นคือ Blob Protocol ใครรู้จัก Protocol นี้ โปรด อธิบาย ด้วย คำ 3 คำ ..... ..... .....

สำหรับคนที่ยังงงว่าเจ้า Blob คืออะไร ให้สูดลมหายใจเข้าออกสัก 10 วินาที แล้วมาลุยกันต่อ


Blob Protocol ( Blob URLs )

หลังจากที่ได้เกริ่นๆไปว่า อยากเขียนบล๊อคเกี่ยวกับเรื่องนี้ ซึ่งทำให้ต้องท้าวความเกี่ยวกับความเข้าใจของ Base64 Character ก่อน ทั้ง Encoding Decoding และการใช้งาน ซึ่งสามารถหาอ่านได้ที่ตรงนี้ แตะตรงนี้หรือจิ้มเบาๆ ครับ

Protocol เป็นเพียง How to ในการสื่อสาร

Blob Protocol หรือ ชื่อ Official คือ Blob URLs

หากเราเริ่มต้นจาก ความหมายของ Blob นั้นละก็ Blob มันย่อมาจาก Binary Large OBject ซึ่งมันก็คือ การระบุว่าข้อมูลที่อยู่ในนี้มันจะเป็นไฟล์ Binary จ๊ะ จริงๆที่ชื่อก็บอกด้วยตัวมันเองแล้วว่ามันจะต้องมีขนาดใหญ่ แต่ไม่ได้ระบุว่า เป็น data ของอะไร ซึ่งมันสามารถเป็นไฟล์ Type ไหนก็ได้ ขอแค่เป็น Library โดยได้มีการนำไปประยุกต์ ใช้กับอะไรหลายๆอย่าง เช่น Database เราสามารถเก็บข้อมูลเป็น type นี้ได้ จนมีคนเห็นความเชื่องช้าของ browser ในการโหลดข้อมูล รวมถึงเล็งเห็นข้อเสียของ เจ้า Data URI ที่มี overhead บน browser จนเกิด RFC ใหม่ขึ้น นั่นก็คือ Blob URLs โดยมาตรฐานนี้ถูกใช้งานบน Browser มาตั้งแต่ปี ....

?

?

?

?

?

?

??? โน้นครับ นายไปเล่นตรงนู้นเลย เอาเป็นว่าใครอยากรู้ก็ google ดูเองน้า หรือ เปิดดูในเว็บที่แปะอยู่กับรูปเบื้องบนดูนะครับ

ที่นี้มาดูเรื่องการทำงานของเจ้า Blob บนเว็บกันบ้าง เจ้า blob เนี่ยสามารถใส่ได้บน attribute type src ของ tag บน html ได้เท่านั้น เช่น <img src="blob:https://www.blobimage.com/logo.png" /> ซึ่งเวลา browser เอาไปทำงานก็จะ มอง source นี้เป็นเหมือน Byte Stream ซึ่งตอนทำงานก็จะต่อท่อไปยัง source ลด ภาระการ request file แบบ HTTP Protocol คล้ายๆกับต่อ socket คุยกันเอง ปล.เนื้อหาตรงส่วนนี้ผมอธิบายโดยใช้ความเข้าใจของตนเองอธิบาย โปรดอย่าเชื่อ 100% หากจะนำไปคุยต่อ โปรดศึกษาข้อมูลเพิ่มเติมนะครับ

แล้ววิธีนี้มันดีกว่า Data URI ยังไง

ขออ้างอิงคำตอบใน stack overflow มานะครับ ตัว Data URI หรือ Base64 นั้นมีปัญหาตรงที่ แต่ละตัวอักษรกินพื้นที่ 2 Bytes ใน Javascript ยิ่งไปกว่านั้นข้อมูลต้นทางจะถูกเพิ่มปริมาณ 33% ตอน Encoding แต่เจ้า Blob นั้นมันเป็น Binary Byte Array ตรงๆ ไม่มี overhead แต่อย่างใด ซึ่งทำให้ การจัดการ Blob นั้นเร็วกว่า และประหยัดกว่า

It is also a better alternative to Data-URI which are strings encoded as Base-64. The problem with Data-URI is that each char takes two bytes in JavaScript. On top of that a 33% is added due to the Base-64 encoding. Blobs are pure binary byte-arrays which does not have any significant overhead as Data-URI does, which makes them faster and smaller to handle.

ที่นี้ปัญหามันไปอยู่ตรงที่ เราจะ Implement Webview ของ Android ที่มีการทำงานเกี่ยวกับ DownloadListenerยังไงให้สามารถ Support Protocol นี้ได้ละ 555 ทิ้ง Bomb ไว้เผื่อมีใครอยากเขียนต่อ สามารถ Direct มาฝากลิงค์ได้นะครับ

FIRST AID : https://stackoverflow.com/questions/35400616/how-to-read-the-data-in-a-blob-in-webview-on-android

ถ้าใครชอบ ก็อย่าลืมกดปรบมือ กับกด Follow ด้วยนะครับ ขอบคุณครับ

จบแล้วฮ่ะ มีใครอยากเสริมตรงไหนไหมครับ เสริมได้นะครับ สำหรับวันนี้ต้องขอตัวลาไปก่อน เจอกันใหม่ บล๊อคหน้า กับ สิ่งเล็กๆที่เรียกว่าบัค 😁😁😁