DEV Community: zhihu wu

URL Encoding Demystified: encodeURIComponent vs encodeURI

zhihu wu — Wed, 29 Jul 2026 13:08:46 +0000

You are debugging a broken API call. The URL looks fine in your browser, but the server returns 400. You stare at the query string: ?q=hello world&filter=active. There is your problem — that space.

URL encoding is one of those things every developer encounters but few fully understand. Let us fix that.

The Two JavaScript Functions (and Why Both Exist)

encodeURI() is for entire URLs. It preserves characters that have structural meaning: :, /, ?, &, #. Use it when you have a complete URL and just need to make it safe.

encodeURIComponent() is for individual parameter values. It encodes everything except A-Z a-z 0-9 - _ . ! ~ * ' ( ). The & in your filter value? Encoded. The = in your base64 token? Encoded.

encodeURI("https://example.com/search?q=hello world")
// → "https://example.com/search?q=hello%20world"

encodeURIComponent("hello world")
// → "hello%20world"

The rule: encodeURI() for the whole URL, encodeURIComponent() for each parameter value. Mix them up and you either break the URL structure or leave dangerous characters unencoded.

The Double-Encoding Trap

If you encode a string that is already encoded, the % signs get re-encoded to %25. hello%20world becomes hello%2520world. The server decodes once and gets hello%20world — still encoded. A second decode gives you the original, but most servers only decode once.

Spot double-encoding by looking for %25 in your output. If you see it, decode first, then re-encode.

%20 vs + for Spaces

In query strings, HTML forms use + for spaces (application/x-www-form-urlencoded). In path segments, use %20 (RFC 3986). encodeURIComponent() always outputs %20, which is safe everywhere. If your server expects +, use %20 anyway — most modern frameworks handle both.

The Quick Fix

Next time a URL misbehaves, paste it into a decoder, inspect what is actually being sent, and fix the encoding at the source. A free tool like CodeToolbox URL Encoder does this in your browser — no server uploads, instant results.

Base64 Decoded: What Actually Happens When You Hit 'Encode'

zhihu wu — Sun, 26 Jul 2026 13:06:07 +0000

Base64 is not encryption — it's encoding. If you paste Hello into a Base64 encoder and get SGVsbG8=, no secret key was used. The algorithm just translates binary data into 64 printable ASCII characters so it can travel through text-only channels like email, JSON, and URLs.

The Algorithm in Plain English

Take your input bytes and group them in sets of 3 (24 bits total).
Split those 24 bits into four 6-bit chunks.
Each 6-bit value (0-63) maps to one character in the Base64 alphabet: A-Z, a-z, 0-9, +, /.
If the input isn't a multiple of 3 bytes, add = padding to round it out.

For Hello (5 bytes), the encoder processes bytes 0-2 as one group (producing 4 characters), then bytes 3-4 as a 2-byte group (producing 3 characters + 1 =). Result: 8 characters — SGVsbG8=.

Where You Encounter Base64 Every Day

Data URIs — embed images directly in HTML/CSS as data:image/png;base64,iVBOR..., saving HTTP requests for small icons.
JWT tokens — the payload section of every JSON Web Token is Base64-encoded JSON.
Email attachments — MIME uses Base64 to send binary files through text-only SMTP.
API authentication — Basic Auth encodes username:password as a Base64 string in the Authorization header.
Inline SVGs — embed vector graphics in a single HTML file without external dependencies.

Common Gotchas

Standard vs URL-safe. Standard Base64 uses + and /, which break in URLs. URL-safe Base64 replaces them with - and _ and strips the = padding. If you are encoding something for a query string, always use the URL-safe variant.

Base64 expands data by ~33%. Encoding 1 MB of binary produces ~1.33 MB of text. For large payloads, gzip the original data before Base64-encoding to offset the bloat.

It is not encryption. Anyone can decode Base64 with zero effort. Never use it as a security measure — it provides exactly zero confidentiality.

