マイクロソフト「改元は極めて複雑な検討と作業が必要」 焦点は“合字” Unicodeに新文字登録が必要
■ このスレッドは過去ログ倉庫に格納されています
大手IT企業が新元号対応に動く、焦点は「合字」の扱い
平成が31年で終わり、2019年に新たな元号が施行されることが決まった。日本マイクロソフトをはじめ
大手ITベンダーは影響調査に動き出した。元号の表記に使う「合字」対応など特有の作業が必要になる。
元号改正まで残り500日を切った。政府は2017年12月8日、天皇陛下の退位日を2019年4月30日に定める
政令を閣議決定。2018年中に新元号が公表され、2019年5月1日以降は新元号に変わる。
元号改正をにらんでITベンダーが顧客企業のシステムや自社製ソフトの影響調査に動き出した。
焦点の1つが元号を一文字にまとめて表示する「合字」の取り扱いだ。Unicodeに新元号の合字を
登録することが検討されている。日本マイクロソフトは合字の処理方法をはじめ、同社製品の元号に
関する影響を調べる。結果に応じて同社製品の改修や顧客企業への情報提供を検討する。
合字を使っている企業はシステム改修が必要になる。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/122001253/ph01.jpg
Unicodeに新元号の合字が追加されたときの作業（日本マイクロソフトの例）
「改元は極めて複雑な、非常に多くの検討事項や作業が必要になる」。日本マイクロソフトは改元に対応した
システム関連作業についてこう指摘する。作業の一例として元号を表示する合字への対応を挙げる。
合字とは「㍻」「㍼」など、いくつかの文字を一文字で表示したものだ。
経済産業省 国際電気標準課によれば「新元号の合字にコードを割り当てる検討が始まっている」。
これまでの元号については「㍻」は「U+337B」、「㍼」は「U+337C」、「㍽」は「U+337D」、「㍾」は「U+337E」の
コードがそれぞれ割り当てられている。新元号に割り当てるコードについては、ISO（国際標準化機構）の
規格を議論する委員会「ISO/IEC JTC 1」（ISO/IEC合同技術委員会）の分科委員会で検討する。
■修正は容易だが影響調査が難問
日本マイクロソフトによれば「製品やバージョンが多岐にわたるため、影響の大きさや具体的な内容はまだ
分からない」。Office製品であれば新元号の合字を表示・変換する機能の開発、SQL Serverであれば和暦と
西暦の変換テーブルに新元号を追加する修正作業などが考えられる。
富士通は新元号のシステム対応について、「個別開発したアプリケーションの影響を特定する洗い出し作業に
手間がかかる」と話す。「元号改正による修正作業そのものよりもテストの工数が増えそうだ」（同社）。
システム環境を2019年5月1日以降の未来日付にして、修正内容が正しいかを画面や帳票などで確認する。
NTTデータも元号改正による修正作業そのものは「限定的」（同社）とみる。システム内部で保持する西暦日付を
和暦日付に変更するテーブルの修正などが必要とする。
「影響は軽微」との見方もあるが、油断は禁物だ。残り500日の使い方が問われる。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/122001253/ 半角ｶﾅ含めて機種依存文字使う奴はＰＣ使う仕事しないで欲しい 和暦廃止しろよ。天皇が変わる度にシステムをコロコロ変えてたらキリがねぇわ。 2019年は消費税も上がるし、色々めんどくさい年だな そもそも要らない空いてるから作ったならわかるが元々一文字で打てる必要性は無い ハングルといい、東アジア系の文字は組み合わせた状態の文字もコード上に登録しないといけない決まりでもあるんだろうか
南アジアや東南アジア系の文字だと基本的なパーツ(漢字でいう偏)だけをユニコード上に登録して、複雑な文字もそれらの組み合わせで表現している
東アジア系の文字もそうすればいい。
「平」と「成」という文字がすでにコード上にあるのに、「平成」という文字をわざわざ登録する理由がわからん >>16
列島猿にはドキュメントや帳票を方眼紙ベースでデザインし、情報をギチギチに詰め込みたがる習性がある
だから一文字が二文字になるとレイアウトが完全に破綻し、SE族の猿が方眼紙を必至で弄って作り直す羽目になるの
半角カナが無くならないのも等幅フォントが好まれるのもそのせい 使ってるの見たことねえけどな
単位とかならまだしも それより消費税が上がる時に電卓の設定変える方が面倒くさい 元号は儀礼的な意味だけで残して
公文書での使用はさっさと廃止すべき ㍾337E
㍽337D
㍼337C
㍻337B
新元号337F
順番的に何となく気持ち悪いんだが、なんで明治337B→平成337Eにしなかったんだろうか？ >>1
それよりWin10のバグを早く治せやアホ！ “㍿” U+337F なので明治を新年号にするかな >>1
最初から次の元号ように割り当てとけよ。
無能なのは誰だよ >>4
こんな馬鹿が営業になるからデスマなどが生まれる >>21
お前は行政手続きを自分でした事のないカスニートだと自己紹介してるんだぞ？ 新元号をｷﾛにすればよい
MTSHにも引っかからない >>1
もう無視すればいいよ
西暦で統一できない辺境の独自制度を取り込む必要などない 公文書の年表記は原則元号だからしょうがない
元号はここで終わりってんなら今がまさにチャンス ㍾
㍽
㍼
㍻
こんなのあったのか
別に必要ないだろ >>36
二文字にしちゃいけない理由ってなんなんだろうな
仮に3文字以上の元号が生まれたらどうするつもりなんだ？ JISが諸悪の根源じゃね？
使いもしない文字を定義して後々問題起こすとか（笑） 何処に需要が有るんだ？
無くても問題無いから、廃止しろ。 >>8
それ言ったら、西暦だってキリストが変わるたびにコロコロ変わるだろ。。。理論上は >>38
むしろ、ジャストシステムが復活する最後のチャンスかも これからは一文字でやりゃいいんだよ
今の時代影響考えろ 合字使う利点においてデメリットのほうが圧倒的に大きいって話なのこれって？
合字使うことで余計な仕事増やしてるだけじゃん。 >>42
本当そうだよね。
昔からある、ＤＯＳでのドットインパクトプリンターですら使わない。
だってあれは、コントロールコードに縦半分縮小文字モードがあるから。
一体誰が使うんだろう？ >>46
>余計な仕事
多分これが目的
食いぶち確保 >>44
縦書きならまあね
ワードの縦書きがゴミすぎるから 決めるんなら早く決めてくれ
システム改修が間に合わなくなるし 基本は西暦で管理して表示用だけ変換用クラス１個作ればおｋ
漢字なんて近い常用漢字でも使っとけ ｲﾔｧｧｧｧｧｧ
Unicodeの文字割り当ての必要まであんのか、めんどくせぇなぁ
予約領域ねーんだろうなぁ むしろイチイチフォント起こす必要あんの？
漢字２文字でやりゃあいいじゃん >>25
作った順番なのかも。
㍻337Bが一番最初にできた >>57
ほらやっぱり空きがない！
もうその次の年号は「ｐＡ」にしよ…… >>43
今、67代目キリストだけど何も変わってないな 将来面倒なことになるのは予想できるんだからこんな合字を作るなよ 「合字をつくらないとダメだ！」って最初に言いだしたバカはどこのどいつなんだよ >>17
そう言う奴に限って、 昭和を懐かしむ とか言ったりする。 個別開発とか30年前のもん資料あんの？
まあ、30年間動いてるようなもんはレアだろうけど普通に5年位で担当者いなくなったりするだろうから大変やな。
NTTのコメントは楽観的過ぎないか？変換テーブル利用が全ての案件で義務付けられてるもんなの？ >>69
どうなんだろね。印刷スペース都合で印字する時だけ変換したりして。
あ、そうしたらプリンターも対応しないといかんのね。 >>57
明治を置き換えればいい
もう明治生まれで生きてるの居ねーだろ？ まともなシステム屋は合字なんて知らないし使わねえよ もう廃止で良いじゃん
元号なんて誰も必要としてない >>75
漢字はUnicodeでもsjisでも独自の拡張コードの範囲や標準でデコード出来なきゃいけない範囲が決められている。
その狭間みたいな領域もある。
合字はその狭間に定義されたコードだよ。
一応各社合意で決められているが必須ではない。 Unicodeに登録されてるの今知ったわ
一度も使ったことねーわ
いらねーだろこれ モリサワとかも大変なんじゃないの。フォントメーカーはそうでもないのか その昔、フロッピー1枚でOS起動してワープロ起動して日本語変換して文書作成して保存できる時代があってだな
そのころは漢字の情報をパソコン側がオンボードに搭載してたんだ >>84
逆に、合字に対応してて、活用する客がついてるフォントなら、サブスクリプション更新のチャンスになる。 >>74
とっくに死んだ故人の記録にも普通に使うからそれはできない 新しい元号が決まっても合字はいらないだろ。普通に漢字入力すればいい。 区点コード13区にはまだ空きがあってそっちは何の問題もない
ややこしいのはUnicodeのほう 要するに、金の成る木だな。
雇用創出しまくりだな。 表示は間に合わなくても割り当て予定のUnicodeの所に「新元号」っていうフォントを合字で作って入れておけば？ この際、Unicodeは大化から慶応まで合字作って30個ぐらいは空きにして元号用に区画確保したら？ >>93
JISもUnicodeも、とりあえずアドレス用意するところからだから大変
Unicodeは近くに空いてるアドレスないから新規に合字領域確保するところから
しかも最近は内部的にUTF-8が多いから、JISコードだけ定義されても文字化けして使えないかと(最近のブラウザだとShift_JISで文字未割り当ての字を打ち出すと文字化けする) トボケた機能ばっか追加しては喜んでるのに
合字やめます！需要ないっしょ！っていう思い切りはできないMS >>60
キリストは立川に引っ越してきたからすでに和暦扱いだぞ >>18
政府機関は和暦で統一でしょう。
我々の生年月日も和暦で登録されているはず。 >>85
世界を和暦で統一すべきだな。
陛下には世界帝になっていただこう。 ゴミみたいな絵文字を大量に登録できるんだから、天皇の象徴くらい登録できないわけないだろ？ 元々２つの漢字を合わせて作られてる漢字を元号にすればいいんだよ。
麻＋呂＝麿 とか 久＋米＝粂 みたいに。 こんなのいちいち登録しなくても良いだろ
合同会社
もあるのか？ 平成31年と新元号元年が同じ年っていうのが地味に嫌だな
昭和64年と平成元年もそうだけど
合字は止めれば良い それより
ミリバールをヘクトパスカルに
直してくれ
㍊ 元号とか世界でジャップしか使ってないシステム廃止しろよ >>1
アホ氏ね
おまえらソフト産業界に収益アップの機会を与えてるのに
有難く思え MS 「従順な日本人にはWindows7をここで捨ててもらうとするかな、ははは」 >>3
こういわれたら、そっすねじゃあポンと追加しときまーすと言って追加しとけばいい これ新元号発表されるまで手が出ないじゃん。半年前らしいけど
しかもわかってから認証/実装するまで半年でできんの？ｗ
コレだから日本はIT音痴なんだよ 合字いくつかさがしてみた
鮎 さかなうらない
轄 こうつうじこ
煌 フレイムカイザー
? はげあたま >「㍻」は「U+337B」、「㍼」は「U+337C」、「㍽」は「U+337D」、「㍾」は「U+337E」
ユニコードにこういうバカ字組み入れた奴の首を絞めたい
絵文字も同様 元号一文字にすれば
良いんじゃないか
というか早く発表すればいいのに >>1
そもそもUnicode作ったとき英字に比べて遥かに種類の多い漢字に僅かなコードしか割り当てなかったやつが悪いんだろ
しかも異なる漢字に同じコード割り当てるとか
設計したやつはバカしかいないんじゃねぇかと思うよ だからダブルスタンダードの年号なんてやめろよったく後進国 >>8
案件できるからいいだろ
ケチな経営者にシステム更新させる理由になってホッとしてる営業も多い >>127
作った時は足らなくなったら未来のやつがなんとかするだろって感じだったんやろな >>128
さすが、自国の歴史を持たない植民地人は言うことが違うなｗ >>103
そうなのか
よくわからんけど西暦から和暦引っ張る方が効率的な気がするけどなあ ユニコードで年号とか 皆さん使われているんでしょうか？？
いらないやつ 1個削ればいいじゃん 順番じゃないと使いにくいの？ >>89
なんで 明治 という2文字じゃあかんの？
あかん場合ってどういうケース？ 隠れ共産党員というか元号廃絶主義者=皇室廃絶主義者が見事にあぶり出されましたね。 >>133
西暦から和暦へは日付で元号が変わる場合があるけど
和暦から西暦の変換は年号だけで決まるから後者の方が楽でしょ 時代に合わない憲法は変えるし、
時代に合わない和暦も辞める。
これでおけ DB上は西暦でいいじゃん。
入力と出力だけ元号表示にすればいいだろ。
うちの会社のDBはそう組んでるぞ。 伝統を守るというのはコストがかかるんだよね。
効率化するなら一切の伝統を捨て去ることですな >>140
西暦での一括管理だと再利用しやすいし
変換もプログラムでやる分には手間かかっても困らないからうちも同じ
新たにシステム組むときでもDBは西暦で設計する >>120
普通なら天皇が突然死んですぐ対応しなきゃいけないんだよ
今回は特例措置で生前退位が認められたから全然楽な方
これで大変だというなら辞めろ 改元なんて分かっていたことなのに、なんで最初から対応出来るように作っておかないんだ
アホしかいないのか ネットにあるgo.jpとかの文章ほとんどが元号で
平成32年とか書いてあるのあるけど
ああいうのどうすんだろ
役所はマジでアホだろ 組み文字なんか使わなければいい。
互換性のために今のコードは残しても、新規に追加する必要なんてない。
有限のコード範囲を改元のたびに消費することに無理がある。 普通の漢字で書けばいいだろ
それと、クソ可愛くもない顔文字追加すんのももうやめろ で、シフトJISの愚行をまた繰り返すんだろ？
あ、でも今は純日本産のマシンなんか無いから無理か。 なぜ1文字じゃないといけないのかという合理的理由が何もないだろ >>3
こんなこと言うのうちの上司だけじゃなかったんだな 超簡単じゃね？
元号変換テーブルに追加するだけだろ >>153
バカなSEが将来の事をまったく考えていないシステムを作っている可能性があるからでしょ
ホント そんなのほっときゃ良い >>155
修正は簡単だが影響調査やテストが大変
一通りのシステムが問題なく稼働することを確認するのはしんどいんだぞ >>157
帳票システムは場所の奪い合いになる事が多いから1文字分減らして辻褄合わせようと考える輩もいるかもね なんでシステムエンジニアの「しんどいんだぞ！」を
受け入れなければいけないのか。
「知らねーよ。直ぐにやれ。お前の仕事だろ？」が
世間一般の見方。 >>7
いまどき半角カナが機種依存とか、君、MSXでも使っているのかな？ >>162
世界中のローカルまで入れちゃおうかなぁ ってのがそれだから >>158
いや、すでにライブラリもあるし、テストなんてそんな大変じゃねえぞ。
ただ、COBOLでDB直結とか未だそんなところもあるから、そういうところは大変なんだろうけど。 最近和暦を全部西暦に直してくれって言われてる
最初から西暦にすりゃよかったじゃないか >>161
まじでそう思うわ
システム系の仕事のやつの
「客が理解を示せ！俺たちは大変なんだぞ！」という傲慢な態度がすげえ勘違いしててキモいわ
特にネット上で声のでかいバカなシステム屋ども >>5
システム上で和暦管理してるシステムなんか有るわけないやろハゲ
西暦和暦変換は、契約書や生年月日などを印字、画面表示する時に発生する。 >>68
３０年前って１９８７年か。メインフレームやったらチョコチョコありそう。
１９９７年やったらＶＢ出てるからオープン系でいっぱい今でも動いてる >>174
宇宙大帝 Σ Σ GodΣ パッパン♪ >>164インドネシアの少数民族の100年前から使わなくなった文字とかも沢山入ってるしな でも、明治、大正、昭和、平成…どれもそれ自身が１文字である必要無いんだよなぁ 暫定的に西暦で運用しろよ
そしてそのままなし崩しに… ㍻29年12月25日?
そういや昔①とかの丸数字を含んだ書き込みをしたらマカーが発狂してたよな >>3
本文にも修正自体は容易って書いてあるのにな
何故か発狂してるエアエンジニア様方きめぇよな 元号なんか使うバカ企業はシステム開発なんかやめちまえよw この際元号なんて廃止してしまえよ
何もメリットないわ >>191
後平成天皇ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ >合字を使っている企業はシステム改修が必要になる。
意訳「金くれ」
昭和から平成へ変わった時に学習していないシステム屋は無能ｗ >>3
チョンの次の年号は「ポン」なのか(´･ω･｀) >>57
大漢民族の大移動に近い移動が起こりそうな気配 >>194
「次変わった時もまた改修費用請求すればその分売上が増える」 >>147
金融もそうだぞw
ローン契約書の最終支払日は平成47年とか書いてあったりするw
経理の人間が馬鹿なせいでそうなってるのかは知らん ■ このスレッドは過去ログ倉庫に格納されています
