ตัวละครที่ปลอดภัยสำหรับ url ที่เป็นมิตร [ปิด]


168

ฉันต้องการสร้างเว็บไซต์ที่จะมีบทความและฉันต้องการสร้าง URL ที่จำง่ายสำหรับมันตัวอย่างเช่น URL ของหน้าเว็บด้วย

หัวข้อ: การทดสอบบทความ

ควรจะเป็น: http://www.example.com/articles/article_test.

แน่นอนฉันต้องลบตัวละครบางตัวออกจากชื่อชอบ?หรือ#แต่ฉันไม่แน่ใจว่าตัวละครตัวไหนที่จะลบ

ใครสามารถบอกฉันว่าตัวละครมีความปลอดภัยที่จะเก็บ?


มีคำถามที่คล้ายกันคือที่นี่ ลองดูสิคุณอาจพบคำตอบที่เป็นประโยชน์เช่นกัน (มีจำนวนมากด้วย)
Rook

คำตอบ:


210

อ้างส่วน 2.3 ของRFC 3986 :

"ตัวละครที่ได้รับอนุญาตใน URI แต่ไม่มีวัตถุประสงค์ที่สงวนไว้จะเรียกว่า unreserved ซึ่งรวมถึงตัวอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กตัวเลขทศนิยมยัติภังค์ระยะเวลาเครื่องหมายขีดล่างและเครื่องหมายตัวหนอน"

ALPHA  DIGIT  "-" / "." / "_" / "~"

โปรดทราบว่า RFC 3986 รายการน้อยเครื่องหมายวรรคตอนที่สงวนไว้กว่าเก่าRFC 2396


@Skip หัวไม่ "ตัวอักษร" รวมถึงตัวละครที่เข้ารหัสละตินเหมือนçและõ?
Mohamad

6
@Mohamad: ไม่ ASCII เท่านั้นแม้ว่าการสนับสนุน UTF-8 จะดีขึ้น
Dietrich Epp

@Dietrich Epp ขอบคุณ ฉันเดาว่ามันไม่สำคัญว่า URL จะใช้สำหรับการตกแต่งและทำ SEO เช่น: www.mysite.com/urlpostId Same/post
Mohamad

1
@Mohamad: ส่วนสุดท้ายจะมีได้รับการเปลี่ยนแปลงภายใต้ประทุนไปแต่ก็จะยังคงแสดงในแถบที่อยู่ของผู้ใช้เป็นpost-title-with-%C3%A7-and-%C3%B5 post-title-with-ç-and-õ
Dietrich Epp

7
ผู้อ่านของคุณเป็นชาวโปรตุเกสดังนั้นใช้ตัวอักษรภาษาโปรตุเกส
Dietrich Epp

107

มีสองชุดของตัวละครที่คุณต้องระวังสำหรับ: ลิขสิทธิ์และไม่ปลอดภัย

สงวนตัวอักษร:

  • เครื่องหมายแอมเปอร์แซนด์ ("&")
  • ดอลลาร์ ("$")
  • เครื่องหมายบวก ("+")
  • เครื่องหมายจุลภาค (",")
  • เครื่องหมายทับ ("/")
  • โคลอน (":")
  • เซมิโคลอน (";")
  • เท่ากับ ("=")
  • เครื่องหมายคำถาม ("?")
  • สัญลักษณ์ 'At' ("@")
  • ปอนด์ ("#")

