คำถามติดแท็ก character-encoding

2
จะตรวจจับการเข้ารหัสไฟล์ได้อย่างไร?
ในระบบไฟล์ของฉัน (Windows 7) ฉันมีไฟล์ข้อความบางไฟล์ (นี่คือไฟล์สคริปต์ SQL หากมีความสำคัญ) เมื่อเปิดด้วยNotepad ++ในเมนู "การเข้ารหัส" บางรายการถูกรายงานว่ามีการเข้ารหัส "UCS-2 Little Endian" และ "UTF-8 ที่ไม่มี BOM" บางส่วน ความแตกต่างที่นี่คืออะไร? พวกเขาทั้งหมดดูเหมือนจะเป็นสคริปต์ที่สมบูรณ์แบบ ฉันจะบอกได้อย่างไรว่าการเข้ารหัสไฟล์นั้นไม่มีแผ่นจดบันทึก ++

5
ข้อดีของการเลือกการเข้ารหัส ASCII ผ่าน UTF-8 คืออะไร
อักขระทั้งหมดใน ASCII สามารถเข้ารหัสได้โดยใช้ UTF-8 โดยไม่ต้องเพิ่มหน่วยความจำ (ทั้งคู่ต้องใช้หน่วยเก็บข้อมูลเป็นไบต์) UTF-8 มีประโยชน์เพิ่มเติมจากการสนับสนุนอักขระนอกเหนือจาก "ASCII-characters" หากเป็นกรณีที่ว่าทำไมเราจะเคยเลือกการเข้ารหัส ASCII กว่า UTF-8? มีกรณีการใช้งานเมื่อเราจะเลือก ASCII แทน UTF-8 หรือไม่?

2
เหตุใดสตริงที่แฮชและการเข้ารหัสจำนวนมากจึงลงท้ายด้วยเครื่องหมายเท่ากับ
ฉันทำงานใน C # และ MSSQL และตามที่คุณคาดหวังว่าฉันเก็บรหัสผ่านของฉันเค็มและแฮช เมื่อฉันดูแฮชที่เก็บไว้ในคอลัมน์ nvarchar (ตัวอย่างเช่นผู้ให้บริการสมาชิก aspnet out box) ฉันสงสัยอยู่เสมอว่าทำไมค่าของเกลือและแฮชที่สร้างขึ้นดูเหมือนจะจบลงด้วยสัญญาณหนึ่งหรือสองเท่ากับ ฉันเคยเห็นสิ่งที่คล้ายกันขณะทำงานกับอัลกอริธึมการเข้ารหัสนี่เป็นเหตุบังเอิญหรือมีเหตุผลหรือไม่

3
ทำไมเราต้องใส่ N ก่อนสตริงใน Microsoft SQL Server
ฉันเรียนรู้ T-SQL จากตัวอย่างที่ฉันเห็นการแทรกข้อความในvarchar()เซลล์ฉันสามารถเขียนเฉพาะสตริงที่จะแทรก แต่สำหรับnvarchar()เซลล์ตัวอย่างทุก ๆ คำนำหน้าสตริงด้วยตัวอักษร N ฉันลองใช้แบบสอบถามต่อไปนี้บนตารางที่มีnvarchar()แถวและทำงานได้ดีดังนั้นคำนำหน้า N จึงไม่จำเป็น: insert into [TableName] values ('Hello', 'World') เหตุใดสตริงจึงถูกนำหน้าด้วย N ในทุกตัวอย่างที่ฉันเห็น ข้อดีหรือข้อเสียของการใช้คำนำหน้านี้คืออะไร

