macOSは新元号に対応するんですかね?情報が無いよ
■ このスレッドは過去ログ倉庫に格納されています
あのさ、Apple。東方の小さな島国の年号だからって軽く見てやしませんかね? >>87 macOSのカレンダーによると大化-644年ですね 天文学では西暦使いにくいのでJulian date使う西暦紀元前4713年が原点。 シュメール文明の最初とかエジプト古王朝の初めとだいたい一致するが、特に意味は考えてはいけない。 >>46 Windowsはすでにレジストリに定義が付加されてる。 文字コード(合字)が決まったらそこにアプデパッチで対応。 合字って、ユニコードで元号が1文字になってるやつのこと? (平成 -> U+337Bとか) 場所はもうU+32FFに予約されてるみたいだけど。 今後フォント的にその情報を足さないといけないのか。あとユニコードの正規化情報も。 U+32FFって、◯ + ヲの後のかろうじて一つだけ空いてた場所に無理やり突っ込んだ感は否めないw ここらへんの記号の類の場所は既にギチギチで、数十年以内に次の元号が来るはずだが、 その時はどうしようもなさそう。もうBMPから外れてもいいかもしれんけど。 あるいはその頃にはユニコードも違うものになってたりするだろうか。 そうですか、初耳です。よろしければなぜ合字と呼んではいけないのかと。 >>96 > 今後フォント的にその情報を足さないといけないのか。あとユニコードの正規化情報も。 どうせUnicodeは毎年のようの文字が増えてる あとBMP内の日本語の領域でも空きはあちこちあるだろ そんな都合よくぴったり収まってるわけないんだし > Unicode 毎年バンバン増える絵文字に対応する手間に比べたら 実際のところ一文字増やす手間くらいどうってこともない 新元号をいちいちフォントに追加するのか!とか騒いでる人いるけど 年号の合成文字より絵文字の方が使用頻度としては明らかに少ないからね そういうことをいう人はまずは絵文字について問題視する方がいい 実際少数民族の言語ほったらかしで絵文字が先かよ!という批判もある あるけど、ならそう思うヤツがとっとと提案しろやってのがコンソーシアム的対応 >>100 お前は日経のそんな記事を真に受けてるのかw だから U+337B とかは 「リガチャ(合字)」 ではないんだよ >>100 の記事を書いてる田中 陽菜ってのも合字が何なのかわかってないんだろうな >>106 間違っているというか カギ括弧つきで「合字」と書いてあるように本来の意味ではないってことでしょう ただ読者には説明としてわかりやすいからね >>107 さんのこだわりもわかるがアドビも合字と表現したプレスリリースを出した https://www.adobe.com/jp/news-room/news/201904/20190401-adobe-newera.html まあリガチャはリガチャであって日本語の合字とは違うぜっていわれそうだが NKFDで正規化すると~が平成になるから一応Unicode的には合字扱いなんじゃないかな 学問的には合字って言うと本来は麿みたいなやつを言うんだろうけど NSString *str = @"\u337b"; NSLog(@"%@,%@",str,[str decomposedStringWithCompatibilityMapping]); 広義の合字(盾ニか_も含む)と狭義の合字(Unicodeのリガチャ)をごっちゃにしてマウントしあって虚しくねぇか?w もう一度言うけど U+337B とかは 「リガチャ(合字)」 ではないんだよ >>108 の記事を書いてるアドビってのも合字が何なのかわかってないんだろうな Windowsだと○○1年は元年と表示できるみたいね。macOSは単に1年だったかと。ちょっと負けてるw macOSのカレンダーで遊んでみたが、年表示の場合1989年は単に昭和64年となるのね。 日数的には平成だし、さらにいえば昭和64年/平成元年 などと表示すべきかなと。 理論上2つ以上の元号もありうるんでそういうコードにするということでw >>112 OSXのロケールはNEXTSTEP由来だったのでかなり頑張ってた方で 旧OS9に比べるとちゃんとしててスゲーなと思っていたのもつかの間 アップルがさぼっている(かどうか知らないが)うちにWindowsに抜かれた https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_5_beta_2_release_notes >Support for the Reiwa (令和) era of the Japanese calendar, which begins on May 1, 2019, is now available. >The first year of Japanese-calendar era is represented as “元年” (“Gannen”) instead of “1年”, except in the >shorter numeric-style formats which typically also use the narrow era name; for example: “R1/05/01”. (27323929) 令和も元年対応もICU由来なんでしょ多分。新しいICUを移植しましたって書けばいいのにw でもあれか、ライブラリ的にちゃんとインターフェースを出してなかったり、あくまでも内部のこと、 ということになってるのか。MeCabなんかと同じで。さすがApple様w >>114 結局このアップデートは令和になるまでに出るのかな? そしてMojave以外は? もしかして現在中の人が最終チェック中? とりあえずMacの日付設定を和暦にして待つとするかw >>112 Windows OS本体の初期値は"1年" → レジストリの変更により"元年"に設定可能 .NET Frameworkの初期値は"元年" ユーザーの憶測では4/10のWindows Updateで対応すると思っていたが未対応 MSのコメントでは連休前(4/26)には対応したい遅れるかもと言っていたが 明日に配信されるようには思えない Windowsはレジスリにキー追加するだけで対応可能 アプリはまた別の話 アプリの件はmacOSやiOSも同様というかxcodeが対応しないとというレベルで もっとひどいよw >>117 まあ、所詮、連休前に対応してくれるかもっていうのは 日本政府の希望的観測ですからねw MSの方をチラチラみながら、ほら前倒ししたよ? 対応してくれるよね?ね?っていっても MSからすりゃ、そんな約束してないし知らんがな。なんだろうねw ぶっちゃけ遅れてトラブルになってほしい。 そうすりゃシステム対策には時間がかかるって 馬鹿にも理解できるやろ >>119 Xcodeは古いままでも問題ないから。しかるべきコードを書いてれば自動的に新元号に対応する。 ベータ版のiOSとmacOSで令和って表示できたよ。 コード書いてベータ版のiOS入れたiPhoneでも問題なしだった。 セキュリティホール残したままで新API対応不可 あまつさえしてAppStoreでの利用禁止なのに何言ってんだw OSの新元号対応より日本語変換の新元号対応して →ATOKは4/18に対応済み >>126 単に単語登録すればいいと思うが。 細かいことを言うと、macOSの日本語変換だと変換候補の意味表示を更新したりする必要が あるのか。 令和 -> 年号(2019年5月1日〜)。今上天皇の時代。
平成 -> 年号(1989年1月8日〜2019年4月30日)。...の時代。 おっとっと、この最後の部分は? もう最終的な称号がどうなるかは決まってるんだっけ? 今までの経緯からすると平成天皇に なりそうだが... そのタイミングって? もしかして崩御後? とりあえずは太上天皇? >>127 >単に単語登録 それだと、「あした」「きのう」で変換できない >>128 平成は諡号になる予定なので、今はまだ使えない。 上皇殿下だっけ? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる