เมื่อใดที่คุณจะใช้ ID สตริงยาวแทนที่จะเป็นจำนวนเต็มอย่างง่าย [ปิด]


54

ฉันต้องการที่จะใช้ Youtube เป็นตัวอย่าง: PEckzwggd78พวกเขาใช้รหัสในรูปแบบของ

ทำไมพวกเขาถึงไม่ใช้จำนวนเต็มอย่างง่าย?

หรือ imgur.com - พวกเขายังใช้ ID เช่น9b6tMZSรูปภาพและแกลเลอรี่ ไม่ใช่จำนวนเต็มตามลำดับ

  • ทำไมพวกเขาไม่ใช้จำนวนเต็ม (โดยเฉพาะอย่างยิ่งลำดับ)

  • ในสิ่งที่กรณีมันคือการตัดสินใจที่ชาญฉลาดในการใช้รหัสสตริงดังกล่าวแทนจำนวนเต็ม?


47
อะไรทำให้คุณเชื่อว่า ID ไม่ใช่แค่จำนวนเต็มอย่างง่าย? ฉันรู้ว่าบริการเว็บจำนวนมากที่ใช้จำนวนเต็มใน DB แต่แสดงในการเข้ารหัส base64 บางส่วนเพื่อให้ URL ดูดีขึ้น ที่น่าสนใจคือ youtube ID เกือบจะจับคู่กับจำนวนเต็ม 64 บิต
Josef

2
@rwong แต่คำถาม OPs คือทำไมพวกเขาไม่ใช้ ID ตัวเลขและคำตอบอาจเป็น: พวกเขาใช้ ID ตัวเลขพวกเขาเพียงแค่แสดงใน base64 แทน base10 หรือ base2 แต่ฉันก็ไม่รู้เหมือนกันดังนั้นฉันจึงถาม OP ว่าอะไรทำให้พวกเขาคิดว่า ID ไม่ใช่เลขจำนวนเต็ม 64 บิตแบบง่ายใน base64
Josef


3
ไม่ได้เป็นที่เดียวกับนี้
the_lotus

คำตอบ:


101

Youtube ไม่สามารถใช้ ID ตามลำดับได้ด้วยเหตุผลสองประการ:

  1. ฐานข้อมูลของมันกระจายเกือบแน่นอนทำให้การเรียงลำดับหมายเลขมีความซับซ้อน

  2. มีตัวเลือกความเป็นส่วนตัว "วิดีโอที่ไม่แสดง": วิดีโอที่ไม่แสดงในผลการค้นหา แต่จะมีให้หากคุณทราบ ID

ดังนั้นรหัสวิดีโอควรมีการสุ่มและคาดเดาไม่ได้อย่างสมเหตุสมผล ไม่ว่าจะเป็น ID ที่แสดงด้วยตัวเลขเท่านั้นหรือโดยการรวมกันของตัวอักษรและตัวเลขนั้นไม่เกี่ยวข้อง: มีการทำแผนที่เล็กน้อยจากการเป็นตัวแทนหนึ่งไปยังอีก


11
รหัสตัวเลขไม่จำเป็นต้องเรียงตามลำดับ
Sopel

28
@Sopel ฉันคิดว่าจุดของ IMil คือ Youtube ต้องการสร้าง ID ที่เบาบาง กล่าวอีกนัยหนึ่งหากประเมินว่าคุณจะต้องเก็บ2^40รายการไว้ในสถาปัตยกรรมบางแห่งเท่านั้นมีเหตุผลที่ถูกต้องสำหรับการเลือกช่องว่าง2^80หรือ2^120บิต ตัวอย่างของเหตุผลคือ: ลดการชนโดยไม่ต้องตรวจสอบการชนกันทางเทคนิค ใช้ความกระจัดกระจายของปุ่มเป็นส่วนหนึ่งของการสร้างความลับที่หายาก ("วิดีโอที่ไม่แสดง") และอื่น ๆ
rwong

