JIS X 0208 row 3, by contrast, only includes the letters and numbers, though most of the ASCII punctuation is included in row 1. It is, however, missing straight quotes (added in some vendor extensions), has a “wave dash” not a wide tilde for all that they differ (Microsoft still treat it as a wide tilde), and has separate hyphen and minus sign assignments (Microsoft treat the minus sign as a wide hyphen-minus). JIS X 0213 didn’t exist at the time. EUC-CN (GBK, its superset, didn’t exist at the time), its underlying GB character set encodes the entirety of an ISO 646 variant in row 3 (with Yuan/Yen not Dollar, Overline/Macron not Tilde) and the remaining ASCII (Tilde and Dollar) in row 1. Unicode layout here copies ASCII though. Pretty much every East Asian MBCS is responsible for at least some of it. E.g.
(Most characters in this block were present since Unicode 1.0.0, exceptions are noted below.) Fullwidth ASCII variants (U+FF01–FF5E)
So… blame for Halfwidth and Fullwidth forms, by subheading?
EDITPAD LITE SHIFT JIS CODE
That being said, the origin of the individual characters is not always obvious. Being that not everyone is motivated to read code pages if they don’t have to for some reason, I have decided to write this up. Unicode’s Halfwidth and Fullwidth Forms block encodes equivalents to other Unicode characters, differing entirely in being intended to display wider or narrower than their compatibility-normalised equivalents. This usually harks back to East Asian multiple-byte character sets (MBCSs), which combined a single byte character set such as ASCII or another ISO 646 variant (a SBCS) with a (possibly reärranged) double byte character set (DBCS) often of separate orgin. This resulted in duplicate encoding of some characters, where the single byte versions often rendered narrower than the double byte ones (duospace typesetting). (Jump to navigation) Whence Unicode’s Halfwidth and Fullwidth forms?
0 kommentar(er)
