UTF-8 แบบปกติคืออะไร?


129

โครงการไอซียู (ซึ่งตอนนี้ยังมีห้องสมุด PHP ) มีการเรียนที่จำเป็นในการช่วยเหลือปกติ UTF-8 สตริงเพื่อให้ง่ายในการเปรียบเทียบค่าเมื่อการค้นหา

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


230
ใคร̸͢k̵͟n̴͘ǫw̸̛s͘w͘͢ḩ̵a҉̡͢tความน่ากลัวอยู่ในที่มืดใจกลางของ Unicode ͞
ObscureRobot

@ObscureRobot ผมอยากจะทราบว่าสัญลักษณ์พิเศษเหล่านั้นสามารถมีรัฐหรือไม่
eonil

1
@Eonil - ฉันไม่แน่ใจว่าสถานะหมายถึงอะไรในบริบทของ Unicode
ObscureRobot

@ObscureRobot ตัวอย่างเช่นจุดรหัสบางอย่างเช่นนี้มากกว่านี้(begin curved line) (char1) (char2) … (charN) (end curved line) (curved line marker prefix) (char1) (curved line marker prefix) (char2) (curved line marker prefix) (char2)กล่าวอีกนัยหนึ่งหน่วยขั้นต่ำที่สามารถแสดงผลได้?
eonil

2
ฟังดูเหมือนเป็นคำถามที่ดีในตัวของมันเอง
ObscureRobot

คำตอบ:


181

ทุกสิ่งที่คุณไม่เคยอยากรู้เกี่ยวกับ Unicode Normalization

มาตรฐานที่ยอมรับได้

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

เมื่อต้องการใช้

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

การปรับมาตรฐานตามมาตรฐานมี 2 รูปแบบ: NFD และ NFC ทั้งสองมีความเท่าเทียมกันในแง่ที่ว่าหนึ่งสามารถแปลงระหว่างสองรูปแบบนี้โดยไม่สูญเสีย การเปรียบเทียบสตริงสองสายภายใต้ NFC จะให้ผลลัพธ์เหมือนกับการเปรียบเทียบภายใต้ NFD เสมอ

NFD

NFD มีการขยายตัวอักษรอย่างเต็มที่ นี่เป็นรูปแบบการนอร์มัลไลเซชันที่เร็วกว่าในการคำนวณ แต่ผลลัพธ์จะมีจุดรหัสมากขึ้น (เช่นใช้พื้นที่มากขึ้น)

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

เอ็นเอฟซี

NFC จะรวมจุดรหัสใหม่เมื่อทำได้หลังจากเรียกใช้อัลกอริทึม NFD การดำเนินการนี้ใช้เวลานานกว่าเล็กน้อย แต่ส่งผลให้สตริงสั้นลง

Normalization ที่เข้ากันได้

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

การปรับมาตรฐานความเข้ากันได้จะแปลงสิ่งเหล่านี้เป็นลำดับที่สอดคล้องกันของอักขระ "จริง" และยังทำการนอร์มัลไลเซชันตามรูปแบบบัญญัติ ผลลัพธ์ของการปรับมาตรฐานความเข้ากันได้อาจไม่เหมือนกับต้นฉบับ

อักขระที่มีข้อมูลการจัดรูปแบบจะถูกแทนที่ด้วยอักขระที่ไม่มี ยกตัวอย่างเช่นตัวอักษรที่ได้รับการแปลง 9คนอื่น ๆ ไม่เกี่ยวข้องกับความแตกต่างของการจัดรูปแบบ ยกตัวอย่างเช่นตัวอักษรเลขโรมันจะถูกแปลงเป็นตัวอักษรปกติIX

เห็นได้ชัดว่าเมื่อทำการเปลี่ยนแปลงนี้แล้วจะไม่สามารถแปลงกลับไปเป็นชุดอักขระดั้งเดิมได้อีกต่อไป

ควรใช้เมื่อใด

Unicode Consortium แนะนำให้คิดถึงการทำให้เป็นมาตรฐานเดียวกันเช่นการToUpperCaseแปลง มันเป็นสิ่งที่อาจมีประโยชน์ในบางสถานการณ์ แต่คุณไม่ควรใช้มันอย่างเต็มใจ

กรณีการใช้งานที่ดีจะเป็นเครื่องมือค้นหาตั้งแต่คุณอาจจะต้องการค้นหาสำหรับการแข่งขัน9

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

NFKC / NFKD

