Uppercase O with strokeBox cross junction, double horizontal
ASCII 216 is Ø on Windows and ╪ in old DOS.
Ø (Capital O with Stroke) is byte 216 in Windows-1252, Unicode U+00D8. Danish, Norwegian and Faroese use it as a letter, as in Øresund and Østfold. Outside Scandinavia it gets borrowed for symbols it only resembles. Engineers write Ø 12 for a 12 mm diameter, where the proper sign is ⌀ (U+2300), and maths uses ∅ (U+2205) for the empty set. On paper the difference barely shows, but search treats all three as unrelated characters, so a parts catalog searched for ⌀ won't find entries typed with Ø. UTF-8 stores Ø as C3 98, which misreads as Ø. The HTML entity is Ø.
╪ (Single Vertical, Double Horizontal) is byte 216 in code page 437, the original IBM PC character set, and maps to Unicode U+256A. It's the crossing where a single column line │ (179) passes through a double row line ═ (205), a common way to set a header apart from the rows below it. Python's tabulate draws its fancy_grid header separator exactly like that: ╞═════╪═════╡. Code page 850 put Ï on this byte and replaced both ends too, so the same separator read as 850 comes out as ã═════Ï═════Á. In UTF-8 it's E2 95 AA, and the HTML entity is ╪.
#include <stdio.h>int main(void) {/* On Windows (code page 1252) byte 216 is Ø.Modern terminals expect UTF-8, so print the code point, not the byte. */printf("\u00D8\n"); /* UTF-8: C3 98 */unsigned char b = 216; /* the raw Windows-1252 byte */printf("%d 0x%02X\n", b, b); /* 216 0xD8 */return 0;}
#include <stdio.h>int main(void) {/* Byte 216 is ╪ only on a console using code page 437(chcp 437 on Windows, or DOSBox). On a UTF-8 terminal thelone byte 0xD8 is invalid and prints as garbage, often �. */putchar(216);/* char is signed on x86, so a plain char holding 0xD8 is -40.Use unsigned char when you compare or index by byte value. */char c = (char)216;unsigned char u = 216;printf("\n%d %d\n", c, u); /* -40 216 *//* Portable: print the Unicode character as UTF-8 instead. */printf("\u256A\n"); /* E2 95 AA */return 0;}
Because the HTTP header wins over the meta tag. If the server sends Content-Type: text/html; charset=iso-8859-1, the browser follows that and ignores your <meta charset=utf-8>, so Ø keeps coming out as Ø. Open the network tab in your browser's dev tools, look at the Content-Type on the page response, and change the server or framework config until it says charset=utf-8.
Ø has no Unicode decomposition, so the usual trick of normalizing to NFKD and dropping everything non-ASCII deletes it instead of leaving an O. Ødegaard becomes degaard the same way. Map it yourself before normalizing: the Danish and Norwegian fallback is Ø to Oe and ø to oe, which turns Søren into soeren. Æ has the same problem and falls back to Ae.
No. A slashed zero is the digit 0 drawn with a stroke in some fonts, so underneath it's still U+0030. Ø is a letter. It sneaks into serial numbers, product keys and radio callsigns when someone retypes a zero they saw printed with a slash, and then numeric parsing or a lookup fails. In fields that should only hold digits or codes, map Ø to 0 before validating.
It's code page 437 being read as Windows-1252, and a double header rule happens to land on Scandinavian-looking letters: ╞ (198) turns into Æ, ═ (205) into Í, each ╪ crossing into Ø and ╡ (181) into µ. Browsers can't decode code page 437 at all, so if the table is headed for a web page, convert the file to UTF-8 before you serve it.
It's code page 437 being read as Windows-1252, and a double header rule happens to land on Scandinavian-looking letters: ╞ (198) turns into Æ, ═ (205) into Í, each ╪ crossing into Ø and ╡ (181) into µ. Browsers can't decode code page 437 at all, so if the table is headed for a web page, convert the file to UTF-8 before you serve it.