প্লাসটি মেলটো: হাইপারলিংকগুলিতে এনকোড করা উচিত?

Question

কোনও মেইলটো হাইপারলিঙ্কে কোনও ঠিকানা ট্যাগ (ওরফে সাব-ঠিকানা) সহ কোনও ইমেল ঠিকানা স্থাপন করার সময় …

<a href="mailto:[e-mail]">mail us now!</a>

… ইমেলের প্লাসটি কি ইউআরএল এনকোড করা উচিত?

<a href="mailto:[e-mail]">mail us now!</a>

আমি এটি বের করতে পারি না, এবং ডকুমেন্টেশনগুলি বিরোধী। আমাদের আসল ওয়ার্ল্ড টেস্টগুলি মিশ্র ফলাফলও এনেছে, এটি আরও বিভ্রান্তিকর করে তুলেছে।

Comments

আপনার বাস্তব-বিশ্বের পরীক্ষার পদ্ধতি এবং ফলাফল সম্পর্কে আপনি আরও নির্দিষ্ট হতে পারেন? কিছু ইমেল ক্লায়েন্ট / পরিষেবাগুলি এটি সঠিকভাবে চিকিত্সা করে এবং অন্যেরা দম বন্ধ করে দেয়? আপনি আরো নির্দিষ্ট হতে পারে?

— ব্রাইসন

@ ব্রাইসন আমি জানি "জিমেইল ব্যবহার করে প্রেরণ করুন" ক্রোম এক্সটেনশনের মেলটোলে আনঙ্কডবিহীন প্লাসের সমস্যা রয়েছে: উদাহরণস্বরূপ, তবে সম্ভবত এটি একটি বাগ।

— জেফ আতউড

ক্রোমের সাথে যে কেউ কাজ করে কেবল এটি ব্যবহার করুন।

— হার্ডওয়্যারগুই

Answer 1

প্লাসটি ইউআরএলগুলিতে স্পেসগুলি এনকোড করতে ব্যবহৃত হয়, এইচটিএমএলে নয় এবং এসএমটিপিতে (আরএফসি 2821) নয়। তবে যেহেতু mailto:[e-mail]একটি ইউআরআই (এটির একটি প্রোটোকল, প্রোটোকল বিভাজক এবং প্রোটোকল ঠিকানা রয়েছে) তাই এটি ইউআরআই হিসাবে বিবেচনা করা উচিত এবং এটি শতাংশ এনকোড করা উচিত ।

অতএব, এনকোডযুক্ত উপস্থাপনাটি সঠিকভাবে সমাধান করা এবং যথাসম্ভব এটিকে ডিকোড করা ক্লায়েন্টের হাতে। মাইক্রোসফ্টের আধিকারিক এই বিষয়টি গ্রহণ করবেন ।

আপনার মেলটোতে ইউআরএল এনকোডিং প্রয়োগ করা উচিত: ইমেল ঠিকানার অক্ষরগুলি ইউআরআই সংরক্ষিত থাকলে এইচটিএমএল এমবেড করা URL গুলি। এটি নিশ্চিত করে যে আপনি সঠিক কাজটি করছেন। কোথা থেকে ইউআরআই গ্রহণ করা হয়েছে তা যথাযথভাবে ইউআরআই ডিকোড করার পক্ষে এটি ক্লায়েন্টের। হ্যাঁ, [e-mail]একটি খুব বৈধ ইমেল; হ্যাঁ [e-mail]বৈধ। হ্যাঁ এই দুটি আলাদা, তবে তাদের সাথে আলাদা আচরণ করা হবে কিনা তা ক্লায়েন্টের উপর নির্ভর করে ...

আপনি পূর্বে উল্লেখ করেছেন যে, সমস্ত ক্লায়েন্ট সঠিকভাবে এটি রেন্ডার করে না। আমি আপনার সর্বাধিক সম্ভাব্য ক্লায়েন্ট (জিমেইল? ব্রাউজার ভিত্তিক ক্লায়েন্ট? আউটলুক?) সন্ধান করার পরামর্শ দিচ্ছি যে আপনার ব্যবহারকারীরা সেই ক্লায়েন্টটি কী করবে এবং তা করবে। আপনি বলেছিলেন আপনি জিমেইলে পরীক্ষা করেছেন? আপনি এটি পরীক্ষা কিভাবে? একটি "ব্রাউজার ভিত্তিক মেইলটো: ক্লায়েন্ট (যেমন ফায়ারফক্স এবং জিমেইল অফারের অ্যাড-অনস) সহ ইউআরআই সম্ভবত ডিকোডড হয় না (যেমনটি হওয়া উচিত)।

Comments

কারও কাছে কোথায় কাজ করে তার কোনও আসল তথ্য রয়েছে?

— ওয়েজ ফারলং

