Conceptually, compatibility characters are those that would not have been encoded except
for compatibility and round-trip convertibility with other standards. They are variants of
characters that already have encodings as normal (that is, non-compatibility) characters in
the Unicode Standard; as such, they are more properly referred to as compatibility variants.
Examples of compatibility variants in this sense include all of the glyph variants in the
Compatibility and Specials Area: halfwidth or fullwidth characters from East Asian character encoding standards, Arabic contextual form glyphs from preexisting Arabic code pages,
Arabic ligatures and ligatures from other scripts, and so on. Other examples include CJK
compatibility ideographs, which are generally duplicates of a unified Han ideograph, and
legacy alternate format characters such as U+206C INHIBIT ARABIC FORM SHAPING.
The fact that a character can be considered a compatibility variant does not mean that the
character is deprecated in the standard. The use of many compatibility variants in general
interchange is unproblematic. Some, however, such as Arabic contextual forms or vertical
forms, can lead to problems when used in general interchange. In identifiers, compatibility
variants should be avoided because of their visual similarity with regular characters. (See
Unicode Technical Report #36, “Unicode Security Considerations.”)
The Compatibility and Specials Area contains a large number of compatibility characters,
but the Unicode Standard also contains many compatibility characters that do not appear
in that area. These include examples such as U+2163 “IV”ROMAN NUMERAL FOUR, U+2007
FIGURE SPACE, and U+00B2 “2” SUPERSCRIPT TWO. There is no formal listing of all compatibility
characters in the Unicode Standard.
As with other compatibility characters, the preferred Unicode encoding is to use the nominal
counterparts of these characters and use rich text font or style bindings to select the
appropriate glyph size and width.
タレコミ修正希望 (スコア:-1, オフトピック)
半角カナは勘弁して下さい、修正ヨロ>編集者殿
スラドで半角カナ書く人間がいるとはなー
いまどきの若いもんはそんなもんなのか？？
Re:タレコミ修正希望 (スコア:1, すばらしい洞察)
いかがなものかと思う人もいるかと思うが、でもそういう環境への
配慮をなるべくしたほうがいいだろうね。
あと無闇に(2ch系に限らず)スラング入れても、後から見ると寒いものだし
スラングが嫌いな人種には攻撃されるし、スラングの意味が分からない人にも
疎外感を感じさせるというか、オタクが内輪で固まって
バカ話をしているようにしか見えない。
あと、余計なお世話だけども、スラングに頼っていては筆力は鍛えられない。
Re:タレコミ修正希望 (スコア:1, すばらしい洞察)
ここでの「半角カナ」に対するツッコミは、文字集合としての JIS X 0201 と
文字符号化方式としての UTF-8 を混同していることから起きているので、
配慮がどうのこうのという話ではないと思いますよ。
Re:タレコミ修正希望 (スコア:1, オフトピック)
いわゆる半角カタカナが嫌われるのは
- RFC 1468によりISO-2022-JPには含まれないことが規定されている
- SHIFT_JISで使用した場合、EUC-JPと判別しづらくなる（特に連続して偶数文字使用した場合）
ところが、ここ/.JではUTF-8が使用されているためどちらにも該当しない。スラドで（理由も知らずに）半角カナ書く（なと主張する）人間がいるとはなー
前の方のコメントにとあるけど…漢字で書かれているためか読み飛ばされてる。
Re:タレコミ修正希望 (スコア:4, 参考になる)
それは間違いです。
前者は『じゃあISO-2022-JP以外なら』となるし、後者は『UTF-8だったらいいよね』となります。
問題の本質は同じ文字が二つのコードポイントに存在するコストです。
副次的には、規格で『使うな』と決まっているからです(JIS X 0208, Unicode Standard)。
Re:タレコミ修正希望 (スコア:3, 参考になる)
少なくともThe Unicode Standardでは、「使うな」というほど強いことは言っていないようですが。
長いけれど、The Unicode Standard 5.0.0の Chapter 2 [unicode.org]
から引用:大雑把に説明すれば、
…ということで。
Re:タレコミ修正希望 (スコア:1)
5.0になってから表現がだいぶ和らぎましたね。というか不安感をなだめるかのような書き方だ...日本からの問い合わせが多かったのだろうか? ;)
4.1まではもう少し強めに書いてあります。Unicode 4.0.0 East Asian Scripts [unicode.org]より:
適当に訳すと、