Clear
Lead Graphic Papers

ข้อควรระวังในการใช้เครื่องมือตรวจพิสูจน์พยานหลักฐานดิจิทัลในการค้นหาคำหรือข้อความภาษาไทย

ผู้เขียน: เสฏฐวุฒิ แสนนาม
วันที่เผยแพร่: 29 มีนาคม 2557
ปรับปรุงล่าสุด: 29 มีนาคม 2557

Share on Facebook Share on Twitter Share on Google+

ในการตรวจพิสูจน์พยานหลักฐานดิจิทัล มีปัจจัยสำคัญหลายอย่างที่ต้องคำนึงและต้องคอยระมัดระวังเพื่อไม่ให้เกิดความผิดพลาด โดยเฉพาะอย่างยิ่ง การเลือกเครื่องมือที่เหมาะสมกับงาน การทำความเข้าใจถึงวิธีการใช้เครื่องมือที่ถูกต้อง การตรวจสอบความสามารถและข้อจำกัดของเครื่องมือ รวมถึงการตรวจทานเพิ่มเติมอีกครั้งเพื่อยืนยันว่าผลลัพธ์ที่ได้จากการใช้เครื่องมือนั้นถูกต้องจริงๆ  และนอกจากนี้หากจำเป็นต้องเลือกใช้เครื่องมือที่ผลิตจากต่างประเทศก็ต้องตรวจสอบว่าสามารถใช้งานร่วมกับระบบที่เป็นภาษาไทย ซึ่งอาจมีรูปแบบการทำงานที่เป็นลักษณะเฉพาะ ซึ่งหากเครื่องมือที่ใช้นั้นไม่รองรับการทำงานร่วมกับภาษาไทยอย่างเต็มที่หรือมีข้อจำกัดในบางกรณี ก็อาจทำให้ผลการตรวจพิสูจน์นั้นไม่ถูกต้องหรือไม่ครอบคลุมในสิ่งที่ต้องการค้นหาได้

ปัญหาอย่างหนึ่งของการใช้เครื่องมือตรวจพิสูจน์พยานหลักฐานดิจิทัลในการค้นหาคำหรือข้อความที่เป็นภาษาไทย คือเรื่องของ Character set เนื่องจากมาตรฐานการเก็บข้อมูลอักขระภาษาไทยนั้นมีอยู่ด้วยกันหลายรูปแบบ ในกรณีที่ต้องการตรวจสอบว่ามีข้อความภาษาไทยที่เราต้องการค้นหาอยู่ในไฟล์ที่กำหนดหรือไม่ ถ้าหากเลือก Character set ผิด ผลการค้นหาก็อาจกลายเป็นว่าไม่พบข้อความที่ต้องการอยู่ในไฟล์ดังกล่าวได้ ทั้งที่จริงๆ แล้วข้อความนั้นมีอยู่

Character set คืออะไร

ก่อนจะไปพูดถึง Character set ขอเล่าถึงที่มาและรูปแบบการเก็บข้อมูลในคอมพิวเตอร์กันซักนิด เราคงทราบกันดีกว่าคอมพิวเตอร์เก็บข้อมูลในรูปแบบดิจิทัลโดยใช้แค่ตัวเลข 0 กับ 1 ตัวเลขหนึ่งตัวเรียกว่า 1 bit ถ้ามีตัวเลขแปดตัว (8 bit) เรียกว่า 1 byte

เนื่องจากว่าการรับส่งข้อมูลในคอมพิวเตอร์โดยแท้จริงแล้วเป็นแค่การรับส่งตัวเลข 0 กับ 1 ดังนั้นถ้าจะส่งข้อมูลที่เป็นตัวอักษร ก็จำเป็นต้องมีการสร้างรหัสขึ้นมาเพื่อใช้อ้างอิงว่าตัวเลขชุดนี้แทนตัวอักษรอะไร ซึ่งถ้าหากจะเปรียบเทียบให้เห็นภาพในสิ่งที่คล้ายๆ กันก็ลองเปรียบเทียบกับรหัสมอร์สที่ใช้การเคาะจังหวะสั้นกับยาวเพื่อใช้ในการส่งข้อความ

