Japan New Era Name Support Blog https://docs.microsoft.com/archive/blogs/jperablog/feed.xml 日本マイクロソフトの新元号 (和暦) 対応に関するサポート情報のブログです Wed, 28 Nov 2018 03:14:50 GMT ja hourly 1 新元号対応に関する情報提供方法につきまして https://docs.microsoft.com/archive/blogs/jperablog/new-channel-for-information-about-the-japan-era-change Wed, 28 Nov 2018 12:12:53 GMT https://blogs.technet.microsoft.com/jperablog/?p=285 (English follows Japanese) マイクロソフトでは、2019 年の新元号への変更の重要度を高いと考えており、この変更に対応するため会社全体にわたり取り組んでいます。今後数か月の間に、弊社のパートナーの皆様やお客様と連携して、この新元号の変更によって必要となるアプリケーションと IT システムにおける調整に向けて準備するお手伝いをいたします。 マイクロソフトの新元号対応に関する製品、サービス、および、テクノロジーに関連する情報は、以下のサポート技術情報をご確認ください。このサポート技術情報は、マイクロソフトの新元号対応に関する集約的な位置づけのページであり、必要に応じて更新致します。ここから、各製品、サービス、テクノロジーごとの詳細な情報を入手できます。   2019 年 5 月の新元号の変更についてのアップデート https://support.microsoft.com/ja-jp/help/4470918/ https://aka.ms/jpera   今後は、新元号に関する情報は、上記サポート技術情報を通してご提供してまいります。 ----------------------------------------------------- Title : New channel for information about the Japan era change   Microsoft considers the Japan era change of high importance and is working across the company to prepare our solutions for the 2019 change. In the months ahead, we’ll work with our partners and customers to help them prepare for the adjustments in applications and IT systems this era change will require.    The following Microsoft Knowledge Base (KB) article provides information about the Japan era change for Microsoft products, services and technologies. This article is a centralized page for the Japan era change and will be updated as needed.   Updates for May 2019 Japan Era Change https://support.microsoft.com/en-us/help/4470918/ https://aka.ms/jpera_en   Going forward, Japan era updates will be provided in articles in the Microsoft Knowledge Base channel.]]> 新元号検証ラボと新元号に関するセミナー開催予定のご案内 https://docs.microsoft.com/archive/blogs/jperablog/testlab Tue, 09 Oct 2018 02:58:57 GMT https://blogs.technet.microsoft.com/jperablog/?p=265 お申込み: 新元号対応で求められる開発、展開と運用における対応]]> Windows 10 Version 1803 における新元号の仮定義の削除について https://docs.microsoft.com/archive/blogs/jperablog/april2018update-placeholder-deletion Fri, 21 Sep 2018 00:00:24 GMT https://blogs.technet.microsoft.com/jperablog/?p=255 本 Blog 4 月の記事でもお伝えしてまいりました。 その後、個別に本レジストリ値の追加や削除を実施されたいというフィードバックを頂戴し、手順や .reg ファイルのご紹介を行ってまいりました。 アプリケーションの互換性の向上と、さらに柔軟に検証等をご実施いただくことを目的として、日本時間 9 月 21 日よりご提供を開始いたします Windows 10 Version 1803 向けの更新プログラム KB4458469 により下記スクリーン ショットにございます仮定義の削除が行われます。検証や開発等に必要な場合には、個別に追加をご検討くださいますようお願いいたします。 なお、今秋よりご提供を開始いたします予定の Windows 10 Version 1809 では、この仮定義は含まれない状態で出荷される見込みです。 新元号の公表後、弊社よりご提供いたします更新プログラム等により新元号の定義となるレジストリ値を追加いたしますため、一般のユーザー様において手動で値を追加いただく必要は通常ございません。 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] 手順等の詳細は、こちらの記事をご参照ください。 --- To make it easier for customers and partners to prepare for the Japan Era change, customers will now be able to control when they add the placeholder registry entry to their systems – choosing the timing that meets their needs. In the spring release of Windows 10, a default registry value was available as a mechanism for testing. As a next step to help provide an opt-in option, the default value is removed in the September update, and customers will be able to opt-in at their convenience. The Windows registry key value that defines the era names for the Japanese calendar support is in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] This registry value that defines the era behavior is editable by an administrator using regedit or other tools. With the September update, there are 4 string values for the eras. You can add a new value in the format "yyyy mm dd" followed by a temporary name information with [two Kanji character name]_[first Kanji character]_[Latin full name]_[Latin short]. For example, for Heisei it is "1989 01 08"="平成_平_Heisei_H".” For further details, please see Shawn’s blog August. ]]> 弊社製品の新元号対応予定について https://docs.microsoft.com/archive/blogs/jperablog/microsoft-products-newera-schedule Fri, 20 Jul 2018 18:00:35 GMT https://blogs.technet.microsoft.com/jperablog/?p=235 新元号への対応についてのアップデート 記事にて以前よりお伝えしておりますが、 例えば "合字への対応" や "正規化" への対応については、新元号が公表されて以降に開始する必要があるためです。 弊社では可能な限り前倒しでの対応を進めますが、具体的な時期については引き続き本 blog 等で随時お伝えしてまいります。 なお、SQL Server 製品につきましては、製品サポート チームでの調査結果を公開済みとなっております。併せて下記 Blog もご参照いただけますと幸いです。 元号／和暦 の変更に伴う影響について (SQL Server, Azure SQL Database, SQL Data Warehouse) ]]> 新元号プレースホルダーのレジストリを個別に削除、追加する方法について https://docs.microsoft.com/archive/blogs/jperablog/delete-reg Mon, 25 Jun 2018 10:46:23 GMT https://blogs.technet.microsoft.com/jperablog/?p=175 4 月の記事でもご紹介しておりました。 本レジストリについては、削除、追加を個別に行われたいというフィードバックもいただいており、今回は同レジストリの削除、追加を簡単に行うための .reg ファイルをご紹介します。 なお、レジストリの変更を伴う操作であるため、対象のコンピューターに対する管理者権限が必要となります。 また、レジストリの誤った変更はシステム全般にわたる重大な問題を引き起こす可能性もありますので、ご利用に際してはお客様の責任のもと、十分ご注意くださいますようお願いします。  

削除する方法

1. 以下の “delete_new_jpera.zip” をダウンロードして、右クリック メニュー [すべて展開] を選択してファイルを展開します。 delete_new_jpera 2. 展開された "delete_new_jpera.reg" をダブル クリックして実行します。 3. ユーザー アカウント制御のダイアログならびに、レジストリ変更に関する警告ダイアログが表示される場合は、それぞれ [はい] を選択して実行してください。  

追加する方法

1. 以下の “add_new_jpera_placeholder.zip” をダウンロードしてダブルクリックして実行します。 add_new_jpera_placeholder 2. 展開された "add_new_jpera_placeholder.reg" をダブル クリックして実行します。 3. ユーザー アカウント制御のダイアログならびに、レジストリ変更に関する警告ダイアログが表示される場合は、それぞれ [はい] を選択して実行してください。  

確認方法

作成した .reg ファイルが意図したように動作しているかを確認するには、レジストリ エディター (regedit.exe) を使用して、対象のレジストリ キー [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] を確認し、“2019 05 01” のエントリが削除、または追加されているかどうかをご確認ください。  

ご注意事項

冒頭で述べましたように、本レジストリの削除や追加には対象のコンピューターに対する管理者権限が必要となります。 管理者権限を持たない一般ユーザーで .reg ファイルを実行すると、削除の場合 (delete_new_jpera.reg) はエラーが表示されず、削除が成功したように見えるメッセージが表示される動作となりますが、実際にはレジストリは削除されていない状態となりますのでご注意ください。 追加の場合 (add_new_jpera_placeholder.reg) は権限不足により追加に失敗した旨のメッセージが表示されます。 分かりづらい動作となっており申し訳ありませんが、実際にレジストリが削除・追加されたかどうかにつきましては、上述の "確認方法" のとおり、レジストリ エディター (regedit.exe) を使用する方法にてご確認ください。 ]]> .NET Framework の新元号対応予定について https://docs.microsoft.com/archive/blogs/jperablog/netframework Mon, 25 Jun 2018 10:08:30 GMT https://blogs.technet.microsoft.com/jperablog/?p=165 変更内容 現在、マイクロソフトでは .NET Framework のクラス ライブラリの新元号対応に関して以下の 2 点の変更を予定しています。

変更 1.

各元号における最終年を超えた和暦表現の文字列 (平成 32 年、昭和 65 年など) を日付型オブジェクトに変換する際の緩和措置

変更 2.