মাইক্রোসফ্ট affirms যা কাজ করে তার একটি নির্দিষ্ট নোট আমি দিয়েছিলাম ...

— jcolebrand

এটি স্পট অন। Gmail এগুলি সঠিকভাবে পরিচালনা করে না, তবে গুগল ব্যবহারকারী বাগ রিপোর্টগুলিকে উপেক্ষা করার কারণে আপনি এটি সম্পর্কে তেমন কিছু করতে পারেন না।

— ম্যাথু

আপনার যদি ইউআরআইতে এনকোড +থাকে তবে এগুলি এনকোড @করাও দরকার কারণ এটিও একটি সংরক্ষিত চরিত্র। আপনি যদি সাবধানে আরএফসিটি পড়েন তবে আপনি খুঁজে পাবেন যে একটি অস্বচ্ছ অংশে +আইনী।

— ইউজিন ইয়োকোটা

আমি ভুল হতে পারি তবে এটি কি হোস্টের থেকে আলাদা আলাদা ব্যবহারকারীর নাম সংরক্ষণ করা যায় না (যেমন উদাহরণস্বরূপ @ উদাহরণস্বরূপ / পাথ )? তারপরে এটি ঠিকানায় তার জায়গা তৈরি করবে কারণ এটি হোস্ট থেকে ব্যবহারকারী নামটি পৃথক করে।

— ম্যাকিয়েজ পাইচোটকা

Answer 2

আপনি এনকোড +করতে পারেন, কিন্তু আপনার দরকার নেই।

প্রথমত, আমাদের সম্মত হওয়া দরকার যে mailtoএটি জেনেরিক ইউআরআই-এর একটি উদাহরণ, আরএফসি 2396 দ্বারা নির্দিষ্ট । (এটি এক্সএইচটিএমএল এবং এইচটিএমএল 4 ব্যবহার করে)।

এখন আসুন আরএফসি 2396-এ সংরক্ষিত অক্ষরের তালিকাটি খুঁজে বের করি।

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

ইউআরআই পরম এবং আপেক্ষিক মধ্যে বিভক্ত:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

এবং যেহেতু স্কিম mailto:নির্দিষ্ট করা হয়েছে এটি একেবারে ইউআরআই:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

এবং যেহেতু hier_partশুরুতে উভয় নিদর্শন /, mailtoএটি একটি অস্বচ্ছ অংশ।

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

সুতরাং সীমাবদ্ধতাটি হ'ল এটি /যদি প্রথম চরিত্রের দিকে আসে তবে আপনাকে পালাতে হবে তবে এর পরে আপনি +এবং সহ সংরক্ষিত অক্ষর রাখতে পারেন @।

এটি সমর্থন করার জন্য এখানে আরও একটি আরএফসি রয়েছে। ২০১০ সালে আরএফসি 6068 নামে প্রকাশিত মেলটো স্কিমের সর্বশেষ আরএফসিগুলিতে , এটি বলে:

'mailto'ইউআরআই তৈরির মতো সফ্টওয়্যারগুলিতে যে কোনও সংরক্ষিত অক্ষর ব্যবহৃত হয় তা এনকোড করতে সতর্কতা অবলম্বন করতে হবে। এইচটিএমএল ফর্মগুলি এক ধরণের সফ্টওয়্যার যা 'mailto'ইউআরআই তৈরি করে । বর্তমান বাস্তবায়নগুলি কোনও স্থানকে এনকোড করে '+', তবে এটি সমস্যার সৃষ্টি করে কারণ '+'কোনও জায়গার জন্য এই জাতীয় অবস্থানটি '+'কোনও 'mailto' ইউআরআই-তে বাস্তবের থেকে আলাদা করা যায় না । 'mailto'ইউআরআই তৈরি করার সময় , সমস্ত স্থানকে এনকোড করা উচিত %20, এবং '+'অক্ষরগুলি হিসাবে এনকোড করা উচিত %2B। দয়া করে নোট করুন যে '+' অক্ষরগুলি একটি সাবএড্রেস নির্দেশ করতে ইমেইল ঠিকানার অংশ হিসাবে প্রায়শই ব্যবহৃত হয়, যেমন উদাহরণ হিসাবে <[e-mail]>।

Comments

আমি সেই ব্যাকরণের সাথে পুরোপুরি পরিচিত নই, তবে এটি অক্ষরগুলি অনারক্ষিত পুল থেকে পৃথক হিসাবে তালিকাভুক্ত করে, যা নির্দেশ করে যে + একটি সংরক্ষিত চরিত্র। এটি নির্দেশ করে না যে এটি অবশ্যই এনকোড করা উচিত । মাইক্রোসফ্ট এটিকে এনকোড করতে বলেছে। সি'স্ট লা ভি, আমি দেখার অপেক্ষা করছি।