ASCII เป็นรหัสที่ทางอเมริกากำหนดขึ้นมาเพื่อใช้ในการแลกเปลี่ยนข้อมูล โดยในรหัส ASCII ประกอบด้วยตัวอักษรภาษาอังกฤษ (แบบ Latin) ตัวเลขอารบิค เครื่องหมายวรรคตอน และสัญลักษณ์ต่างๆ โดยมีตารางแอสกี (ASCII table) หรือชุดอักขระแอสกี (ASCII character set) มาใช้ในการอ้างอิงว่ารหัสนี้แทนตัวอักษรอะไร เช่น ตัว A ในภาษาอังกฤษ ถูกแทนด้วย 65 ในเลขฐานสิบ (Decimal) หรือ 41 ในเลขฐานสิบหก (Hexadecimal) เป็นต้น [1] ตัวอย่างตารางแอสกีเป็นดังรูปที่ 1


รูปที่ 1 ตัวอย่างตารางแอสกี (ที่มา: ASCII Set [2])

เนื่องจากอักขระ (Character) ในภาษาอังกฤษ (ตัวเลข+ตัวอักษร+เครื่องหมาย+อักขระพิเศษอื่นๆ) รวมกันแล้วมีประมาณร้อยกว่าตัว จึงสามารถใช้รหัส ASCII แบบ 7 bit ที่สามารถเก็บข้อมูลได้ 128 รูปแบบ (2^7 = 128) มาใช้ในการเก็บตัวอักษรและอักขระพิเศษทั้งหมดได้ในรหัสตั้งแต่ 0 - 127

ต่อมาได้มีการปรับปรุงรหัส ASCII ให้เป็นแบบ 8 bit เพื่อให้เก็บอักขระภาษาอื่นๆ เพิ่มได้อีก 128 ตัว (2^8 = 256) โดยอักขระของภาษาอื่นๆ จะถูกเก็บอยู่ในส่วน 128 ช่องที่เพิ่มเข้ามา (รหัสตั้งแต่ 128-255) ส่วนที่เพิ่มขึ้นมานี้เรียกว่า Extended ASCII ดังตัวอย่างในรูปที่ 2


รูปที่ 2 ตัวอย่างตาราง Extended ASCII (ที่มา: ASCII Set [2])

ผังตาราง ASCII แบบ 8 bit จะแตกต่างกันไปตามแต่ละภาษา โดยในส่วน 128 bit แรก ส่วนใหญ่จะยังคงเป็นเหมือนกันหมด แต่ส่วน 128 bit หลังจะเพิ่มอักขระของภาษาตัวเองเข้ามา ผังตารางอักขระที่แตกต่างกันไปในแต่ละภาษานี้เรียกว่า Code page (หรือ Character encoding) [3] อย่างไรก็ตาม เนื่องจากในสมัยก่อน Code page ของบางภาษายังไม่มีมาตรฐานที่ชัดเจน หรืออาจจะมีมาตรฐานอยู่แล้วแต่ผู้ผลิตซอฟต์แวร์ไม่ยอมทำตาม ไปสร้าง Code page ของตัวเองขึ้นมาใช้เอง ทำให้ในบางภาษามีหลาย Code page ซึ่งอาจทำให้มีปัญหาเวลานำไปใช้อ้างอิง เพราะถ้าเลือก Code page ผิด ข้อมูลที่อ่านได้จะไม่ตรงกัน [4]