.NET Framework 3.5 においても、和暦計算時に元号情報のレジストリを参照するような変更

  それぞれの詳細について、以下にご案内します。    

変更 1. について

.NET Framework では、System.DateTime.Parse メソッドや VisualBasic の CDate 関数など、和暦表現の文字列を DateTime などの日付関連のオブジェクトに変換する処理において、”昭和65年1月1日” のような各元号の最終年を超える日付に対しては、System.FormatException やSystem.InvalidCastException といった例外をスローする動作となっていました。 今回、元号のレジストリが追加されたことによって .NET Framework でも平成は 31 年が最終年であると認識するようになりますが、これにより、レジストリが追加される前までは問題なく処理されていた “平成32年1月1日” といった和暦表現の入力も例外を発生させてしまうことが想定されます。 しかしながら、昭和65年や平成32年といった表現は、法令上無効なものではなく、本来は例外をスローすることなく処理されるべきものでした。 これを踏まえ、本変更にて “平成32年1月1日” や ”昭和65年1月1日” といった和暦表現に対しても例外をスローせずに正しく処理するよう修正が加えられました。   なお、上記のような動作を望まないアプリケーションに対しては、更新プログラムの適用後でも、以下のような設定を適用することで、従来の動作と同様に例外をスローさせることが可能となっています。   - .NET Framework 4.6 以降のアプリケーションで変更 1. の動作を無効化する方法 アプリケーション構成ファイル (***.exe.config) の <runtime> 要素に、以下のような <AppContextSwitchOverrides> 要素を記述します。 本設定は .NET Framework 4.6 から提供されている AppContext の機能を使用して本変更をオプトアウトするもので、アプリケーションごとに設定可能です。 <?xml version="1.0" encoding="utf-8"?> <configuration>     <runtime>            <AppContextSwitchOverrides value="Switch.System.Globalization.EnforceJapaneseEraYearRanges=true" />     </runtime> </configuration>   - .NET Framework 4.5.2 以前のアプリケーションで変更 1. の動作を無効化する方法 以下のレジストリ値を設定します。本設定は対象のシステム上で動作するすべての .NET Framework 4.5.2 以前のアプリケーションに対して本変更を無効化します。 キー : HKEY_LOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext 名前 : Switch.System.Globalization.EnforceJapaneseEraYearRanges 種類 : REG_SZ データ : 1  

変更 2. について

.NET Framework では、これまで、西暦に対応する和暦の算出方法がバージョンによって以下のように異なっていました。

.NET Framework 3.5 (2.0/3.0 も含む)

モジュールにハードコードされた情報をもとに算出

.NET Framework 4 以降

レジストリ (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras) に定義された情報をもとに算出

  このため、Windows 10 April 2018 Update で追加されたように、上記のレジストリに新しい元号の情報が追加されたとしても、.NET Framework 3.5 アプリケーションではその情報が利用されることはありませんでした。 本変更では、.NET Framework 3.5 についても .NET Framework 4 以降と同様に、上記のレジストリを参照して和暦を算出できるよう修正が加えられています。 これにより、各種書式関数における和暦の処理や、System.Globalization.JapaneseCalendar クラスの GetEra メソッドや Eras プロパティなども、上記レジストリの情報に基づいて処理を行うようになります。    

リリース予定について

上述の変更 1. および 変更 2. について、Windows 10 April 2018 Update を対象として (*1)、以下のスケジュールにてリリースを予定しています。  
  6/26 (火) 7/10 (火)
変更 1. Optional の更新 (*2) 重要な更新 (*3)
変更 2. Optional の更新 (*2) 更新には含めず取り下げ (*4)
※ 日付はいずれも米国時間です   (*1) Windows 10 April 2018 Update 以外の OS に対しても順次更新が提供される予定です。提供予定が決まり次第、本ブログでご案内します。 (*2) 6/26 リリース予定の更新プログラムは重要な更新として自動的にインストールされるものではなく、Windows 10 のサービス チャネルで  Insider Program を利用されている端末に対してのみ配信されるものとなっています。これ以外の端末で個別にインストールするには Microsoft Update Catalog からインストーラーを入手するか、[設定] - [Windows Update の設定] から [更新プログラムのチェック] を明示的に実行する必要があります。 また、配信される更新プログラムの KB 番号としては、本稿の執筆時点では KB4284848 の割り当てが予定されています。Microsoft Update Catalog から入手する場合は、この KB 番号でサーチを行ってください。KB 番号に変更があった場合には、本ブログでご案内する予定です。 (*3) 7/10 リリース予定の更新プログラムは重要な更新として自動的にインストールされます。 (*4) 変更 2. が現時点で適用された場合、.NET Framework 3.5 上で動作するアプリケーションへの影響が懸念されるというフィードバックを多くいただいたことから、特別措置として、変更 2. の修正は 7 月、8 月の更新プログラムに含めないことを決定しました。9 月以降の予定は未定ですが、予定が決まり次第、本ブログでご案内します。    

