ရေးသားသူ- Sir Tim Berners-Lee၊ URIs၊ URLs၊ HTTP၊ HTML နှင့် World Wide Web တို့ကို တီထွင်သူနှင့် W3C ၏ လက်ရှိအကြီးအကဲ။ 1998 တွင်ရေးခဲ့သောဆောင်းပါး

မည်သည့် URI ကို "အေး" ဟု ယူဆသနည်း။
မပြောင်းလဲသော တစ်ခု။
URI တွေ ဘယ်လိုပြောင်းလဲ။
URI တွေက မပြောင်းပါဘူး- လူတွေက သူတို့ကို ပြောင်းတယ်။

သီအိုရီအရ၊ လူတွေက URI ကိုပြောင်းဖို့ အကြောင်းပြချက်မရှိဘူး (ဒါမှမဟုတ် စာရွက်စာတမ်းတွေကို ရပ်လိုက်တာ)၊ ဒါပေမယ့် လက်တွေ့မှာတော့ သန်းပေါင်းများစွာရှိပါတယ်။

သီအိုရီအရ၊ domain namespace တစ်ခု၏အမည်ခံပိုင်ရှင်သည် domain namespace ကို အမှန်တကယ်ပိုင်ဆိုင်ပြီး ထို့ကြောင့် ၎င်းအတွင်းရှိ URI များအားလုံး။ ပျက်ကွက်ခြင်းမှလွဲ၍ domain name တစ်ခု၏ပိုင်ရှင်ကို မည်သည့်အရာကမှ နာမည်မထိန်းထားနိုင်ပါ။ သီအိုရီအရ၊ သင့်ဒိုမိန်းအမည်အောက်ရှိ URI နေရာသည် သင့်ထိန်းချုပ်မှုအောက်တွင် အပြည့်ရှိနေသောကြောင့် သင်နှစ်သက်သလောက် တည်ငြိမ်အောင် ပြုလုပ်နိုင်သည်။ စာရွက်စာတမ်းတစ်ခု အင်တာနက်မှ ပျောက်ကွယ်သွားရခြင်း၏ တစ်ခုတည်းသော အကြောင်းအရင်းမှာ ဒိုမိန်းအမည်ကို ပိုင်ဆိုင်သည့် ကုမ္ပဏီသည် လုပ်ငန်းမှ နှုတ်ထွက်သွားခြင်း သို့မဟုတ် ဆာဗာကို ဆက်လက်လည်ပတ်ရန် မတတ်နိုင်တော့ခြင်းကြောင့် ဖြစ်သည်။ ဒါဆို ကမ္ဘာပေါ်မှာ ဘာကြောင့် ပျောက်နေတဲ့ လင့်ခ်တွေ အများကြီး ရှိနေတာလဲ။ အချို့က ရိုးရိုးရှင်းရှင်း ကြိုတွေးထားခြင်းမရှိ။ ဤသည်မှာ သင်ကြားနိုင်သော အကြောင်းရင်းအချို့ဖြစ်သည်-

ကျွန်ုပ်တို့သည် ဆိုက်ကို ပိုကောင်းစေရန် ပြင်ဆင်ဖွဲ့စည်းလိုက်ပါသည်။

URI အဟောင်းများသည် အလုပ်မလုပ်တော့ဟု သင်အမှန်တကယ်ထင်ပါသလား။ သို့ဆိုလျှင် သင်သည် ၎င်းတို့ကို ရွေးချယ်ရာတွင် အလွန်ညံ့ဖျင်းပါသည်။ နောက်အသစ်ဒီဇိုင်းအတွက် အသစ်များကို သိမ်းဆည်းရန် စဉ်းစားပါ။

ကျွန်ုပ်တို့တွင် ခေတ်မမီသောအရာများ၊ လျှို့ဝှက်ထားသောအရာများနှင့် သက်ဆိုင်နေသေးသည်များကို ခြေရာခံ၍မရသော အရာများစွာရှိသည်၊ ထို့ကြောင့် အားလုံးကို ပိတ်ထားရန် အကောင်းဆုံးဟု ကျွန်ုပ်တို့ ထင်မြင်ပါသည်။

ကိုယ်ချင်းစာလို့ ရပါတယ်။ W3C သည် ၎င်းတို့အား လူသိရှင်ကြားမထုတ်ပြန်မီ လျှို့ဝှက်ရေးဆိုင်ရာ စာရွက်စာတမ်းများကို ဂရုတစိုက် ခွဲခြမ်းစိပ်ဖြာရမည့် ကာလကို ဖြတ်သန်းခဲ့ရသည်။ ဆုံးဖြတ်ချက်ကို ကြိုတင်စဉ်းစားထားသင့်သည် - စာရွက်စာတမ်းတစ်ခုစီတွင် လက်ခံနိုင်သော စာဖတ်သူ၊ ဖန်တီးသည့်ရက်စွဲနှင့် သက်တမ်းကုန်ဆုံးရက်တို့ကို မှတ်တမ်းတင်ကြောင်း သေချာပါစေ။ ဤမက်တာဒေတာကို သိမ်းဆည်းပါ။

ဖိုင်တွေကို ရွှေ့ဖို့ လိုတယ်ဆိုတာ သိလိုက်ရတယ်...