— jcolebrand

যখন কোনও অংশ শুরু হয় না /, তখন +আর সংরক্ষিত অক্ষর হয়ে যায় না।

— ইউজিন ইয়োকোটা

আমি একমত না "ইমেল ঠিকানাগুলি" খুব অদ্ভুতভাবে সংজ্ঞায়িত করা হয়েছে এবং প্রথমে কিছু যত্ন সহকারে চিকিত্সা করা উচিত। এই স্ট্যান্ডার্ডটি খুব বিভ্রান্তিকর। ভাগ্যক্রমে, আমরা এখানে মতবিরোধ করতে পারি।

— jcolebrand

Answer 3

প্রাসঙ্গিক আরএফসির একটি কঠোর পঠন বলছে যে "+" এনকোড করা উচিত।

বিভাগ 2, http://tools.ietf.org/html/rfc2368 পৃষ্ঠার 2 শীর্ষে বলেছেন:

"নোট করুন যে" থেকে "-র সমস্ত URL টি সংরক্ষিত অক্ষরগুলি অবশ্যই এনকোড করা উচিত: বিশেষত, প্রথম বন্ধনী, কমা এবং শতাংশ চিহ্ন ("% "), যা সাধারণত" মেলবক্স "সিনট্যাক্সে দেখা যায়।"