ご留意いただきたい点について

上述の、6/26 (米国時間) にリリースを予定している Optional の更新プログラムをインストールした場合、.NET Framework 3.5 上で動作する和暦を扱うアプリケーションの動作に影響が生じる可能性があります。 本更新プログラムは通常ご利用いただいている環境に自動的にインストールされることはありませんが、.NET Framework 3.5 上で動作し和暦を扱うアプリケーションを使用されている場合は、本更新プログラムを個別にインストールすることはお控えいただくか、Windows 10 April 2018 Update で追加された元号のレジストリを削除していただくようお願いします。 アプリケーションの開発者様は、本更新プログラムを適用することで .NET Framework 3.5 上で動作するアプリケーションで改元の影響を評価していただけますので、ご活用いただけると幸いです。  ]]> 新元号への対応に向けた検証とテスト ケースについて https://docs.microsoft.com/archive/blogs/jperablog/test-case Tue, 01 May 2018 14:00:09 GMT https://blogs.technet.microsoft.com/jperablog/?p=145 先日の記事にてご紹介いたしましたレジストリ値が使用されます。 [コントロール パネル] 　- [時計、言語、および地域] 　　- [地域と言語] 　　　- [形式] タブ 　　　　- [追加の設定] ボタン 　　　　　- [日付」タブ 　　　　　　- [カレンダーの種類] 　　　　　　　- "和暦" このような表示形式の設定は、API を使用しアプリケーションから取得することができます。そのため、OS の言語設定や表示形式に従い既定の表示を変えているアプリケーションが少なからず存在いたします。 一方、Microsoft Excel のように OS の設定とは無関係に和暦を使用できるアプリケーションも存在します。 例えば、セルの書式設定や連続データを自動的に入力するオートフィル機能がそれに該当します。お使いのアプリケーションが和暦に対応しているか、または OS の言語設定に従い和暦を表示する機能があるか、ご確認ください。 次に、Microsoft Outlook のようにカレンダー、スケジュール機能を持つアプリケーションでは、改元以降の祝日や六曜の表示や、うるう年等、特殊な日付が正しく表示できるかご確認いただくことをお勧めいたします。 また、MonthCalendar コントロールのようにカレンダー形式で UI を表示する場合も、元号の切り替わりの表示等にご注意ください。 最後に、和暦 ⇔ 西暦変換を行う場合の動作のご確認についてお伝えいたします。例として、MS IME では "きょう" や "２０１８ねん" 等を予測変換した場合、候補として和暦が表示されます。現時点では、ここで使用される元号名は前述いたしましたレジストリ値と連動しません。このように、和暦 ⇔ 西暦変換のロジックがどのように実装されているか、また Windows が提供する方法を使用しているのか独自に実装いただいているのかをご確認いただくことが必要と想定されます。 それでは、フォント (合字) 関連についてもご説明してまいります。 MS IME では、"へいせい" を変換した際 "平成" と "㍻" が候補として表示されます。後者の 1 文字分のコードで元号を表現しているものを合字と呼びます。 現時点で新元号は発表されておりませんが、新元号に対しても合字を用意すべく、弊社では Unicode コンソーシアムや日本政府、業界団体とともに Unicode 上の文字コードの確保や新しい字形の作成、フォントの更新について準備を進めております。 新しい合字のコード ポイント等については未確定の状況でございますが、今一度、下記のような合字の表示、入力に問題がないかご確認ください。また新元号の発表後に追加される合字を正しく表示するためにはフォントの更新 (合字のグリフの追加) が必要となりますため、アプリケーションにてご使用のフォントについても確認が必要と想定されます。 - ㍻ (U+337B) - ㍼ (U+337C) - ㍽ (U+337D) - ㍾ (U+337E) また、合字を含めた検索や並べ替えについては、少々考慮が必要です。弊社の Web 検索 "Bing" では、"㍻" を検索した際 ”㍻” と ”平成” の両方が検索されます。一方、Word では "㍻" の検索の際には "㍻" のみが検索されます。 検索や並べ替えの動作についても正規化処理の状況によって異なる結果となることが予想されますため、ご確認をいただくことをお勧めいたします。]]> Windows 10 機能更新プログラム (2018 Spring Release) における元号のレジストリ更新について https://docs.microsoft.com/archive/blogs/jperablog/rs4-registry Fri, 20 Apr 2018 09:40:06 GMT https://blogs.technet.microsoft.com/jperablog/?p=135 Windows 10 の機能更新プログラムでは、新しい元号となる 2019 年 5 月に先立ち、各元号の期間を保持しているレジストリが更新される予定です。新しい元号の名称はまだ公表されていませんので、レジストリにはプレースホルダーとして仮の名称が設定された形となります。 レジストリの更新は、新元号が追加されることに伴う問題をより早い段階で発見し、来る 2019 年 5 月に問題が発生することを未然に防ぐことを目的にリリースされます。Windows 10 Insider Preview での先行公開を経て、既存のアプリケーションやシステムへの影響も検討した上で、このタイミングでリリースされることが決定されました。   更新されるレジストリの設定は以下のとおりです。   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] "1868 01 01"="明治_明_Meiji_M" "1912 07 30"="大正_大_Taisho_T" "1926 12 25"="昭和_昭_Showa_S" "1989 01 08"="平成_平_Heisei_H" "2019 05 01"="？？_？_??????_?"     レジストリが更新されることで想定されるコントロールや API への影響は、次のようなものが考えられます。  
  1. 2019 年 5 月以降の日付を表す和暦の文字列がプレースホルダーに置き換わる可能性があります。例えば、"2020/10/10" は "？？2年10月10日" になります。カレンダー コントロールや、.NET Framework 4 以降はこの変更の影響を受けます。
  2. 2019 年 5 月以降の日付を表す和暦の文字列を日付型に変換する API やメソッドは、エラーを返したり例外がスローする可能性があります。.NET Framework 4 以降はこの変更の影響を受けます。
  3. 元号の一覧を返すメソッドやプロパティは 5 つの元号を返します。現在の 4 つの元号を返すことを仮定したアプリケーションなどは影響を受ける可能性があります。
  今回の機能更新プログラムの時点では、レジストリを参照している機能はカレンダー コントロールや .NET Framework 4 以降のバージョンなどに限られています。 .NET Framework 3.5 など、本レジストリに未対応の機能や製品については今後対応を進めていく予定で、進展があり次第このブログを通じて情報を発信する予定です。   なお、新元号が公表された後は改めてレジストリが更新される予定のため、例えば "？？2年10月10日" は西暦に変換できなくなります。アプリケーションやシステムでは、プレースホルダーの元号をそのままデータベースやファイルなどに保存しないようにご注意ください。現時点で 2019 年 5 月以降の日付を扱う必要がある環境では、お手数をおかけいたしますが、上記で黄色でハイライトしたレジストリ キーを削除するようお願いします。   また、上記の 2. につきましては、次回の機能更新プログラムの時期を目途に、.NET Framework のクラス ライブラリの動作を例外をスローせず許容するように変更する予定です。既存のアプリケーションへの影響も考慮し、この変更は設定などで切り替えを可能とすることも検討しています。詳細な対応方針が決まり情報公開できる運びとなりましたら、このブログを通じてご案内する予定です。   今回の Windows 10 の機能更新プログラムでレジストリの更新を行う目的につきましては、下記の弊社社員のブログ記事でも公開しています。あわせてご参考にしていただければ幸いです。   The Japanese Calendar’s Y2K Moment https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-calendars-y2k-moment/  ]]> 新元号への対応についてのアップデート https://docs.microsoft.com/archive/blogs/jperablog/%E6%96%B0%E5%85%83%E5%8F%B7%E3%81%B8%E3%81%AE%E5%AF%BE%E5%BF%9C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88 Mon, 02 Apr 2018 17:07:46 GMT https://blogs.technet.microsoft.com/jperablog/?p=125 ● 新元号への対応レベルにつきまして 弊社製品の新元号への対応レベルとしては、大きく下記の 3 点があります。個々の製品やサービス、バージョンによって必要な対応レベルが異なるため、弊社ではどのような対応が必要か精査を急ピッチで実施しています。 - 日付フォーマットの変換 "日付フォーマットの変換" とは、主に西暦 ⇔ 和暦の変換処理を指します。 西暦 2019 年 5 月 1 日以降の日付は平成ではなく、新しい和暦に変換される必要があります。 Win32 や ATL / COM、.NET Framework に含まれる API、オブジェクトやメソッドによる日付フォーマットの変換が主となります。 この対応は 2019 年 4 月末までに完了できればよいというものではなく、新元号での変換が業務で必要となるまでに完了しなければならない点に注意してください。 - 合字への対応 "合字" は耳慣れない言葉ですが、「㍿」や「℡」のように 2 つ以上の文字を 1 文字で表現する記号を指します。 明治以降の元号は、Unicode 上に以下のような合字が存在しています。 ㍻ (U+337B) ㍼ (U+337C) ㍽ (U+337D) ㍾ (U+337E) 弊社によるこれまでの調査では、和暦の表示等に合字を使用しているケースが相当数存在し、このようなシステムでは新元号に対しても同様に合字への対応が必要と考えられます。 新たな合字の作成には Unicode コンソーシアムでの文字の標準化作業を含み、そのスケジュールは標準化作業の進捗に大きく影響されます。また、「㍾」、「㍽」、「㍼」は JIS X 0208 の集合に含まれていますが、「㍻」は含まれておりません。そのため、JIS X 0201/0208 で使用される符号化方式の一つであるシフトJISでは「㍻」を使用することができません。新しい元号についても同様となります。(CodePage 932 は互換性問題解消を目的に策定しており、今後更新の予定はありません。) 本 Blog で以前お伝えしております通り、新しい合字を正しく表示するには上記のような符号位置の決定とともにフォントの対応も必要不可欠です。 - 正規化 "正規化" とは、先にお話しいたしました合字と関連の深い対応になります。 例えば、"平成" と "㍻" を同様に扱う処理などがこの影響を受けます。検索キーワードとして元号が指定された際、合字を含むドキュメントを検索できる必要があり、このような処理ができるよう対応する必要があります。 ● 弊社製品での今後の対応につきまして 弊社では新元号に対応する製品やそのバージョン、および更新の実施方法について検討を進めており、2018 年 6 月を目標に確定し公開できる予定です。 また、Windows 10 の次期機能アップデートにおいて、アプリケーション開発者様向けに日付フォーマット変換の開発や検証を目的とした API レベルの仮対応を実施する予定です。具体的な内容については、リリース時までの公開を予定しております。 加えて、4 月下旬にはパートナー様、開発者様向けの説明会を実施いたします。また、 Shift-JIS 対応に関するお問い合わせも複数頂戴しており、日程や詳細につきましては、別途ご案内いたします。 引き続き、新元号についての新しい情報は本 Blog にてお伝えしていきます。]]> 文字情報基盤国際標準化シンポジウム https://docs.microsoft.com/archive/blogs/jperablog/%E6%96%87%E5%AD%97%E6%83%85%E5%A0%B1%E5%9F%BA%E7%9B%A4%E5%9B%BD%E9%9A%9B%E6%A8%99%E6%BA%96%E5%8C%96%E3%82%B7%E3%83%B3%E3%83%9D%E3%82%B8%E3%82%A6%E3%83%A0 Tue, 28 Nov 2017 14:51:23 GMT https://blogs.technet.microsoft.com/jperablog/?p=115 2017 年 12 月 1 日 (金) 13:30 より、TKP 赤坂駅カンファレンス センターにて、テーマ『激変する文字コードの世界。とりのこされないために』と題して、『文字情報基盤国際標準化シンポジウム』が開催されます。主催は、文字情報技術促進協議会 (CITPC)、後援は経済産業省、情報処理推進機構 (IPA) です。弊社より、文字情報技術促進協議会 事務局長 / 導入支援部会長 田丸 健三郎氏が登壇します。 新元号の話が直接言及される予定はございませんが、Unicode IVS/IVDなど最新のUnicodeの状況が網羅されますので、改元の対応を検討する際に重要な基礎知識が得られる講演内容となっております。また、人名、地名などを扱うシステムを開発するパートナー、企業、ユーザーには非常に役立つシンポジウムです。 参加費用は無料です。詳細、参加申し込みはこちら https://www.citpc.jp/seminars.html のサイトからになります。]]>