ANSI เป็นรูปแบบหนึ่งของ Extended ASCII โดยทั่วไปใช้สำหรับอ้างอิงอักขระภาษาอังกฤษ อย่างไรก็ตาม การอ้างอิงรหัสอักขระในแบบ ANSI นั้นยังไม่มีมาตรฐานที่แน่นอน โดยหลักๆ แล้ว 128 bit แรกจะยังคงเหมือนกับตารางมาตรฐาน ASCII แต่ส่วน 128 bit หลังนั้นอาจแตกต่างกันไปตามแต่ละซอฟต์แวร์ ขึ้นอยู่กับว่าจะอ้างอิงมาตรฐานอะไร [5]

มาตรฐานรหัสภาษาไทย

ในสมัยก่อนคอมพิวเตอร์ยังไม่รองรับภาษาไทย และยังไม่มีการกำหนดมาตรฐานรหัสภาษาไทยอย่างเป็นทางการ ผู้ผลิตซอฟต์แวร์แต่ละเจ้าจึงทำมาตรฐานภาษาไทยของตัวเองขึ้นมาใช้ ซึ่งโดยหลักๆ ก็อ้างอิงพื้นฐานมาจากตาราง ASCII แบบ 7 bit โดยใช้พื้นที่ 128 ช่องที่เหลือในการเก็บอักขระภาษาไทย ตัวอย่างรหัสภาษาไทยที่เคยมีการใช้งานในสมัยก่อน เช่น รหัสเกษตรฯ [6] รหัส สมอ. [7] รหัส MacThai [8] เป็นต้น ตัวอย่างโปรแกรม CU Writer ที่ใช้มาตรฐานรหัสภาษาไทยสมัยเก่าเป็นดังรูปที่ 3


รูปที่ 3 ตัวอย่างโปรแกรม CU Writer ที่ใช้มาตรฐานรหัสภาษาไทยสมัยเก่า (ที่มา: Wikipedia [9])

ในส่วนของรายละเอียดมาตรฐานรหัสภาษาไทยที่เคยมีการใช้งานในสมัยก่อน ปัจจุบันนี้อาจหาได้ยากเต็มที เพราะบางรหัสไม่มีการเปิดเผยข้อมูลทางเทคนิคออกสู่สาธารณะ หรือบางรหัสไม่ได้รับความนิยมและไม่มีการเก็บข้อมูลรายละเอียดในส่วนนี้เอาไว้

ภายหลังจากที่มีการพัฒนามาตรฐานรหัสภาษาไทยอย่างเป็นทางการขึ้นมา มาตรฐานรหัสภาษาไทยสมัยเก่าที่ผู้ผลิตซอฟต์แวร์พัฒนาขึ้นมาเองก็เริ่มเสื่อมความนิยมและไม่ถูกใช้งานในที่สุด ปัจจุบันมาตรฐานรหัสภาษาไทยที่ยังคงมีการใช้งานอยู่ โดยหลักๆ มีอยู่ 3 แบบ คือ TIS-620, Windows-874 และ Unicode

TIS-620

มีเรียกอีกชื่อหนึ่งว่ารหัส มอก.620 หรือ รหัส สมอ. เป็นมาตรฐานรหัสตัวอักษรภาษาไทยที่กำหนดโดยสำนักงานมาตรฐานอุตสาหกรรม (สมอ.) โดยพัฒนาเพิ่มเติมจากมาตรฐาน ISO-646-1983 และ IBM GX20-1850-4 ซึ่งเป็นรหัสที่ใกล้เคียงกับ ASCII แบบ 7 bit [10] [11] มาตรฐาน TIS-620 ออกมาครั้งแรกในปี พ.ศ. 2529 และมีการปรับปรุงเพิ่มเติมอีกครั้งหนึ่งในปี พ.ศ. 2533 ตัวอย่างตาราง TIS-620 เป็นดังรูปที่ 4


รูปที่ 4 ตัวอย่างตาราง TIS-620 (ที่มา: IBM [12])