ইউআরআইয়ের জন্য আরএফসি (http://tools.ietf.org/html/rfc3986#section-2.2) সংরক্ষিত অক্ষর হিসাবে "+" তালিকাভুক্ত করে।

এটি বলেছিল যে, "সঠিক" কোনটি ব্রাউজারে কাজ করবে তা অগত্যা নয়। কিছু ব্রাউজার স্পষ্টতই সঠিক জিনিসগুলি হ্যান্ডেল করে রাখে যেন সেগুলি ভুল ছিল এবং ভুলগুলি যেমন তারা সঠিক ছিল।

সম্পাদনা করুন: আরএফসি 6068 এবং এর "মাই" হিসাবে, আমি এটি প্রাসঙ্গিক নির্ভর হিসাবে পড়তে চাই। আপনি যদি পাঠ্য পাঠের জন্য ইউআরএল লিখছেন তবে "+" আরও বুদ্ধিমান হবে, তবে আপনি যদি এটি এইচটিএমএলটিতে লিখছেন তবে আরএফসি 3986 এর কঠোর ব্যাখ্যাটি "বৈধ এইচটিএমএল" ধারণাগুলির সাথে আরও ইনলাইন হবে এবং সুতরাং মানটি ব্যবহার করে যে কোনও কিছুই করা উচিত এটি এনকোড করা হবে আশা।

Comments

আরএফসি 3986-তে, mailtoহিসাবে বিবেচিত হবে path-rootless, যা pcharদ্বারা সংজ্ঞায়িত ক্রমের মঞ্জুরি দেয় (unreserved / pct-encoded / sub-delims / ":" / "@")। +এর অংশ sub-delims। তাই কঠোর পাঠ্য বলতে +শতকরা এনকোডিং দরকার হয় না।

— ইউজিন ইয়োকোটা

Answer 4

প্রতি নতুন আরএফসি http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

সুতরাং আমি অনুমান করি উত্তরটি না, তবে সম্ভবত?

Answer 5

আমি মনে করি এটি এনকোডিং বা না, একটি বাস্তব পার্থক্য করতে পারে না। সমস্যা মেইল ​​ক্লায়েন্টদের। পরীক্ষার জন্য, ইয়াহু মেল কেবল সাব অ্যাড্রেসিংয়ের জন্য হাইফেন ব্যবহার করে যেখানে জিমেইল প্লাসটি ব্যবহার করে।

এটি আমার 2 সেন্ট ...

সম্পাদনা: নীচের প্রতিক্রিয়াগুলির একটি শক্ত পয়েন্ট রয়েছে।

Comments

সত্য, ভাল পয়েন্ট যে ইমেল সাব অ্যাড্রেসিংয়ের কিছু বৈকল্পিকতা রয়েছে - তবে এই ক্ষেত্রে ইমেলগুলি জিমেইল হোস্ট করা হয় তাই আমি জানি যে প্লাসটি সঠিক এবং সার্ভারের দ্বারা প্রাপ্ত হয়ে কাজ করবে, ধরে নিই যে ক্লায়েন্টের মাধ্যমে ইমেলটি পেয়েছে gets

— জেফ আতউড

সমস্যাটি হল ইউআরআই অনুরোধটিকে বিশ্লেষণকারী অ্যাপ্লিকেশন। যদি এটি ইউআরএলএনকোডড ডেটা পাওয়ার প্রত্যাশা করে তবে এটি ডেটা ডিকোড করবে তবে এটি আপনার পক্ষে (মিথ্যাভাবে এনকোড করা) বা ক্লায়েন্টের কাছে (অনুমান করা) উপযুক্ত নয়। প্রোটোকলটি প্রত্যাশিত এনকোডিংটি নির্দেশ করে না, ক্লায়েন্ট করে। @ ওয়েজ

— জেকোলেব্র্যান্ড

Answer 6

RFC1738

3.5। MAILTO

মেলটো ইউআরএল স্কিমটি কোনও ব্যক্তি বা পরিষেবার ইন্টারনেট মেইলিং ঠিকানা নির্ধারণ করতে ব্যবহৃত হয়। কোনও ইন্টারনেট মেইলিং ঠিকানা ব্যতীত কোনও অতিরিক্ত তথ্য উপস্থিত বা বোঝানো হয়নি।

একটি মেলটো URL টি রূপ নেয়:

    mailto:<rfc822-addr-spec>

আরএফসি 822-তে উল্লিখিত হিসাবে অ্যাডর-স্পেক (কোনও এনকোডিং) রয়েছে । মেলটো ইউআরএলগুলির মধ্যে, কোনও সংরক্ষিত অক্ষর নেই।

নোট করুন যে শতাংশ চিহ্ন ("%") সাধারণত আরএফসি 822 ঠিকানার মধ্যে ব্যবহৃত হয় এবং অবশ্যই এনকোড করা উচিত।

অনেকগুলি URL- এর বিপরীতে, মেলটো স্কিমটি সরাসরি অ্যাক্সেসের জন্য কোনও ডেটা অবজেক্টকে উপস্থাপন করে না; এটি কোনও বস্তুকে মনোনীত করে এমন কোনও ধারণা নেই। মাইমে বার্তা / বাহ্যিক-দেহের ধরণের চেয়ে এটির আলাদা ব্যবহার রয়েছে।

যেহেতু কোনও সংরক্ষিত অক্ষর নেই তাই এটি এনকোড করা উচিত।

Comments

এবং এখনো প্রতি tools.ietf.org/html/rfc6068 "যখন 'mailto' এর URI উল্লিখিত উত্পাদক, সমস্ত স্পেস% 20 যেমন এনকোড করা উচিত, এবং + 'অক্ষরের% 2B যেমন এনকোড হতে পারে"

— জেফ অ্যাটউড

Since there are no reserved characters it should be encoded.ummmm যে কোন মানে না।

— jcolebrand

@ jcolebrand '+' ইউআরএল স্কিমের একটি বিশেষ চরিত্র এবং সুতরাং যখন এটির বিশেষ ভূমিকা না থাকে - সুতরাং অবশ্যই এনকোড করা আবশ্যক । যখন এটি সংরক্ষিত নেই।

— এস.স্কভ

@ জেফ প্রকৃতপক্ষে - একটি পুরানো আরএফসি বিশ্বে বাস করার পক্ষে আমার খারাপ। তারপরে টুলস.ইএইটিএফ.আর.এইচটিএমএল / আরএফসি 2119 মূলত আপনাকে যা বলে মনে হয় তা আপনাকে সবচেয়ে ভাল করে বলে মনে করে।

— এস.স্কভ

মনে হচ্ছে .... আমি নির্দেশাবলীর শুরুতে যেভাবে পড়েছি সেভাবে আত্মার পিছনে।

— jcolebrand

Answer 7

প্রতি আরএফসি 6068 প্রতি উত্তরে উল্লিখিত হিসাবে, আপনি প্লাস চিহ্নটি এনকোড করতে পারেন %2B।

বিভ্রান্তির কারণ হ'ল কোনও স্থানকে প্লাসে রূপান্তর করা আসলে স্ট্যান্ডার্ড ইউআরএল এনকোডিংয়ের অংশ নয়, এটি ফর্ম প্যারামিটার এনকোডিংয়ের অংশ (যেমন application/x-www-form-urlencoded)

এটি পিএইচপি rawurlencode()এবং এর মধ্যে পার্থক্যের মতো urlencode()।

সুতরাং আরএফসি 6068 যা বলছে তা হ'ল কোনও mailto:ইউআরএল "কাঁচা" স্ট্যান্ডার্ড ইউআরএল এনকোডিং (প্রতি আরএফসি 3986 প্রতি ) ব্যবহার করা উচিত , এবং ইউআরএল-এ প্রদর্শিত একটি প্লাস চিহ্নটি সর্বদা আক্ষরিক প্লাস চিহ্ন হিসাবে বিবেচিত হওয়া উচিত, স্থান হিসাবে নয় ফর্ম এনকোড করা হয়েছে।

স্থানীয় ক্লায়েন্ট যদি প্লাসটি একটি স্পেসে রূপান্তর করে তবে এটি ভেঙে গেছে।