8
ควรยกเลิกการเข้ารหัสอักขระนอกเหนือจาก UTF-8 (และอาจจะ UTF-16 / UTF-32) หรือไม่
สัตว์เลี้ยงของฉันกำลังมองหาโครงการซอฟต์แวร์จำนวนมากที่มีภูเขาของรหัสสำหรับการสนับสนุนชุดอักขระ อย่าเข้าใจฉันผิดฉันทุกคนเข้ากันได้และฉันดีใจที่ผู้แก้ไขข้อความให้คุณเปิดและบันทึกไฟล์ในชุดอักขระหลายชุด สิ่งที่ทำให้ฉันรำคาญคือการแพร่กระจายของการเข้ารหัสอักขระที่ไม่ใช่สากลนั้นมีชื่อว่า "การสนับสนุน Unicode ที่เหมาะสม" แทนที่จะเป็น "ปัญหา" ตัวอย่างเช่นสมมติฉันเลือกใน PostgreSQL และสนับสนุนชุดอักขระ PostgreSQL เกี่ยวข้องกับการเข้ารหัสสองประเภท: การเข้ารหัสไคลเอ็นต์: ใช้ในการสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ การเข้ารหัสเซิร์ฟเวอร์: ใช้เพื่อจัดเก็บข้อความภายในฐานข้อมูล ฉันสามารถเข้าใจได้ว่าทำไมการสนับสนุนการเข้ารหัสลูกค้าจำนวนมากเป็นสิ่งที่ดี ช่วยให้ลูกค้าที่ไม่ทำงานใน UTF-8 สามารถสื่อสารกับ PostgreSQL โดยไม่จำเป็นต้องทำการแปลง สิ่งที่ฉันไม่ได้รับคือ: ทำไม PostgreSQL จึงรองรับการเข้ารหัสเซิร์ฟเวอร์หลายเครื่อง ไฟล์ฐานข้อมูล (เกือบทุกครั้ง) ไม่สามารถใช้งานร่วมกันได้จากรุ่น PostgreSQL หนึ่งไปยังรุ่นถัดไปดังนั้นความเข้ากันได้ข้ามรุ่นจึงไม่ใช่ปัญหาที่นี่ UTF-8 เป็นชุดอักขระมาตรฐานที่เข้ากันได้กับ ASCII เท่านั้นที่สามารถเข้ารหัสรหัสสถานี Unicode ทั้งหมด (ถ้าฉันผิดให้ฉันรู้) ฉันอยู่ในค่ายที่ UTF-8 เป็นชุดตัวละครที่ดีที่สุดแต่ฉันก็ยินดีที่จะใส่ชุดอักขระสากลอื่น ๆ เช่น UTF-16 และ UTF-32 ฉันเชื่อว่าชุดอักขระที่ไม่ใช่สากลควรเลิกใช้แล้ว มีเหตุผลที่น่าสนใจที่พวกเขาไม่ควร?

7
ถ่านขนส่งคืน - พิจารณาว่าล้าสมัยหรือไม่
ฉันเขียนไลบรารีโอเพนซอร์ซที่แยกวิเคราะห์ข้อมูลที่มีโครงสร้าง แต่ตั้งใจออกจากการตรวจจับการรับคืนของการขนส่งเนื่องจากฉันไม่เห็นจุดนั้น มันเพิ่มความซับซ้อนและค่าใช้จ่ายเพิ่มเติมเพื่อผลประโยชน์เพียงเล็กน้อย / ไม่มีเลย ด้วยความประหลาดใจของฉันผู้ใช้ส่งข้อผิดพลาดที่ parser ไม่ทำงานและฉันค้นพบสาเหตุของปัญหาคือข้อมูลที่ใช้ปลายสาย CR ตรงข้ามกับ LF หรือ CRLF OSX ไม่ได้ใช้การสิ้นสุดไลน์สไตล์ LF ตั้งแต่เปลี่ยนไปใช้แพลตฟอร์มที่ใช้ระบบปฏิบัติการยูนิกซ์หรือไม่? ฉันรู้ว่ามีแอปพลิเคชั่นเช่น Notepad ++ ซึ่งสามารถเปลี่ยนจุดสิ้นสุดของบรรทัดเพื่อใช้ CR ได้อย่างชัดเจน แต่ฉันไม่เห็นว่าทำไมใครต้องการ จะปลอดภัยไหมที่จะไม่รวมการสนับสนุนสำหรับผู้ใช้จำนวนเปอร์เซ็นต์ที่ไม่มีนัยสำคัญทางสถิติที่ตัดสินใจ (ไม่ว่าจะด้วยเหตุผลใดก็ตาม) กับการสิ้นสุดไลน์สไตล์ Mac OS เก่า? ปรับปรุง: ในการชี้แจงการสนับสนุนการสิ้นสุดบรรทัด Windows (เช่น CRLF) ไม่จำเป็นต้องมีการรับรู้โทเค็น CR สำหรับวัตถุประสงค์ด้านประสิทธิภาพ lexer จะทำการจับคู่แบบต่อหน่วย ด้วยการละเว้นตัวอักษร CR เงียบ ๆ โทเค็น CRLF จะทำให้ LF ง่ายขึ้น ด้วยเหตุนี้โทเค็น …

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

