เหตุใดชื่อไฟล์ของฉันจึงดู 'ปกติ' ใน Linux แต่ไม่ใช่ในระยะไกลบน Windows

ในขณะที่ทำงานกับเพื่อนร่วมงานฉันพบปัญหาแปลก ๆ ที่เกี่ยวข้องกับการเข้ารหัส เรากำลังทำงานกับภาพบางส่วนที่มีชื่อไฟล์ที่เรียบง่ายพอเช่นcity.gifหรือwine.gifแต่เป็นหนึ่งอาจคาดหวังสิ่งที่ได้รับความซับซ้อนมากขึ้นเมื่อใช้อักขระพิเศษเช่นé, ,ë àเรากำลังทำงานกับข้อมูลดัตช์ที่มีตัวละครเหล่านี้เช่นcafé( pub ) (เราไม่สามารถควบคุมที่มาของไฟล์ได้) ที่นี่มีปัญหาเกิดขึ้น ชื่อไฟล์ต่อไปนี้เป็นเพียงตัวอย่าง ปัญหานี้ยังเกิดขึ้นสำหรับตัวละครอื่น ๆ ที่มีกำกับ

café-2.png
cafetaria.png
café.png

รายการแรกและครั้งสุดท้ายควรมีสำเนียงอีในการมี (สำเนียง aigu, é) นั่นเป็นวิธีการที่จะแสดงในลินุกซ์ (CentOS 6 & 7) lsในขั้วเมื่อทำงาน แต่ Windows มาที่นี่! (ใช้ Windows 10, 64 บิต) เมื่อเชื่อมต่อบน Windows ผ่าน SSL กับเซิร์ฟเวอร์ของเราแล้วโทรlsออกรายการด้านบนจะมีลักษณะดังนี้:

café-2.png
cafetaria.png
caf▒.png

ในขณะที่คุณหวังว่าจะเห็นบรรทัดแรกยังคงมีสำเนียงอี éแต่หนึ่งในสามไม่ได้ แต่ฉันเห็น▒ตัวละครนี้ - ซึ่งอยู่medium shadeใน Unicode (9618 ทศนิยม) นี่มันแปลกในตัวมันเอง อย่างไรก็ตามเมื่อฉันเชื่อมต่อผ่าน SFTP ด้วย Filezilla (ยังคงอยู่บน Windows) ฉันจะได้เห็นสิ่งนี้:

cafÃ©-2.png
cafetaria.png
café.png

ดังนั้นตอนนี้สิ่งต่าง ๆ หันกลับมา: ในอันแรกéเปลี่ยนไปเป็นลำดับและในอันที่สามทุกอย่างก็ดี ฉันพบที่นี่ว่าสิ่งนี้น่าจะเกิดจากการแปลง Latin-1 <-> UTF-8 ที่ผิดไปหากฉันทำให้ถูกต้อง แต่นั่นไม่ใช่สิ่งที่เกิดขึ้นใช่ไหม

Linux แสดงทุกอย่างตามที่เราคาดหวัง Windows แสดงพฤติกรรมที่ไม่สอดคล้องกันขึ้นอยู่กับวิธีที่เราดูชื่อไฟล์ (SSH (putty) หรือ SFTP (filezilla)) มีวิธีการ 'ทำให้ปกติ' ชื่อไฟล์เหล่านี้ - เช่นแก้ไข - และตรวจสอบให้แน่ใจว่าพวกเขาเหมือนกันในทุกระบบปฏิบัติการ หรืออย่างน้อยก็สอดคล้องกันและถ้าเป็นเช่นนั้นได้อย่างไร UTF-8เป็นการเข้ารหัสที่เราเลือก

ถึงแม้ว่าสิ่งนี้อาจเหมือนกัน แต่เป็นปัญหาด้านสุนทรียภาพ แต่ก็ไม่ใช่ เมื่อพยายามดาวน์โหลดสิ่งต่าง ๆ ผ่าน SFTP ใน Windows จากเซิร์ฟเวอร์ Linux ของเราฉันไม่สามารถดาวน์โหลดไฟล์ที่มีปัญหาดังกล่าวข้างต้น Filezilla Can't download file cafÃ©-2.png: cafÃ©-2.png does not exist on the serverจะโยนความผิดพลาดเช่น ซึ่งดูเหมือนว่าฉัน Filezilla อ่านไดเรกทอรีและชื่อไฟล์แปลมันในการเข้ารหัสบางอย่างส่งคำขอ GET ไปยังเซิร์ฟเวอร์ด้วยการตีความ แต่การตีความนั้นแตกต่างจากชื่อไฟล์ Linux ดังนั้นจึงไม่พบไฟล์

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

windows filenames character-encoding

— Bram Vanroy
แหล่งที่มา

มันเป็นเรื่องของไคลเอนต์ (PuTTY ฯลฯ ) และการกำหนดค่าของพวกเขาและไม่เกี่ยวข้องกับ Windows สำหรับ PuTTY เสร็จแล้วในส่วนการแปล

— Thomas Dickey

ดูเหมือนว่าéใน "café-2.png" นั้นถูกเข้ารหัส UTF-8 แต่éใน "café.png" นั้นได้รับการเข้ารหัสตามมาตรฐาน ISO-8859-1 คุณสามารถวิ่งpython -c "import sys; print(repr(sys.argv[1]))" café-2.pngและpython -c "import sys; print(repr(sys.argv[1]))" café.png?

— Oskar Skog

