Microsoft、Shift_JISや外字からUnicodeへの移行を呼びかけ 141
ストーリー by hylom
生き残るShift-JIS 部門より
生き残るShift-JIS 部門より
Microsoftが、外字の利用を止めることを推奨するブログ記事を公開している（窓の杜）。
Microsoftが収集したWindows診断データによると、日本では突出して外字の使用頻度が高いという。この背景には、Windowsにおいては長らく日本語の文字コードとしてShift-JISが使われており、Shift-JISで表現できない文字を外字として登録して使っている、ということがあるようだ。一方で現在のWindowsはUnicodeをサポートしており、Unicodeを利用することで「外字でなければ表示できない文字」はほぼなくなるという。
ただ、たとえばVisual Basic 6で開発されたアプリケーションなど、現在でもUnicodeに対応していない古いアプリケーションが稼働している場合もある。そのためMicrosoftはこうしたシステムを段階的に移行していくことを推奨している。
隗より始めよ (スコア:4, すばらしい洞察)
まず、お前の所からやれ。
何で Shift_JIS でしかセーブできないツール残してるんだ（怒
Re: (スコア:0)
システムロケールの「ベータ：ワールドワイド言語サポートでUnicode UTF-8を使用」を有効にしたら、メモ帳でCP932/ANSIで保存したテキストファイルが盛大に文字化け。
既存のtxtを全てUTF-8で保存し直さない私が悪いのか、
txtをメモ帳なんかに関連付けしている私が悪いんだろうなぁ。
Re:隗より始めよ (スコア:2, 参考になる)
要注意な設定変更のようですね。
Windows 10の「ワールドワイド言語サポートで Unicode UTF-8 を使用」は要注意
https://srad.jp/submission/85086/ [srad.jp]
Re: (スコア:0)
非互換変更なんだからトラブル起きて当然では。
もともとBOMは互換性維持のための機能なんだし。
気になるのは、Microsoftがこの非互換変更をなし崩しにやろうとしている感があるところ。
ちゃんと移行のタイムスケジュールをアナウンスして計画的に対応できるようにしてほしい。
Re: (スコア:0)
ちゃんと移行のタイムスケジュールをアナウンスして計画的に対応できるようにしてほしい。
いやー、理想はやるべきだし、やってくれたら素晴らしいけど、大変だぜーこれは。
スケジュール切って移行せい！言っても未だにShift_JIS使ってるようなとこは大体ガン無視でしょ。
MSも持ってるツールがShift_JISがデフォルトかそれのみになってるやつを悉くUTF-8デフォルトにする訳でしょ。
保守放置されてるシステムとかツールとか問題を誰がケツ拭くのかとか、
結局部分的にShift_JIS生かすオプション付ける羽目になるとか、Xデー迎えても現実は完全移行には程遠いとかなりそうですよ。
Re: (スコア:0)
最低でも簡単なメニュー操作で word, excel, その他主要ツールに UTF-8 でイクスポートするとか、SJISをインポートするとか、そのあたりの整備から始めてくれないと、過去の遺産持っている人は誰も以降できない。
あとFATファイルシステムとか ZIP アーカイブの文字コードの切り換えとかも欲しい。
Re: (スコア:0)
具体的にどのツール？
cmd.exeや、こまごまとしたDOSコマンドは今更直してられないだろうから、もう仕方ないと思う。
（昔のCプログラムを正しくUTF-8対応させるのは大変すぎるし…。UNIX系プラットフォームでもすごく時間がかかった）
PowerShellならUTF-8問題ないので、なるべくPowerShell使う方向で対応でしょう。
それ以外のアプリはおおむね直ってると思う。
昔はSQL Server付属のsqlcmdがShift-JISしか読まなくてムキーとなった記憶があるが、今は改善されたっぽい。
Re:隗より始めよ (スコア:1)
cmd.exeならとうの昔にchcpで各種コードページに対応してるのだが。
Re:隗より始めよ (スコア:1)
ZipフォルダーがいつまでもシフトJISのファイル名で保存し続けて、シフトJISにない文字を含むファイル名を書庫に追加しようとするとエラーを吐く。展開の方はUTF-8に対応済みだしOneDriveの一括ダウンロード機能などで生成されるZipのファイル名もUTF-8だし未パッチの状態でUTF-8ファイル名の展開をサポートしないWindows 7はサポート終了したからいい加減対応してもらいたいのだが
Re: (スコア:0)
提供したUSBストレージ(32GB)には、内部ファイル名がUTF8のZIPファイルと、内部ファイル名がSJISのZIPファイルが入っています。
両方を正しいファイル名で解凍した上で、それがエクセル・ファイルがあった場合は CSV （文字コードは UTF-8 BOM無し) に変換し、他の解凍したファイルと一緒にして全てを提供したUSBストレージに追加して返してください。
・マイクロソフト標準ツール以外には使用できないものとします。
・作業途中でのレジストリ直接操作などは禁止とします。
・USBストレージに元から入っているファイルは消してはならないものとします。
・外字のみ文字化けを許容します。
Re:隗より始めよ (スコア:1)
ダブルクリックでCSV開く → 正しくない使い方
ファイルからCSVで開く → 正しくない使い方
データからテキストファイルとしてインポート → 正しい使い方
・・・選択肢がたくさんあって、正しい方法が一つしかないとか
ギャルゲーですか？
全文検索で引っかからない (スコア:2, 参考になる)
テキストファイルの全文検索で対応してる日本語文字コードはShift-JISとUTF-16(BE/LE)のみ。
JISもEUCもUTF-8も対応してない。
メモ帳(UTF-8)で保存したファイルが検索で引っかからないっていうね……
Unicode って書いてあるけど… (スコア:2)
と書いてあるけど、Microsoft が過去に UTF-16 を強力にプッシュしていた件は、スルーですかね？
例えば、SQL Server は当初 UTF-16だけサポートしていて、UTF-8 に対応したのは 2019/7/3 [mynavi.jp]からです。
（この対応をしたからドヤ顔で言えるようになったのかと邪推）
Re:Unicode って書いてあるけど… (スコア:2)
ああ、これは書き方が悪かった。ごめんなさい
UTF-16 が Unicode なのは知ってます。
マイクロソフトって、Unicode を20年前からサポートしているって言っているけど、UTF-16ばかりプッシュしていて、UTF-8対応はだいぶおろそかだったよねー
って事です。
Re:Unicode って書いてあるけど… (スコア:1)
UTF-16はUnicodeだよ?
Windowsの日本語ロケールでは文化的内部文字コードはCP932 (スコア:2)
ネイティブでUnicodeを使ってるなら「あ～ん」とか入力した場合ににょろっとしてる文字は波ダッシュで出てこなければならない。しかしそうなっていないのは、内部コードがCP932(Shift_JIS)だからであり、Shift_JISの波ダッシュをUnicodeの全角チルダに変換しているから。
他にもハイフンマイナス(U+002D)とかアポストロフィ(U+0027)は通常の文章では使わないが、コーディングやスクリプト等では使用するみたいなのも、GUIツールキットのテキスト入力欄かIMEで対応してないとユーザにとって負荷が高いのに対応されてない。
OSの思想がCP932ベース(というか、ASCII+α)なのに、外面だけUnicodeにしろとかおかしいと思わんのかね。
Windowsの前に (スコア:1)
ARIB外字 [wikipedia.org]を何とかできませんかね（ならないけど。
ガラパゴスすぎてめまいがする。
Re: (スコア:0)
Unicode 5.2において大半がその他の記号ブロックに収録された。
とか
モザイク集合にある文字のほとんどはUnicodeには未収録である。
けど
L2/19-025で提案されており、Unicodeに導入される予定となっている。
なんてあるけど？
B2CのCSV (スコア:1)
クレジットカードの明細や電力会社のスマートメーターのデータが自分が利用しているところは、Shift-JISのCSVです。
サイト自体はUTF-8です。
どのような理由があるのか気になります。
Re: (スコア:0)
少し前のExcelのCSVはShift-JIS前提になってるからじゃない？
Shift_JISとUTF-8の両方が問題なく扱えるように (スコア:1)
今後もWindows上でShift_JISとUTF-8の両方が問題なく扱えるように、マイクロソフト社にはご対応し続けて頂きたい。
Re: (スコア:0)
いまでも使えないか？
それぞれゴッチャにしなければ。
Re: (スコア:0)
今後Shift_JISが使えなくならないようにってことじゃね？
改行コード統一とUTF-16、BOMの非推奨も。 (スコア:0, フレームのもと)
サロゲートペアとかBOMとか鬱陶しいので、UTF-16は廃止。あと\r\nも\nに統一してほしい。
Re:改行コード統一とUTF-16、BOMの非推奨も。 (スコア:1)
CR とか LF とか、本来は書式制御文字なのを、「行区切り」という論理的意味に使っているのが、そもそもおかしくて、
本当は、U+2028 LINE SEPERATOR とかを使うべきなんだろうな。
現実問題としては、インターネットプロトコル等はたいてい CR LF を行区切りに使う（LF も「許容」) のが普通で、
interoperability を考えると、CR LF が無難。
Re: (スコア:0)
\rと\nは役割が違うのでそれは勘弁
Re:改行コード統一とUTF-16、BOMの非推奨も。 (スコア:1)
もともとは¥rと¥nは違うけど、Windowsでは特に意味のない概念になって久しいでしょ。どっちかひとつで十分なのでUNIXに寄せて¥nにしろ、というのは一理あると思う。
Re:改行コード統一とUTF-16、BOMの非推奨も。 (スコア:2, 興味深い)
どっちかに寄せろ論をするなら最大の敵はWindowsじゃなくてHTTP/1.1 [ietf.org]な。
ヘッダの行とかはCRLFで区切ることになってる。
Re: (スコア:0)
内部でクローズで使うのならそうだろうけど、外部機器とやり取りするとね。
Re: (スコア:0)
asciiテキストは機械が生成したり機械が読んだりすることも多い
場合によっては人間の目に触れずない
これらをすべて総点検しなければ改行コードを変えることはできない
Re: (スコア:0)
Microsoft の言う Unicode って UTF-16 のことなのでは？
Re:改行コード統一とUTF-16、BOMの非推奨も。 (スコア:2, すばらしい洞察)
ほんとこれ
マイクロソフトはUnicodeとかいう言葉を何を指しているかふわっとした状況で使うのをやめてほしい。ぜったいやめてほしい。
既存の全ドキュメントに（これはUTF-16のことです)(これはUTF-8です)(これはACRの話です）（これはCCSの事です）って全部入れてほしい。バージョンもちゃんと。
だいたいUTF-16LEなんだけど読んでる方が混乱する
Re: (スコア:0)
OSに関係なく通信文とかcrlfで処理してるものは多いのだが。
日本と台湾だけ？ (スコア:0)
> この問題の場合は日本と台湾で配信停止の措置が取られましたが、外字の使用頻度が高い日本の企業ユーザー様が診断データの送信を停止しているため、統計的には台湾でのインパクトが高いと判断されるケースがありました。
中国でのインパクトが特に語られてないのは簡体字への移行時に異字体があらかた淘汰されたからなんだろうか
Re: (スコア:0)
漢字ってかつては、勝手に個人でアレンジしてもOK、なルールがあったんじゃないかな…。
学校をやってると、しんにょうの点の数とか、突き抜ける突き抜けないとか、
学生らの「手書きの書類に書かれていて、これが自分の姓の正式な字体だ」と主張するものに合わせようとすると、
Unicodeの異字体でもまだ足りなくて外字を作らざるを得ない事がしばしば。
手書き戸籍の時代は、そういう微妙な「オレオレ漢字」も認められていたのかな。
うちの親戚の名前には「そのまま書くと画数が不吉なので、ここの画数を水増しする」みたいな
爺様だか婆様だかが勝手に決めた謎のローカルルールがい
Re:日本と台湾だけ？ (スコア:2, 参考になる)
>>日本人の全戸籍の全漢字を登録
それ既に終わってます
文字情報基盤で調べれば解りますが
戸籍の紙台帳から全漢字を収集(斎、斉等、書体違い含め)、整理して
既にUnicodeで対応済み
ただしフォントで対応してるかは別
IPA製のIPAmj明朝は対応してるみたいだが
他は対応してない可能性が高い
Re: (スコア:0)
アレンジしてもOKかどうかはわからないけど、（経緯はどうあれ）戸籍に記載された字形が正字という決まりがある、あった、はず。
そして戸籍はながらく手書きだった。
UnicodeからShift_JISと外字への移行 (スコア:0)
EP-Wing変換とかだとUnicodeからShift_JISと外字への変換は日常茶飯事。
フォントを画像化して外字にすればいいだけだから割と簡単。
目安としては中国語・タイ語・韓国語の辞書でも全部外字領域に収まるくらいだから余裕(検索はできない)。
それに比べて既存の外字を全部マッピングしないといけないUnicode移行は難易度高いねぇ。
字形から判断して該当文字を検索するツールでもあるのかな。
正直、外字をわざわざ使ってるシステムをわざわざ移行なんて無理ゲーな気がする。
余裕がないから未だに外字を使ってるわけだし。
Re: (スコア:0)
マッピング表を作る作業だけなので、無理ゲーってほどでもない気がするが。
正しくマッピングするのは手間はかかるが、データ変換の実装自体は単純では。
むしろ大変なのは、いまだに外字を使っているようなレガシーシステム自体のリプレースだよなあ（遠い目）。
＞Unicodeを利用することで「外字でなければ表示できない文字」はほぼなくなるという (スコア:0)
https://www.est.co.jp/font/jinmei1500v5/shuroku [est.co.jp]
https://fudemame.net/products/font/jinmei-gaiji/merit2/ [fudemame.net]
こういうのもOKになるの？
まあ、フォントがあるかどうかと文字コードの問題は別っていうんだろうけどさ。
Re: (スコア:0)
＞過去に外字を使用するとアプリケーションが停止する問題がありました。
という部分が問題とされていて。化ける分には全然結構なのだけれど、ハングするのは困る。
ソースコードはUNICODEでも大丈夫？ (スコア:0)
過去にソースコードがいつのまにかUNICODEやらその他へんなコードになってて
トラブルが起こったことがあるのでSJISにしてるけど・・・
あと、日本語じゃない文字が知らない間に混入してたりすることを防ぐためにSJISにしてるとかもある
Re:ソースコードはUNICODEでも大丈夫？ (スコア:1)
VisualStudio 2008か2010あたりだったかと思うけど、UTF-8(BOM付き)で問題なくコンパイルできてたと思う。
ただし *.rc, resource.h を除く。
RC.EXE が UTF-8 に対応していなくて UTF-16LE を使う必要があった。
Localized rc file will not compile [stackoverflow.com]
# SlashDot Light [takeash.net] やってます。
言語による (スコア:0)
今のjavaやpythonは知らないけど、bomつきはダメだった。
c#はbom付きでも問題なかった。
Re: (スコア:0)
自分はVisualStudio2013とLinux(GCC)でソースコードをシェアしてますが
UTF-8(BOM付き)+LF(UNIX式改行コード)で実現できました
※他の組み合わせだと駄目だった…BOM外したかったのに
Re: (スコア:0)
逆じゃね？
Shift-JISだとASCIIで処理してる処理系でダメってよくあった話。
まさかUTF-8でなくUTF-16とかUTF-7で保存してたんじゃ。
文字符号化と文字集合をごっちゃにしてる奴ならやらかしても不思議じゃない。
# UTF-7の存在はしってるけど実際にはみたことないなぁ。一部メーラーであったんだっけ？
Re:ソースコードはUNICODEでも大丈夫？ (スコア:1)
IMAP4プロトコルでの、メールボックス名の取り扱いがUTF-7の修正版です。今でも現役。
本家UTF-7だとBase64符号化に/が使われるので、/で区切られた階層的なメールボックスを本家UTF-7エンコードすると区切りがわからなくなる、といったメールボックス表現上の不便なところを微妙にルール変更してる感じ。
VB6は (スコア:0)
VB6は内部UNICODE対応してるけどIFがCP932なんだよねぇ
MSはまずUTF-8のCSVを関連付けで文字化けせずに開けるようにすべき。
これのせいでなかなかShift-Jisが排除できない。
Re: (スコア:0)
BOMなしならShift_JISとみなす、は仕方ないと思うけどなぁ
Re:WSHでBOMなしテキストファイル作れないのどうにかしろよ (スコア:1)
> コマンドプロンプトで入出力の既定をShift_JISから変える方法
コマンドプロンプトで
c:\unko>chcp 65001
自分は cmd.exe /k "chcp 65001" というショートカット作ってる
というか最近 PowerShell7 も正式版が出たし、PSばかり使ってる