ต่อมามีการพัฒนามาตรฐาน TIS-620 เพิ่มเติมเพื่อให้ได้รับการยอมรับในระดับสากล จนได้รับการประกาศให้เป็นมาตรฐาน ISO-8859-11 ในปี พ.ศ. 2544 โดยรูปแบบแล้ว Character set ของ TIS-620 กับ ISO-8859-11 มีความใกล้เคียงกันมาก มีความแตกต่างกันอยู่บ้างในบางจุดเท่านั้น  [13] [14] [15]

Windows-874

Microsoft นำเอามาตรฐาน TIS-620 มาพัฒนาต่อ เพื่อใช้เป็นรูปแบบตัวอักษรภาษาไทยสำหรับการแลกเปลี่ยนข้อมูลในระบบปฏิบัติการ Windows ตัวมาตรฐาน Windows-874 นั้นถูกพัฒนาขึ้นมาโดยใช้พื้นฐานจาก TIS-620 จึงทำให้มีความเข้ากันได้กับไฟล์ที่ถูกบันทึกมาในมาตรฐาน TIS-620 แต่เนื่องจากว่าใน Windows-874 นั้นมีอักขระบางอย่างที่ถูกใส่เพิ่มขึ้นมาภายหลังซึ่งไม่มีใน TIS-620 จึงอาจก่อให้เกิดปัญหาในกรณีที่บันทึกไฟล์โดยใช้มาตรฐาน Windows-874 แต่ไปเปิดอ่านโดยใช้มาตรฐาน TIS-620 [16]

Windows-874 มีเรียกอีกชื่อหนึ่งว่า CP874, MS874, x-windows-874, และ x-IBM874 อย่างไรก็ตาม เนื่องจากว่า Windows-874 นั้นไม่ได้รับการยอมรับให้เป็นมาตรฐานสากล จึงทำให้บางโปรแกรมหรือบางระบบปฏิบัติการไม่รองรับมาตรฐานนี้ ตัวอย่างตาราง Windows-874 เป็นดังรูปที่ 5


รูปที่ 5 ตัวอย่างตาราง Windows-874 (ที่มา: Microsoft [17])

Unicode

เนื่องจากว่า Character set ของ ASCII แบบ 8 bit ใช้ 1 byte ต่อ 1 ตัวอักษร ทั้งภาษาอังกฤษและภาษาอื่นๆ และสามารถเก็บอักขระได้สูงสุดแค่ 256 ตัว การเก็บข้อมูลในลักษณะนี้จึงทำให้หนึ่ง Character set เก็บได้มากสุดแค่ 2 ภาษา (128 bit แรกเป็นภาษาอังกฤษ 128 bit หลังเป็นภาษาอื่นๆ) เนื่องจากข้อจำกัดของการอ้างอิง Character set ด้วยวิธีนี้ จึงทำให้ไม่สามารถใช้งานกับระบบที่ต้องรองรับหลายๆ ภาษาพร้อมกันได้

จากปัญหาดังกล่าว จึงได้มีการพัฒนามาตรฐาน Unicode ขึ้นมา เพื่อกำหนดให้เป็นรหัสภาษาที่ใช้ได้ครอบคลุมภาษาส่วนใหญ่บนโลก โดยสร้างตารางที่รวบรวมอักขระของแต่ละภาษา และกำหนดหมายเลขเฉพาะให้กับอักขระนั้นๆ [18] ทำให้โปรแกรมเดียวสามารถแสดงผลหลายๆ ภาษาพร้อมกันได้ ปัจจุบันระบบปฏิบัติการ เบราว์เซอร์ ซอฟต์แวร์สมัยใหม่ รวมถึงการแลกเปลี่ยนข้อมูลผ่านอินเทอร์เน็ต ต่างก็รองรับมาตรฐาน Unicode ด้วยกันทั้งสิ้น