ဤသည်မှာ သနားစရာအကောင်းဆုံး အကြောင်းပြချက်များထဲမှ တစ်ခုဖြစ်သည်။ ဝဘ်ဆာဗာများသည် သင့်အား အရာဝတ္ထုတစ်ခု၏ URI နှင့် ဖိုင်စနစ်ရှိ ၎င်း၏အမှန်တကယ်တည်နေရာကြား ဆက်နွယ်မှုကို ထိန်းချုပ်နိုင်စေသည်ဟု လူများစွာ မသိကြပါ။ URI အာကာသကို စိတ်ကူးစိတ်သန်း အာကာသတစ်ခုအဖြစ် စုံလင်စွာ ပုံဖော်ပါ။ ထို့နောက် ၎င်းကိုနားလည်ရန် သင်အမှန်တကယ်အသုံးပြုသည့် မည်သည့်အရာကိုမဆို လက်တွေ့ကျကျပုံဖော်ပါ။ ထို့နောက် ၎င်းကို ဝဘ်ဆာဗာသို့ သတင်းပို့ပါ။ သင့်ကိုယ်ပိုင် ဆာဗာအတိုအထွာများကိုပင် မှန်ကန်စေရန် သင်ရေးသားနိုင်သည်။

John က ဒီဖိုင်ကို မထိန်းသိမ်းတော့ဘူး၊ အခု Jane က လုပ်နေပါပြီ။

URI တွင် John ၏အမည်ဖြစ်ပါသလား။ မဟုတ်ဘူး၊ ဖိုင်က သူ့လမ်းညွှန်ထဲမှာပဲ ရှိပါသလား။ အင်း ဟုတ်ပါပြီ။

ယခင်က ၎င်းအတွက် CGI script ကို အသုံးပြုခဲ့သော်လည်း ယခုအခါတွင် binary ပရိုဂရမ်ကို အသုံးပြုထားသည်။

scripts များမှဖန်တီးထားသောစာမျက်နှာများသည် "cgibin" သို့မဟုတ် "cgi" ဧရိယာတွင်တည်ရှိသင့်သည်ဟူသောစိတ်ကူးတစ်ခုရှိသည်။ ၎င်းသည် သင့်ဝဘ်ဆာဗာကို သင်မည်ကဲ့သို့ လုပ်ဆောင်ပုံ၏ စက်ပြင်များကို ဖော်ထုတ်ပေးသည်။ သင် (အကြောင်းအရာကို သိမ်းဆည်းနေစဉ်) ယန္တရားကို သင်ပြောင်းလိုက်ပြီး အို - သင်၏ URI များအားလုံး ပြောင်းလဲသွားပါသည်။

ဥပမာအားဖြင့် အမျိုးသားသိပ္ပံဖောင်ဒေးရှင်း (NSF) ကိုကြည့်ပါ-

NSF အွန်လိုင်းစာရွက်စာတမ်းများ

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

စာရွက်စာတမ်းများကို စတင်ကြည့်ရှုသည့် ပထမစာမျက်နှာသည် နှစ်အနည်းငယ်အတွင်း တူညီမည်မဟုတ်ပါ။ cgi-bin, oldbrowse и pl ဤအရာအားလုံးသည် ကျွန်ုပ်တို့ မည်သို့လုပ်ဆောင်သည်နှင့် ပတ်သက်သည့် အချက်အလက်အနည်းငယ်ကို ပေးဆောင်သည်။ စာရွက်စာတမ်းတစ်ခုကို ရှာဖွေရန် စာမျက်နှာကို အသုံးပြုပါက၊ သင်ရရှိသည့် ပထမရလဒ်သည် တူညီသည်-

Cryptology and Coding Theory ဆိုင်ရာ အလုပ်အဖွဲ့၏ အစီရင်ခံစာ

http://www.nsf.gov/cgi-bin/getpub?nsf9814

စာရွက်စာတမ်းအညွှန်းစာမျက်နှာအတွက် html စာရွက်စာတမ်းကိုယ်တိုင်က ပိုကောင်းပေမယ့်၊

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

ဤနေရာတွင် အရက်ဆိုင်/1998 ခေါင်းစီးသည် 1998 စာရွက်စာတမ်း အမျိုးအစားခွဲခြားမှု အစီအစဉ်ဟောင်းကို အသက်ဝင်သည်ဟူသော အရိပ်အယောင်ကို နောင်တွင် မှတ်တမ်းပြုစုသည့် ဝန်ဆောင်မှုကို ပေးပါလိမ့်မည်။ စာရွက်စာတမ်းနံပါတ်များသည် 2098 တွင် ကွဲပြားနေသော်လည်း ဤ URI သည် တရားဝင်နေသေးမည်ဖြစ်ပြီး NSF သို့မဟုတ် မှတ်တမ်းကို ထိန်းသိမ်းမည့် အခြားအဖွဲ့အစည်းကို အနှောင့်အယှက်ပေးမည်မဟုတ်ဟု ကျွန်တော် တွေးကြည့်မိပါသည်။

URL များသည် အမြဲရှိနေသင့်သည်ဟု မထင်ခဲ့ဘဲ - URN များ ရှိပါသည်။

၎င်းသည် URN ဆွေးနွေးပွဲ၏ အဆိုးရွားဆုံး ဘေးထွက်ဆိုးကျိုးများထဲမှ တစ်ခု ဖြစ်နိုင်သည်။ ပိုမိုတည်မြဲသော namespace တွင် သုတေသနပြုမှုကြောင့် "URNs များအားလုံးကို ဖြေရှင်းပေးမည်" ဖြစ်သောကြောင့် အချို့သောလူများက လင့်ခ်များကို ချိတ်ဆွဲရန် ဂရုမစိုက်နိုင်ဟု ထင်ကြသည်။ မင်းက ဒီလူတွေထဲက တစ်ယောက်ဆိုရင် ငါ မင်းကို စိတ်ပျက်အောင် ထားပါရစေ။