13
@Sopel คำถามคือ "ทำไมพวกเขาไม่ใช้จำนวนเต็ม (โดยเฉพาะอย่างยิ่งตามลำดับ)?" ฉันอธิบายว่า: 1) รหัสลำดับไม่พึงประสงค์; 2) จำนวนเต็มและสตริงเป็นสิ่งเดียวกันโดยทั่วไป
IMil

3
ประโยค "ดังนั้น" ไม่ได้ทำตามเหตุผลอย่างมีเหตุผล แต่จุดที่มีหมายเลขทั้งสองนั้นถูกต้อง ตัวอย่างของสาเหตุที่การสุ่มไม่จำเป็นต้องเกิดขึ้น: การเรียงหมายเลขตามลำดับด้วยช่องว่างสม่ำเสมอจะทำงานเพื่อให้รหัสที่ไม่ซ้ำกันในฐานข้อมูลอิสระหลายแห่งซึ่งผลลัพธ์สามารถนำมารวมกันในคลังข้อมูล - นี่คือรูปแบบของการแบ่งส่วน นั่นคือสมมติว่าคุณคาดว่าจะมีฐานข้อมูลภูมิภาคไม่เกิน 10,000 แห่ง (บางทีคุณอาจมีเพียง 10 ฐานข้อมูลในขณะนี้ดังนั้น 10,000 ก็เพียงพอแล้ว) จากนั้นแต่ละฐานข้อมูลสามารถมีคอลัมน์ข้อมูลประจำตัวที่มีค่านับ 10,000 ด้วยตัวเลข 4 หลักสุดท้ายที่ไม่ซ้ำกันซึ่งจะไม่มีการชนกันของการผสาน
davidbak

2
@davidbak ข้อกำหนดสำหรับการสุ่มตามจาก (2) ความไม่แน่นอนอาจได้มาจากการกำหนดช่วงที่ไม่ทับซ้อนกับอินสแตนซ์ฐานข้อมูลที่แตกต่างกัน แต่สิ่งนี้จะทำให้ ID สามารถคาดเดาได้
IMil

75
  • เกี่ยวกับรูปแบบของรหัสที่พวกเขากำลังใช้ Base64 (โดยใช้ตัวละครa- z, A- Z, 0- 9, -และ_) สิ่งนี้ช่วยให้พวกเขามีข้อมูล 6 บิตต่อตัวละคร YouTube ใช้รหัสวิดีโอ 11 ตัวอักษรซึ่งหมายความว่าพวกเขาสามารถสร้าง 2 6 * 11หรือมากกว่า 7 * 10 19 ID ดังที่Tom Scott กล่าวไว้นั่นคือ "เพียงพอสำหรับมนุษย์ทุกคนบนโลกโลกที่จะอัปโหลดวิดีโอทุก ๆ นาทีเป็นเวลาประมาณ 18,000 ปี" Base64 ยังง่ายต่อการทำงานด้วยเนื่องจาก 64 เป็นพลังงาน 2 ซึ่งหมายความว่าอักขระทุกตัวแสดงถึงจำนวนบิตที่แน่นอน เราใช้เลขฐานสิบหก (ฐาน 16) ด้วยเหตุผลเดียวกัน

  • ในลักษณะที่ไม่ต่อเนื่องของ ID: หมายความว่าพวกเขาไม่ต้องการตัวนับการซิงโครไนซ์ระหว่างเซิร์ฟเวอร์ทั้งหมดที่กำหนด ID ให้กับวิดีโอ พวกเขาสามารถสร้างตัวเลขสุ่มตรวจสอบว่ามีการใช้งานอยู่และไปจากที่นั่น พวกเขายังสามารถกำหนด ID บล็อกให้แต่ละเซิร์ฟเวอร์เพื่อเลือกและกำจัดการตรวจสอบการทำซ้ำ ฉันไม่รู้ว่าพวกเขากำลังทำสิ่งนั้น แต่พวกเขาทำได้

  • อีกเหตุผลหนึ่งสำหรับรหัสที่ไม่ต่อเนื่องคือมันเป็นสิ่งที่ทำให้วิดีโอ "ไม่แสดง" วิดีโอเหล่านี้เป็นวิดีโอที่จะไม่ปรากฏในผลการค้นหาหรือเป็นคำแนะนำ แต่สามารถเข้าถึงได้หากคุณมีลิงก์ หากคุณใช้การนับตามลำดับคุณสามารถไปที่วิดีโอเพิ่ม ID หนึ่งรายการและแนวคิดของวิดีโอที่ไม่แสดงในรายการนั้นเสีย

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

