337A;<square>;0049 0055 # SQUARE IU => LATIN CAPITAL LETTER I + LATIN CAPITAL LETTER U 337B;<square>;5E73 6210 # SQUARE ERA NAME HEISEI => HAN5E73 + HAN6210 337C;<square>;662D 548C # SQUARE ERA NAME SYOUWA => HAN662D + HAN548C 337D;<square>;5927 6B63 # SQUARE ERA NAME TAISYOU => HAN5927 + HAN6B63 337E;<square>;660E 6CBB # SQUARE ERA NAME MEIZI => HAN660E + HAN6CBB 337F;<square>;682A 5F0F 4F1A 793E # SQUARE CORPORATION => HAN682A + HAN5F0F + HAN4F1A + HAN793E
どこで利用? (スコア:0)
元号の合字使ったことがないけど、どこで使ってるのだろう?
Re:どこで利用? (スコア:0)
帳票の業界ではメジャーって聞いたことがあるな。
個人的にはcollationアルゴリズムの隙間に入ってこられるのが嫌な感じだけど。例えば、「㍻31年」って文字列を入力したら「平成31年」って返すような関数があったとして、自分では簡単に令和版に対応できても上流の行程を考えると手が出せなかったりするわけで。
https://www.unicode.org/Public/UCA/12.0.0/decomps.txt [unicode.org] (閲覧注意:600KB弱のテキストファイル)
とかを先に対応してほしい。それまでは合字のコードポイント自体を使ってほしくないしフォント配布も待ってほしい。
Re: (スコア:0)
5月7日にUnicode 12.1.0 [unicode.org]が出てそのときにCollationも更新される。逆にそれまではU+32FFもまだ正式に割り当てられていないので、Adobeのこれはフライング
Re: (スコア:0)
フライングというより、経産省が4月5日付で、U+32FFに令和の合字が割り当てられると出してますがな。
新元号名で使用する文字コードについて(周知) [meti.go.jp](注:PDF)
# 現時点では、Adobe以外ではダイナフォントが4月3日から一部のフォントで対応 [dynacw.co.jp]している模様。
Re: (スコア:0)
経産省の発表自体がフライング。JIS X 0213:2000のときも、当時未使用だったBMPのコードポイントを(括弧付きとはいえ)勝手に使っていた前科があるしな(今でも住基統一文字コードがJIS X 0213:2000の括弧付きコードポイントに基づいた割り当てを使用している)
Re: (スコア:0)
じゃあ、Adobeのフライングじゃなくね?
経産省がやっちまっただけで。
Re:どこで利用? (スコア:1)
Adobeが経産省の発表を見て対応したなら経産省に責任をなすりつけられるかもしれないけど、経産省の発表が4月5日付なのに対してAdobeは4月1日には速攻で発表していた [adobe.com]ので無理。残念でした。
Re: (スコア:0)
http://blog.unicode.org/2018/09/new-japanese-era.html [unicode.org]
まず2018年9月6日の時点で、Unicode consortiumがU+32FFを新元号の合字に割り当てることを発表しています。経産省もAdobeもそれに基づいて行動しているはずです。とは言え、5/7予定のUnicode 12.1.0が出るまでは、経産省もAdobeもどっちもフライングであるというべきなのだと思いますが。
Re: (スコア:0)
施行がまだなだけで実質決まってるんじゃない?
法令上はほんとは今は平成31年5月1日とか、平成40年1月1日と表示するのが正しいけれど、
システム改修の都合上、2019年4月以前は未来の日付も平成、2019年5月以降は未来の日付は令和と表示するのが煩雑だからと
いまから令和元年5月1日とか令和10年1月1日と表示しちゃうのと同じようなもん
Re: (スコア:0)
システム改修の都合って言うけど、上のコメントにもある通り、バグ発生の可能性を抑えたいなら今は使わない方がいい。