ငါမြင်ဖူးတဲ့ URN အစီအမံအများစုဟာ မင်းရွေးချယ်တဲ့ရက်စွဲနဲ့ စာကြောင်းတစ်ကြောင်း ဒါမှမဟုတ် မင်းရွေးချယ်လိုက်တဲ့ စာကြောင်းတစ်ခုရဲ့နောက်မှာ အာဏာပိုင်အထောက်အထားတစ်ခုနဲ့တူပါတယ်။ ၎င်းသည် HTTP URI နှင့် အလွန်ဆင်တူသည်။ တစ်နည်းအားဖြင့် သင့်အဖွဲ့အစည်းသည် သက်တမ်းရှည် URN များကို ဖန်တီးနိုင်မည်ဟု သင်ထင်ပါက၊ သင်၏ HTTP URIs များအတွက် ၎င်းတို့ကို အသုံးပြုခြင်းဖြင့် ယခုသက်သေပြလိုက်ပါ။ သင်၏ URI မတည်မငြိမ်ဖြစ်စေသော HTTP ကိုယ်တိုင်၌ မည်သည့်အရာမျှ မရှိပါ။ မင်းရဲ့အဖွဲ့အစည်းသာ။ စာရွက်စာတမ်း URN ကို လက်ရှိ ဖိုင်အမည်နှင့် မြေပုံဆွဲထားသော ဒေတာဘေ့စ်တစ်ခု ဖန်တီးပြီး ဖိုင်များကို အမှန်တကယ် ပြန်လည်ရယူရန်အတွက် ဝဘ်ဆာဗာကို အသုံးပြုခွင့်ပေးလိုက်ပါ။

အကယ်၍ သင့်တွင် software အချို့ကို ဖန်တီးရန် အချိန်၊ ငွေနှင့် ချိတ်ဆက်မှုများ မရှိတော့ပါက၊ အောက်ပါ အကြောင်းပြချက်ကို သင်ဖော်ပြနိုင်သည်။

ကျွန်တော်တို့ လိုချင်ပေမယ့် မှန်ကန်တဲ့ ကိရိယာတွေ မရှိပါဘူး။

ဒါပေမယ့် မင်း ဒါကို ကိုယ်ချင်းစာနိုင်တယ်။ လုံးဝသဘောတူပါတယ်။ သင်လုပ်ဆောင်ရမည့်အရာမှာ အမြဲရှိနေသော URI ကို ချက်ချင်းခွဲခြမ်းစိတ်ဖြာပြီး သင့်လက်ရှိအမိုက်စားဖိုင်စနစ်တွင် သိမ်းဆည်းထားသည့်နေရာတိုင်းတွင် ဖိုင်ကို ပြန်ပို့ပေးရန်ဖြစ်သည်။ သင်သည် URI အားလုံးကို စစ်ဆေးချက်တစ်ခုအဖြစ် ဖိုင်တစ်ခုတွင် သိမ်းဆည်းထားလိုပြီး ဒေတာဘေ့စ်ကို အချိန်တိုင်း နောက်ဆုံးရနေအောင် ပြုလုပ်လိုသည်။ သင်သည် မတူကွဲပြားသောဗားရှင်းနှင့် စာရွက်စာတမ်း၏ ဘာသာပြန်ဆိုမှုများကြား ဆက်စပ်မှုကို ထိန်းသိမ်းထားလိုပြီး မတော်တဆအမှားကြောင့် ဖိုင်ပျက်စီးသွားခြင်းမရှိကြောင်း သေချာစေရန် သီးခြားလွတ်လပ်သော checksum မှတ်တမ်းကိုလည်း ထိန်းသိမ်းထားလိုပါသည်။ ထို့အပြင် ဝဘ်ဆာဗာများသည် ဤအင်္ဂါရပ်များဖြင့် ကွက်လပ်မှ ထွက်မလာပါ။ စာရွက်စာတမ်းအသစ်တစ်ခုကို ဖန်တီးလိုသောအခါ၊ သင်၏အယ်ဒီတာက သင့်အား URI ကို သတ်မှတ်ရန် တောင်းဆိုသည်။

URI ကို မပြောင်းဘဲ URI space တွင် ပိုင်ဆိုင်မှု၊ စာရွက်စာတမ်းဝင်ရောက်ခွင့်၊ သိမ်းဆည်းမှုအဆင့် လုံခြုံရေးစသည်ဖြင့် ပြောင်းလဲနိုင်ရပါမည်။

ဆိုးလွန်းတယ်။ ဒါပေမယ့် အခြေအနေကို ပြင်ပေးမယ်။ W3C တွင်၊ ကျွန်ုပ်တို့သည် ဗားရှင်းများကို ခြေရာခံသည့် Jigedit (Jigsaw တည်းဖြတ်ဆာဗာ) လုပ်ဆောင်ချက်ကို အသုံးပြုပြီး စာရွက်စာတမ်းဖန်တီးမှု scripts များဖြင့် စမ်းသပ်ပါသည်။ သင်ကိရိယာများ၊ ဆာဗာများနှင့် ဖောက်သည်များကို တီထွင်ပါက ဤပြဿနာကို အာရုံစိုက်ပါ။

ဤအကြောင်းပြချက်အပါအဝင် W3C စာမျက်နှာများစွာနှင့်လည်း သက်ဆိုင်သည်- ငါပြောသလို လုပ်ပါ၊ ငါလုပ်သလိုဘဲ။

ငါဘာကြောင့်ဂရုစိုက်ရမှာလဲ?

သင့်ဆာဗာပေါ်ရှိ URI ကို သင်ပြောင်းသောအခါ၊ URI ဟောင်းသို့ လင့်ခ်များရှိနေမည့်သူအား လုံးလုံးပြောပြနိုင်မည်မဟုတ်ပေ။ ၎င်းတို့သည် ပုံမှန်ဝဘ်စာမျက်နှာများမှ လင့်ခ်များ ဖြစ်နိုင်သည်။ သင့်စာမျက်နှာကို မှတ်သားပါ။ URI သည် သူငယ်ချင်းတစ်ဦးထံ စာတစ်စောင်၏ အနားသတ်တွင် ဖြန့်ကျက်ထားနိုင်သည်။