ตัวละครโดยทั่วไปถือว่าไม่ปลอดภัยคือ:

  • ช่องว่าง ("")
  • น้อยกว่าและมากกว่า ("<>")
  • วงเล็บเปิดและปิด ("[]")
  • เครื่องมือจัดฟันแบบเปิดและปิด ("{}")
  • ท่อ ("|")
  • แบ็กสแลช ("\")
  • เครื่องหมายตก ("^")
  • เปอร์เซ็นต์ ("%")

ฉันอาจลืมไปแล้วหนึ่งข้อขึ้นไปซึ่งทำให้ฉันสะท้อนคำตอบของ Carl V ในระยะยาวคุณน่าจะดีกว่าโดยใช้ "รายการขาว" ของตัวละครที่ได้รับอนุญาตแล้วเข้ารหัสสตริงแทนที่จะพยายามให้ทันกับตัวละครที่ไม่ได้รับอนุญาตจากเซิร์ฟเวอร์และระบบ


#เป็นอักขระที่สงวนไว้ใช้สำหรับบุ๊กมาร์กในหน้าใดหน้าหนึ่งที่สร้างขึ้นโดยมีองค์ประกอบ HTML หนึ่งรายการพร้อมกับชื่อแอตทริบิวต์หรือ id-attribute (sans #-symbol) ที่ตรงกัน
TheLonelyGhost

ขอบคุณ - ฉันได้อัพเดตคำตอบแล้ว
Gary.Ray

เครื่องหมายคำถามปรากฏขึ้นที่นี่ทั้งที่จองและไม่ปลอดภัย - ฉันคิดว่ามันสงวนไว้เฉพาะ แต่ฉันอาจไม่ถูกต้อง
Jonathan Basile

6
ดูเหมือนว่าคนอื่นจะไม่เห็นด้วยว่าตัวหนอน~นั้นไม่ปลอดภัย คุณแน่ใจเหรอ
drs

3
รายการที่อนุญาตไม่ดีนักหากใช้ภาษาอื่นนอกเหนือจากภาษาอังกฤษ Unicode มีจุดรหัสตกลงมากเกินไป ดังนั้นการขึ้นบัญชีดำที่ไม่ปลอดภัยน่าจะเป็นวิธีที่ง่ายที่สุดในการนำไปใช้ในนิพจน์ทั่วไป
Patanjali

41

คุณควรเก็บอักขระบางตัว (บัญชีขาว) เอาไว้แทนการลบอักขระบางตัว (บัญชีดำ)

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

  1. ตัวอักษรตัวพิมพ์เล็ก (แปลงตัวพิมพ์เล็กเป็นใหญ่)
  2. ตัวเลข 0 ถึง 9
  3. เส้นประ - หรือขีดล่าง _
  4. ทิลเดอ ~

ทุกอย่างอื่นมีความหมายพิเศษที่อาจเกิดขึ้น ตัวอย่างเช่นคุณอาจคิดว่าคุณสามารถใช้ + แต่สามารถแทนที่ด้วยช่องว่าง & เป็นอันตรายเช่นกันโดยเฉพาะหากใช้กฎการเขียนซ้ำ

เช่นเดียวกับความคิดเห็นอื่น ๆ ตรวจสอบมาตรฐานและข้อกำหนดเพื่อดูรายละเอียดที่สมบูรณ์


15
preiod ฉันค้นพบในวันนี้เป็นตัวเลือกที่ไม่ดีของตัวละครที่ใช้สำหรับการเข้ารหัส Base64 ที่ปลอดภัยเพราะจะมีกรณีที่หายากเหล่านั้นซึ่งข้อมูลที่เข้ารหัสของคุณอาจสร้างจุดติดต่อกันสองจุด (".. ") ซึ่งมีความสำคัญใน มันหมายถึงไดเรกทอรีหลัก
pohl

5
@pohl: เป็นเพียงปัญหาหาก URL ของคุณถูกใช้เป็นเส้นทางไฟล์ไม่ว่าจะเป็นในรหัสของคุณหรือหากเว็บเซิร์ฟเวอร์ของคุณพยายามแมป URL กับไฟล์ก่อนส่งต่อคำขอไปยังสคริปต์
André Caron

4
ที่จริงแล้วในกรณีของเราที่ใช้มันเป็นเส้นทางของไฟล์จะโอเคเนื่องจากไฟล์ยูนิกซ์ได้รับอนุญาตให้มีหลายจุดและต่อเนื่องกันเป็นจุดในชื่อของพวกเขา สำหรับเราปัญหาเกิดขึ้นในเครื่องมือตรวจสอบที่เรียกว่า Site Scope ซึ่งมีข้อผิดพลาด (อาจเป็น regex ที่ไร้เดียงสา) และมีการรายงานข้อผิดพลาดปลอม ๆ สำหรับเราเราติดอยู่กับขอบเขตเว็บไซต์รุ่นเก่าทีมผู้ดูแลระบบปฏิเสธที่จะจ่ายสำหรับการอัพเกรดและลูกค้ารายสำคัญคนหนึ่งมีขอบเขตเว็บไซต์ (ไม่เทียบเท่า) ที่เขียนไว้ในสัญญาของพวกเขา เป็นที่ยอมรับกันว่าส่วนใหญ่จะไม่พบตัวเองในรองเท้าของฉัน
pohl

8
ขอบคุณพระเจ้าที่มีคนโพสต์รายชื่อโดยไม่มีการพูดมาก สำหรับ dot (.) - ตามที่ @ pohl กล่าวว่าอย่าใช้มัน! นี่เป็นอีกกรณีแปลก ๆ ใน IIS (ไม่รู้ว่าจะเกิดอะไรขึ้นกับเว็บเซิร์ฟเวอร์อื่น ๆ ): ถ้ามันอยู่ท้าย URL ของคุณคุณน่าจะได้รับข้อผิดพลาด 404 (มันจะพยายามค้นหา [/ pagename] . หน้า)
nikib3ro

34

ปลอดภัยเสมอ

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

    A-Z a-z 0-9 - . _ ~ ( ) ' ! * : @ , ;

บางครั้งก็ปลอดภัย

ปลอดภัยเฉพาะเมื่อใช้ภายในส่วนประกอบ URL เฉพาะ ใช้ด้วยความระมัดระวัง

    Paths:     + & =
    Queries:   ? /
    Fragments: ? / # + & =
    

ไม่ปลอดภัย

ตามข้อกำหนดของ URI (RFC 3986) อักขระอื่น ๆ ทั้งหมดจะต้องเข้ารหัสเป็นเปอร์เซ็นต์ รวมถึง:

    <space> <control-characters> <extended-ascii> <unicode>
    % < > [ ] { } | \ ^
    

หากข้อกังวลเกี่ยวกับความเข้ากันได้สูงสุดให้ จำกัด ชุดอักขระไว้ที่ AZ az 0-9 - _
(พร้อมจุดเฉพาะส่วนขยายชื่อไฟล์)

คำนึงถึงบริบท

แม้ว่าจะถูกต้องตามข้อกำหนด แต่ URL ก็ยังสามารถ "ไม่ปลอดภัย" ได้ทั้งนี้ขึ้นอยู่กับบริบท เช่นไฟล์: /// URL ที่มีอักขระชื่อไฟล์ไม่ถูกต้องหรือส่วนประกอบข้อความค้นหาที่มี "?", "=" และ "&" ​​เมื่อไม่ได้ใช้เป็นตัวคั่น การจัดการกรณีเหล่านี้อย่างถูกต้องนั้นขึ้นอยู่กับสคริปต์ของคุณและสามารถแก้ไขได้ แต่ก็เป็นสิ่งที่ควรคำนึงถึง


คุณสามารถให้แหล่งข้อมูลใด ๆ สำหรับการอ้างสิทธิ์ครั้งที่สองของคุณ ("บางครั้งปลอดภัย") โดยเฉพาะฉันเชื่อว่าคุณผิดที่บอกว่า=ไม่ปลอดภัยสำหรับข้อความค้นหา ตัวอย่างเช่นFIQLยอมรับเครื่องหมายที่เท่ากันและอธิบายตัวเองว่า "เป็นมิตรกับ URI" และ "ปรับให้เหมาะสมและมีไว้สำหรับใช้ในองค์ประกอบแบบสอบถาม" ในการตีความของฉัน RFC 3986 อนุญาตอย่างชัดเจน "=", "&", "+" และอื่น ๆ ในการสืบค้น
DanielM

@DanielM "?", "=" และ "&" ​​ถูกต้องในการสืบค้นต่อข้อมูลจำเพาะ แต่ในทางปฏิบัติพวกเขาใช้กันอย่างแพร่หลายสำหรับการแยกคู่ค่าชื่อในแบบสอบถาม ดังนั้นพวกเขาจึงไม่ปลอดภัยโดยเป็นส่วนหนึ่งของชื่อ / ค่าด้วยตนเอง สิ่งนี้ถือเป็น "ไม่ปลอดภัย" หรือไม่อาจเป็นเรื่องของความเห็น
Beejor

แหล่งข้อมูลบางแห่งตามที่ร้องขอ (1) RFC 3986, Sec 3.4: "[... ] ส่วนประกอบการสืบค้นมักจะถูกนำมาใช้เพื่อดำเนินการระบุข้อมูลในรูปแบบของ 'key = value' pairs [... ]" (2) WhatWG URL Spec, Sec 6.2: "การสร้างและการทำให้สตริงวัตถุ URLSearchParams ค่อนข้างตรงไปตรงมา: [... ] params.toString() // "key=730d67"" (3) คู่มือ PHP, http-build-query: "สร้างสตริงการค้นหา URL ที่เข้ารหัส [... ] ตัวอย่างด้านบนจะแสดงผลลัพธ์: 0=foo&1=bar[...]"(4) J. Starr กดที่เน่าเสียง่าย:" เมื่อสร้างเว็บเพจบ่อยครั้งที่จำเป็นต้องเพิ่มลิงก์ที่ต้องใช้สตริงการสืบค้นแบบกำหนดพารามิเตอร์ "
Beejor

@Beejor: ฉันกำลังสร้าง URL & ฉันใช้ '-' และ ';' ระหว่างการก่อสร้าง มันไม่ใช่เว็บแอพ แต่เป็นแอพมือถือ ไม่ใช่นักพัฒนาเว็บ & ดังนั้นฉันจะปลอดภัยไหมถ้าฉันใช้สองตัวอักษรด้านบนในคุณสมบัติ Path docs.microsoft.com/en-us/dotnet/api/…
karsnen

1
@karsnen เป็นอักขระ URL ที่ถูกต้อง แม้ว่าจะใช้เพื่ออ้างอิงพา ธ บนระบบไฟล์โลคัลโปรดทราบว่าบางระบบไม่อนุญาตให้ใช้อักขระบางตัวในชื่อไฟล์ ตัวอย่างเช่น "file: /// path / to / my: file.ext" จะไม่ถูกต้องบน Mac
Beejor

17

ดูที่RFC3986 - Uniform Resource Identifier (URI): Generic Syntaxคำถามของคุณจะหมุนรอบองค์ประกอบพา ธของ URI

    foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

อ้างถึงส่วน 3.3 ตัวอักษรที่ถูกต้องสำหรับ URI segmentเป็นประเภทpchar:

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

ซึ่งแบ่งลงเป็น:

ALPHA / DIGIT / "-" / "." / "_" / "~"

pct-encoded

"!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

":" / "@"

หรือในคำอื่น ๆ : คุณอาจจะใช้ใด ๆ (ที่ไม่ใช่ควบคุม) ตัวละครจากตาราง ASCII , ยกเว้น / , ?, #, และ[]

ความเข้าใจนี้ได้รับการสนับสนุนโดยRFC1738 - Uniform Resource Locators (URL)


2
นี่เป็นตัวอย่างที่ดีของคำตอบที่ถูกต้องตามหลักวิชาซึ่งนำไปสู่ปัญหาเมื่อนำไปใช้กับโลกแห่งความจริงที่เราอาศัยอยู่จริงมันเป็นความจริงที่ว่าตัวละครเหล่านั้นส่วนใหญ่จะไม่ทำให้เกิดปัญหาส่วนใหญ่ แต่มีอยู่ในโลกแห่งความเป็นจริงเช่นพร็อกซีเราเตอร์เกตเวย์รีเลย์ ฯลฯ ซึ่งทั้งหมดนี้ "รัก" เพื่อตรวจสอบและโต้ตอบกับ URL ในรูปแบบที่ไม่สนใจมาตรฐานทางทฤษฎี เพื่อหลีกเลี่ยงหลุมพรางเหล่านี้คุณมีข้อ จำกัด ในการหลบหนีทุกอย่างยกเว้นตัวอักษรและตัวเลขขีดกลางขีดล่างและจุด
deltamind106

1
@ deltamind106 คุณสามารถให้ตัวอย่างและ / หรือการอ้างอิงเพื่อชี้แจงว่าตัวละครเหล่านั้นปลอดภัยตาม RFCs จริงหรือไม่? ฉันต้องการที่จะยึดติดกับข้อเท็จจริงที่ได้รับการสนับสนุนจากมาตรฐานในคำตอบของฉันและฉันยินดีที่จะอัปเดตคำตอบของฉันหากคุณสามารถระบุข้อเท็จจริงใด ๆ ที่ฉันอาจถูกทอดทิ้ง
Philzen

2
@ deltamind106 ฉันขอแนะนำให้เราลองรับผลิตภัณฑ์ให้เป็นไปตามมาตรฐานแทนที่จะบอกว่าไม่ทำ ฉันพิจารณาคำเตือนของคุณแล้วคุณควรทำตามส่วนของเราในการรายงานการไม่ปฏิบัติตามผู้ขายหากจำเป็น
Lo-Tan

@Philzen: ฉันกำลังสร้าง URL & ฉันใช้ '-' และ ';' ระหว่างการก่อสร้าง มันไม่ใช่เว็บแอพ แต่เป็นแอพมือถือ ไม่ใช่นักพัฒนาเว็บ & ดังนั้นฉันจะปลอดภัยไหมถ้าฉันใช้สองตัวอักษรด้านบนในคุณสมบัติ Path docs.microsoft.com/en-us/dotnet/api/…
karsnen

1
@karsnen ใช่แน่นอน-และ;ปลอดภัยนั่นคือคำตอบของฉันและ RFC ที่ระบุไว้อย่างชัดเจน
Philzen

12

ไม่ได้จอง = ALPHA / DIGIT / "-" / "." / "_" / "~"


3
"ALPHA" แปลว่า "DIGIT" ใช่หรือไม่ ฉันถือว่า ALPHA สั้นสำหรับ "ตัวอักษรและตัวเลข" และตัวอักษรและตัวเลขหมายถึงตัวพิมพ์ใหญ่ตัวพิมพ์เล็กและตัวเลข
Luc

11
ที่จริงแล้วอัลฟาไม่ได้หมายความถึงตัวอักษรและตัวเลข อัลฟ่าและตัวเลขเป็น 2 สิ่งที่แตกต่างและตัวอักษรและตัวเลขคือการรวมกันของสิ่งเหล่านั้น เขาสามารถเขียนคำตอบของเขาได้เช่น: ALPHANUMERIC / "-" / " / "_" / "~"
MacroMan

1
เอกสาร ABNF สำหรับ 'ไม่ได้สำรอง' ใน RFC 3986 แสดงรายการแยกต่างหาก
Patanjali

11

จากบริบทที่คุณอธิบายฉันสงสัยว่าสิ่งที่คุณพยายามทำจริงๆคือสิ่งที่เรียกว่า 'ตัวบุ้ง SEO' วิธีปฏิบัติที่เป็นที่รู้จักทั่วไปที่ดีที่สุดสำหรับสิ่งเหล่านี้คือ:

  1. แปลงเป็นตัวพิมพ์เล็ก
  2. แปลงลำดับอักขระทั้งหมดที่ไม่ใช่ az และ 0-9 ให้เป็นหนึ่งยัติภังค์ (-) (ไม่ใช่ขีดล่าง)
  3. ลบ 'stop words' ออกจาก URL เช่นคำที่ไม่สามารถจัดทำดัชนีได้เช่น 'a', 'an' และ 'the'; 'คำหยุด' ของ Google สำหรับรายการที่กว้างขวาง

ตัวอย่างเช่นบทความที่มีชื่อว่า "The Usage of! @% $ * เพื่อเป็นตัวแทนของ Swearing In Comics" จะได้รับ "การใช้งานเป็นตัวแทน - สาบาน - การ์ตูน"


เป็นวิธีที่ดีหรือไม่ที่จะลบ "คำหยุด" เหล่านี้ออกจาก URL? เครื่องมือค้นหาจะลงโทษเว็บไซต์เพราะเหตุนี้หรือไม่
เปาโล

เครื่องมือค้นหาโดยทั่วไปเชื่อว่ายอมรับเฉพาะบางส่วนของ URL และ / หรือเพื่อลดความสำคัญของส่วนต่อมาดังนั้นการลบคำหยุดสิ่งที่คุณทำคือเพิ่มจำนวนคำหลักที่คุณฝังใน URL ของคุณให้มากที่สุด จากการจัดอันดับจริงใน
34430 วุ่นวาย

1
@chaos คุณยังแนะนำให้ใช้StopWordถ้าคุณคำนึงถึงสิ่งนี้: seobythesea.com/2008/08/google-stopword-patentนอกจากนี้คุณยังสามารถแนะนำรายการคำหลักที่ดีได้หรือไม่? นี่คือรายการที่ดีที่สุดที่ฉันเคยพบมา - link-assistant.com/seo-stop-words.html
nikib3ro

@ kape123 ดูเหมือนว่าจะไม่ใช่รายการที่ดีสำหรับฉัน "c" และ "d" เป็นภาษาการเขียนโปรแกรมและคำอื่น ๆ อีกมากมายที่มีความสำคัญเช่นกัน ฉันอาจจะแค่ดึงสิ่งพื้นฐาน: a, และ, คือ, บน, จาก, หรือ, กับด้วย
mpen

6

รูปแบบสำหรับ URI ถูกกำหนดไว้ในRFC 3986 ดูหัวข้อ 3.3 สำหรับรายละเอียด


6

จากมุมมองของ SEO ยัติภังค์เป็นที่ต้องการมากกว่าขีดล่าง แปลงเป็นตัวพิมพ์เล็กลบเครื่องหมายอะโพสโทรฟีทั้งหมดจากนั้นแทนที่สตริงอักขระที่ไม่ใช่ตัวอักษรและตัวเลขทั้งหมดด้วยเครื่องหมายยัติภังค์เดียว ตัดยัติภังค์ส่วนเกินออกจากจุดเริ่มต้นและสิ้นสุด


3

ฉันมีปัญหาที่คล้ายกันฉันต้องการมี URL ที่สวยและถึงข้อสรุปว่าฉันต้องอนุญาตเฉพาะตัวอักษรตัวเลข - และ _ ใน URL นั่นเป็นเรื่องปกติจากนั้นฉันก็เขียน regex ที่ดีและฉันรู้ว่ามันตระหนักถึง UTF8 chars ทั้งหมดไม่ใช่ตัวอักษรใน. NET และถูกทำให้เป็นเกลียว นี่ดูเหมือนจะเป็นปัญหาที่ทราบสำหรับเอ็นจิน. NET regex ดังนั้นฉันถึงวิธีนี้:

private static string GetTitleForUrlDisplay(string title)
{
    if (!string.IsNullOrEmpty(title))
    {
        return Regex.Replace(Regex.Replace(title, @"[^A-Za-z0-9_-]", new MatchEvaluator(CharacterTester)).Replace(' ', '-').TrimStart('-').TrimEnd('-'), "[-]+", "-").ToLower();
    }
    return string.Empty;
}


/// <summary>
/// All characters that do not match the patter, will get to this method, i.e. useful for unicode chars, because
/// .NET impl of regext do not handle unicode chars. So we use char.IsLetterOrDigit() which works nicely and we 
/// return what we approve and return - for everything else.
/// </summary>
/// <param name="m"></param>
/// <returns></returns>
private static string CharacterTester(Match m)
{
    string x = m.ToString();
    if (x.Length > 0 && char.IsLetterOrDigit(x[0]))
    {
        return x.ToLower();
    }
    else
    {
        return "-";
    }
}

3
.NET regexes สนับสนุนยูนิโค้ดค่อนข้างดีจริง ๆ คุณต้องใช้คลาสอักขระ Unicode เช่น \ p {L} สำหรับตัวอักษรทั้งหมด ดูmsdn.microsoft.com/en-us/library/20bw873z.aspx#CategoryOrBlock
TheCycoONE

1

ฉันพบว่ามีประโยชน์มากในการเข้ารหัส URL ของฉันให้ปลอดภัยเมื่อฉันคืนค่าผ่าน ajax / php ไปยัง url ซึ่งอ่านหน้านั้นอีกครั้ง

เอาต์พุต PHP พร้อมตัวเข้ารหัส URL สำหรับอักขระพิเศษ &

//PHP returning the sucess info of ajax request
echo "".str_replace('&','%26',$_POST['name'])." category was changed";

//javascript sending the value to url
window.location.href='time.php?return=updated&val='+msg;

//javascript/php executing the function printing the value of the url,
//now with the text normally lost in space because of the reserved & character.

setTimeout("infoApp('updated','<?php echo $_GET['val'];?>');",360);

หวังว่าทุกคนจะพบว่าโค้ดเล็ก ๆ ของฉันมีประโยชน์มาก! :)


0

ฉันคิดว่าคุณกำลังมองหาบางอย่างเช่น "การเข้ารหัส URL" - เข้ารหัส URL เพื่อให้ "ปลอดภัย" เพื่อใช้บนเว็บ:

นี่คือข้อมูลอ้างอิงสำหรับสิ่งนั้น หากคุณไม่ต้องการอักขระพิเศษใด ๆ เพียงลบสิ่งที่ต้องการการเข้ารหัส URL:

http://www.w3schools.com/TAGS/ref_urlencode.asp


-4

ระหว่าง 3-50 ตัวอักษร สามารถมีตัวอักษรตัวพิมพ์เล็กตัวเลขและอักขระพิเศษ - จุด (.), ขีดกลาง (-), ขีดล่าง (_) และที่อัตรา (@)


4
มีการอ้างอิงอะไรบ้าง?
dakab
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.