The code I'm writing here is JavaScript, and by default all strings are considered Unicode. So, to get (say) a "trademark" symbol, I can write String.fromCharCode(0x2122), or write XML markup saying "™" and get a character with numeric value way up in the thousands.

Weirdly, these very-high characters passed right through the pipe - in one end, out the other - in both directions, without breaking. Yet more mundane symbols such as the pound sign ("£") and Latin-1 accented characters would detonate along the way. (The actual symptom was reporting that my SQL Server was stopped, but that was a red herring).

So, that pound sign was character 163 ("%A3" after URL-escaping), but the URL wanted UTF-8, where the pound becomes two bytes: 194 163, or %C2%A3. UTF8 is wonderful and slightly strange - don't ever try working backwards through a UTF8 string!

That includes data conversions (dates as milliseconds-of-Unix-epoch, ISO8601 text, locale text, and a few others; numbers, currencies, single- and multi-line text), XML entity encoding and decoding, URL encoding... you get the idea. I'm obsessive about doing this right, because if it's wrong it will break unpredictably. Not just with weird international stuff, but with regular users typing regular text.

I'm a strong believer in the notion of a "clean data path". This may be influenced by having spent a lot of time in localization work, where it's really important to (a) know what character set you're dealing with, and (b) avoid unnecessary string operations: text strings are way too subtle and complex, and the cause of much pain. Any time you take apart a string, rearrange its contents, or reassemble a string, there's plenty of room for errors.

The other influence here is electronic engineering, and the "signal path". What we're building, if it's right, will be a very close analog of another obsession of mine: the Quad 405. It rocks.