เช็คอะไรนิดหน่อย ไปเจออันนี้ วิธีการคิดเงินของ Google Cloud Translation API ก็แฟร์ระดับหนึ่งนะ คือคิดตามจำนวนตัวอักษร (code point) แทนที่จะคิดตามปริมาณข้อมูลจริงๆ (byte)
Charged characters
To calculate usage, Google counts usage on a per character basis, even if a character is multiple bytes. Each character corresponds to a code point.
You are charged for all characters that you include in a Cloud Translation request, even untranslated characters. This includes, for example, whitespace characters. If you translate <p>こんにちは</p> to English, it counts as 12 characters for the purposes of billing.
Google also charges for empty queries. If you make a request without any content, Google charges one character for the request.
—-
คือในทางคอมพิวเตอร์ มาตรฐานตัวอักษรที่แพร่หลายในปัจจุบัน คือมาตราฐาน Unicode และวิธีการจัดเก็บตัวอักษรที่นิยมและเข้ากันได้กับแอปบนอินเทอร์เน็ตต่างๆ ก็คือ UTF-8 ซึ่งในตัวอักษรในแต่ละระบบการเขียนอาจใช้จำนวนไบต์ไม่เท่ากัน ตัวละตินที่ไม่มีเครื่องหมายประสม (อย่างที่ใช้ในภาษาอังกฤษ มาเลย์ อินโด) จะใช้เพียง 1 ไบต์ต่อ 1 ตัวอักษร (code point) ส่วนตัวอักษรไทยจะใช้ 3 ไบต์ต่อ 1 ตัวอักษร
—
จากการตัดสินใจในขั้นการออกแบบ มันเป็นไปได้ที่จะมีการเลือกปฏิบัติ มีความ “ไม่เท่าเทียม” หรือความ “ไม่ปลอดภัย” หรือความใดๆ ที่ถ้าเป็นไปได้ก็ไม่อยากให้มี ฝังอยู่ในระบบสถาปัตยกรรมของระบบ บางอย่างไม่ได้อยากให้มี แต่ด้วยข้อจำกัดของทรัพยากรที่มีจำกัดกว่าหรือสมมติฐานของบริบทการใช้งานในตอนที่ออกแบบ ก็เลยตัดสินใจว่าใช้แบบนี้ไปละกัน มันโอเคสำหรับตอนนั้น – แต่พอเวลาผ่านไป ย้อนกลับไปพิจารณา ก็อาจตัดสินใจอีกแบบได้ (จะมีโอกาสแก้ไขไหมก็อีกเรื่อง)
ตัวอย่างหนึ่งก็เช่นระบบอีเมลและ www ที่ไม่ได้มีการเข้ารหัสลับมาในระดับมาในโปรโตคอลแต่แรก ซึ่งก็อาจเป็นการตัดสินใจทางวิศวกรรมที่สมเหตุสมผลสำหรับบริบทการใช้งานขณะนั้น ที่เป็นการใช้งานระหว่างหน่วยงานที่เชื่อใจกันอยู่แล้ว และการจะเข้าสู่ระบบได้ต้องให้ผู้ดูแลระบบสร้างบัญชีให้ รู้ตัวตนกันแน่นอน ดังนั้นอาจจะไม่ต้องห่วงเรื่องดักฟังหรือการยืนยันตัวตนมาก ที่ต้องห่วงมากกว่าคือจะส่งข้อมูลยังไงให้เล็กให้เร็ว เพราะแบนด์วิธสมัยนั้นมันต่ำ ทางยังแคบ
แต่ต่อมาเมื่อสมมติฐานความปลอดภัยนั้นไม่เป็นจริงแล้ว หรือข้อจำกัดทางเทคโนโลยี/เศรษฐกิจนั้นได้คลายลงแล้ว ก็มีการคิดวิธีเข้ารหัสลับให้กับข้อมูลขึ้นมา โดยยังทำงานอยู่บนโปรโตคอลเดิม มีความเข้ากันได้กับระบบเก่าๆ (backward compatible)
—
การออกแบบคอมพิวเตอร์ดิจิทัลยุคแรก นอกจากจะมีแต่ตัวละตินแล้ว ยังไม่มีกระทั่งตัวอักษรพิมพ์เล็ก เพราะพื้นที่หน่วยความจำและจัดเก็บมีขนาดจำกัด และยังต้องกันที่สำหรับอักขระพิเศษเพื่อควมคุมเครื่องพิมพ์เข้าไปด้วย (จอภาพอาจไม่ใช่ส่วนแสดงผลหลักของระบบคอมพิวเตอร์หลายๆ ระบบในตอนนั้น และการแสดงผลกราฟิกที่แม่นยำที่สุด ก็คือพล็อตเตอร์ ที่เป็นแขนกลวาดรูปด้วยปากกา)
แม้จะมีข้อจำกัด แต่มันก็พอใช้ได้ โดยเฉพาะเมื่อคำนึงถึงบริบทว่าในสมัยนั้น “ผู้ใช้” ระบบคอมพิวเตอร์ก็มีแนวโน้มจะเป็น “ช่างเทคนิค” ในที่ได้รับการอบรมมาในระดับหนึ่งสำหรับการใช้เครื่องระบบดังกล่าว (พูดอีกแบบคือ คนต้องปรับตัวให้เข้ากับเครื่อง เครื่องยังไม่ต้องปรับตัวให้เข้ากับคน)
เมื่อระบบเหล่านี้ขยายใหญ่ขึ้น มีการนำไปใช้กับหลากหลายภาษาวัฒนธรรรมมากขึ้น มีผู้ใช้จำนวนมากขึ้น จากหลากหลายภูมิหลังขึ้น ใช้กับหลากหลายบริบทความปลอดภัยมากขึ้น สมมติฐานหลายๆ อย่างที่เคยใช้ได้ ก็เปลี่ยนไป
แต่จะเปลี่ยนการทำงานของคอมพิวเตอร์ที่ระดับพื้นฐานไปทั้งหมดเลยมันก็ลำบาก เพราะก็ยังมีระบบเก่าๆ ที่ยังต้องใช้งานหรือมาเชื่อมประสานกันอยู่ เลยไม่ได้รื้อระบบทำใหม่หมด แต่ขยายเพิ่มเติมแทน
เช่น เดิมใช้ 7 บิตเพื่อแทนชุดตัวอักษร 128 ตัว ก็ขยายมาเป็น 8 บิต 16 บิต ฯลฯ โดยพยายามทำให้มันรองรับระบบเดิมอยู่ โดย 128 ตัวแรก ยังใช้ตัวอักษรชุดเดิมอยู่อะไรงี้ ซึ่งวิธีที่เก็บตัวอักษรที่ใช้บนอินเทอร์เน็ตส่วนใหญ่ตอนนี้ใช้วิธีนี้อยู่ ชื่อมาตรฐานคือ UTF-8
UTF-8 นี่เป็นวิธีการแปลงรหัสเพื่อบันทึกตัวอักษรแบบที่เรียกว่า “variable-width encoding” คือ ตัวอักษรแต่ละตัวอาจใช้จำนวนข้อมูล (คิดเป็นไบต์) ในการเก็บไม่เท่ากัน — พวกตัวอักษรละตินและสัญลักษณ์พื้นฐาน 128 ตัวแรก จะใช้ 1 ไบต์ ตัวละตินอื่นๆ เกือบทั้งหมดที่เหลือ (ซึ่งภาษาจำนวนมากในยุโรปใช้ รวมถึงภาษาอย่างเวียดนาม ก็ใช้ตัวเขียนเหล่านี้) รวมถึงตัวอักษรกรีก ฮีบรู อารบิก คอปติก พวกนี้ใช้ 2 ไบต์ ตัวอักษรที่เหลือเกือบทั้งหมดจะใช้ 3 ไบต์ ในกลุ่มนี้มีตัวอักษรจีน ญี่ปุ่น เกาหลี ไทย รวมอยู่ด้วย ส่วนพวก 4 ไบต์นี่จะเป็นตัวอักษรที่ไม่พบบ่อยนัก หรือเป็นส่วนขยาย/กรณีพิเศษของตัวอักษรบางตัว
วิธีคิดของคณะออกแบบ UTF-8 ก็คือ ตัวอักษรไหนมีแนวโน้มจะใช้บ่อย ใช้มาก ก็พยายามให้ใช้จำนวนไบต์น้อยๆ เพื่อที่ว่าในภาพรวมจะได้ประหยัดพื้นที่จัดเก็บ เว้นเสียว่าจะทำไม่ได้จริงๆ อย่างกลุ่มตัวอักษรจีนญี่ปุ่นเกาหลี (CJK) ที่จำนวนตัวอักษรมันเยอะ จะยัดลง 2 ไบต์ก็ไม่ไหว ก็ใช้ 3 ไบต์ไป
ซึ่งในแง่นี้ การให้ตัวอักษร ASCII ใช้เพียง 1 ไบต์ ก็เข้าใจได้มาก ๆ เพราะตัวอักษรในชุดนี้ถูกใช้เป็นคำสั่งและคำสำคัญต่างๆ ในโปรโตคอลการรับส่งข้อมูลและมาตรฐานข้อมูลอื่น ๆ ในระดับพื้นฐานของคอมพิวเตอร์ ถ้าเกิดตัวอักษรชุดนี้ใช้จำนวนไบต์เยอะ ทุกอย่างในระบบก็จะพองขึ้นทันที ซึ่งผลพลอยได้ก็คือ พวกภาษาที่ใช้ตัวอักษรที่อยู่ในกลุ่มตัวละติน (A-Z, a-z) ก็เลย “โชคดี” ไปด้วย (หรือมองอีกมุม ก็เป็นเพราะคนที่ใช้ภาษาที่ใช้อักษรละติน เป็นคนกำหนดมาตรฐานคอมพิวเตอร์ไง ผลที่ตามมาเลยเป็นแบบนี้)
—
อย่างไรก็ตาม ก็มีคำถามแหละ ว่าเอ๊ะ แล้วเอาเฉพาะชุดตัวที่ใช้บ่อยๆ ของตัวอักษรที่ตอนนี้ถูกจัดอยู่ในหมวด 3 ไบต์ (อย่าง CJK) ไปอยู่ใน 2 ไบต์ก็ได้รึเปล่า อย่าง ฮันกึลของเกาหลี หรือ คะนะของญี่ปุ่น พวกนี้ก็ไม่ได้เยอะมากแบ่งไปใส่ในชุด 2 ไบต์ได้ไหม แล้วพวกฮันจาหรือคันจิ (ตัวจีน) ค่อยใส่ในชุด 3 ไบต์ ไม่ต้องยกกันไปทั้งยวงก็ได้
หรืออย่างตัวอักษรไทย มันก็ไม่ได้เยอะอะไร รวมพยัญชนะ รูปสระ วรรณยุกต์ เครื่องหมายวรรคตอน ตัวเลขไทย มีประมาณ 80-90 ตัวได้ ไม่ได้เยอะมาก และคนใช้ตัวอักษรไทยก็ไม่ได้น้อย น่าจะมากกว่าคนใช้ภาษาคอปติกในชีวิตประจำวันแน่ ทำไมอักษรไทยถึงได้เป็น 3 ไบต์ และคอปติกได้ 2 ไบต์
คำว่า “บ่อย ๆ” นี่เอาอะไรวัด จากมุมของใคร หรืองานแบบไหน
แต่เอาล่ะ มาตรฐานมันก็กำหนดมาแบบนี้แล้ว ไปแก้อะไรไม่ได้ (จริงๆ ก็แก้ได้ แต่ต้องไปตามแก้ข้อมูลที่ถูกจัดเก็บไปแล้วทั้งหมด ก็ลำบากมากๆ อยู่) ก็เลยกลายเป็นว่ามีบางภาษา พอออกมาเป็นรูปตัวเขียน ต้องใช้พื้นที่ในการจัดเก็บมากกว่าภาษาอื่น เพราะต่อ 1 ตัวอักษร ใช้จำนวนไบต์มากกว่า
—
กลับไปประเด็นตั้งต้น ถ้าบริการไหนคิดค่าบริการตามจำนวนไบต์ (ขนาดพื้นที่จัดเก็บ/รับส่งข้อมูลจริงๆ) มันก็เป็นประเด็นได้ว่า ทำให้ผู้ใช้ภาษาบางภาษาหลีกเลี่ยงไม่ได้ที่จะต้องจ่ายแพงกว่าภาษาอื่น
วิธีการคิดค่าบริการตามจำนวนตัวอักษร แทนที่จะเป็นจำนวนไบต์ข้อมูลที่จะต้องใช้เก็บตัวอักษรนั้น ก็เลยถูกมองได้ว่าแฟร์ขึ้นมาอีกนิดนึง
แต่ก็อาจมองต่อไปได้ว่า พอถัวเฉลี่ยกัน ก็เลยกลายเป็นว่าคนที่ใช้ภาษาที่ใช้จำนวนไบต์น้อย แทนที่จะได้จ่ายถูก ก็ต้องมารับภาระจ่ายแพงขึ้นหลังจากการถัวรึเปล่า แบบนี้ก็ไม่แฟร์สิ
หรือถ้าไปให้สุดๆ เฮ้ย บางภาษา 1 ตัวอักษร มันเก็บความหมาย อุ้มความหมายเอาไว้ได้เยอะกว่า 1 ตัวอักษรในอีกภาษา ภาษาญี่ปุ่นเขียน 1 ตัว 空 ภาษาไทยต้องเขียน 7 ตัว เพื่อจะได้ความหมายว่า ท้องฟ้า เท่ากัน แบบนี้คนไทยก็ต้องจ่ายแพงกว่าคนญี่ปุ่นรึเปล่า (แบบ 280 ตัวอักษรบนทวิตเตอร์ คนจีนแทบจะเขียนเรื่องสั้นได้แล้ว คนไทยแค่รายงานข่าวอาจจะไม่พอ) แบบนี้การคิดค่าบริการตามตัวอักษรก็ไม่แฟร์อยู่ดีปะ
แต่มันก็คงยากไปอีก ไม่รู้จะคิดเงินกันยังไง ถ้าไปถึงขั้นนั้น การมานับที่หน่วยนับที่พอจะนับได้ อย่าง ตัวอักษร ก็น่าจะพอใช้ได้สุดแล้วมั้ง อย่างน้อยก็ดีกว่าการนับด้วยจำนวนไบต์ แล้วกูเกิลก็เลือกวิธีนี้
—
ตราบใดที่การสร้างมันเกิดการกระบวนการตัดสินใจเลือก การเลือกปฏิบัติมันมีอยู่แน่ๆ ในผลงานทางวิศวกรรม
มันไม่จำเป็นต้องเป็นการเลือกปฏิบัติในทางลบ (ภาษากฎหมายระหว่างประเทศใช้คำว่า “การเลือกประติบัติ”) มันอาจเป็นทางบวกก็ได้ (จริงๆ การคำนึงถึงความถี่ในการใช้และพยายามให้ตัวอักษรที่พบบ่อย ใช้จำนวนไบต์น้อยๆ ก็เป็นการเลือกปฏิบัติที่พยายามจะให้เกิดผลบวกในภาพรวม ทำให้ในภาพรวมใช้พื้นที่จัดเก็บน้อยลง ส่งข้อมูลได้ไวขึ้น ประหยัดขึ้น)
และหลายครั้งก็ไม่ได้เป็นเรื่องตั้งใจให้เกิดการปฏิบัติที่แตกต่างกับกลุ่มคนแบบนั้นแต่แรก แต่อาจมาจากความไม่รู้ ไม่ได้อยู่ในความคิด-อันเนื่องมาจากการติดต่อข้ามวัฒนธรรมยังมีจำกัดในอดีต พอมารู้แล้วในตอนหลังจะให้รื้อทำใหม่หมดก็มีข้อจำกัด ก็เลยยังต้องใช้ของที่มีมาแต่เดิมผสมอยู่ด้วย รื้อหมดไม่ได้
อย่างไรก็ตาม สิ่งตกค้างที่ไม่สามารถกำจัดให้หมดสิ้นไปหมดได้เหล่านี้ ก็เป็นไปได้ว่าจะนำไปสู่การมอบอำนาจและทรัพยากรที่ไม่เท่ากันระหว่างคนแต่ละกลุ่มได้ (เช่นในตัวอย่างนี้ การใช้จำนวนไบต์ต่างกันของตัวอักษร อาจทำให้คนที่ใช้ภาษาต่างกันจ่ายถูกแพงต่างกันได้) ทีนี้คนออกแบบจะรู้ตัวได้อย่างไร และเมื่อรู้ตัวแล้วจะหาทางลดผลกระทบ ให้ทุกคนพอจะอยู่ด้วยกันได้แบบโอเคๆ ยังไง โดยระบบก็ยังทำงานต่อไปได้โดยสะดวก คุ้มค่า และมีประสิทธิภาพด้วย
เผยแพร่ครั้งแรก 7 เมษายน 2564 บนเฟซบุ๊ก
—
พอโพสต์เรื่องข้างต้นจบ ก็นึกถึงอีกประเด็นในสัปดาห์ก่อนหน้า ที่คนพูดถึงบทความ When Binary Code Won’t Accommodate Nonbinary People ซึ่งก็คิดๆ ไปก็น่าจะเป็นเรื่องของ encoding นี่อยู่เหมือนกัน เป็นการเอาการจัดประเภทฝังลงไปในระบบ
ถ้าได้อ่านในบทความนั้น คิดว่าหลักใหญ่ใจความประเด็นมันคือเรื่องการออกแบบตัวระบบ — ทั้งระดับโครงสร้างพื้นฐานและระดับส่วนติดต่อผู้ใช้ — ไม่ว่าจะเป็น database schema ช่องหรือปุ่มที่มีให้กดในหน้าจอ UI หรือวิธีการทำ data validation ที่ทำให้ข้อมูลที่อยู่นอกเหนือไปจากที่ผู้ออกแบบระบบอนุญาต มันกรอกไม่ได้ รวมไปถึงคู่มือใช้งาน/การอบรมการใช้งานที่ทำให้เจ้าหน้าที่ที่เป็นผู้กรอกยึดอยู่กับคุณค่าบางอย่าง แม้ตัวระบบจะไม่ได้บังคับ (ในระบบที่ตัวเจ้าของข้อมูลไม่ได้เป็นผู้กรอกเอง)
ส่วนตัวมีประสบการณ์นี้ตอนไปทำบัตรประชาชนนานมาแล้ว ตอนผมกรอกข้อมูลในฟอร์มกระดาษ ช่องศาสนาผมไม่กรอก เว้นว่าง แต่พอเจ้าหน้าที่ไปกรอกในฟอร์มคอมพิวเตอร์ เขาใส่เป็น “พุทธ” ให้ (คงคิดว่าผมลืมกรอก เลยเติมให้)
ผมแย้ง ให้เว้นว่าง เขาบอกว่าเว้นว่างไม่ได้ ต้องใส่ค่าอะไรบางอย่าง ไม่งั้นจะคลิกไปต่อไม่ได้ จะเลือก “ไม่มี” ก็ไม่มีให้เลือกใน drop-down list สุดท้ายเลยมาดูจอกัน แล้วค่อยพบว่า เราสามารถกรอก “-” เพื่อให้คลิกต่อได้ ซึ่งเจ้าหน้าที่ก็เพิ่งรู้
พาดหัวมันเล่นกับคำ หลายคนอาจจะ อิหยังวะ เพราะอาจคิดไปถึงเลขฐานสองตรงตัว แต่ถ้าอ่านข้อถกเถียงข้างใน ประเด็นมันก็ตามที่ว่าไว้ข้างบนน่ะ
ซอฟต์แวร์เป็นสถาปัตยกรรมที่กำหนด (อนุญาต/ไม่อนุญาต) ทางที่เราจะใช้ชีวิต{ใน/กับ/ด้วย}สภาพแวดล้อมนี้ได้ ไอเดียเดียวกับที่เลซสิกเสนอว่า code is law น่ะแหละ
เผยแพร่ครั้งแรก 31 มีนาคม 2564 บนเฟซบุ๊ก