ฉันสามารถแนะนำวิดีโอของ Tom Scott ได้อย่างมาก ข้อมูลของเขาเกือบจะทั้งน่าสนใจและแม่นยำ


6
ลองชี้ให้เห็นว่า 11 ตัวอักษรของการเข้ารหัส base64 เก็บข้อมูล 66 บิตซึ่งหมายความว่าพวกเขาสามารถแมปจำนวนเต็ม 64 บิตลงในสตริงได้อย่างง่ายดาย เช่นภายในพวกเขาสามารถใช้ 64 บิต int ได้ (แต่ไม่จำเป็นต้องทำ)
Bernhard Hiller

1
สำหรับการเปรียบเทียบการแทนทศนิยมแบบเดิมอาจต้องใช้อักขระมากถึง 20 ตัวโดย“ สิ้นเปลือง” ถึง 9 ตัวอักษรเมื่อเทียบกับ Base64
dan04

วิดีโอ Tom Scott อธิบายสิ่งนี้ได้อย่างสมบูรณ์แบบ
AGB

13
  • จำนวนเต็มไม่ได้ปรับขนาดที่ดีจำนวนเต็ม 32 บิตแบบ "ปกติ" ที่ไม่ได้ลงชื่อจะสูงสุดเพียง 4 พันล้านเท่านั้น

  • พวกเขาอาจไม่ต้องการให้คุณรู้ว่าพวกเขามีรายการออนไลน์หรือติดตามอัตราการเติบโตของพวกเขา

  • ตัวอักษรสามารถเก็บข้อมูลได้มากกว่าตัวเลขคุณต้องใช้ตัวอักษรน้อยลงในการแสดง "หมายเลข" เดียวกัน สำหรับฐานข้อมูลตัวทำดัชนีขนาดใหญ่สิ่งนี้อาจเพิ่มขึ้น


7
1) หนึ่งสามารถใช้ int 64
Rakori

4
2) ทำไม ........... พวกเขาทั้งหมดเป็นสาธารณะ สิ่งที่ไม่ใช่สาธารณะ - ไม่สามารถเข้าถึงได้ แค่นั้น
แหละ

3
3) คุณสามารถทำอย่างละเอียด? แสดงข้อมูลอะไร
Rakori

2
สำหรับ 1: เหมือนกันไปสำหรับ int32 และ int64 ในขณะที่ int64 อาจมีขนาดใหญ่ขึ้น แต่อาจไม่ใหญ่พอ
Nepho

3
ในฐานข้อมูลคุณจะเก็บตัวเลขเป็นตัวเลข ดังนั้น 32 บิตจะใช้ 32 บิต ข้อความจะมีความหนาแน่นน้อยกว่า (วิธีข้อความที่ยากจนมากจะขึ้นอยู่กับการเข้ารหัส)
Taemyr

8

1) ทำไมบางเว็บไซต์ใช้ตัวอักษรในรหัสของพวกเขา พวกเขาเป็นสตริง?

เราไม่ทราบว่าเว็บไซต์เหล่านั้นเก็บ ID ในฐานข้อมูลของพวกเขาเป็นสตริงหรือไม่ ตัวเลขและสตริงเหมือนกันกับคอมพิวเตอร์ สตริงเป็นตัวเลขเพียงแสดงด้วยฐานที่แตกต่างกัน 'A' = 0x41 = 65 = 0b1000001สำหรับคอมพิวเตอร์มันเหมือนกันทั้งหมด แต่ถ้าคุณแสดงมันยิ่งฐานใหญ่ยิ่งแสดงน้อยลงและ URL ที่สั้นลงจะง่ายต่อการอ่านและแชร์สำหรับมนุษย์ ไซต์เช่น YouTube และ Imgur ใช้ฐาน 62 (ตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กบวกตัวเลข) หรือใหญ่กว่า (เพิ่มเส้นประหรืออักขระ URL ที่ถูกต้องอื่น ๆ ) ซึ่งค่อนข้างสั้นสำหรับกลุ่มใหญ่ สิ่งที่คุณต้องการที่จะใช้youtu.be/23489234892348234933หรือyoutu.be/B9k6KMrv8vh?