แบบฟอร์มการปรับมาตรฐานความเข้ากันได้มีสองรูปแบบ NFKD และ NFKC พวกเขามีความสัมพันธ์เช่นเดียวกับระหว่าง NFD และ C

สตริงใด ๆ ใน NFKC ก็อยู่ใน NFC เช่นเดียวกันและเหมือนกันสำหรับ NFKD และ NFD ดังนั้นNFKD(x)=NFD(NFKC(x))และNFKC(x)=NFC(NFKD(x))อื่น ๆ

ข้อสรุป

หากมีข้อสงสัยให้ใช้การปรับมาตรฐานตามรูปแบบบัญญัติ เลือก NFC หรือ NFD ตามพื้นที่ / ความเร็วในการแลกเปลี่ยนที่เกี่ยวข้องหรือขึ้นอยู่กับสิ่งที่จำเป็นสำหรับบางสิ่งที่คุณกำลังดำเนินการระหว่างกัน


42
การอ้างอิงอย่างรวดเร็วเพื่อจดจำว่าตัวย่อย่อมาจากอะไร: NF = รูปแบบปกติ D = สลาย (คลายการบีบอัด) , C = เขียน (บีบอัด) K = ความเข้ากันได้ (เนื่องจากใช้ "C")
Mike Spross

12
คุณต้องการให้ NFD สตริงทั้งหมดบนอินพุตเป็นสิ่งแรกเสมอและเอ็นเอฟซีสตริงทั้งหมดจะเป็นสิ่งสุดท้าย นี้เป็นที่รู้จักกันดี
tchrist

3
@tchrist: นั่นเป็นคำแนะนำที่ดีโดยทั่วไปยกเว้นในกรณีที่หายากที่คุณต้องการให้เอาต์พุตเป็นไบต์สำหรับไบต์เหมือนกับอินพุตเมื่อไม่มีการเปลี่ยนแปลง มีบางกรณีที่คุณต้องการ NFC ในหน่วยความจำหรือ NFD บนดิสก์ แต่เป็นการกำจัดมากกว่ากฎ
Kevin Cathcart

@ เควิน: ใช่ NFD เข้าและ NFC ออกจะทำลายเสื้อกล้าม ฉันไม่แน่ใจว่ามีใครสนใจเรื่องเหล่านี้ แต่อาจเป็นไปได้
tchrist

2
คุณอาจคิดอย่างนั้น แต่จากภาคผนวก: "ในการแปลงสตริง Unicode เป็นรูปแบบ Unicode Normalization ที่กำหนดขั้นตอนแรกคือการสลายสตริงทั้งหมด" แม้ว่าเราจะใช้ NFC แต่ Q-Caron ก็กลายเป็น Q + Caron ก่อนและไม่สามารถจัดองค์ประกอบใหม่ได้เนื่องจากกฎความเสถียรห้ามไม่ให้เพิ่มการแมปองค์ประกอบใหม่ NFC ถูกกำหนดอย่างมีประสิทธิภาพเป็นNFC(x)=Recompose(NFD(x)).
Kevin Cathcart

40

อักขระบางตัวเช่นตัวอักษรที่มีการเน้นเสียง (พูดé) สามารถแสดงได้สองวิธีคือจุดรหัสเดียวU+00E9หรือตัวอักษรธรรมดาตามด้วยเครื่องหมายเน้นเสียงรวมU+0065 U+0301กัน การทำให้เป็นมาตรฐานทั่วไปจะเลือกหนึ่งในสิ่งเหล่านี้เพื่อแสดงเสมอ (จุดรหัสเดียวสำหรับ NFC รูปแบบการรวมสำหรับ NFD)

สำหรับอักขระที่สามารถแสดงโดยลำดับอักขระพื้นฐานหลายตัวและเครื่องหมายรวมกัน (เช่น "s, dot below, dot above" เทียบกับการวางจุดด้านบนแล้วจุดด้านล่างหรือใช้อักขระพื้นฐานที่มีจุดใดจุดหนึ่งอยู่แล้ว) NFD จะ เลือกหนึ่งในสิ่งเหล่านี้ด้วย (ด้านล่างไปก่อนตามที่เกิดขึ้น)

