アカウント名:
パスワード:
Office for Mac 2016 のExcelにて、和暦表示ができない。 [microsoft.com]
MSに匙を投げられ、多くのユーザがあきらめていた日付の元号表記ですが、ユーザの試行錯誤により無事解決した模様ついさっき調べなおして知った…
まあMacでMS Office 使うとか情弱と言われてもしかたないけど、なんだかなあ、、
システム設定を和暦にしてもダメとか、どんな理由あればこんな仕様変更になるのか知りたいもんですね。
アイデア絡みだと言えないのは確かだが、これだとそういう可能性無いと思うしなぁ。。
2ページ目見た?ロケール設定を個別指定すると直せるってことは、ロケール設定の一部が何処かの段階で消え去ってるって事になるはず。Mac側のロケール情報を取得する辺りで英語の物を読み込んでから一部だけ日本語にしてて暦関係が死んでるとか、その手の機種依存コードの中で取り込み処理をケチってデフォの西暦で上書きしたり、デフォルトで初期化した後設定値を反映し忘れてたりとか、そんなトコだろう。
和暦問題にはこんなものも・・・https://blogs.technet.microsoft.com/jperablog/2017/09/12/%E6%96%B0%E5%... [microsoft.com]
どうせ近いうちに修正しなければならん。
そっかUnicodeに追加なんてのもありましたね。コンソーシアムで拒否られたらどうなるんだろ?w
元号用の合字とか誰がUnicodeに持っていこうと思ったのか。新元号が制定されても追加するべきではないし、㍾㍽㍼㍻もdeprecatedとすべきと思う。未来永劫追加し続けるというなら、逆に大化~慶応も用意しとけって話ですよ。
> 元号用の合字とか誰がUnicodeに持っていこうと思ったのか。合字を単一文字として持つ文字セットが既に存在していたから、だろう。単一の文字コードで既存の文字コード全てをカバーしようとしてたら入れるしか無い。 ㍾は複数の規格・符号で定義されてしまっている [wdic.org]ので消せない。
元々JIS C 6226(JIS X 0208) [wikipedia.org]やコアな(IANA登録の)Shift_JIS [wdic.org]には定義されていなかったのだけど、NECがメインフレーム用に作ったJIPS [wikipedia.org]にてJIS X 0208を元に13区にその文字を追加していて、 MS-DOS時代のCP932が放置されていた頃 [wikipedia.org]にNECがPC9801でそれをCP932の空き領域に配置して拡張、Unicodeは1.0の漢字部制定(1992年6月) [wdic.org]の際にこれらの合字をCJK互換用文字 [wikipedia.org]として採用し、MicrosoftもOEMコードページの統合(1993年) [wikipedia.org]の際にそれを13区 NEC特殊文字 [wdic.org]として採用し、JISもJIS X 0213 [wikipedia.org]にて
でも、在ると無いとでは修正の手間が結構違うからなあ。㍻、㍼、㍽、㍾のコードポイントが並んでいることを利用しているようなロジックだったら、しらんがな状態になるけれども。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
Excel 2016 for Mac 和暦問題 (スコア:0)
Office for Mac 2016 のExcelにて、和暦表示ができない。 [microsoft.com]
MSに匙を投げられ、多くのユーザがあきらめていた日付の元号表記ですが、ユーザの試行錯誤により無事解決した模様
ついさっき調べなおして知った…
まあMacでMS Office 使うとか情弱と言われてもしかたないけど、なんだかなあ、、
Re: (スコア:0)
システム設定を和暦にしてもダメとか、どんな理由あればこんな仕様変更になるのか知りたいもんですね。
アイデア絡みだと言えないのは確かだが、これだとそういう可能性無いと思うしなぁ。。
Re:Excel 2016 for Mac 和暦問題 (スコア:1)
2ページ目見た?
ロケール設定を個別指定すると直せるってことは、ロケール設定の一部が何処かの段階で消え去ってるって事になるはず。
Mac側のロケール情報を取得する辺りで英語の物を読み込んでから一部だけ日本語にしてて暦関係が死んでるとか、
その手の機種依存コードの中で取り込み処理をケチってデフォの西暦で上書きしたり、
デフォルトで初期化した後設定値を反映し忘れてたりとか、そんなトコだろう。
Re: (スコア:0)
和暦問題にはこんなものも・・・
https://blogs.technet.microsoft.com/jperablog/2017/09/12/%E6%96%B0%E5%... [microsoft.com]
どうせ近いうちに修正しなければならん。
Re: (スコア:0)
そっかUnicodeに追加なんてのもありましたね。
コンソーシアムで拒否られたらどうなるんだろ?w
Re: (スコア:0)
元号用の合字とか誰がUnicodeに持っていこうと思ったのか。
新元号が制定されても追加するべきではないし、㍾㍽㍼㍻もdeprecatedとすべきと思う。
未来永劫追加し続けるというなら、逆に大化~慶応も用意しとけって話ですよ。
Re: (スコア:0)
> 元号用の合字とか誰がUnicodeに持っていこうと思ったのか。
合字を単一文字として持つ文字セットが既に存在していたから、だろう。
単一の文字コードで既存の文字コード全てをカバーしようとしてたら入れるしか無い。
㍾は複数の規格・符号で定義されてしまっている [wdic.org]ので消せない。
元々JIS C 6226(JIS X 0208) [wikipedia.org]やコアな(IANA登録の)Shift_JIS [wdic.org]には定義されていなかったのだけど、
NECがメインフレーム用に作ったJIPS [wikipedia.org]にてJIS X 0208を元に13区にその文字を追加していて、
MS-DOS時代のCP932が放置されていた頃 [wikipedia.org]にNECがPC9801でそれをCP932の空き領域に配置して拡張、
Unicodeは1.0の漢字部制定(1992年6月) [wdic.org]の際にこれらの合字をCJK互換用文字 [wikipedia.org]として採用し、
MicrosoftもOEMコードページの統合(1993年) [wikipedia.org]の際にそれを13区 NEC特殊文字 [wdic.org]として採用し、
JISもJIS X 0213 [wikipedia.org]にて
Re: (スコア:0)
でも、在ると無いとでは修正の手間が結構違うからなあ。
㍻、㍼、㍽、㍾のコードポイントが並んでいることを利用しているようなロジックだったら、しらんがな状態になるけれども。