มาตรฐาน Unicode เวอร์ชัน 1.0.0 ออกมาในปี พ.ศ. 2534 รองรับ 24 Character set ครอบคลุมอักขระทั้งหมด 7,161 รูปแบบ ภายหลังได้รับการปรับปรุงเพิ่มเติมเรื่อยๆ จนกระทั่งเวอร์ชันล่าสุดคือ 6.3.0 ที่ออกมาในปี พ.ศ. 2556 รองรับ 93 Character set ครอบคลุมอักขระทั้งหมด 110,187 รูปแบบ [19] [20] และในอนาคต มาตรฐาน Unicode 7.0.0 ที่จะออกในช่วงกลางปี พ.ศ. 2557 ก็จะรองรับอักขระต่างๆ เพิ่มขึ้นอีกกว่า 3,000 รูปแบบ [21] Unicode มีวิธีการ Encode รหัสตัวอักษรอยู่ 2 แบบคือ Unicode Transformation Format (UTF) และ Universal Character Set (UCS) แต่ในปัจจุบันนิยมใช้กันอยู่หลักๆ 2 รูปแบบคือ UTF-8 และ UTF-16

UTF-8 เป็น Encoding ที่นิยมใช้มากที่สุด โดยเฉพาะอย่างยิ่งการใช้เป็น Character encoding ในการรับส่งข้อมูลผ่านอินเทอร์เน็ต โดยส่วนใหญ่เว็บไซต์หรือโปรแกรมรับส่งอีเมลในปัจจุบันต่างก็ใช้ UTF-8 เป็นค่าเริ่มต้น [22] ระบบปฏิบัติการตระกูล Unix หรือ Linux เวอร์ชันใหม่ๆ ส่วนใหญ่ใช้ UTF-8 ในการรับส่งข้อมูลระหว่างโปรแกรม ตั้งชื่อไฟล์ หรือใช้เก็บข้อมูลการตั้งค่าการทำงานอื่นๆ [23] การเก็บข้อมูลในรูปแบบ UTF-8 ในส่วนที่เป็นภาษาอังกฤษยังคงใช้ 8 bit เหมือนกับ ASCII แต่สำหรับอักขระในภาษาอื่นๆ นั้นอาจเป็นไปได้ตั้งแต่ 16 bit ถึง 32 bit อักขระภาษาไทยใน UTF-8 ใช้ 24 bit [24]

UTF-16 เป็น Encoding หลักที่ใช้ใน Windows (ตั้งแต่ Windows 2000 เป็นต้นไป) โปรแกรมต่างๆ ที่ทำงานบน Windows เมื่อบันทึกข้อมูลเป็น Unicode จะใช้ Encoding แบบ UTF-16 [25] การเก็บข้อมูลในรูปแบบ UTF-16 จะใช้ 16 bit ต่อการเก็บข้อมูล 1 อักขระ (ในบางภาษาอาจใช้ 32 bit ในการเก็บ 1 อักขระ) อักขระภาษาไทยใน UTF-16 ใช้ 16 bit [26] ตัวอย่าง Encoding ที่โปรแกรม Notepad รองรับ เป็นดังรูปที่ 6


รูปที่ 6 ตัวอย่าง Encoding ที่โปรแกรม Notepad รองรับ

Unicode ต่างจาก ASCII ตรงที่ไม่ได้มีการกำหนดจำนวน bit ตายตัวว่าแต่ละอักขระจะใช้พื้นที่เท่าไหร่ในการเก็บข้อมูล แต่จะดูที่ค่า Hexadecimal ว่าอักขระนี้ใช้พื้นที่กี่ byte เช่น ใน UTF-8 ถ้าโค้ดที่มีค่า Hex ระหว่าง 000000 ถึง 00007F จะใช้ 1 byte แต่ถ้ามีค่า Hex ระหว่าง 000800 ถึง 003FFF จะใช้ 3 byte ในการเก็บข้อมูล ดังรูปที่ 7


รูปที่ 7 จำนวน byte ต่อโค้ดที่ใช้ในการเก็บข้อมูลในรูปแบบ Unicode (ที่มา: Wikipedia [27])

ปัญหา Character encoding กับข้อความภาษาไทย

