ปัญหาใดที่ทำให้คนใช้การเข้ารหัสเฉพาะภาษาญี่ปุ่นมากกว่า Unicode

24

ที่ทำงานฉันเจอไฟล์ข้อความภาษาญี่ปุ่นจำนวนมากใน Shift-JIS และการเข้ารหัสอื่น ๆ มันทำให้เกิดปัญหาmojibake (อักขระที่อ่านไม่ได้) จำนวนมากสำหรับผู้ใช้คอมพิวเตอร์ทุกคน Unicode มีวัตถุประสงค์เพื่อแก้ไขปัญหานี้โดยการกำหนดชุดอักขระเดียวสำหรับทุกภาษาและแนะนำให้ใช้ serialization UTF-8 สำหรับการใช้งานบนอินเทอร์เน็ต เหตุใดทุกคนจึงไม่เปลี่ยนจากการเข้ารหัสเฉพาะภาษาญี่ปุ่นเป็น UTF-8 ปัญหาอะไรหรือข้อเสียของ UTF-8 กำลังชักจูงผู้คนให้กลับมา?

แก้ไข: W3C แสดงปัญหาที่ทราบเกี่ยวกับ Unicodeนี่อาจเป็นเหตุผลด้วยหรือไม่

legacy unicode character-encoding

— Nicolas Raoul
แหล่งที่มา

จริง ๆ แล้วไซต์ยอดนิยมเพิ่มมากขึ้นใน UTF-8 ตัวอย่างหนึ่งคือニコニコ動画และはてな

— Ken Li

8

ทำไมทุกคนไม่เปลี่ยนจาก ISO-8851-1 เป็น UTF-8

— ysdx

1

มีการกล่าวถึงในการผ่านที่นี่ว่าการแปลง SHIFT-JIS -> UTF-8 นั้นไม่มีความสูญเสียซึ่งเป็นเหตุผลสำคัญที่จะใช้ SHIFT-JIS ต่อไปซึ่งมีการใช้งานแล้ว ฉันพบว่าข้อเท็จจริงที่น่าประหลาดใจที่เห็นได้ชัดดังนั้นฉันหวังว่าหนึ่งในคำตอบที่นี่อาจมีรายละเอียดเพิ่มเติมหรืออย่างน้อยก็ให้แหล่งข้อมูลสำหรับการอ้างสิทธิ์ แต่ไม่มีใครทำ

— Kyle Strand

@KyleStrand ดูsupport.microsoft.com/en-us/help/170559/…

— Ludwig Schulze

@LudwigSchulze ขอบคุณ ยังมีรายละเอียดไม่มากนัก แต่อย่างน้อยก็เป็นแหล่งข่าวอย่างเป็นทางการ ...

— Kyle Strand

28

ในหนึ่งคำ: มรดก

Shift-JIS และการเข้ารหัสอื่น ๆ ถูกนำมาใช้ก่อนที่ Unicode จะพร้อมใช้งาน / เป็นที่นิยมเนื่องจากเป็นวิธีเดียวที่จะเข้ารหัสภาษาญี่ปุ่นเลย บริษัท ต่างๆได้ลงทุนในโครงสร้างพื้นฐานที่สนับสนุน Shift-JIS เท่านั้น แม้ว่าโครงสร้างพื้นฐานดังกล่าวจะรองรับ Unicode แต่ก็ยังคงติดอยู่กับ Shift-JIS ด้วยเหตุผลต่าง ๆ มากมายตั้งแต่มัน - ใช้งานได้ดี - อย่าแตะต้องมันมากกว่าการเข้ารหัส - อะไร? ไปยังย้ายข้อมูลทั้งหมดที่มีอยู่-เอกสารเป็นมากเกินไปเสียค่าใช้จ่าย

มี บริษัท ตะวันตกหลายแห่งที่ยังคงใช้ ASCII หรือละติน -1 ด้วยเหตุผลเดียวกันไม่มีใครสังเกตเห็นเพราะไม่มีปัญหา

— deceze
แหล่งที่มา

8

อุตสาหกรรมซอฟต์แวร์ญี่ปุ่น ... ช้ากว่าความสกปรกในการใช้ซอฟต์แวร์ / มาตรฐานใหม่