Try it yourself: Base64 Encoder/Decoder — free, no signup, works entirely in your browser with no server uploads.

Cron Jobs in 2026: Docker, CI/CD, and Why Your Old crontab Tricks Still Work

zhihu wu — Fri, 24 Jul 2026 13:06:59 +0000

Cron has been scheduling Unix jobs since the 1970s, and it is not going anywhere. But the way we run cron jobs has shifted: from bare-metal servers to Docker containers, from crontab files to CI/CD YAML, and from cron.d to Kubernetes CronJobs. Here is what changed — and what has not.

1. Cron Inside Docker

Docker containers prefer a single foreground process, so running a cron daemon inside a container feels unnatural. Three modern approaches:

Host cron + docker exec: Run cron on the host, and have each entry invoke docker exec container command. Zero container changes, works today.
supercronic: A drop-in crontab-compatible runner that logs to stdout/stderr. Perfect for containers whose log drivers expect stdout.
ofelia: A Docker-native scheduler that reads job config from container labels instead of a crontab file.

2. CI/CD Cron: GitHub Actions & Friends

GitHub Actions, GitLab CI, and Jenkins all support cron-triggered pipelines. The syntax is identical to standard 5-field cron:

# GitHub Actions — runs every weekday at 9 AM UTC
on:
  schedule:
    - cron: "0 9 * * 1-5"

Key difference: CI/CD schedulers use UTC by default, not your local timezone. A 0 0 * * * job that reads "midnight" actually fires at midnight UTC — which may be 8 PM your time. Always verify the timezone offset.

3. The Classic Traps Have Not Changed

Some mistakes transcend the platform:

Weekday numbering: 0 is Sunday (POSIX), but Quartz Scheduler and some libraries start at 1 for Sunday. Check your platform convention.
OR logic: When both day-of-month AND day-of-week are set, the job fires when EITHER matches — not both. This catches everyone at least once.
Minimal environment: Cron runs without your shell PATH, aliases, or environment variables. Use absolute paths and set SHELL=/bin/bash.

Quick tip: I use a free visual cron generator to build expressions, see human-readable descriptions, and preview the next 5 execution times before pasting into production. Beats memorizing field order at 2 AM.

What is the worst cron bug you have deployed? Mine was a timezone mismatch that sent customer emails at 3 AM local time instead of 9 AM.

3 Regex Patterns That Save Hours of Debugging

zhihu wu — Tue, 21 Jul 2026 13:06:26 +0000

Every developer has been there: staring at a regex that should work but doesn't. Here are three patterns I debugged this month that turned hours of head-scratching into one-line fixes.

1. Non-Greedy Matching (`.*?`)

The classic mistake: matching everything between two delimiters.

# Wrong — grabs everything from first <div> to the LAST </div>
<div>.*</div>

# Right — stops at the first </div>
<div>.*?</div>

The ? after * makes the quantifier "lazy" — it matches as little as possible instead of as much as possible. This single character fixes more regex bugs than anything else.

2. Lookaheads Without Lookbehinds

Need to match something only when followed by something else? That's a lookahead. Need the opposite? Lookbehinds aren't supported everywhere.

# Match "USD" only when followed by a number
USD(?=\d+)

# Match a number only when preceded by "$"
(?<=\$)\d+\.?\d*

Lookaheads work in every browser and language. Lookbehinds fail silently in Safari. When in doubt, capture instead.

3. Capture Groups vs. Non-Capturing

Every (...) creates a capture group. If you're grouping for precedence (not extraction), use (?:...).

# Creates 2 unnecessary capture groups
(https?|ftp)://(www\.)?(example\.com)

# Cleaner — only captures what matters
(?:https?|ftp)://(?:www\.)?(example\.com)

When you're writing a replacement with $5 and $7, you'll thank yourself for keeping the group count low.