เนื่องจากมาตรฐาน Character encoding ภาษาไทยนั้นมีอยู่หลายแบบ อีกทั้งระบบปฏิบัติการ หรือโปรแกรมแต่ละตัวก็อาจใช้ Character encoding ที่แตกต่างกัน ทำให้เมื่อนำไฟล์ที่ถูกบันทึกโดยใช้ Character encoding ที่โปรแกรมปลายทางไม่รองรับมาเปิดดูข้อมูล ก็จะพบว่าเป็นข้อมูลที่อ่านไม่ออก หรือที่เราเรียกกันว่าเป็นตัวหนังสือภาษาต่างดาว

เนื่องจาก Character encoding ภาษาไทยที่ใช้ในสมัยก่อน บางรูปแบบไม่ได้รับความนิยมแล้ว ทำให้โปรแกรมสมัยใหม่หลายตัวไม่รองรับ ส่วน Character encoding ภาษาไทยที่ยังมีการใช้งานอยู่ สามารถใช้ไลบรารี libiconv ของ GNU [28] แปลงไปมาระหว่าง ISO-8859-11, TIS-620, CP874, MacThai และ Unicode ได้ อย่างไรก็ตาม ปัจจุบันพบว่าโปรแกรมสมัยใหม่หลายตัวไม่รองรับ Character encoding แบบอื่นแล้วนอกจาก Unicode

การตรวจพิสูจน์พยานหลักฐานดิจิทัลกับการค้นหาข้อความภาษาไทย

ในกรณีที่ต้องตรวจพิสูจน์พยานหลักฐานดิจิทัลเพื่อค้นหาว่ามีไฟล์ที่มีข้อความภาษาไทยตาม Keyword ที่ต้องการอยู่ในพยานหลักฐานหรือเปล่า การเลือก Code page ให้ถูกต้องเป็นสิ่งที่จำเป็น เพราะหากเลือก Code page ผิด อาจทำให้ผลการค้นหาไม่เจอไฟล์ที่มีเนื้อหาตรงกับ Keyword ทั้งที่จริงๆ แล้วมีไฟล์ดังกล่าวอยู่ในพยานหลักฐาน

สำหรับไฟล์ที่มีรูปแบบแน่นอนว่าใช้ Code page แบบไหน ก็ไม่น่าจะมีปัญหาในการค้นหาข้อความที่เป็นภาษาไทยที่อยู่ข้างในไฟล์นั้น แต่หากเป็นไฟล์ที่ไม่มีการกำหนด Code page (เช่น ไฟล์ข้อความ) เครื่องมือตรวจพิสูจน์พยานหลักฐานอาจไม่สามารถตัดสินใจได้ว่าไฟล์นั้นใช้ Code page แบบไหน จึงอาจเลือกอ่านไฟล์ดังกล่าวโดยใช้ Code page มาตรฐาน (เช่น UTF-8) ซึ่งนั่นอาจทำให้ไฟล์ข้อความที่ถูก Encode โดยใช้รูปแบบรหัสภาษาไทยแบบเก่า เช่น TIS-620 หรือ Windows-874 ไม่สามารถอ่านออกเป็นข้อความภาษาไทยได้ และทำให้ค้นหาข้อความที่ต้องการในไฟล์ไม่เจอ

ทดสอบโดยการสร้างไฟล์ข้อความที่มีคำว่า “English,ภาษาไทย” บันทึกโดยใช้ Encoding ที่แตกต่างกันคือ ASCII (US), ANSI, TIS-620, Windows-874, UTF-8 และ Unicode  เมื่อนำไฟล์ที่ได้มาเปิดดูข้อมูลในรูปแบบ Hexadecimal เห็นข้อมูลดังรูปที่ 8


รูปที่ 8 เปรียบเทียบผลลัพธ์ที่ได้จากการ Encode ข้อความภาษาไทย โดยใช้ Character set แบบต่างๆ