— Mark Hosang

2

@Mark Truer คำพูดที่ไม่เคยพูด! (ฉันทำงานใน / กับ

— แผนก

5

จริง แต่ บริษัท ตะวันตกมีข้ออ้างว่าซอฟต์แวร์รุ่นเก่าของเรานั้นเต็มไปด้วยข้อสันนิษฐานที่มีรหัสตายตัวว่า 1 ไบต์ = 1 ตัวอักษรซึ่งทำให้การเปลี่ยนไปใช้ UTF-8 นั้นยากกว่าสำหรับคนเอเชียที่ต้องเขียนรหัสสะอาด MBCS

— dan04

@ MarkHosang ฉันยืนยันว่าคำสั่งของคุณถูกต้อง 100% (ฉันทำงานให้กับ บริษัท ญี่ปุ่นในโตเกียว)

— Hassan Tareq

9

นี่คือเหตุผลที่ฉันจำได้ว่าไม่ให้ UTF-8 หรือ Unicode อื่นแทนการเข้ารหัสอักขระเริ่มต้นสำหรับภาษาสคริปต์ Ruby ซึ่งพัฒนาขึ้นในญี่ปุ่นเป็นหลัก:

เหตุผลที่ 1: ฮันผสมผสาน ชุดอักขระ (ไม่แน่ใจว่า "ตัวอักษร" จะถูกต้องตรงนี้หรือไม่) ที่ใช้กับประเทศจีนเกาหลีและญี่ปุ่นล้วนมีวิวัฒนาการมาจากประวัติศาสตร์ทั่วไปไม่แน่ใจเกี่ยวกับรายละเอียด กลุ่ม Unicode ตัดสินใจที่จะเสียรหัส Unicode เพียงจุดเดียวเพื่อเข้ารหัสสายพันธุ์ทั้งหมด (จีนญี่ปุ่นและเกาหลี) ของตัวละครเดียวกันในประวัติศาสตร์แม้ว่าลักษณะของพวกเขาจะแตกต่างกันใน 3 ภาษา เหตุผลของพวกเขาคือลักษณะที่ปรากฏควรถูกกำหนดโดยแบบอักษรที่ใช้เพื่อแสดงข้อความ

เห็นได้ชัดว่าเหตุผลนี้เป็นที่เข้าใจว่าเป็นเรื่องไร้สาระของผู้ใช้ภาษาญี่ปุ่นเพราะมันจะต้องเถียงกับผู้อ่านภาษาอังกฤษว่าเพราะตัวอักษรละตินได้พัฒนามาจากตัวอักษรกรีกก็เพียงพอแล้วที่จะมีเพียงจุดรหัสเดียวสำหรับกรีกอัลฟา " α "และละติน" a "และให้แบบอักษรที่ใช้งานตัดสิน (เหมือนกันสำหรับ "β" = "b", "γ" = "g" ฯลฯ )

(โปรดทราบว่าฉันจะไม่สามารถรวมอักขระกรีกที่นี่ใน stackexchange หากเป็นกรณีนี้)

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

อาจมีอีกหลายเหตุผลที่ทำให้ฉันจำไม่ได้อีกแล้ว

— ลุดวิกชูลซ์
แหล่งที่มา

ปรากฏว่า ณ วันที่ 2.0 Ruby ได้ใช้ UTF-8 เป็นค่าเริ่มต้น แต่การรวมกันของฮันดูเหมือนจะเป็นรอยย่นที่สำคัญมาก (และประเด็นที่ถกเถียงกันมาก ) ในโลกของ Unicode ที่เห็นได้ชัดว่าไม่ได้รับความสนใจมากพอเนื่องจากฉันไม่เคยได้ยินมาก่อน

— Kyle Strand

และนี่คือบทความ Wikipedia เกี่ยวกับปัญหาการรวมกันของฮัน: en.wikipedia.org/wiki/Han_unificationซึ่งดูเหมือนว่าจะเป็นปัญหาที่ถูกต้องและเป็นคำตอบที่ยอดเยี่ยม! นอกจากนี้การสูญเสียวันที่จะเป็นเหตุผลที่ดี

— spbnick

8

คำตอบของการหลอกลวงมีองค์ประกอบของความจริงที่แข็งแกร่งมาก แต่ก็มีอีกเหตุผลที่ Shift-JIS และผู้อื่นยังคงใช้งานอยู่: UTF-8 ไม่มีประสิทธิภาพอย่างน่ากลัวสำหรับบางภาษาส่วนใหญ่ในชุด CJK Shift-JIS คือ IIRC การเข้ารหัสแบบกว้างสองไบต์ในขณะที่ UTF-8 มักจะเป็น 3 ไบต์และบางครั้งแม้แต่ 4 ไบต์ในการเข้ารหัสด้วย CJK และอื่น ๆ

— เพียงแค่ความคิดเห็นที่ถูกต้องของฉัน
แหล่งที่มา

7

ในขณะที่เป็นจริงมีทางเลือกของ UTF-16 ซึ่งอาจมีประสิทธิภาพเท่ากับ Shift-JIS ฉันยังยืนยันว่าอาการปวดหัวในการจัดการกับการเข้ารหัสที่แตกต่างกันนั้นมีค่ามากกว่าการเพิ่มขนาดในวันนี้และอายุเล็กน้อย เพื่อให้เป็นไปในแนวทางอื่นฉันไม่เคยได้ยินข้อโต้แย้งเรื่องประสิทธิภาพสำหรับ Shift-JIS โดยใครยังคงใช้มัน ;-)