2) เหตุใดจึงใช้รหัสที่ไม่ต่อเนื่องกัน

คำตอบโดย IMilอธิบายได้ดี:

Youtube ไม่สามารถใช้ ID ตามลำดับได้ด้วยเหตุผลสองประการ:

  • ฐานข้อมูลของมันกระจายเกือบแน่นอนทำให้การเรียงลำดับหมายเลขมีความซับซ้อน

  • มีตัวเลือกความเป็นส่วนตัว "วิดีโอที่ไม่แสดง": วิดีโอที่ไม่แสดงในผลการค้นหา แต่จะมีให้หากคุณทราบ ID

สิ่งเหล่านี้ยังอธิบายว่าทำไมรหัสจึงมีขนาดใหญ่: (YouTube ไม่ได้โฮสต์วิดีโอที่แตกต่างกัน 23,489,234,892,348,234,933 วิดีโอที่แตกต่างกันอย่างเห็นได้ชัด)

  • เมื่อสร้าง ID มันเป็นปัญหาถ้าคุณบังเอิญสร้าง ID เดียวกันสองครั้งดังนั้นคุณต้องมีพื้นที่ ID ขนาดใหญ่เพื่อป้องกันปัญหาวันเกิด

  • ผู้คนสามารถเดา URL ของวิดีโอที่ไม่อยู่ในรายการได้หากโอกาสของรหัสที่ถูกต้องที่ใช้สำหรับวิดีโอนั้นมีขนาดไม่เล็กมาก


3
> "YouTube ไม่ได้โฮสต์วิดีโอที่แตกต่างกัน 23,489,234,892,348,234,933 รายการเห็นได้ชัดว่า" ฉันไม่แน่ใจว่านี่ชัดเจนหรือไม่;)
unperson325680

People can just guess the URL of unlisted videos if the chance of any given valid ID being used for a video isn't very, very small.- คุณจะรู้ได้อย่างไรว่าทุกคนสามารถเข้าถึงวิดีโอที่ไม่แสดงในรายการได้ยกเว้นผู้แต่ง แม้ว่าคนอื่นจะเดารหัสได้แล้ว
Rakori


2
@progo ฉันหมายความว่าถ้าทุกคนในโลกอัปโหลดวิดีโอถึง 3.3 พันล้านวิดีโอบน YouTube โดยเฉลี่ย ... ;)
Jasmijn

5

ทำไมไม่เพียงแค่จำนวนเต็มโดยเฉพาะอย่างยิ่งต่อเนื่อง? และเมื่อใดในกรณีใดการตัดสินใจที่ชาญฉลาดที่จะใช้ ID สตริงดังกล่าวแทนที่จะเป็นจำนวนเต็มคืออะไร

  • พื้นที่ UTF-8 ที่ดีกว่า - เมื่อคุณเปลี่ยนตัวเลขเป็นสตริงคุณจะได้รับมากที่สุด 10 ชุดต่อตัวอักษร (0-9) แต่เมื่อคุณอนุญาตให้ตัวอักษรตัวเลขใด ๆ ที่คุณได้รับ 62 ชุดต่อตัวอักษร (az, AZ, 0-9 ) ดังนั้นโดยใช้สตริงตัวอักษรและตัวเลขคุณสามารถสร้าง URL ที่สั้นกว่าถ้าคุณใช้สตริงตัวเลข นี่เป็นสิ่งสำคัญสำหรับเว็บไซต์ที่ผู้ใช้แชร์ URL เช่น Youtube และ Imgur
  • เลขจำนวนเต็มต่อเนื่องนั้นยากที่จะสร้าง ในการสร้างจำนวนเต็มเพิ่มขึ้นตามลำดับคุณต้องมีเธรดเดี่ยวสร้างตัวเลขหรือประสานงานโฮสต์จำนวนมากในระบบกระจายและเมื่อคุณเรียกใช้แอปพลิเคชั่นระดับสูงเช่น Youtube หรือ Imgur ที่ไม่ได้ปรับขนาดอย่างสตริงที่สร้างแบบสุ่ม (ไม่ได้บอกว่าพวกเขากำลังสร้างแบบสุ่ม)

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