จากรูปจะเห็นว่าส่วนที่เป็นอักขระภาษาอังกฤษ ทั้ง ASCII (US), TIS-620, Windows-874, ANSI และ UTF-8 จะใช้ค่าเดียวกัน ส่วน Unicode แบบ UTF-16 ไบต์แรกยังเป็นค่าเดียวกัน แต่ไบต์ที่สองจะเป็น 00 เนื่องจาก UTF-16 ใช้ 2 ไบต์ (16 bit) ต่อการเก็บอักขระหนึ่งตัว (หมายเหตุ: ค่า FFFE ที่เห็นในส่วน Header ของ Unicode เป็นตัวบอกว่าเก็บข้อมูลแบบ big-endian หรือ litttle-endian ถ้าเป็น FFFE คือ little-endian)

ส่วนการเก็บอักขระที่เป็นภาษาไทย เนื่องจาก ASCII (US) ไม่รองรับภาษาไทย เมื่อบันทึกข้อมูลโดยใช้ Encoding แบบนี้จึงเป็นอักขระที่อ่านไม่ได้ และจากรูปจะเห็นว่า Encoding อักขระภาษาไทยของ TIS-620, Windows-874 และ ANSI เป็นค่าเดียวกัน (หมายเหตุ: ค่า 0A เป็นอักขระจบบรรทัด ซึ่งอาจมีหรือไม่มีก็ได้) ส่วน Encoding แบบ UTF-8 และ UTF-16 เก็บข้อมูลอักขระภาษาไทยเป็นคนละค่ากัน

ทดลองใช้โปรแกรม FTK ในการค้นหาข้อความภาษาไทยโดยเลือกวิธีการค้นหาแบบ Live Search ซึ่งเป็นการค้นหา String ที่มีข้อความตรงกับ Keyword ที่กำหนด เมื่อทดลอง Search คำว่า “ภาษาไทย” โดยเลือกรูปแบบข้อความเป็น ANSI, Unicode (UTF-8 และ UTF-16 little-endian) ผลลัพท์ที่ได้คือพบไฟล์ที่มีข้อความตรงกับ Keyword ทั้งหมด 2 ไฟล์ คือไฟล์ที่ Encode แบบ UTF-8 และ UTF-16 ในขณะที่ไฟล์ที่ Encode โดยใช้ ANSI กลับไม่อยู่ในรายชื่อไฟล์ที่มีข้อความตรงกับ Keyword ในขณะที่เมื่อเปลี่ยนไปค้นหาโดยใช้ Encoding แบบ TIS-620 และ Windows-874 ผลที่ได้คือไฟล์ที่ Encode แบบ TIS-620, Windows-874 และ ANSI โดยไฟล์ที่ Encode แบบ UTF-8 และ UTF-16 ไม่ปรากฎในหน้าผลลัพธ์การค้นหา ดังรูปที่ 9


รูปที่ 9 ผลการค้นหาแบบ Live Search

เนื่องจากการ Search ของโปรแกรม FTK จะใช้วิธีนำ Keyword ไป Encoding ตาม Character set ที่เราเลือก เช่น เมื่อนำคำว่า “ภาษาไทย” ไป Encode โดยใช้ Character set แบบ Windows-874 จะได้ค่า Hexadecimal คือ C0D2C9D2E4B7C2 ซึ่งหลังจากนั้นโปรแกรมจะนำค่าที่ได้ไปเปรียบเทียบกับข้อมูลที่อยู่ในพยานหลักฐานอีกทีหนึ่ง ดังตัวอย่างในรูปที่ 10


รูปที่ 10 ตัวอย่างการค้นหาคำว่า “ภาษาไทย” ในไฟล์ที่ Encode โดยใช้ Character set แบบ Windows-874