တစ်စုံတစ်ယောက်သည် လင့်ခ်တစ်ခုကို လိုက်နာပြီး ၎င်းသည် ပျက်သွားသောအခါ၊ ၎င်းတို့သည် များသောအားဖြင့် ဆာဗာပိုင်ရှင်အပေါ် ယုံကြည်မှု ဆုံးရှုံးသွားတတ်သည်။ သူ့ရည်မှန်းချက်ကို မအောင်မြင်နိုင်ခြင်းကြောင့် စိတ်ပိုင်းဆိုင်ရာရော ရုပ်ပိုင်းဆိုင်ရာပါ စိတ်ပျက်မိပါသည်။

လူတော်တော်များများက ပျက်နေတဲ့ လင့်ခ်တွေအကြောင်း တစ်ချိန်လုံး ညည်းညူကြပြီး ပျက်စီးသွားတာ သိသာထင်ရှားမယ်လို့ မျှော်လင့်ပါတယ်။ စာရွက်စာတမ်းပျောက်ကွယ်သွားသော ဆာဗာထိန်းသိမ်းသူအပေါ် ဂုဏ်သိက္ခာပိုင်းဆိုင်ရာ ထိခိုက်မှုများလည်း သိသာထင်ရှားမည်ဟု မျှော်လင့်ပါသည်။

ဒါဆို ဘာလုပ်ရမလဲ။ URI ဒီဇိုင်း

၂ နှစ်၊ အနှစ် ၂၀ အတွင်း၊ အနှစ် ၂၀၀ အတွင်း အသုံးပြုနိုင်သော URI များကို ခွဲဝေပေးရန် ဝဘ်မာစတာ၏ တာဝန်ဖြစ်သည်။ ယင်းသည် စဉ်းစားတွေးခေါ်မှု၊ အဖွဲ့အစည်းနှင့် ဆုံးဖြတ်မှု လိုအပ်သည်။

၎င်းတို့တွင် အချက်အလက် တစ်စုံတစ်ရာ ပြောင်းလဲပါက URI သည် ပြောင်းလဲပါသည်။ ၎င်းတို့ကို သင်မည်ကဲ့သို့ ဒီဇိုင်းဆွဲရန် အလွန်အရေးကြီးပါသည်။ (URI ဒီဇိုင်းက ဘာလဲ၊ URI ကို ဒီဇိုင်းဆွဲဖို့ လိုသလား။ ဟုတ်ကဲ့၊ အဲဒါကို စဉ်းစားသင့်ပါတယ်)။ ဒီဇိုင်းသည် အခြေခံအားဖြင့် URI တွင် မည်သည့်အချက်အလက်ကိုမဆို ချန်ထားခဲ့ခြင်းကို ဆိုလိုသည်။

စာရွက်စာတမ်းကိုဖန်တီးခဲ့သည့်ရက်စွဲ - URI ကိုထုတ်ပေးသည့်ရက်စွဲ - သည် မည်သည့်အခါမျှ ပြောင်းလဲမည်မဟုတ်ပါ။ စနစ်သစ်ကို အသုံးပြုသည့် မေးခွန်းများကို စနစ်ဟောင်းကို အသုံးပြုသူများနှင့် ပိုင်းခြားရန် အလွန်အသုံးဝင်ပါသည်။ ဤသည်မှာ URI ဖြင့် စတင်ရန် ကောင်းမွန်သော နေရာဖြစ်သည်။ အကယ်၍ စာရွက်စာတမ်းသည် အနာဂတ်တွင် သက်ဆိုင်ရာဖြစ်မည်ဆိုပါက၊ ၎င်းသည် ကောင်းမွန်သောအစပြုမှုဖြစ်သည်။

တစ်ခုတည်းသောခြွင်းချက်မှာ အဖွဲ့အစည်းတစ်ခုလုံးအတွက် သို့မဟုတ် ၎င်း၏ကြီးမားသောအစိတ်အပိုင်းအတွက် ရည်ရွယ်ချက်ရှိရှိ "နောက်ဆုံးပေါ်" ဗားရှင်းဖြစ်သော စာမျက်နှာတစ်ခုဖြစ်သည်။

http://www.pathfinder.com/money/moneydaily/latest/

