Rendering Content & the Kanji Edge Case

Website Rebuild with Express

Chapter 7 · Rendering Content & the Kanji Edge Case

The lightest chapter in the course — two of its usual three questions were already answered in earlier chapters, and the third was handled proactively before it could even become a question.

Routing & Rendering: Already Solved

Kanji's two original constraints — a fixed-depth hierarchy, and no self-contained-fragment convention — never applied here. Chapter 2's raw SQL schema has no depth limit of any kind, and Chapter 4's <%- page.body %> renders any page's own stored markup through the identical path every other page already uses.

String Safety: Confirmed a Third Time

The same runtime, a third time in this series
Next.js and Astro both already established this: Node.js's own V8 engine represents strings as UTF-16 code units, and common kanji characters — including 水 — are single code units within that model, with no risk of a slicing operation corrupting them. Express runs on the identical runtime. This isn't a third framework independently reaching the same conclusion; it's the third time in this series the exact same language and engine have simply been reused.

utf8mb4: Already Handled, Learned in Advance

// db.js — written back in Chapter 2 const pool = mysql.createPool({ uri: process.env.DATABASE_URL, charset: 'utf8mb4', });
A gap the Astro rebuild found — already closed here from the start
Astro's own Chapter 7 discovered that mysql2 has no automatic utf8mb4 default the way Rails 5.2+ does, and had to add charset: 'utf8mb4' explicitly, mid-course. This course's own Chapter 2 already included that same option from the very first line of db.js — not a coincidence, but a direct, deliberate application of what Astro's own Chapter 7 already taught. The series' own accumulated findings get applied proactively here, not rediscovered.

Kanji Across All Six Frameworks

Next.jsDjangoLaravelRailsAstroExpress
String-slicing riskNone — same runtime as ExpressNoneReal — mb_substr() neededNoneNone — same runtime as ExpressNone — same runtime as Next.js/Astro
utf8mb4 handlingManualManualManualAutomatic since Rails 5.2Manual — discovered as a gapManual — applied proactively from Chapter 2

Hands-On Exercises

Exercise 1

Confirm the two original kanji constraints are already resolved by Chapters 2 and 4, with no new code needed for this chapter.

📄 View solution
Exercise 2

In a Node REPL, confirm '水のページ'.length and slicing behavior are safe for typical kanji content, the same test already run for the Astro rebuild's own Chapter 7.

📄 View solution
Exercise 3

Confirm Chapter 2's own db.js already includes charset: 'utf8mb4', and explain why this course applied it proactively rather than discovering it as a gap the way the Astro rebuild did.

📄 View solution

Chapter 7 Quick Reference

  • Routing/rendering — already solved by Chapters 2 and 4, no new work
  • String safety — the same Node.js/V8 runtime as Next.js and Astro, confirmed a third time
  • charset: 'utf8mb4' — already present since Chapter 2, applied proactively from Astro's own earlier finding
  • The series' own accumulated knowledge, in action — a gap discovered in one course, avoided entirely in a later one
  • Next chapter: Dynamic Content & Forms