อีกหนึ่งปัญหาที่พบ คือถึงแม้จะเลือกให้ค้นหาข้อความที่ Encode แบบ ANSI แล้วก็ตาม แต่ผลการค้นหากลับไม่พบข้อความในไฟล์ดังกล่าว สาเหตุหลักๆ ของปัญหานี้เกิดจากการที่ Encoding แบบ ANSI นั้นไม่มีมาตรฐานที่ชัดเจน ทำให้บางครั้งการบันทึกไฟล์แบบ ANSI จะไปอ้างอิง Code page จากข้อมูลการตั้งค่า Region ของระบบปฏิบัติการ [29] แต่พอตอน Search กลับไปอ้างอิง Code page อื่น จึงทำให้อ่านข้อมูลไม่ถูกต้อง ซึ่งจากการทดลองพบว่าเมื่อบันทึกไฟล์โดยใช้ Encoding แบบ ANSI ระบบจะบันทึกโดยใช้ Encoding รหัส 874 แต่โปรแกรม FTK ค้นหาข้อความโดยใช้ Encoding รหัสอื่น (โดยปกติ Microsoft เลือกใช้ Code page 1252 เป็นค่าเริ่มต้นของ ANSI ใน Windows [30]) จึงทำให้ค้นหาข้อมูลไม่พบ

สรุป

เนื่องจากมาตรฐานการเข้ารหัสข้อความอักขระภาษาไทยนั้นมีอยู่หลายรูปแบบ  ดังนั้นในการตรวจพิสูจน์พยานหลักฐานที่ต้องการใช้เครื่่องมือค้นหาคำหรือข้อความที่เป็นภาษาไทย จำเป็นต้องตรวจสอบการตั้งค่า Code page ที่สอดคล้องกันด้วย เนื่องจากหากเลือกการตั้งค่าผิด ก็อาจทำให้เกิดข้อผิดพลาดในผลการตรวจสอบพิสูจน์ได้

อ้างอิง

  1. http://www.wps.com/projects/codes/index.html
  2. http://asciiset.com/
  3. http://en.wikipedia.org/wiki/Code_page
  4. http://linux.thai.net/pub/ThaiLinux/cvs/docs/tis-620/
  5. http://stackoverflow.com/questions/701882/what-is-ansi-format
  6. http://www.ku.ac.th/timeline/query.php?year=1981
  7. http://www.narisa.com/forums/index.php?showtopic=6943
  8. http://www.kreativekorp.com/charset/encoding.php?file=macthai.kte
  9. http://th.wikipedia.org/wiki/CU_Writer
  10. http://th.wikipedia.org/wiki/TIS-620
  11. http://www.nectec.or.th/it-standards/thaistd.pdf
  12. http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.nls%2Fdoc%2Fnlsgdrf%2Ftis-620.htm
  13. http://linux.thai.net/pub/thailinux/cvs/docs/thai-howto2/Thai-HOWTO/Thai-HOWTO-2.html
  14. http://www.nectec.or.th/it-standards/std620/std620.htm
  15. http://www.kreativekorp.com/charset/encoding.php?file=iso-8859-11.kte
  16. http://www.kreativekorp.com/charset/encoding.php?file=cp874.kte
  17. http://msdn.microsoft.com/en-us/goglobal/cc305142.aspx
  18. http://www.unicode.org/standard/translations/thai.html
  19. http://www.unicode.org/versions/Unicode6.3.0/
  20. http://en.wikipedia.org/wiki/Unicode
  21. http://babelstone.blogspot.com/2013/10/whats-new-in-unicode-70.html
  22. http://googleblog.blogspot.com/2008/05/moving-to-unicode-51.html
  23. http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux
  24. http://www.utf8-chartable.de/unicode-utf8-table.pl?start=3584&number=128&utf8=0x
  25. http://msdn.microsoft.com/en-us/library/dd374081.aspx
  26. http://www.unicode.org/charts/PDF/U0E00.pdf
  27. http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings
  28. http://www.gnu.org/software/libiconv/
  29. http://msdn.microsoft.com/en-us/library/dd317756%28VS.85%29.aspx
  30. http://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx
Clear