[1] Korean mess (ハングルの大移動, 直訳 韓語混乱) で、 ハングルは U+3400 〜 U+4DFF から U+AC00 〜 U+D7A3 にぶっとびますた。

[26] この改正は、

によって行われました。 >>25

[25] PDF 千夜一夜: PDFと文字(26) – ハングルの扱い, , https://blog.antenna.co.jp/PDFTool/archives/2006/01/pdf26_unicode.html

[8] ハングル跡地には、「BMP にはこれで漢字は最後。」という約束でCJK統合漢字拡張Aが入りました。

[14] ですから単に文字が移動しただけではなく、更に 83JIS のように「同じ文字概念」の場所を入れ替えたのでもなく、全く違うハングルが全く違う漢字に変わってしまったのです。

[15] JTC1/SC2/WG2 と UTCUnicode技術委員会 は「この過ちを2度と繰り返さない」とその後決定したそうです。その舌の根も乾かないうちに、 BMP の全符号位置の数千倍の私用符號位置がばっさり削除されました (PrivateMess)。

[16] また、目立たぬようにこっそりと2種類の「φ」の入れ替えが敢行されました。

[17] Cannot Display Korean Windows NT 3.5 Programs Under Windows 3.51 ( 版) http://support.microsoft.com/default.aspx?scid=kb;en;157447

[7] 韓国の圧力により、 ISO/IEC10646-1:1993 Ammendment 6 において、 ISO/IEC 10646-1:1993 で規定されていたハングル がばっさり削除され、代わりに全ての現代ハングルの完成形が 別の場所に登場したこと。 (See also 組合型) (元のハングルは使用頻度が高いものだけ規定されていた。)

ちなみに、元のハングルの場所には後に追加漢字 (CJK UNIFIED IDOGRAPHS EXTENSION A) が割り当てられた。

Unicode で言えば 1.1 → 2.0 にあたる。

[2] 一歩間違えば 83JIS の混乱のような事態になったでしょうが、 当時 UCS でハングルを使ってた人なんてそんないなかったらしいので、 コップの中の嵐で終わったみたいです。 (当時から UCS を使ってた忠実な Unicoder (など) が被害を被ったわけです。)

[34] >>2 でもそんな忠実な信者って当時はほとんど欧米人だったので・・・

[18] 極めて稀にですけど、当時作られた文書に一部不審な漢字が混じっていて、 ハングルがCJK統合漢字拡張Aに文字化けしていたのだとわかるケースがあります。

[3] これを教訓に SC2 と UTC は二度とこのようなことを しないと決意した・・・と書いてある文書が幾つもあるんですが、 懲りずに 2.0 → 3.2 でギリシャ文字φの入れ替えを行ってみたり (PhiMess)、 私用面・私用群をばっさり消したり (ISO/IEC 10646-1:2000 Ammendment 1) してます (PrivateMess)。

[4] 旧配置は KSX1001 と KSX1002 のハングル部分をそのまま置いた物でした。 (もしそのままだったら2000年くらいに北朝鮮になんとかしる!としつこく言われてただろうな。(変えても実際文句言ってるんだが。))

[35] >>4 その頃の北朝鮮っていきなり出てきてハングルをチョソングルにしろとか順序がおかしいとかわけのわからんこといっていましたけど、 大韓民国がそのほんの何年か前にもっと無茶なことやってるんだから、 朝鮮民主主義人民共和国にだってそんくらい要求する権利くらいはあるよなー、って今になって思うねw

[36] 南も北も競っておかしなこと言ってるのに南は認められて北は認められないって筋が通らんよね。 まあそれが国際政治、国際標準化団体の実態ってやつなんだけどさー

[19] ISO/IEC 10646 や Unicode の枠内の仕組みでハングルの大移動前のデータか、 後のデータかを区別する方法はありません。頻度分析頻度解析等の手法など発見的な方法で推測文字コードの判定するか、 文字化けを人間に検査させるしかありません。

[20] BOM や DOCS のような文字コード判別の役に立ちそうな ISO/IEC 10646 や Unicode や ISO/IEC 2022 に備わった仕組みは、 こういう肝心なときには使えません。 (非互換変更がなされているにも関わらず、 旧規格と新規格で同じ識別子のままになっています。 この点は 83JIS の方がマシだったといえます。目糞鼻糞とはいえw)

[21] MIME charset は UTF-8 や UTF-7 の Unicode 1.1 (旧規格) の名称が登録されているので、新旧規格を区別できます。 ただし、版指定がない方の名前 (昔からあって今も普段遣いされている方の名前) が新規格を表していて、版指定があるのは旧規格の方だけです。 つまりわざわざ旧規格用の MIME charset 名に付け直したときだけ、 正しく判別できる、という微妙な扱いです。 (メールなどで使われていた場合、 過去に遡ってDメール修正などできるわけがなく、 旧規格なのに版指定なしの MIME charset 名になっていたりするので、 送受信の日付からどちらか推測するしかありません。) そして旧規格用の MIME charset 名にはあまり対応されていないようです。

[5] 関連: ISO/IEC 10646におけるエスケープシーケンス, Unicode 1.1

[22] Japanese Windows and hangul, , https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/hangul03.htm

完成型ユニコードは古いバージョンのものです。

[23] 17080-three-hangul-syl.pdf, , https://unicode.org/L2/L2017/17080-three-hangul-syl.pdf

[24] Notes for HANGUL.TXT, , https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/HangulReadMe.html

[13] >>23 #page=22

It is very excellent that hangul syllables were entirely reassigned in Unicode 2.0, especially with names and canonical decomposition mappings that are “algorithmically” defined, which completely eliminated the chance of having errors like the ones mentioned in this document. If the reassignment did not take place and if Unicode kept the same character assignment for hangul syllables (with “hand-crafted” names and canonical decomposition mappings), people would have to suffer when dealing with the three hangul syllables mentioned above.

[30] >>13 は旧 Unicode 仕様書に誤植があったから、 Unicode 2.0 でハングルの大移動をやったのはとってもよかった☆っていってる。

[31] ハングルの大移動はそんな雑に正当化できるレベルのやらかしではないと思うんだが...

[32] Unicode にはもう対抗できる競合が皆無だし、こんな昔のことに今更反論してくるやつもいないだろうしで、言いたい放題だなw

[33] Index of /L2/Historical/UTCdocs-Joan-2005-09-07/UTC62 (Sept 94 Toronto @ IBM), https://www.unicode.org/L2/Historical/UTCdocs-Joan-2005-09-07/UTC62%20(Sept%2094%20Toronto%20@%20IBM)/