1
2) ในกรณีที่เป็นสตริง ID แต่คุณจะต้องตรวจสอบว่ามีการสร้าง ID สตริงแล้วก่อนที่จะแทรกระเบียนใหม่ลงในฐานข้อมูล แล้วความแตกต่างกับ int ID นั้นคืออะไร?
Rakori

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

1
@davidpacker และวิธีการที่แตกต่างจากการสร้างจำนวนเต็มอีกต่อไป?
Sopel

@Sopel ตามที่ซามูเอลชี้ให้เห็นจำนวนเต็มจะใช้พื้นที่มากขึ้นเช่นยาวกว่าสตริง มิฉะนั้นจะไม่มีความแตกต่างใด ๆ
แอนดี้

1
@davidpacker เมื่อพิมพ์เท่านั้น
Sopel

2

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

ฉันคิดว่าเหตุผลหลักก็คือสมมติว่ามีช่วงคงที่ตามอำเภอใจเช่นuint32(เพื่อประโยชน์ของตัวอย่าง) หากคุณใช้ตัวอักษรเช่นกันคุณสามารถมี ID ที่สั้นกว่าโดยรวม

ฉันจินตนาการว่านี่เป็นเหตุผลด้านสุนทรียภาพสำหรับ URL แทนที่จะมี4,129,873,773ตัวอักษรมันสั้นกว่ามากFu837t(สร้างโดยฉันเอง) ผู้ใช้อาจจำ URL ที่มอบให้เพื่อนได้ แพลตฟอร์มอย่างYoutubeมักจะมี UUID ที่ยาวกว่า 32 บิตเพราะจะหมดพื้นที่อย่างรวดเร็ว


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

หากผู้ใช้สามารถจำ Fu837t ได้ แต่เขาจำ 2390 ไม่ได้?
Rakori

4
@Rakori: Fu837t จะเปรียบเทียบกับ 2223955238 ดังนั้นใช่ 2390 จะถูกเข้ารหัสเป็น "Vg" ดังนั้น: ใช่
Mooing Duck

@MooingDuck ไม่ คุณจะรู้ได้อย่างไรว่าอัลกอริทึมในการสร้างสตริง ID นั้นคืออะไร?
Rakori

3
@Rakori ไม่ใช่อัลกอริธึม แต่เป็นการเข้ารหัส มีอัลกอริธึมที่จะถ่ายโอนตัวเลขระหว่างการเข้ารหัสที่แตกต่างกัน แต่อันไหนที่ใช้ไม่สำคัญตราบใดที่การเข้ารหัสถูกกำหนดไว้อย่างดี url เข้ารหัส base64 ปลอดภัยเป็นที่รู้จักกันดีและได้มาตรฐาน
Josef

2

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

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

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


1

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

ประเภทของการระบุตัวตน:

  • จำนวนเต็มอย่างง่าย: (12345, 981027489382493)
  • จำนวนเต็มฐาน 16: 123456789abcdef - หรือที่เรียกว่า Hex
  • จำนวนเต็มฐาน 64: 9b6tMZS
  • สตริงที่อ่านได้: 12032017-Read-my-awesome-article-01

พวกเขาล้วนมีจุดแข็งและจุดอ่อน อักขระที่ไม่ซ้ำกันมากขึ้นที่คุณสามารถใช้สำหรับตัวระบุของคุณมีจำนวนอักขระน้อยลงซึ่งคุณต้องใช้แทนตัวเลข หมายเลขฐาน 64 เป็นข้อตกลงที่ดีเพราะมีตัวแปรที่สร้างขึ้นที่ใช้งานได้กับ URL และบีบอัดจำนวนอักขระที่ต้องใช้เพื่อแสดงตัวเลข 6 ถึง 8 (เช่นขนาด 3/4 ของขนาด)

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