การย่อยสลายความเข้ากันได้ประกอบด้วยอักขระจำนวนหนึ่งที่ "ไม่ควร" เป็นอักขระจริงๆ แต่เป็นเพราะใช้ในการเข้ารหัสแบบเดิม การทำให้เป็นมาตรฐานทั่วไปจะไม่รวมสิ่งเหล่านี้ (เพื่อรักษาความสมบูรณ์แบบไปกลับ - นี่ไม่ใช่ปัญหาสำหรับรูปแบบการรวมเนื่องจากไม่มีการเข้ารหัสแบบเดิม [ยกเว้นการเข้ารหัสภาษาเวียดนามจำนวนหนึ่ง] ที่ใช้ทั้งสองอย่าง) แต่การทำให้เป็นมาตรฐานความเข้ากันได้จะ ลองคิดว่าเหมือนเครื่องหมายกิโลกรัม "kg" ที่ปรากฏในการเข้ารหัสของเอเชียตะวันออก (หรือคาตาคานะครึ่งความกว้าง / เต็มความกว้างและตัวอักษร) หรือการรวมกลุ่ม "fi" ใน MacRoman

ดูรายละเอียดเพิ่มเติมได้ที่http://unicode.org/reports/tr15/


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

13

รูปแบบปกติ (ของ Unicode ไม่ใช่ฐานข้อมูล) จัดการ (เฉพาะ?) เป็นหลักด้วยอักขระที่มีเครื่องหมายกำกับเสียง Unicode ให้อักขระบางตัวที่มีเครื่องหมายกำกับเสียง "built in" เช่น U + 00C0, "Latin Capital A with Grave" อักขระเดียวกันนี้สามารถสร้างขึ้นได้จาก "Latin Capital A" (U + 0041) พร้อมด้วย "Combining Grave Accent" (U + 0300) นั่นหมายความว่าแม้ว่าทั้งสองลำดับจะสร้างอักขระผลลัพธ์ที่เหมือนกัน แต่แบบไบต์ต่อไบต์ การเปรียบเทียบจะแสดงให้เห็นว่าแตกต่างกันอย่างสิ้นเชิง

Normalization คือความพยายามในการจัดการกับสิ่งนั้น การทำให้เป็นมาตรฐานจะทำให้มั่นใจได้ว่า (หรืออย่างน้อยก็พยายาม) ว่าอักขระทั้งหมดได้รับการเข้ารหัสในลักษณะเดียวกันไม่ว่าจะทั้งหมดโดยใช้เครื่องหมายกำกับเสียงที่แยกจากกันหากจำเป็นหรือทั้งหมดโดยใช้จุดรหัสเดียวเมื่อเป็นไปได้ จากมุมมองของการเปรียบเทียบมันไม่สำคัญกับสิ่งที่คุณเลือกมากนัก - สตริงปกติใด ๆ จะเปรียบเทียบกับสตริงปกติอื่นได้อย่างเหมาะสม

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

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


นี่คือส่วนที่ทำให้ฟังก์ชันกราฟมีเข้ามา อักขระไม่เพียง แต่มีไบต์มากกว่า ASCII เท่านั้น แต่หลายลำดับสามารถเป็นอักขระเดี่ยวได้ใช่ไหม (ตรงข้ามกับฟังก์ชันสตริง MB )
Xeoncross

4
ไม่ 'จุดรหัสเดียวคืออักขระหนึ่งตัว' สอดคล้องกับ NFC โดยประมาณ (จุดที่มีเครื่องหมายรวมคือ NFD และไม่มีทั้งสองจุดคือ "ความเข้ากันได้") - การปรับมาตรฐานความเข้ากันได้ NFKC / NFKD เป็นปัญหาที่แตกต่างกัน ความเข้ากันได้ (หรือไม่มี) สำหรับการเข้ารหัสแบบเดิมที่เช่นมีอักขระแยกต่างหากสำหรับ greek mu และ 'micro' (เป็นเรื่องสนุกที่จะนำมาใช้เพราะเวอร์ชัน "ความเข้ากันได้" เป็นเวอร์ชันที่อยู่ในบล็อกละติน 1)
Random832

@ Random832: โอ๊ะถูกต้อง ฉันควรจะรู้ดีกว่าที่จะไปจากความทรงจำเมื่อฉันไม่ได้ทำงานกับมันในปีที่แล้ว
Jerry Coffin