Quick test tip: When debugging regex, I use a free online regex tester that shows match highlighting and capture groups in real time. Paste your pattern, write test cases, iterate — all in the browser.

What's the worst regex bug you've shipped? Drop it in the comments — I'll go first: I once used [0-9] instead of [0-9]+ in a credit card validator…

Stop Using 'password123': A Developer's Guide to Strong Passwords

zhihu wu — Sun, 19 Jul 2026 13:05:44 +0000

Every developer knows the drill: create an account, type a "temporary" password, and promise to change it later. Months go by, and that password — often something painfully predictable — is still protecting your production database, your CI/CD pipeline, or your cloud console.

Let's fix that. Here's what actually makes a password strong, and how to generate one you can trust.

Length Is Everything

People obsess over adding symbols and uppercase letters, but length is the single biggest factor in password strength. A 16-character all-lowercase password takes centuries to brute-force with today's hardware. An 8-character password with symbols takes hours.

Every additional character multiplies the search space exponentially. A 12-character password using only lowercase letters has 26¹² ≈ 95 quadrillion combinations. Add just 4 more characters, and you jump to 26¹⁶ ≈ 43 sextillion. That's the difference between crackable and effectively uncrackable.

Randomness > Cleverness

Your brain is terrible at randomness. "CorrectHorseBatteryStaple" is predictable because it uses dictionary words. "P@ssw0rd!" is in every rainbow table ever compiled. The only reliable way to generate a truly strong password is to let a cryptographically secure random number generator do it.

In the browser, that means crypto.getRandomValues() — the Web Crypto API backed by your OS's entropy source. It's the same API that password managers like 1Password and Bitwarden use under the hood.

Checking Your Password's Strength

Not all "strong" passwords are equal. A good password generator should show a strength indicator based on:

Length (the biggest factor — aim for 16+)
Character variety (lowercase + uppercase + numbers + symbols = 4 character pools)
True randomness (no human-chosen patterns)

I use a free password generator that shows real-time strength feedback and lets you customize length and charsets. Everything runs locally via crypto.getRandomValues() — the generated password never touches a server.

Quick Tips for Developers

API keys/tokens: use 32-64 character alphanumeric strings (no symbols — some systems choke on special chars)
Database passwords: 20+ characters, all four charsets
Wi-Fi passwords: 20+ characters — they're shared, so make them strong enough to survive a handoff
Never reuse: a strong password used on two sites is a weak password

The Bottom Line

Stop typing "Summer2026!" and convincing yourself it's fine. Use a generator, pick 16+ characters, and let entropy do the work. Your production environment will thank you.