1

แฮชเนื้อหา

คำว่า "hash" ไม่พบในคำตอบที่ดีคำตอบดังนั้นเราจะไปที่นี่:

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

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

แฮชดีถ้าวัตถุข้อมูลของคุณไม่เปลี่ยนรูป (เช่นใน ZFS หรือgit); พวกเขาจะดีในการจัดเก็บภาพเช่นบน CDNs ขนาดใหญ่ ผมไม่ทราบว่ารหัสโดยเฉพาะอย่างยิ่งผู้ที่จริงมี hashes แต่แน่นอนจะทำให้ความรู้สึก (และไมเคิลKjörlingความเห็นสั้นรหัสอาจจะไม่ hashes เหตุผลที่ชัดเจน - การเปรียบเทียบ, คอมไพล์ใช้ค่า SHA-1 ซึ่งเป็น 20 ไบต์หรือ 40 เลขฐานสิบหก)


1
อย่างน้อยรหัสวิดีโอ Youtube สั้นเกินไปที่จะแฮช วันเกิดที่ผิดธรรมดาใช้; กล่าวโดยเฉลี่ยแล้วที่มีพื้นที่แฮชของ n บิตคุณจะเริ่มเห็นการชนหลังจากเห็นการป้อนข้อมูลแบบ 2 ^ (n / 2) ด้วย ~ 60-70 บิตใน ID นั่นคือ 30-35 บิตของเอกลักษณ์หรือไม่กี่พันล้านรายการ ฉันค่อนข้างแน่ใจว่าพวกเขาโฮสต์วิดีโอมากกว่านั้นโดยตอนนี้ และแน่นอนว่าแฮชส่วนใหญ่เป็นจำนวนเต็มไม่เป็นไร โดยปกติแล้วพวกเขาจะไม่พิมพ์ในรูปแบบทศนิยมไม่มีการแบกบนหรือไม่พวกเขาเป็นจำนวนเต็ม เป็นที่ยอมรับว่าข้อมูลเดียวกันสามารถตีความได้ว่าเป็นข้อมูลเลขฐานสองแบบลอยตัว ...
CVn

3
@ MichaelKjörling: รหัสวิดีโอ YouTube สั้นเกินไปที่จะแฮ็คการเข้ารหัสแต่มีฟังก์ชั่นแฮชจำนวนมากที่มีเอาต์พุต 64 บิตหรือน้อยกว่า - CRC-16/32/64, Java hashCode()ฯลฯ แน่นอนยิ่งสั้น แฮ็ชการชนแบบสุ่มมีแนวโน้มมากขึ้น
dan04

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

0

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

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

นอกจากนี้ยังมีปัจจัยมนุษย์:

ใช้ imgur เป็นตัวอย่าง: https://imgur.com/ ***** / s6UqP

s6UqP,

ช่วงสำหรับตัวละครทุกตัว: a ถึง z capital, a sub z capital, และ 0 ถึง 9 = 26+ 26+ 26+ 10 = 62 ตัวเลือกสำหรับทุกตำแหน่งในสตริง ด้วยตำแหน่งที่ห้านั่นคือชุดค่าผสมที่เป็นไปได้ 916132832 หากคุณจะใช้ตัวเลขเท่านั้นคุณจะต้องมี 9 หลัก

ผู้คนสามารถถือวัตถุได้ประมาณ 7 ชิ้นในหน่วยความจำ 9 หลักมากเกินไป 5 ตัวอักษรทำได้

เวทมนต์หมายเลข 7


มันจดจำ Gfycat: พวกเขาใช้สามคำสองคำคุณศัพท์และชื่อสัตว์ เนื่องจากมีความเป็นไปได้มากมาย ( 1502 adjetivesและ1751 สัตว์ ) พวกเขามีชุดค่าผสมมากกว่า 3 พันล้านชุดโดยใช้เพียงวัตถุสามชิ้น
Gustavo Rodrigues
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.