@ Random832 นั่นไม่เป็นความจริง "คร่าวๆ" ของคุณมีมากเกินไป พิจารณาสองกราฟคือ ō̲̃ และ ȭ̲ มีหลายวิธีในการเขียนแต่ละวิธีซึ่งแต่ละวิธีคือ NFC และหนึ่ง NFD แต่ก็มีวิธีอื่นเช่นกัน ไม่มีกรณีที่มีเพียงจุดรหัสเดียว NFD สำหรับแรกคือและเงื่อนงำ"o\x{332}\x{303}\x{304}" "\x{22D}\x{332}"สำหรับสอง NFD เป็นและเงื่อนงำ"o\x{332}\x{304}\x{303}" "\x{14D}\x{332}\x{303}"อย่างไรก็ตามมีความเป็นไปได้ที่ไม่ใช่บัญญัติหลายประการซึ่งเทียบเท่ากับสิ่งเหล่านี้ นอร์มัลไลเซชันช่วยให้สามารถเปรียบเทียบไบนารีของกราฟที่เทียบเท่ากันได้
tchrist

5

หากสตริงยูนิโค้ดสองสตริงเทียบเท่ากันในทางบัญญัติสตริงจะเหมือนกันจริงๆโดยใช้ลำดับยูนิโคดต่างกันเท่านั้น ตัวอย่างเช่นÄสามารถแสดงโดยใช้อักขระÄหรือการรวมกันของ A และ◌̈

หากสตริงมีความเข้ากันได้เท่านั้นที่เทียบเท่าสตริงไม่จำเป็นต้องเหมือนกัน แต่อาจเหมือนกันในบางบริบท เช่น ff ถือได้ว่าเหมือนกับ ff

ดังนั้นหากคุณกำลังเปรียบเทียบสตริงคุณควรใช้การเทียบเท่าตามรูปแบบบัญญัติเนื่องจากความเท่าเทียมกันของความเข้ากันได้ไม่ใช่ความเท่าเทียมที่แท้จริง

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


5

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

อักขระ "Ç" สามารถแสดงเป็นลำดับไบต์ 0xc387 แต่ยังสามารถแทนด้วยC(0x43) ตามด้วยลำดับไบต์ 0xcca7 คุณจึงพูดได้ว่า 0xc387 และ 0x43cca7 เป็นอักขระเดียวกัน เหตุผลที่ใช้งานได้คือ 0xcca7 เป็นเครื่องหมายรวม กล่าวคือต้องใช้อักขระนำหน้า (a Cที่นี่) และแก้ไข

ตอนนี้เท่าที่ความแตกต่างระหว่างความเทียบเท่ามาตรฐานเทียบกับความเท่าเทียมกันของความเข้ากันได้เราจำเป็นต้องดูอักขระโดยทั่วไป

อักขระมี 2 ประเภทคืออักขระที่สื่อความหมายผ่านค่าและอักขระที่ใช้อักขระอื่นและแก้ไข 9 เป็นตัวอักษรที่มีความหมาย super-script ⁹รับความหมายนั้นและปรับเปลี่ยนโดยการนำเสนอ ดังนั้นในทางบัญญัติจึงมีความหมายที่แตกต่างกัน แต่ก็ยังแสดงถึงอักขระพื้นฐาน

การเทียบเท่ามาตรฐานคือการที่ลำดับไบต์แสดงอักขระเดียวกันที่มีความหมายเดียวกัน ความเท่าเทียมกันของความเข้ากันได้คือเมื่อลำดับไบต์แสดงอักขระอื่นที่มีความหมายฐานเดียวกัน (แม้ว่าจะมีการเปลี่ยนแปลงก็ตาม) 9 และ⁹เทียบเท่าความเข้ากันได้เนื่องจากทั้งคู่หมายถึง "9" แต่ไม่เทียบเท่าตามบัญญัติเนื่องจากไม่มีการแทนค่าเดียวกัน


@tchrist: อ่านคำตอบอีกครั้ง ฉันไม่เคยพูดถึงวิธีต่างๆในการแสดงจุดรหัสเดียวกัน ฉันบอกว่ามีหลายวิธีในการแสดงอักขระพิมพ์เดียวกัน(ผ่านตัวผสมและอักขระหลายตัว) ซึ่งใช้ได้กับทั้ง UTF-8 และ Unicode ดังนั้นการโหวตลงคะแนนและความคิดเห็นของคุณจึงไม่มีผลกับสิ่งที่ฉันพูดเลย ในความเป็นจริงฉันกำลังสร้างจุดเดียวกับที่โปสเตอร์ด้านบนที่นี่ทำ (แม้ว่าจะไม่ใช่เช่นกัน) ...
ircmaxell

4

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

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

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


1

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

ดูการเทียบเท่ามาตรฐานของ Unicode : ถ้าอัลกอริทึมการเปรียบเทียบนั้นเรียบง่าย (หรือต้องเร็ว) จะไม่มีการใช้การเทียบเท่า Unicode ปัญหานี้เกิดขึ้นตัวอย่างเช่นในการเปรียบเทียบมาตรฐาน XML โปรดดู http://www.w3.org/TR/xml-c14n