@OskarSkog ฉันจะลองดูในตอนเช้า แต่ฉันคิดเสมอว่าชื่อไฟล์ไม่มีการเข้ารหัสในคำอื่น ๆ : เป็นไปตามที่ระบบปฏิบัติการต้องการ นั่นหมายความว่าไฟล์ต่าง ๆ ถูกสร้างบนระบบปฏิบัติการที่แตกต่างกันหรือ (เราไม่สามารถควบคุมที่มาของไฟล์ได้)

— Bram Vanroy

ในระบบปฏิบัติการยูนิกซ์เช่นชื่อไฟล์เป็นเพียงสตริงไบต์ แนวคิดของตัวละครมาในระดับที่สูงขึ้น

— Oskar Skog

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

— user207673

แต่ Windows มาที่นี่!

Windows ไม่มีส่วนเกี่ยวข้องกับสิ่งนี้ คุณสามารถทำซ้ำพฤติกรรมตรงนี้เหมือนกันกับอินสแตนซ์ของท้องถิ่น (พูด) GNOME ขั้วกับเลือกที่เหมาะสมเข้ารหัสขั้วและสถานที่กำหนดค่าอย่างเหมาะสมสำหรับการlsได้โดยไม่ต้องใช้ Windows ใด ๆ อยู่ในภาพที่ทุกคน

สิ่งเดียวที่ Windows ทำคือแสดงให้เห็นอย่างชัดเจนว่าเกิดอะไรขึ้นที่นี่ โปรแกรม Windows FTP ของคุณกำลังรับไบต์ในชื่อไฟล์และแสดงเป็นจุดรหัสที่เกี่ยวข้องในรหัสหน้า 1252 นี่เป็นการเข้ารหัสไบต์เดียวที่มีเกือบทุกอย่างที่เหนือ 0x1F เป็น glyph ที่พิมพ์ได้บอกเราว่าไบต์ในชื่อไฟล์ของคุณคืออะไร .

ชื่อไฟล์ที่สองของคุณส่วนใหญ่ไม่เป็นไปตามปกติ แต่ที่หนึ่งและสามกำลังบอก

ชื่อไฟล์แรกเป็นลำดับไบต์63 61 66 c3 a9 2d 32 2e 70 6e 67- ในโค้ดหน้า 1252 cafÃ©-2.pngนี้คือ นอกจากนี้ยังมีการเข้ารหัส UTF-8 café-2.pngของ
ที่สามชื่อไฟล์เป็นลำดับไบต์63 61 66 e9 2e 70 6e 67- ในโค้ดหน้า 1252 café.pngนี้คือ อย่างไรก็ตามมันไม่ใช่การเข้ารหัส UTF-8 ที่ถูกต้อง e9เริ่มต้นลำดับการเข้ารหัสอักขระที่ไม่สมบูรณ์

ดังนั้นสิ่งที่เกิดขึ้นคือสิ่งที่ไม่ได้ใช้รหัสหน้า 1252 แต่ที่ใช้ UTF-8 กล่าวคือ SSH เซสชั่นของคุณและเครื่องจำลอง terminal ท้องถิ่นของคุณกำลังจัดการUTF-8 ที่ถูกต้องในลักษณะเดียวกับที่อื่น แต่กำลังจัดการที่ไม่ถูกต้อง UTF-8 ในสองวิธีที่แตกต่างกัน

สิ่งที่แสดงกราฟิกบล็อกนั้นอาจเป็นเพียงการใช้กราฟิกบล็อกนั้นเป็นอักขระเอาต์พุตทั่วไปสำหรับลำดับ UTF-8 ที่ไม่ถูกต้อง
ตัวอักษรที่แสดงตัวอักษรéนั้นกลับไปที่หน้ารหัส 1252 เมื่อพบการเข้ารหัสที่ไม่ถูกต้อง

ปัญหาพื้นฐานของคุณคือระบบที่สร้างชื่อไฟล์บางส่วนที่เข้ารหัสเป็น UTF-8 และชื่อไฟล์อื่นที่เข้ารหัสในรหัสหน้า 1252

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

ฉันไม่เห็นด้วยว่า Windows ไม่มีส่วนเกี่ยวข้องกับเรื่องนี้ มันอาจจะไม่เกิดขึ้นบน Linux ตัวอื่น ปัญหาคือการเข้ารหัสเริ่มต้นและ afaik Windows มี (หรืออย่างน้อยก็มี) ใช้ CP ของพวกเขาและไม่ UTF ทำให้เกิดปัญหานี้เกิดขึ้นแม้ในระบบปฏิบัติการเดียวกันทั่วประเทศ คุณสามารถทำซ้ำสิ่งนี้บน Linux แต่ Linux จะมีความสอดคล้องกันมากขึ้นในการเลือก Unicode

— MatthewRock

สวัสดี! ขอบคุณสำหรับคำตอบที่บรรจง คุณมุ่งเน้นไปที่สิ่งที่เกิดขึ้นซึ่งเป็นเรื่องดี: ฉันมักจะชอบที่จะเข้าใจสิ่งที่เกิดขึ้น แต่บางทีคุณอาจทำให้เข้าใจว่าทำไมสิ่งนี้ถึงเกิดขึ้นและเราจะรับมือกับปัญหาที่ตามมาจากความไม่สอดคล้องนี้ได้อย่างไร? ฉันได้เพิ่มสองย่อหน้าเพื่อชี้แจงสิ่งที่ฉันหมายถึง

— Bram Vanroy

ฉันสงสัยว่าทำไม "café" ถึงแสดงเป็นเหมือนกันเมื่อไม่ ls (1) ของ GNU มีข้อผิดพลาดในการจัดการการเข้ารหัสที่ไร้สาระหรือไม่?

— Oskar Skog

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

— user207673

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

— Bram Vanroy