Escaping е лесен за объркване, защото няколко различни задачи изглеждат подобно отдалеч. Имате текст, текстът съдържа special characters и друга система трябва да го получи, без да го разбере погрешно. Грешката е да приемете, че един вид escaping работи навсякъде.
URL encoding, HTML escaping и JSON escaping решават различни проблеми. Space в query string не е същият проблем като < character в rendered HTML или quotation mark вътре в JSON string. Инструментът Case / Slug / Escape помага, като държи тези outputs близо един до друг, но полезната част е да знаете кой output принадлежи на destination-а, който подготвяте.
URL кодиране е за URL адреси и query values
Използвайте URL encoding, когато текстът отива в URL component, особено query parameter или value, който може да съдържа spaces, punctuation или non-path-safe characters.
Представете си support link, който трябва да включи search term като pricing & billing. Ако поставите тази фраза директно в URL, тя може да промени начина, по който URL-ът се интерпретира, защото & вече има значение в query string. URL encoding превръща текста във форма, която може да пътува в URL, без да бъде объркана с URL syntax.
Това е различно от създаването на slug. Slug обикновено превръща title в readable path segment като pricing-and-billing. URL encoding запазва original value по-директно за transport.
HTML escaping е за текст, който ще се рендерира в HTML
Използвайте HTML escaping, когато текст трябва да се появи като текст в HTML context, а не да стане markup.
Ако code example съдържа <button> и искате читателите да видят тези characters, browser-ът трябва да получи escaped characters. Иначе може да ги интерпретира като реален element. HTML escaping е за това да предпази текста от прочитане като HTML syntax там, където content-ът трябва да остане visible text.
Това има значение в documentation, CMS fields, changelogs и product copy. Особено релевантно е, когато source text съдържа markup examples, snippets или user-generated values, които не трябва да станат част от page structure.
JSON escaping е за string values вътре в JSON
Използвайте JSON escaping, когато текст трябва да стои безопасно вътре в JSON string.
Quotation mark е безобиден в normal prose, но вътре в JSON string може да затвори string-а твърде рано. Newline също може да има нужда от representation, която държи JSON-а valid. JSON escaping запазва value-то, докато surrounding JSON остава parseable.
Това често се появява, когато екипи споделят API examples, config snippets, analytics payloads или sample data. Ако следващата стъпка е по-широк structured-data cleanup, комбинирайте тази статия с Как да форматирате JSON, преди да споделите API пример и JSON / YAML / TOML конвертора.
Избирайте escaping според destination-а
Най-простото правило е първо destination-ът.
| Destination | Използвайте | Защо |
|---|---|---|
| URL query value или URL component | URL encoding | Пази текста от интерпретиране като URL syntax |
| Visible text вътре в HTML | HTML escaping | Пази special characters от превръщане в markup |
| String value вътре в JSON | JSON escaping | Държи quotes, slashes и line breaks parseable |
| Public article или route title | Slug generation | Създава readable path text, вместо да запазва всеки character |
Converty помага, защото можете да поставите веднъж и да сравните outputs, без да отваряте отделен encoder за всеки case. Така задачата остава proportional. Не строите pipeline; подготвяте една text value за мястото, където трябва да отиде.
Отворете Case / Slug / Escape, когато трябва да решите дали следващият output трябва да бъде slug, URL-encoded value, HTML-safe text или JSON-safe string.