เพื่อหลีกเลี่ยงปัญหานี้ ... จะใช้มาตรฐานอะไร? "UTF8 ที่ขยาย" หรือ "UTF8 ขนาดกะทัดรัด"?
ใช้ "ç" หรือ "c + ◌̧."?

W3C และอื่น ๆ (เช่นชื่อไฟล์ ) แนะนำให้ใช้คำว่า "ประกอบเป็นบัญญัติ" (คำนึงถึง C ของสตริงที่สั้นกว่า "กะทัดรัดที่สุด") ... ดังนั้น

มาตรฐานคือC ! สงสัยใช้NFC

สำหรับความสามารถในการทำงานร่วมกันและสำหรับตัวเลือก "convention over configuration"คำแนะนำคือการใช้NFCเพื่อ "กำหนดมาตรฐาน" สตริงภายนอก ตัวอย่างเช่นในการจัดเก็บ XML ตามรูปแบบบัญญัติให้เก็บไว้ใน "FORM_C" CSVของ W3C บน Web Working Groupยังแนะนำ NFC (หัวข้อ 7.2)

PS: de "FORM_C" เป็นรูปแบบเริ่มต้นในไลบรารีส่วนใหญ่ อดีต ใน PHP ที่ normalizer.isnormalized ()


คำว่า " compostion form" ( FORM_C) ใช้กับทั้งสองเพื่อบอกว่า "สตริงอยู่ในรูปแบบ C-canonical" (ผลจากการแปลง NFC) และบอกว่าใช้อัลกอริทึมการแปลง ... ดูhttp: //www.macchiato.com/unicode/nfc-faq

(... ) แต่ละลำดับต่อไปนี้ (สองลำดับแรกเป็นลำดับอักขระเดี่ยว) แทนอักขระเดียวกัน:

  1. U + 00C5 (Å) LATIN CAPITAL อักษร A พร้อมแหวนด้านบน
  2. U + 212B (Å) ANGSTROM SIGN
  3. U + 0041 (A) LATIN CAPITAL LETTER A + U + 030A (̊) แหวนรวมด้านบน

ลำดับเหล่านี้เรียกว่าเทียบเท่าตามบัญญัติ ครั้งแรกของรูปแบบเหล่านี้เรียกว่า NFC - สำหรับการฟื้นฟูแบบคที่ C สำหรับcompostion ( ... ) ฟังก์ชั่นเปลี่ยนสตริง S เข้ามาในรูปแบบ NFC สามารถย่อว่าtoNFC(S)ในขณะที่หนึ่งว่าการทดสอบว่า S isNFC(S)อยู่ในเอ็นเอฟซีถูกเรียกโดยย่อว่า


หมายเหตุ: ในการทดสอบการทำให้เป็นมาตรฐานของสตริงเล็ก ๆ น้อย ๆ (การอ้างอิง UTF-8 หรือเอนทิตี XML บริสุทธิ์) คุณสามารถใช้การทดสอบ / ทำให้ตัวแปลงออนไลน์เป็นมาตรฐานได้


ฉันสับสน. ฉันไปที่หน้าผู้ทดสอบออนไลน์นี้และเข้าไปที่นั่น: "TÖSTMÉpleasé" และลองใช้การทำให้เป็นมาตรฐานทั้ง 4 ตัว - ไม่มีการเปลี่ยนแปลงข้อความของฉัน แต่อย่างใดยกเว้นว่าจะเปลี่ยนรหัสที่ใช้ในการนำเสนอตัวอักษรเหล่านั้น ฉันคิดผิดหรือเปล่าว่า "normalization" หมายถึง "ลบเครื่องหมายกำกับเสียงและคำที่คล้ายกันทั้งหมดออก" และหมายความว่าจริง ๆ แล้ว - เพียงแค่เปลี่ยนรหัส utf ด้านล่าง
userfuser

สวัสดี @userfuser บางทีคุณอาจต้องการตำแหน่งเกี่ยวกับแอปพลิเคชัน: เพื่อเปรียบเทียบหรือกำหนดมาตรฐานข้อความของคุณ? โพสต์ของฉันที่นี่เป็นเพียงแอปพลิเคชัน "เพื่อสร้างมาตรฐาน" PS: เมื่อทั่วโลกใช้มาตรฐานปัญหาการเปรียบเทียบจะหายไป
Peter Krauss
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.