— หลอกลวง

5

ฉันได้ยินมาว่าปัญหาเรื่องประสิทธิภาพที่ใช้เป็นข้ออ้างสำหรับความเฉื่อยชาและความเฉื่อย

— เพียงแค่ความคิดเห็นที่ถูกต้องของฉัน

1

UTF-16 สร้างอักขระ ASCII พื้นฐาน [ซึ่งมีจำนวนมากเช่น HTML] สองครั้งใหญ่ ตามที่ฉันเข้าใจแล้วสิ่งนี้ทำให้ UTF-16 ยิ่งแย่กว่า UTF-8 สำหรับเว็บเพจญี่ปุ่น

— Random832

2

@ เพียงความคิดเห็นที่ถูกต้องของฉัน: ลอง "ดูแหล่งที่มา" หรือเทียบเท่า สมมติว่าข้อความจริงทั้งหมดเป็นภาษาญี่ปุ่นมีแนวโน้มที่จะมีคำหลักจำนวนมากและสิ่งที่คล้ายกันที่ได้มาจากภาษาอังกฤษและแสดงเป็น ASCII

— David Thornley

4

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

— Julien Guertault

2

นับจำนวนการใช้งานสตริง / หน่วยความจำท่ามกลางเหตุผลหลัก

ใน UTF-8 ภาษาเอเชียตะวันออกมักต้องการอักขระอย่างน้อย 3 ไบต์ขึ้นไป โดยเฉลี่ยแล้วพวกเขาต้องการหน่วยความจำมากกว่า50%เมื่อใช้ UTF-16 ซึ่งหลังมีประสิทธิภาพน้อยกว่าการเข้ารหัสแบบเนทีฟ

เหตุผลหลักอื่น ๆ จะเป็นมรดกตามที่ชี้ไปที่การหลอกลวง

— เดนิสเดอเบอร์นาดี
แหล่งที่มา

2

แบบดั้งเดิมและขนาดสตอเรจตามที่คนอื่นพูด แต่มีอีกอย่างหนึ่ง: คาตาคานะตัวละคร

ใช้เวลาเพียงหนึ่งไบต์ในการเป็นตัวแทนของตัวละครคาตาคานะใน Shift-JIS ดังนั้นข้อความภาษาญี่ปุ่นรวมถึงคาตาคานะจะใช้เวลาน้อยกว่า 2 ไบต์ต่อตัวอักษร (1.5 สำหรับส่วนผสม 50/50) ทำให้ Shift-JIS ค่อนข้างมีประสิทธิภาพมากกว่า UTF-16 (2 ไบต์ / char) และมีประสิทธิภาพมากกว่า UTF-8 (3 bytes / char)

พื้นที่เก็บข้อมูลราคาถูกควรทำให้ปัญหานี้มีขนาดเล็กลงมาก แต่ดูเหมือนจะไม่ใช่

— azheglov
แหล่งที่มา