4
ทำไม UTF-8 ถึงเสียหลายบิตในการเข้ารหัส
ตามบทความ Wikipedia , UTF-8 มีรูปแบบนี้: รหัสแรกรหัสล่าสุดไบต์ไบต์ 1 ไบต์ 2 ไบต์ 3 ไบต์ 4 จุดจุดที่ใช้ U + 0000 U + 007F 1 0xxxxxxx U + 0080 U + 07FF 2 110xxxxx 10xxxxxx U + 0800 U + FFFF 3 1110xxxx 10xxxxxx 10xxxxxx U + 10000 U + 1FFFFF 4 11110xxx 10xxxxxx …

2
UTF-16 เป็นความกว้างคงที่หรือความกว้างผันแปรหรือไม่? ทำไม UTF-8 ถึงไม่มีปัญหาการสั่งซื้อแบบไบต์
UTF-16 เป็นความกว้างคงที่หรือความกว้างผันแปรหรือไม่? ฉันได้รับผลลัพธ์ที่แตกต่างจากแหล่งข้อมูลอื่น: จากhttp://www.tbray.org/ongoing/When/200x/2003/04/26/UTF : UTF-16 เก็บอักขระ Unicode ในช่องสิบหกบิต จากhttp://en.wikipedia.org/wiki/UTF-16/UCS-2 : UTF-16 (รูปแบบการแปลง Unicode แบบ 16 บิต) เป็นการเข้ารหัสอักขระสำหรับ Unicode ที่สามารถเข้ารหัสได้ 1,112,064 หมายเลข [1] (เรียกว่าจุดโค้ด) ในพื้นที่โค้ด Unicode ตั้งแต่ 0 ถึง 0x10FFFF มันสร้างผลลัพธ์ความยาวผันแปรของหน่วยรหัส 16 บิตหนึ่งหรือสองหน่วยต่อจุดรหัส จากแหล่งแรก UTF-8 ยังมีข้อได้เปรียบที่หน่วยการเข้ารหัสเป็นไบต์ดังนั้นจึงไม่มีปัญหาการเรียงลำดับไบต์ ทำไม UTF-8 ถึงไม่มีปัญหาการสั่งซื้อแบบไบต์ มันเป็นความกว้างผันแปรและตัวละครหนึ่งตัวอาจมีมากกว่าหนึ่งไบต์ดังนั้นฉันคิดว่าคำสั่งแบบไบต์อาจเป็นปัญหาได้หรือไม่ ขอบคุณและขอแสดงความนับถือ!

3
รหัสแหล่งที่มาของฉันควรอยู่ใน UTF-8 หรือไม่
ฉันรู้สึกว่าบ่อยครั้งที่คุณไม่ได้เลือกรูปแบบของรหัสของคุณฉันหมายถึงเครื่องมือส่วนใหญ่ในอดีตตัดสินใจให้ฉัน หรือฉันไม่เคยแม้แต่จะคิดเกี่ยวกับมัน ฉันใช้ TextPad บน windows เมื่อวันก่อนและเมื่อฉันบันทึกไฟล์มันจะแจ้งให้ฉันทราบเกี่ยวกับ ASCII, UTF-8/16, Unicode และอื่น ๆ ... ฉันสมมติว่าเกือบทุกรหัสที่เขียนเป็น ASCII แต่ทำไมมันควรเป็น ASCII เราควรจะใช้ไฟล์ UTF-8 ตอนนี้สำหรับซอร์สโค้ดหรือไม่และทำไม? ฉันคิดว่านี่อาจเป็นประโยชน์กับทีมหลายภาษา มีมาตรฐานที่เกี่ยวข้องกับการตั้งชื่อตัวแปรฟังก์ชั่น / ฟังก์ชั่น ฯลฯ อย่างไร?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.