アカウント名:
パスワード:
Office for Mac 2016 のExcelにて、和暦表示ができない。 [microsoft.com]
MSに匙を投げられ、多くのユーザがあきらめていた日付の元号表記ですが、ユーザの試行錯誤により無事解決した模様ついさっき調べなおして知った…
まあMacでMS Office 使うとか情弱と言われてもしかたないけど、なんだかなあ、、
和暦問題にはこんなものも・・・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]にて1面13区 [wikipedia.org]としてコレを追認してしまった。
後どうもCJK互換用文字は丸ごと「使用は推奨されない。」 [wikipedia.org]らしい。参考資料リンク先の何処で非推奨と書いてあるかはわからんかった…一応チャプター22 Symbols [unicode.org]の805pにある「Note that～」の下りで「版組システムで字を並べたほうが良いよ」ってざっくりした事は言ってるけどそれのことだろうか。
でも、在ると無いとでは修正の手間が結構違うからなあ。㍻、㍼、㍽、㍾のコードポイントが並んでいることを利用しているようなロジックだったら、しらんがな状態になるけれども。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
Excel 2016 for Mac 和暦問題 (スコア:0)
Office for Mac 2016 のExcelにて、和暦表示ができない。 [microsoft.com]
MSに匙を投げられ、多くのユーザがあきらめていた日付の元号表記ですが、ユーザの試行錯誤により無事解決した模様
ついさっき調べなおして知った…
まあMacでMS Office 使うとか情弱と言われてもしかたないけど、なんだかなあ、、
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:Excel 2016 for Mac 和暦問題 (スコア: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]にて1面13区 [wikipedia.org]としてコレを追認してしまった。
後どうもCJK互換用文字は丸ごと「使用は推奨されない。」 [wikipedia.org]らしい。
参考資料リンク先の何処で非推奨と書いてあるかはわからんかった…
一応チャプター22 Symbols [unicode.org]の805pにある「Note that～」の下りで「版組システムで字を並べたほうが良いよ」ってざっくりした事は言ってるけどそれのことだろうか。
Re: (スコア:0)
でも、在ると無いとでは修正の手間が結構違うからなあ。
㍻、㍼、㍽、㍾のコードポイントが並んでいることを利用しているようなロジックだったら、しらんがな状態になるけれども。