ဒါက Money မဂ္ဂဇင်းရဲ့ နောက်ဆုံးထွက် Money Daily ကော်လံဖြစ်ပါတယ်။ ဤ URI တွင် ရက်စွဲတစ်ခုအတွက် မလိုအပ်သည့် အဓိကအကြောင်းရင်းမှာ မှတ်တမ်းကို အသက်သာလွန်စေမည့် URI ကို သိမ်းဆည်းရန် အကြောင်းမရှိခြင်းကြောင့်ဖြစ်သည်။ Money Daily ၏ သဘောတရားသည် ငွေပျောက်ဆုံးသွားသောအခါတွင် ပျောက်ကွယ်သွားမည်ဖြစ်သည်။ အကြောင်းအရာသို့ လင့်ခ်ချိတ်လိုပါက၊ မော်ကွန်းတိုက်တွင် သီးခြား လင့်ခ်ချိတ်သင့်သည်-

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(ကြည့်ကောင်းပါသည်။ "ငွေ" သည် pathfinder.com ၏ ဘဝတစ်လျှောက်လုံး တူညီသည့်အရာဟု ယူဆပါသည်။ "98" နှင့် မလိုအပ်သော ".html" တစ်ခု ထပ်တူရှိနေသော်လည်း အခြားမဟုတ်ပါက အားကောင်းသော URI နှင့်တူပါသည်။

ဘာကို ဖယ်ထားရမလဲ

အားလုံး! ဖန်တီးသည့်ရက်မှလွဲ၍ URI တွင် မည်သည့်အချက်အလက်ကိုမဆို ထည့်သွင်းခြင်းသည် တစ်နည်းမဟုတ်တစ်နည်း ပြဿနာကို တောင်းဆိုနေပါသည်။

• Имя автора. ဗားရှင်းအသစ်များ ရနိုင်သည်နှင့်အမျှ ရေးသားပိုင်ခွင့် အပြောင်းအလဲ ရှိနိုင်ပါသည်။ လူတွေက အဖွဲ့အစည်းတွေကို စွန့်ခွာပြီး တခြားသူတွေကို ပေးကမ်းကြတယ်။
• ဘာသာရပ်. အလွန်ခက်ခဲသည်။ အစပိုင်းမှာ အမြဲကြည့်ကောင်းပေမယ့် အံ့သြစရာကောင်းလောက်အောင် မြန်မြန်ဆန်ဆန် ပြောင်းလဲသွားပါတယ်။ ဒီအကြောင်းကို အောက်မှာ ဆက်ပြောပါမယ်။
• အဆင့်အတန်း. "အဟောင်း"၊ "မူကြမ်း" ကဲ့သို့သော လမ်းညွှန်များ "နောက်ဆုံးပေါ်" နှင့် "အေး" ကို ဖော်ပြခြင်းမပြုဘဲ ဖိုင်စနစ်အားလုံးတွင် ပေါ်လာပါသည်။ စာရွက်စာတမ်းများသည် အခြေအနေပြောင်းသည် - မဟုတ်ပါက မူကြမ်းများဖန်တီးရာတွင် အဓိပ္ပါယ်ရှိမည်မဟုတ်ပါ။ စာရွက်စာတမ်း၏ နောက်ဆုံးဗားရှင်းသည် ၎င်း၏အခြေအနေ မည်သို့ပင်ရှိစေကာမူ တည်မြဲနေစေမည့် အထောက်အထားတစ်ခု လိုအပ်ပါသည်။ အဆင့်အတန်းကို နာမည်နဲ့ မထားပါနဲ့။
• လက်လှမ်းမီသည်. W3C တွင်၊ ကျွန်ုပ်တို့သည် ဝဘ်ဆိုက်ကို ဝန်ထမ်းများ၊ အဖွဲ့ဝင်များနှင့် အများသူငှာအတွက် အပိုင်းများခွဲထားသည်။ ဤအရာသည် ကောင်းမွန်သော်လည်း၊ စာရွက်စာတမ်းများသည် ဝန်ထမ်းများမှ အဖွဲ့၏ အကြံဉာဏ်များအဖြစ် စတင်သည်၊ အဖွဲ့ဝင်များနှင့် ဆွေးနွေးပြီးနောက် အများသူငှာ အသိပညာများ ဖြစ်လာသည်။ စာတမ်းတစ်ခုကို ကျယ်ကျယ်ပြန့်ပြန့် ဆွေးနွေးရန် ဖွင့်လိုက်တိုင်း၊ ၎င်းနှင့် ဆက်စပ်နေသော လင့်ခ်ဟောင်းများ ပျက်သွားလျှင် အမှန်ပင် ရှက်စရာပင်။ ယခု ကျွန်ုပ်တို့သည် ရိုးရှင်းသော ရက်စွဲကုဒ်တစ်ခုသို့ ဆက်သွားပါမည်။
• ဖိုင်တိုးချဲ့မှု. အလွန်အဖြစ်များသော ဖြစ်စဉ်တစ်ခုဖြစ်သည်။ "cgi"၊ ".html" ပင်လျှင် အနာဂတ်တွင် ပြောင်းလဲပါမည်။ သင်သည် ဤစာမျက်နှာအတွက် HTML ကို အနှစ် 20 အတွင်း မသုံးဖြစ်နိုင်သော်လည်း ၎င်းနှင့်ပတ်သက်သည့် လင့်ခ်များသည် ယနေ့အချိန်အထိ အလုပ်ဖြစ်နေဆဲဖြစ်သည်။ W3C ဆိုက်ရှိ Canonical လင့်ခ်များသည် တိုးချဲ့မှုကို အသုံးမပြုပါ (ဘယ်လိုလုပ်ပြီးပြီလဲ။).
• Software ယန္တယား. URI တွင်၊ "cgi", "exec" နှင့် "ကျွန်ုပ်တို့အသုံးပြုနေသော software ကိုကြည့်ပါ" ဟုအော်သော အခြားအသုံးအနှုန်းများကိုရှာပါ။ Perl CGI ဇာတ်ညွှန်းများရေးရာတွင် ၎င်းတို့၏ဘဝတစ်ခုလုံးကို ကုန်ဆုံးလိုပါသလား။ မရှိဘူးလား? ထို့နောက် .pl extension ကို ဖယ်ရှားပါ။ ၎င်းကိုပြုလုပ်ပုံနှင့်ပတ်သက်၍ ဆာဗာလက်စွဲကိုဖတ်ပါ။
• ဒစ်ခ်အမည်။ စလာသည်! ဒါပေမယ့် ဒါကို မြင်ဖူးတယ်။

ထို့ကြောင့် ကျွန်ုပ်တို့၏ဆိုက်မှ အကောင်းဆုံးဥပမာမှာ ရိုးရိုးရှင်းရှင်းဖြစ်သည်။

http://www.w3.org/1998/12/01/chairs

... W3C Chairs အစည်းအဝေးမှတ်တမ်းများ။

ခေါင်းစဉ်များနှင့် ခေါင်းစဉ်အလိုက် အမျိုးအစားခွဲခြင်း။

ရှောင်ရန်အခက်ခဲဆုံးအရာများထဲမှ တစ်ခုဖြစ်သောကြောင့် ဤအန္တရာယ်နှင့် ပတ်သက်၍ အသေးစိတ်ရှင်းပြပါမည်။ ပုံမှန်အားဖြင့်၊ ၎င်းတို့လုပ်ဆောင်သော အလုပ်အားဖြင့် သင့်စာရွက်စာတမ်းများကို အမျိုးအစားခွဲသောအခါတွင် အကြောင်းအရာများသည် URI တွင် အကျုံးဝင်ပါသည်။ ဒါပေမယ့် ဒီပြိုကွဲမှုက အချိန်နဲ့အမျှ ပြောင်းလဲသွားမှာပါ။ နယ်မြေအမည်များ ပြောင်းလဲသွားပါမည်။ W3C တွင် ကျွန်ုပ်တို့သည် MarkUP သို့ Markup သို့ပြောင်းပြီးနောက် ကဏ္ဍ၏အမှန်တကယ်အကြောင်းအရာကို ထင်ဟပ်စေရန် HTML သို့ ပြောင်းလဲလိုခဲ့သည်။ ထို့အပြင်၊ မကြာခဏ ပြန့်ကားသော namespace ရှိသည်။ အနှစ် 100 မှာ ဘာကိုမှ ပြန်မသုံးချင်တော့တာ သေချာလား။ ကျွန်ုပ်တို့၏ တိုတောင်းသောသက်တမ်းတွင် ဥပမာ "History" နှင့် "Style Sheets" ကို ပြန်လည်အသုံးပြုလိုပါသည်။

ဝဘ်ဆိုက်တစ်ခုအား စုစည်းရန် ဆွဲဆောင်မှုရှိသော နည်းလမ်းတစ်ခု—နှင့် ဝဘ်တစ်ခုလုံးအပါအဝင် မည်သည့်အရာကိုမဆို စုစည်းရန် အမှန်တကယ် ဆွဲဆောင်မှုရှိသော နည်းလမ်းတစ်ခုဖြစ်သည်။ ၎င်းသည် ကောင်းမွန်သော ကာလလတ်ဖြေရှင်းချက်ဖြစ်သော်လည်း ရေရှည်တွင် ဆိုးရွားသော ချို့ယွင်းချက်ရှိသည်။

အကြောင်းတရား၏ တစ်စိတ်တစ်ပိုင်းသည် ဒဿန၏ အဓိပ္ပါယ်တွင် တည်ရှိသည်။ ဘာသာစကားတစ်ခုရှိ စကားလုံးတိုင်းသည် အစုအဝေးပြုလုပ်ရန် အလားအလာရှိသော ပစ်မှတ်ဖြစ်ပြီး လူတစ်ဦးစီသည် ၎င်းကို ဆိုလိုသည့် အယူအဆကွဲပြားနိုင်သည်။ အဖွဲ့အစည်းများကြားရှိ ဆက်ဆံရေးများသည် သစ်ပင်ထက် ဝဘ်တစ်ခုနှင့် ပိုတူသောကြောင့်၊ ဝဘ်နှင့်သဘောတူသူများသည်ပင် သစ်ပင်၏ မတူညီသောကိုယ်စားပြုမှုကို ရွေးချယ်နိုင်သည်။ ဤအရာများသည် ယေဘူယျအဖြေတစ်ခုအဖြစ် အထက်အောက်ခွဲခြားခြင်း၏အန္တရာယ်များနှင့်ပတ်သက်ပြီး ကျွန်ုပ်၏ (မကြာခဏ ထပ်ခါတလဲလဲ) ယေဘူယျရှုမြင်ချက်များဖြစ်သည်။

တကယ်တော့၊ သင် URI တွင် ခေါင်းစဉ်အမည်တစ်ခုကို အသုံးပြုသောအခါ၊ သင်သည် အမျိုးအစားခွဲခြားမှုအချို့ကို သင်ကိုယ်တိုင်လုပ်ဆောင်နေပါသည်။ နောင်တွင် သင်သည် အခြားရွေးချယ်မှုတစ်ခုကို နှစ်သက်လိမ့်မည်ဖြစ်နိုင်သည်။ ထို့နောက် URI သည် ချိုးဖောက်ခံရနိုင်ချေရှိသည်။

URI ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ဘာသာရပ်နယ်ပယ်တစ်ခုကို အသုံးပြုရခြင်းအကြောင်းရင်းမှာ URI နေရာ၏ အပိုင်းခွဲများအတွက် တာဝန်ကို အများအားဖြင့် လွှဲအပ်ထားခြင်းကြောင့်ဖြစ်ပြီး၊ ထို့နောက် အဆိုပါနေရာခွဲအတွက် တာဝန်ရှိသည့် အဖွဲ့အစည်း၏အမည်ကို သင်လိုအပ်ပါသည်။ ၎င်းသည် အဖွဲ့အစည်းဖွဲ့စည်းပုံနှင့် ချိတ်ဆက်ထားသော URI ဖြစ်သည်။ နောက်ထပ် (ဘယ်) URI ကို ရက်စွဲတစ်ခုဖြင့် ကာကွယ်ထားမှသာ ဘေးကင်းနိုင်သည်- 1998/pics သည် "1998 တွင် ပုံများဖြင့် ကျွန်ုပ်တို့ ဆိုလိုသည်" အစား "1998 တွင် ကျွန်ုပ်တို့ ပြုလုပ်ခဲ့သည့် pics" ထက် သင့်ဆာဗာအတွက် "ပုံများ" ကို ဆိုလိုပေမည်။

ဒိုမိန်းအမည်ကို မမေ့ပါနှင့်

၎င်းသည် URI ရှိလမ်းကြောင်းနှင့်သာမက ဆာဗာအမည်နှင့်လည်း သက်ဆိုင်ကြောင်း သတိရပါ။ သင့်တွင် မတူညီသော အရာများအတွက် သီးခြားဆာဗာများရှိပါက၊ လင့်များစွာကို မဖျက်ဆီးဘဲ ဤဌာနခွဲသည် ပြောင်းလဲရန် မဖြစ်နိုင်ကြောင်း သတိရပါ။ အချို့သော ဂန္တဝင် "ကျွန်ုပ်တို့ ယနေ့အသုံးပြုနေသည့် ဆော့ဖ်ဝဲကိုကြည့်ပါ" အမှားများသည် ဒိုမိန်းအမည် "cgi.pathfinder.com", "secure", "lists.w3.org" ဖြစ်သည်။ ၎င်းတို့သည် ဆာဗာစီမံခန့်ခွဲမှုကို ပိုမိုလွယ်ကူစေရန် ဒီဇိုင်းထုတ်ထားသည်။ ဒိုမိန်းတစ်ခုသည် သင့်ကုမ္ပဏီရှိ ဌာနခွဲတစ်ခု၊ စာရွက်စာတမ်းအခြေအနေ၊ ဝင်ရောက်မှုအဆင့် သို့မဟုတ် လုံခြုံရေးအဆင့်ကို ကိုယ်စားပြုသည်ဖြစ်စေ၊ စာရွက်စာတမ်းအမျိုးအစားများစွာအတွက် ဒိုမိန်းအမည်တစ်ခုထက်ပို၍ အသုံးမပြုမီ အလွန်သတိထားပါ။ လမ်းကြောင်းလွှဲခြင်းနှင့် ပရောက်စီထုတ်ခြင်းတို့ကို အသုံးပြု၍ မြင်နိုင်သော ဝဘ်ဆာဗာတစ်ခုတည်းတွင် ဝဘ်ဆာဗာများစွာကို သင်ဝှက်ထားနိုင်ကြောင်း သတိရပါ။

အိုး၊ ပြီးတော့ မင်းရဲ့ domain name အကြောင်းကိုလည်း စဉ်းစားပါ။ ထုတ်ကုန်လိုင်းများပြောင်းပြီး ဆပ်ပြာပြုလုပ်ခြင်းကို ရပ်လိုက်ပြီးနောက် သင်သည် soap.com အဖြစ် မရည်ညွှန်းလိုတော့ပါ (ယခုအချိန်တွင် soap.com ကို ပိုင်ဆိုင်သူတိုင်းအား တောင်းပန်အပ်ပါသည်။)

ကောက်ချက်

URI ကို 2၊ 20၊ 200 သို့မဟုတ် 2000 နှစ်များအထိ ထိန်းသိမ်းခြင်းသည် ထင်သလောက် မလွယ်ကူသည်မှာ ထင်ရှားပါသည်။ သို့သော်၊ အင်တာနက်တစ်ခွင်လုံးတွင်၊ ဝဘ်မာစတာများသည် ဤတာဝန်ကို အနာဂတ်တွင် ၎င်းတို့အတွက် အမှန်တကယ်ခက်ခဲစေမည့် ဆုံးဖြတ်ချက်များချနေကြသည်။ မကြာခဏဆိုသလို ၎င်းတို့သည် လက်ရှိအချိန်တွင်သာ အကောင်းဆုံးဝဘ်ဆိုက်ကို တင်ပြရန် အလုပ်ဖြစ်သည့် ကိရိယာများကို အသုံးပြုသောကြောင့်ဖြစ်သည် - အရာအားလုံးပြောင်းလဲသွားသည့်အခါ လင့်ခ်များ မည်သို့ဖြစ်လာမည်ကို မည်သူမျှ အကဲဖြတ်ခြင်းမရှိပေ။ သို့သော်၊ ဤနေရာတွင် အဓိကအချက်မှာ များစွာ၊ များစွာသော အရာများ ပြောင်းလဲနိုင်သည်၊ သင်၏ URI များသည် တူညီနေနိုင်သည်၊ ဖြစ်သင့်သည်။ ၎င်းတို့ကို သင်မည်ကဲ့သို့ဖန်တီးမည်ကို သင်စဉ်းစားသည့်အခါမှသာ ဖြစ်နိုင်သည်။

ကိုလည်းကြည့်ပါ .:

• Jakob Nielsen ၏ တူညီသောအကြောင်းအရာအပေါ်

ဖြည့်စွက်

ဖိုင် extensions တွေကို ဘယ်လိုဖယ်ရှားမလဲ...

...လက်ရှိ ဖိုင်အခြေခံ ဝဘ်ဆာဗာရှိ URI မှလား။

ဥပမာအားဖြင့် သင်သည် Apache ကိုအသုံးပြုပါက၊ အကြောင်းအရာညှိနှိုင်းရန် ၎င်းကို သင် configure လုပ်နိုင်ပါသည်။ ဖိုင်တိုးချဲ့မှု (ဥပမာ .png) ကို ဖိုင်တစ်ခုသို့ သိမ်းဆည်းပါ (ဥပမာ။ mydog.png) သို့သော် ၎င်းမပါဘဲ ဝဘ်အရင်းအမြစ်တစ်ခုသို့ လင့်ခ်ချိတ်နိုင်သည်။ ထို့နောက် Apache သည် ထိုအမည်နှင့် မည်သည့် extension ဖြင့်မဆို ဖိုင်အားလုံးအတွက် လမ်းညွှန်ကို စစ်ဆေးပြီး သတ်မှတ်မှ အကောင်းဆုံးကို ရွေးချယ်နိုင်သည် (ဥပမာ၊ GIF နှင့် PNG)။ မတူကွဲပြားသော ဖိုင်အမျိုးအစားများကို မတူညီသော လမ်းညွှန်များတွင် ထည့်ထားရန် မလိုအပ်ပါ၊ အမှန်မှာ ၎င်းကို ပြုလုပ်ပါက အကြောင်းအရာ ကိုက်ညီမှု ရှိမည်မဟုတ်ပါ။

• အကြောင်းအရာညှိနှိုင်းရန် သင့်ဆာဗာကို စနစ်ထည့်သွင်းပါ။
• တိုးချဲ့မှုမပါဘဲ URI များသို့ အမြဲချိတ်ဆက်ပါ။

တိုးချဲ့မှုများပါရှိသော လင့်ခ်များသည် အလုပ်မဖြစ်သေးသော်လည်း လက်ရှိနှင့် အနာဂတ်တွင် ရရှိနိုင်သော အကောင်းဆုံးဖော်မတ်ကို သင့်ဆာဗာမှ ရွေးချယ်ခြင်းမှ တားဆီးမည်ဖြစ်သည်။

(တကယ်တော့, mydog, mydog.png и mydog.gif - မှန်ကန်သော ဝဘ်အရင်းအမြစ်များ၊ mydog universal content type အရင်းအမြစ်တစ်ခုဖြစ်ပြီး၊ mydog.png и mydog.gif — သီးခြား အကြောင်းအရာအမျိုးအစားတစ်ခု၏ အရင်းအမြစ်များ)။

သင့်ကိုယ်ပိုင်ဝဘ်ဆာဗာကိုရေးသားနေပါက၊ အကန့်အသတ်မရှိသောဒေတာဘေ့စ်ကြီးထွားမှုကိုသတိထားသော်လည်း၊ အကန့်အသတ်မရှိသောဒေတာဘေ့စ်ကြီးထွားမှုကိုသတိထားသော်လည်း၊ အမြဲရှိနေသောသတ်မှတ်သူများကို ၎င်းတို့၏လက်ရှိပုံစံနှင့်တွဲဖက်ရန် ဒေတာဘေ့စ်ကိုအသုံးပြုခြင်းသည် ကောင်းပါတယ်။

The Board of Shame - Story 1: Channel 7

1999 ခုနှစ်အတွင်းမှာ စာမျက်နှာပေါ်က နှင်းတွေကြောင့် ကျောင်းပိတ်ရတာကို ကျွန်တော် ခြေရာခံခဲ့တယ်။ http://www.whdh.com/stormforce/closings.shtml. တီဗီဖန်သားပြင်၏အောက်ခြေတွင် အချက်အလက်များပေါ်လာရန် စောင့်မနေပါနှင့်။ ၎င်းကို ကျွန်ုပ်၏ ပင်မစာမျက်နှာမှ ချိတ်ဆက်ထားပါသည်။ 2000 ခုနှစ်ရဲ့ ပထမဆုံး နှင်းမုန်တိုင်းကြီး ရောက်ရှိလာပြီး စာမျက်နှာကို စစ်ဆေးကြည့်မိပါတယ်။ အဲဒီမှာ ရေးထားတယ်၊

- ၏အဖြစ်။
လောလောဆယ် ဘာမှ မပိတ်ပါဘူး။ ရာသီဥတုသတိပေးချက်များရှိပါက ကျေးဇူးပြု၍ ပြန်လာပါ။

ဒီလောက်ပြင်းထန်တဲ့ မုန်တိုင်းမဖြစ်နိုင်ပါဘူး။ ရက်စွဲပျောက်နေတာ ရယ်စရာကောင်းတယ်။ သို့သော် အကယ်၍ သင်သည် ဆိုက်၏ ပင်မစာမျက်နှာသို့ သွားပါက၊ စာမျက်နှာသို့ ဦးတည်သည့် “ကျောင်းများပိတ်” ခလုတ်ကြီးတစ်ခု ပေါ်လာလိမ့်မည်။ http://www.whdh.com/stormforce/ ပိတ်ထားသောကျောင်းများစာရင်းရှည်များနှင့်အတူ။

စာရင်းရယူခြင်းအတွက် ၎င်းတို့သည် စနစ်အား ပြောင်းလဲနိုင်သော်လည်း URI ကို ပြောင်းလဲရန် မလိုအပ်ပါ။

Board of Shame - Story 2: Microsoft Netmeeting

အင်တာနက်ပေါ်တွင် မှီခိုအားထားမှု ကြီးထွားလာသည်နှင့်အမျှ ထုတ်လုပ်သူ၏ဝဘ်ဆိုဒ်သို့ လင့်ခ်များကို အပလီကေးရှင်းများတွင် ထည့်သွင်းနိုင်စေရန် အကြံဉာဏ်တစ်ခု ထွက်ပေါ်လာခဲ့သည်။ ၎င်းကို အများအပြားအသုံးပြုပြီး အလွဲသုံးစားလုပ်ထားသော်လည်း URL ကို ပြောင်းလဲ၍မရပါ။ အခြားနေ့တွင် ကျွန်ုပ်သည် Microsoft Netmeeting 2/Web/Microsoft Web/Free ပစ္စည်းမီနူးရှိ Help/Microsoft မှ လင့်ခ်တစ်ခုကို စမ်းကြည့်ရာ 404 error ရရှိခဲ့သည် - ဆာဗာမှ တုံ့ပြန်မှုမတွေ့ပါ။ ပြင်ပြီးသားဖြစ်နိုင်တယ်...

© 1998 Tim BL

သမိုင်းမှတ်စု- 20 ရာစုနှောင်းပိုင်းတွင်၊ ဤအရာကို ရေးသားသောအခါ၊ "အေး" သည် အထူးသဖြင့် လူငယ်များကြားတွင်၊ ဖက်ရှင်ကျကျ၊ အရည်အသွေး သို့မဟုတ် သင့်လျော်မှုတို့ကို ညွှန်ပြသော နှစ်သက်မှုတစ်ခုဖြစ်သည်။ အလျင်စလိုအားဖြင့် URI လမ်းကြောင်းကို အသုံးဝင်မှု သို့မဟုတ် ကြာရှည်ခံခြင်းထက် "အေးမြခြင်း" အတွက် ရွေးချယ်လေ့ရှိသည်။ ဤပို့စ်သည် အမိုက်စားရှာဖွေမှုနောက်ကွယ်မှ စွမ်းအင်ကို ပြန်လည်ညွှန်းရန် ကြိုးပမ်းမှုတစ်ခုဖြစ်သည်။

source: www.habr.com