What's the worst password you've seen in a codebase? (Config files committed to public repos, I'm looking at you.)

5 Signs Your Regex Is Wrong (and How to Spot Them in Seconds)

zhihu wu — Thu, 16 Jul 2026 13:05:52 +0000

We've all been there. You write a regex, it looks correct, you deploy it... and then the bug reports roll in. Regex is deceptively tricky — what looks right often contains subtle flaws that only surface with specific inputs. Here are five telltale signs your pattern needs fixing, and how to catch them before they hit production.

1. It Matches Way More Than You Expected

This is the #1 regex gotcha. You write <.*> to match HTML tags, but it swallows the entire <div>hello</div><span>world</span> in one match. The culprit? Greedy quantifiers. By default, * and + match as much as possible. Add ? after the quantifier to make it lazy: <.*?> matches each tag individually.

Spot it: A visual regex tester with match highlighting makes this instantly obvious — when one match spans three lines of text, you know something's off.

2. It Silently Returns Zero Matches

No errors, no warnings — just zero results. This usually means your anchors (^, $) are in the wrong place, or you forgot that . doesn't match newlines by default. Toggle the multiline (m) flag and watch the behavior change.

Spot it: If you're staring at a blank results pane, check your anchors and flags before rewriting the pattern.

3. Capture Groups Return Empty or Wrong Values

You wrapped a subpattern in parentheses, but the captured value is empty or contains the wrong text. This happens when nested groups interfere with each other, or a quantifier makes the group optional. Reorder your groups from most-specific to least-specific, and use non-capturing groups (?:...) for grouping without capturing.

Spot it: A tester that shows individual capture group values per match (not just the full match) lets you verify each extraction without console.log debugging.

4. It "Works" But Fails on Edge Cases

Your email regex \w+@\w+\.\w+ passes your test, but fails on user.name+tag@domain.co.uk. The pattern was too simplistic — real-world input is messier than your test data. Throw unicode, special characters, empty strings, and deliberately malformed input at your pattern before shipping.

Spot it: Paste 5-10 edge-case strings into the test area and watch the highlighting. If any legitimate input doesn't highlight, your pattern needs hardening.

5. The RegExp Constructor Throws a Syntax Error

Unbalanced brackets, missing escapes, or invalid lookbehind syntax crash the new RegExp() call. In production, this throws an unhandled error. In development, you catch it — but only if you test.

Spot it: A good tester surfaces syntax errors immediately as you type, with a clear error message pointing to the problem character. No need to open the browser console.

The Fix: Visual Debugging Beats Mental Parsing

The fastest way to debug regex isn't staring at the pattern harder — it's testing it visually. I use a free online regex tester that highlights matches in real-time, shows capture group breakdowns, and comes with presets for common patterns (email, URL, IPv4, dates). Every keystroke gives instant feedback — no compile-run-debug cycle.

Quick workflow: Paste your regex → toggle flags → paste test data → watch matches highlight → refine until correct → copy the final pattern into your code.

All processing runs locally in your browser, so you can safely test with real data without uploading anything to a server.

What's your go-to regex debugging technique? Have you been bitten by a subtle regex bug that took hours to find? Drop your war stories in the comments.

Stop Uploading Your Images to Random Servers: Compress Locally Instead

zhihu wu — Tue, 14 Jul 2026 13:06:28 +0000

Every time you use a "free online image compressor," ask yourself: where is my image being sent?

Most image compression tools upload your files to a remote server for processing. Your photos, screenshots, and design assets pass through someone else's infrastructure — and there's no way to know if they're stored, scanned, or resold.

Local Compression Is Not Magic — It's Canvas

The HTML5 Canvas API has had everything we need for client-side image compression for years. Here's the core idea:

Load the image into the browser
Draw it onto an invisible canvas
Call toBlob() with your quality setting
Download the result

Zero bytes leave your computer. The entire pipeline runs on your hardware, and it's surprisingly fast — milliseconds for most images.

3 Things I Learned Compressing Hundreds of Images

1. WebP Is the Undisputed King

Switching your output format from JPEG to WebP typically saves 25-35% more space at the same visual quality. Every modern browser supports it. Unless you need IE11 compatibility (and I hope you don't), WebP is a no-brainer.

2. Resizing Before Compressing Doubles the Savings

If your original photo is 4000×3000 but your website only displays it at 800px wide: resize first, compress second. That 5MB photo can drop below 50KB with both steps.

3. The Visual Breakpoint Technique

Start at 100% quality and slide down while watching the preview side-by-side. The moment you spot degradation, bump back up 5%. That's your sweet spot — maximum compression with zero visible difference.

The Tool I Actually Use

I've been using the CodeToolbox Image Compressor — it runs entirely in the browser, no uploads, no signup, no daily limits. Drop an image, tweak the slider, see the side-by-side preview, and download.

It handles JPEG, PNG, and WebP conversion in both directions. The offline support is a nice bonus: once the page loads, it works on planes and metered connections.

Bottom Line

Local image compression isn't some exotic feature — it's table stakes in 2026. If a tool needs to upload your files to a server to resize them, find a better tool. Your users' privacy (and your page load times) will thank you.

Why UUIDs Belong in Every Developer's Toolbelt (Not Just Your Database)

zhihu wu — Sat, 11 Jul 2026 13:04:51 +0000

Most developers first encounter UUIDs when setting up database primary keys. But UUIDs solve problems far beyond the database — and once you start using them, you'll wonder why you ever reached for auto-increment.

The Problem with Sequential IDs

Auto-increment IDs are fast and small, but they leak information. Every /users/42 tells an attacker there are at least 42 users. Every /orders/1087 reveals your order volume. In a REST API, sequential IDs are an enumeration attack waiting to happen.

UUIDs fix this by being unguessable. /users/550e8400-e29b-41d4-a716-446655440000 tells an attacker nothing.

Beyond the Database: Where UUIDs Shine

Idempotency Keys. When processing payments or API calls, the client generates a UUID as an idempotency key before sending the request. If the network drops and the client retries, the server recognizes the same key and avoids double-charging. Stripe's API requires this pattern.

Optimistic UI. In collaborative apps like Figma or Notion, the client generates UUIDs for new elements before the server confirms. This gives instant feedback — no waiting for a database round-trip to get an ID.

File Uploads. Use UUIDs for uploaded filenames instead of the user's original filename. /uploads/550e8400-e29b-41d4-a716-446655440000.pdf avoids naming conflicts and doesn't leak the original filename.

Distributed Systems. When multiple services generate IDs independently, auto-increment fails — they'd collide. UUIDs let every service create IDs without coordination.

Generating UUIDs in Your Stack

// Browser & Node.js 19+
const id = crypto.randomUUID();
// => "550e8400-e29b-41d4-a716-446655440000"

import uuid
id = str(uuid.uuid4())

id := uuid.New().String()

Are They Too Big?

A UUID is 16 bytes as binary, or 36 characters as a string. For modern databases like PostgreSQL (which has a native uuid type storing only 16 bytes), the overhead is negligible. For MySQL, store UUIDs as BINARY(16) instead of CHAR(36) to save space.

The Bottom Line

UUIDs aren't just for databases. They're for idempotent APIs, offline-first apps, file storage, and any system where multiple pieces need to generate IDs without talking to each other. If you need to quickly generate UUIDs for testing or development, I keep this free UUID generator bookmarked — it supports bulk generation up to 100 at a time, and all processing happens locally in your browser.

5 Markdown Tricks That Make Your README Stand Out

zhihu wu — Thu, 09 Jul 2026 13:06:25 +0000

I've reviewed hundreds of GitHub READMEs while contributing to open source, and the difference between a forgettable one and one that makes people stop scrolling often comes down to a few small Markdown tricks.

1. Collapsible Sections for Long Content

Nobody wants to scroll through 2,000 lines of setup instructions. Use HTML <details> tags to hide secondary content:

<details>
<summary>Advanced Configuration</summary>

Your long config docs here...

</details>

This renders as a clickable expandable section that keeps your README scannable.

2. Task Lists for Roadmaps

GFM task lists aren't just for personal to-dos. Use them as a public roadmap:

- [x] Core API (v1.0)
- [x] Webhook support
- [ ] GraphQL endpoint
- [ ] Multi-region deployment

Users instantly see what's done and what's coming.

3. Reference-Style Links for Cleaner Source

Inline links make raw Markdown hard to read. Reference-style links keep paragraphs clean:

Check the [contributing guide][contrib] for details.

[contrib]: CONTRIBUTING.md

4. Mermaid Diagrams Inside Code Blocks

GitHub renders Mermaid diagrams in fenced code blocks. Show architecture without uploading an image:

```mermaid
graph LR
    Client-->API-->Database
    API-->Cache
```

5. Align Tables with Consistent Column Widths

Tables are Markdown's weakest feature. Make them maintainable by aligning columns:

| Parameter | Type   | Default | Description        |
|-----------|--------|---------|--------------------|
| timeout   | number | 5000    | Request timeout ms |
| retries   | number | 3       | Max retry attempts |

Adding spaces so the pipes align makes the raw source readable.

The fastest way to test any of these is a live preview. I use this free Markdown previewer when drafting READMEs or blog posts — it renders GFM tables, task lists, and diagrams in real time without touching a server.

3 Times You Need Base64 (and One Time You Definitely Don't)

zhihu wu — Wed, 01 Jul 2026 01:40:20 +0000

When Base64 Makes Sense

Base64 converts binary data into text using 64 printable ASCII characters so it can travel through systems that don't handle raw bytes well. Here are three times you actually need it, and one time you shouldn't bother.

1. Embedding Small Images in HTML/CSS

Inline images via data URIs eliminate HTTP requests. For tiny assets like icons and email signature graphics, this is genuinely faster than a separate file:

<img src="data:image/png;base64,iVBORw0KGgo..." alt="logo">

The tradeoff: Base64 inflates file size by ~33%. For anything over 5KB, a separate file with browser caching wins. But for that one-off SVG favicon or email footer, inline Base64 is perfect.

2. Sending Binary in JSON APIs

JSON can't carry raw bytes. When your API needs file uploads alongside metadata, Base64-encoding is the standard approach:

{
  "filename": "report.pdf",
  "content": "JVBERi0xLjQKJeLjz9MK...",
  "userId": 422
}

Most cloud APIs (AWS Lambda payloads, webhook implementations) use this pattern under the hood.

3. Debugging Tokens and Auth Headers

JWT payloads are just Base64URL. Basic Auth headers are Base64-encoded user:pass. When debugging, paste a JWT's middle segment into any Base64 decoder and read the claims directly. Same trick for Authorization: Basic *** headers — decode the token after "Basic " to see the credentials.

When NOT to Use Base64

For security. Base64 is encoding, not encryption. It's trivially reversible and offers zero protection. I've seen devs Base64-encode API keys in client-side code thinking it hides them. It doesn't. Use AES-256 for actual security.

Need a quick Base64 encoder/decoder? I use this free tool — it runs entirely in the browser, handles files and data URIs, and works with both standard and URL-safe variants.

Your JSON Is Valid... Until It's Not: Common Parse Errors and How to Fix Them

zhihu wu — Wed, 24 Jun 2026 13:02:56 +0000

We've all seen it: an API response that looks perfectly fine, but JSON.parse() throws a cryptic error at position 0. Or position 472. Or somewhere deep inside a 10,000-line config file. Here are the most common JSON syntax issues and how to diagnose them fast.

1. Trailing Commas (The #1 Offender)

{
  "name": "App",
  "version": "2.0.1",
  "dependencies": [
    "react",
    "lodash",
  ],
}

JSON spec (RFC 8259) does not allow trailing commas. JavaScript and TypeScript are forgiving, so your IDE doesn't complain — but strict JSON parsers will fail. The fix: remove the comma after the last array item and last object key.

2. Smart Quotes vs. Straight Quotes

If you copy JSON from a word processor or a ChatGPT output, you might get "smart quotes" (curly) instead of straight quotes. They look similar but are different Unicode characters:

// This WILL fail — smart quotes on the key
{“name”: “hello”}

// This is correct
{"name": "hello"}

3. Unquoted Keys

JavaScript objects let you use unquoted keys. JSON does not:

// Valid JS object, INVALID JSON
{name: "Alice", age: 30}

// Correct JSON
{"name": "Alice", "age": 30}

4. The Invisible BOM

If your JSON file starts with a UTF-8 BOM (Byte Order Mark), many parsers fail at position 0 — even though the file looks empty of problems. cat file.json | xxd | head -1 and look for EF BB BF at the start.

5. Single Quotes

JavaScript accepts both single and double quotes for strings. JSON does not:

// Invalid
{'key': 'value'}

// Valid
{"key": "value"}

Debugging Tip

When you encounter a parse error, don't just stare at the JSON. Use a formatter that shows the exact line and column of the first syntax error.

I built a free JSON formatter and validator for exactly this purpose — paste your JSON, click Validate, and it tells you exactly where the error is. All processing happens in your browser, no data leaves your machine.

The most useful feature: it works offline once the page loads. I've used it on flights to debug local config files without internet.

Got a favorite JSON debugging technique? Drop it in the comments.

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

zhihu wu — Sun, 21 Jun 2026 13:05:23 +0000

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

Every developer has done it: you Google "regex for email," copy the first Stack Overflow answer, paste it into your code, and cross your fingers that it covers all edge cases. Then six months later, user+tag@domain.co.uk slips through and breaks something.

Let's fix that. Here are five regex patterns you probably copy-paste, explained so you actually understand them — and can adapt them yourself.

1. Email Validation: The Pattern Everyone Gets Wrong

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

Broken down:

[a-zA-Z0-9._%+-]+ — username part: letters, digits, dots, underscores, percent, plus, hyphens. The + means "one or more."
@ — literal at sign.
[a-zA-Z0-9.-]+ — domain name: letters, digits, dots, hyphens.
\. — literal dot (escaped because . normally means "any character").
[a-zA-Z]{2,} — TLD: at least 2 letters.

When it fails: Unicode characters in the local part (café@example.com), quoted strings, IP-address domains. For production email validation, send a confirmation link — regex alone can't guarantee deliverability.

2. URL Extraction: Greedy vs. Lazy Trap

https?:\/\/[^\s/$.?#].[^\s]*

https? — "http" optionally followed by "s." The ? makes the preceding character optional.
:\/\/ — literal :// (forward slashes must be escaped outside character classes).
[^\s/$.?#] — match one character that is NOT whitespace, /, $, ., ?, or #. This prevents matching bare punctuation.
[^\s]* — then match everything until whitespace (\s). Note the * (zero or more) — if the URL is followed by a space, it stops there.

Pitfall: The * after [^\s] is greedy — always use it with a character class ([^\s]) rather than . to avoid gobbling up surrounding text. Test this in the regex tester with URLs embedded in paragraphs to see the difference.

3. IP Address Extraction: Backreference Magic

\b(?:\d{1,3}\.){3}\d{1,3}\b

\b — word boundary: ensures we don't match "192.168.1.1" inside "192.168.1.100".
(?:\d{1,3}\.) — a non-capturing group (?:): one to three digits followed by a dot. Non-capturing groups group without saving the match.
{3} — repeat the group exactly 3 times. So we get 123.45.67.
\d{1,3} — final octet, no trailing dot.
\b — word boundary again.

This pattern doesn't validate IPs — it matches 999.999.999.999. For validation, you'd need a much more complex pattern checking each octet's range (0-255). This pattern's job is extraction, not validation — it finds anything that looks like an IP in a log file.

4. Date Extraction (ISO 8601): Character Classes Done Right

\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])

\d{4} — exactly 4 digits (the year).
- — literal hyphen.
(0[1-9]|1[0-2]) — month: either 0 followed by 1-9 (Jan-Sep) OR 1 followed by 0-2 (Oct-Dec). The | means "OR."
- — literal hyphen.
(0[1-9]|[12]\d|3[01]) — day: 0[1-9] (1st-9th) OR [12]\d (10-29) OR 3[01] (30-31).

Known limitation: This accepts invalid dates like 2025-02-30. For bulletproof date validation, parse with a date library after the regex confirms the format.

5. The "Everything Between Tags" Problem

<([a-zA-Z][a-zA-Z0-9]*)>(.*?)<\/\1>

<([a-zA-Z][a-zA-Z0-9]*)> — opening tag: <, a letter, then optional alphanumeric characters, >. The parentheses capture the tag name.
(.*?) — content between tags. The ? after * makes it lazy — stop at the first closing tag, not the last.
<\/\1> — closing tag: <, /, then (backreference to the first capture group, the tag name), >.

Without the lazy *?, <.*> applied to <div>hello</div> would match the entire string instead of just <div>. This is the #1 "why isn't my regex working" moment.

The Debugging Workflow I Actually Use

Start with a known-good preset (email, URL, IPv4 from the tool's library)
Tweak one thing at a time, watching the match highlights change in real-time
Add edge cases to the test string: empty input, special chars, unicode
Only move to production code when the tester shows exactly what you expect

I use the free Regex Tester at codetoolbox.pro/tools/regex-tester.html for this — it runs entirely in the browser, highlights matches instantly, and shows capture groups individually. No signup, no server uploads.

What's the regex that burned you the worst? Drop a comment — genuinely curious how many of us have been bitten by the same patterns.

DEV Community: zhihu wu

URL Encoding Demystified: encodeURIComponent vs encodeURI

The Two JavaScript Functions (and Why Both Exist)

The Double-Encoding Trap

%20 vs + for Spaces

The Quick Fix

Base64 Decoded: What Actually Happens When You Hit 'Encode'

The Algorithm in Plain English

Where You Encounter Base64 Every Day

Common Gotchas

Cron Jobs in 2026: Docker, CI/CD, and Why Your Old crontab Tricks Still Work

1. Cron Inside Docker

2. CI/CD Cron: GitHub Actions & Friends

3. The Classic Traps Have Not Changed

3 Regex Patterns That Save Hours of Debugging

1. Non-Greedy Matching (.*?)

2. Lookaheads Without Lookbehinds

3. Capture Groups vs. Non-Capturing

Stop Using 'password123': A Developer's Guide to Strong Passwords

Length Is Everything

Randomness > Cleverness

Checking Your Password's Strength

Quick Tips for Developers

The Bottom Line

5 Signs Your Regex Is Wrong (and How to Spot Them in Seconds)

1. It Matches Way More Than You Expected

2. It Silently Returns Zero Matches

3. Capture Groups Return Empty or Wrong Values

4. It "Works" But Fails on Edge Cases

5. The RegExp Constructor Throws a Syntax Error

The Fix: Visual Debugging Beats Mental Parsing

Stop Uploading Your Images to Random Servers: Compress Locally Instead

Local Compression Is Not Magic — It's Canvas

3 Things I Learned Compressing Hundreds of Images

1. WebP Is the Undisputed King

2. Resizing Before Compressing Doubles the Savings

3. The Visual Breakpoint Technique

The Tool I Actually Use

Bottom Line

Why UUIDs Belong in Every Developer's Toolbelt (Not Just Your Database)

The Problem with Sequential IDs

Beyond the Database: Where UUIDs Shine

Generating UUIDs in Your Stack

Are They Too Big?

The Bottom Line

5 Markdown Tricks That Make Your README Stand Out

1. Collapsible Sections for Long Content

2. Task Lists for Roadmaps

3. Reference-Style Links for Cleaner Source

4. Mermaid Diagrams Inside Code Blocks

5. Align Tables with Consistent Column Widths

3 Times You Need Base64 (and One Time You Definitely Don't)

When Base64 Makes Sense

1. Embedding Small Images in HTML/CSS

2. Sending Binary in JSON APIs

3. Debugging Tokens and Auth Headers

When NOT to Use Base64

Your JSON Is Valid... Until It's Not: Common Parse Errors and How to Fix Them

1. Trailing Commas (The #1 Offender)

2. Smart Quotes vs. Straight Quotes

3. Unquoted Keys

4. The Invisible BOM

5. Single Quotes

Debugging Tip

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

1. Email Validation: The Pattern Everyone Gets Wrong

2. URL Extraction: Greedy vs. Lazy Trap

3. IP Address Extraction: Backreference Magic

4. Date Extraction (ISO 8601): Character Classes Done Right

5. The "Everything Between Tags" Problem

The Debugging Workflow I Actually Use

1. Non-Greedy Matching (`.*?`)