パスワードを忘れた? アカウント作成
14128580 story
マイクロソフト

Microsoft、Shift_JISや外字からUnicodeへの移行を呼びかけ 141

ストーリー by hylom
生き残るShift-JIS 部門より

Microsoftが、外字の利用を止めることを推奨するブログ記事を公開している窓の杜)。

Microsoftが収集したWindows診断データによると、日本では突出して外字の使用頻度が高いという。この背景には、Windowsにおいては長らく日本語の文字コードとしてShift-JISが使われており、Shift-JISで表現できない文字を外字として登録して使っている、ということがあるようだ。一方で現在のWindowsはUnicodeをサポートしており、Unicodeを利用することで「外字でなければ表示できない文字」はほぼなくなるという。

ただ、たとえばVisual Basic 6で開発されたアプリケーションなど、現在でもUnicodeに対応していない古いアプリケーションが稼働している場合もある。そのためMicrosoftはこうしたシステムを段階的に移行していくことを推奨している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 隗より始めよ (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2020年03月06日 13時51分 (#3774282)

    まず、お前の所からやれ。
    何で Shift_JIS でしかセーブできないツール残してるんだ(怒

    • by Anonymous Coward

      システムロケールの「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」を有効にしたら、メモ帳でCP932/ANSIで保存したテキストファイルが盛大に文字化け。

      既存のtxtを全てUTF-8で保存し直さない私が悪いのか、
      txtをメモ帳なんかに関連付けしている私が悪いんだろうなぁ。

      • Re:隗より始めよ (スコア:2, 参考になる)

        by Anonymous Coward on 2020年03月06日 14時32分 (#3774315)

        要注意な設定変更のようですね。

        Windows 10の「ワールドワイド言語サポートで Unicode UTF-8 を使用」は要注意
        https://srad.jp/submission/85086/ [srad.jp]

        親コメント
      • by Anonymous Coward

        非互換変更なんだからトラブル起きて当然では。
        もともとBOMは互換性維持のための機能なんだし。

        気になるのは、Microsoftがこの非互換変更をなし崩しにやろうとしている感があるところ。
        ちゃんと移行のタイムスケジュールをアナウンスして計画的に対応できるようにしてほしい。

        • by Anonymous Coward

          ちゃんと移行のタイムスケジュールをアナウンスして計画的に対応できるようにしてほしい。

          いやー、理想はやるべきだし、やってくれたら素晴らしいけど、大変だぜーこれは。
          スケジュール切って移行せい!言っても未だにShift_JIS使ってるようなとこは大体ガン無視でしょ。
          MSも持ってるツールがShift_JISがデフォルトかそれのみになってるやつを悉くUTF-8デフォルトにする訳でしょ。
          保守放置されてるシステムとかツールとか問題を誰がケツ拭くのかとか、
          結局部分的にShift_JIS生かすオプション付ける羽目になるとか、Xデー迎えても現実は完全移行には程遠いとかなりそうですよ。

          • by Anonymous Coward

            最低でも簡単なメニュー操作で word, excel, その他主要ツールに UTF-8 でイクスポートするとか、SJISをインポートするとか、そのあたりの整備から始めてくれないと、過去の遺産持っている人は誰も以降できない。

            あとFATファイルシステムとか ZIP アーカイブの文字コードの切り換えとかも欲しい。

    • by Anonymous Coward

      具体的にどのツール?

      cmd.exeや、こまごまとしたDOSコマンドは今更直してられないだろうから、もう仕方ないと思う。
      (昔のCプログラムを正しくUTF-8対応させるのは大変すぎるし…。UNIX系プラットフォームでもすごく時間がかかった)
      PowerShellならUTF-8問題ないので、なるべくPowerShell使う方向で対応でしょう。

      それ以外のアプリはおおむね直ってると思う。
      昔はSQL Server付属のsqlcmdがShift-JISしか読まなくてムキーとなった記憶があるが、今は改善されたっぽい。

      • by Anonymous Coward on 2020年03月06日 16時02分 (#3774403)

        cmd.exeならとうの昔にchcpで各種コードページに対応してるのだが。

        親コメント
      • by Anonymous Coward on 2020年03月06日 18時56分 (#3774546)

        ZipフォルダーがいつまでもシフトJISのファイル名で保存し続けて、シフトJISにない文字を含むファイル名を書庫に追加しようとするとエラーを吐く。展開の方はUTF-8に対応済みだしOneDriveの一括ダウンロード機能などで生成されるZipのファイル名もUTF-8だし未パッチの状態でUTF-8ファイル名の展開をサポートしないWindows 7はサポート終了したからいい加減対応してもらいたいのだが

        親コメント
      • by Anonymous Coward

        提供したUSBストレージ(32GB)には、内部ファイル名がUTF8のZIPファイルと、内部ファイル名がSJISのZIPファイルが入っています。
        両方を正しいファイル名で解凍した上で、それがエクセル・ファイルがあった場合は CSV (文字コードは UTF-8 BOM無し) に変換し、他の解凍したファイルと一緒にして全てを提供したUSBストレージに追加して返してください。

        ・マイクロソフト標準ツール以外には使用できないものとします。
        ・作業途中でのレジストリ直接操作などは禁止とします。
        ・USBストレージに元から入っているファイルは消してはならないものとします。
        ・外字のみ文字化けを許容します。

  • by Anonymous Coward on 2020年03月06日 19時09分 (#3774562)

    テキストファイルの全文検索で対応してる日本語文字コードはShift-JISとUTF-16(BE/LE)のみ。
    JISもEUCもUTF-8も対応してない。

    メモ帳(UTF-8)で保存したファイルが検索で引っかからないっていうね……

  • Windows は非常に初期のバージョンから Unicode に準拠して設計・開発され、その歴史は 20 年を超えます。

    と書いてあるけど、Microsoft が過去に UTF-16 を強力にプッシュしていた件は、スルーですかね?

    例えば、SQL Server は当初 UTF-16だけサポートしていて、UTF-8 に対応したのは 2019/7/3 [mynavi.jp]からです。
    (この対応をしたからドヤ顔で言えるようになったのかと邪推)

  • ネイティブでUnicodeを使ってるなら「あ~ん」とか入力した場合ににょろっとしてる文字は波ダッシュで出てこなければならない。しかしそうなっていないのは、内部コードがCP932(Shift_JIS)だからであり、Shift_JISの波ダッシュをUnicodeの全角チルダに変換しているから。
    他にもハイフンマイナス(U+002D)とかアポストロフィ(U+0027)は通常の文章では使わないが、コーディングやスクリプト等では使用するみたいなのも、GUIツールキットのテキスト入力欄かIMEで対応してないとユーザにとって負荷が高いのに対応されてない。
    OSの思想がCP932ベース(というか、ASCII+α)なのに、外面だけUnicodeにしろとかおかしいと思わんのかね。

  • by Anonymous Coward on 2020年03月06日 13時54分 (#3774286)

    ARIB外字 [wikipedia.org]を何とかできませんかね(ならないけど。
    ガラパゴスすぎてめまいがする。

    • by Anonymous Coward

      Unicode 5.2において大半がその他の記号ブロックに収録された。

      とか

      モザイク集合にある文字のほとんどはUnicodeには未収録である。

      けど

      L2/19-025で提案されており、Unicodeに導入される予定となっている。

      なんてあるけど?

  • by Anonymous Coward on 2020年03月06日 15時05分 (#3774350)

    クレジットカードの明細や電力会社のスマートメーターのデータが自分が利用しているところは、Shift-JISのCSVです。
    サイト自体はUTF-8です。
    どのような理由があるのか気になります。

    • by Anonymous Coward

      少し前のExcelのCSVはShift-JIS前提になってるからじゃない?

  • by Anonymous Coward on 2020年03月06日 15時28分 (#3774374)

    今後もWindows上でShift_JISとUTF-8の両方が問題なく扱えるように、マイクロソフト社にはご対応し続けて頂きたい。

    • by Anonymous Coward

      いまでも使えないか?
      それぞれゴッチャにしなければ。

      • by Anonymous Coward

        今後Shift_JISが使えなくならないようにってことじゃね?

  • by Anonymous Coward on 2020年03月06日 14時08分 (#3774297)

    サロゲートペアとかBOMとか鬱陶しいので、UTF-16は廃止。あと\r\nも\nに統一してほしい。

    • by Anonymous Coward on 2020年03月06日 15時55分 (#3774397)

      CR とか LF とか、本来は書式制御文字なのを、「行区切り」という論理的意味に使っているのが、そもそもおかしくて、
      本当は、U+2028 LINE SEPERATOR とかを使うべきなんだろうな。

      現実問題としては、インターネットプロトコル等はたいてい CR LF を行区切りに使う(LF も「許容」) のが普通で、
      interoperability を考えると、CR LF が無難。

      親コメント
    • by Anonymous Coward

      \rと\nは役割が違うのでそれは勘弁

      • by Anonymous Coward on 2020年03月06日 14時30分 (#3774314)

        もともとは¥rと¥nは違うけど、Windowsでは特に意味のない概念になって久しいでしょ。どっちかひとつで十分なのでUNIXに寄せて¥nにしろ、というのは一理あると思う。

        親コメント
        • by Anonymous Coward on 2020年03月06日 16時47分 (#3774439)

          どっちかに寄せろ論をするなら最大の敵はWindowsじゃなくてHTTP/1.1 [ietf.org]な。
          ヘッダの行とかはCRLFで区切ることになってる。

          親コメント
        • by Anonymous Coward

          内部でクローズで使うのならそうだろうけど、外部機器とやり取りするとね。

    • by Anonymous Coward

      Microsoft の言う Unicode って UTF-16 のことなのでは?

      • by Anonymous Coward on 2020年03月06日 16時48分 (#3774440)

        ほんとこれ
        マイクロソフトはUnicodeとかいう言葉を何を指しているかふわっとした状況で使うのをやめてほしい。ぜったいやめてほしい。
        既存の全ドキュメントに(これはUTF-16のことです)(これはUTF-8です)(これはACRの話です)(これはCCSの事です)って全部入れてほしい。バージョンもちゃんと。
        だいたいUTF-16LEなんだけど読んでる方が混乱する

        親コメント
    • by Anonymous Coward

      OSに関係なく通信文とかcrlfで処理してるものは多いのだが。

  • by Anonymous Coward on 2020年03月06日 14時10分 (#3774300)

    > この問題の場合は日本と台湾で配信停止の措置が取られましたが、外字の使用頻度が高い日本の企業ユーザー様が診断データの送信を停止しているため、統計的には台湾でのインパクトが高いと判断されるケースがありました。
    中国でのインパクトが特に語られてないのは簡体字への移行時に異字体があらかた淘汰されたからなんだろうか

    • by Anonymous Coward

      漢字ってかつては、勝手に個人でアレンジしてもOK、なルールがあったんじゃないかな…。

      学校をやってると、しんにょうの点の数とか、突き抜ける突き抜けないとか、
      学生らの「手書きの書類に書かれていて、これが自分の姓の正式な字体だ」と主張するものに合わせようとすると、
      Unicodeの異字体でもまだ足りなくて外字を作らざるを得ない事がしばしば。

      手書き戸籍の時代は、そういう微妙な「オレオレ漢字」も認められていたのかな。
      うちの親戚の名前には「そのまま書くと画数が不吉なので、ここの画数を水増しする」みたいな
      爺様だか婆様だかが勝手に決めた謎のローカルルールがい

      • by Anonymous Coward on 2020年03月06日 18時00分 (#3774498)

        >>日本人の全戸籍の全漢字を登録
        それ既に終わってます
        文字情報基盤で調べれば解りますが
        戸籍の紙台帳から全漢字を収集(斎、斉等、書体違い含め)、整理して
        既にUnicodeで対応済み
        ただしフォントで対応してるかは別
        IPA製のIPAmj明朝は対応してるみたいだが
        他は対応してない可能性が高い

        親コメント
      • by Anonymous Coward

        アレンジしてもOKかどうかはわからないけど、(経緯はどうあれ)戸籍に記載された字形が正字という決まりがある、あった、はず。
        そして戸籍はながらく手書きだった。

  • by Anonymous Coward on 2020年03月06日 14時20分 (#3774308)

    EP-Wing変換とかだとUnicodeからShift_JISと外字への変換は日常茶飯事。
    フォントを画像化して外字にすればいいだけだから割と簡単。
    目安としては中国語・タイ語・韓国語の辞書でも全部外字領域に収まるくらいだから余裕(検索はできない)。

    それに比べて既存の外字を全部マッピングしないといけないUnicode移行は難易度高いねぇ。
    字形から判断して該当文字を検索するツールでもあるのかな。
    正直、外字をわざわざ使ってるシステムをわざわざ移行なんて無理ゲーな気がする。
    余裕がないから未だに外字を使ってるわけだし。

    • by Anonymous Coward

      マッピング表を作る作業だけなので、無理ゲーってほどでもない気がするが。
      正しくマッピングするのは手間はかかるが、データ変換の実装自体は単純では。

      むしろ大変なのは、いまだに外字を使っているようなレガシーシステム自体のリプレースだよなあ(遠い目)。

  • https://www.est.co.jp/font/jinmei1500v5/shuroku [est.co.jp]
    https://fudemame.net/products/font/jinmei-gaiji/merit2/ [fudemame.net]

    こういうのもOKになるの?

    まあ、フォントがあるかどうかと文字コードの問題は別っていうんだろうけどさ。

    • by Anonymous Coward

      >過去に外字を使用するとアプリケーションが停止する問題がありました。
      という部分が問題とされていて。化ける分には全然結構なのだけれど、ハングするのは困る。

  • by Anonymous Coward on 2020年03月06日 14時37分 (#3774324)

    過去にソースコードがいつのまにかUNICODEやらその他へんなコードになってて
    トラブルが起こったことがあるのでSJISにしてるけど・・・

    あと、日本語じゃない文字が知らない間に混入してたりすることを防ぐためにSJISにしてるとかもある

    • 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] やってます。
      親コメント
    • by Anonymous Coward

      今のjavaやpythonは知らないけど、bomつきはダメだった。
      c#はbom付きでも問題なかった。

    • by Anonymous Coward

      自分はVisualStudio2013とLinux(GCC)でソースコードをシェアしてますが
      UTF-8(BOM付き)+LF(UNIX式改行コード)で実現できました
      ※他の組み合わせだと駄目だった…BOM外したかったのに

    • by Anonymous Coward

      逆じゃね?
      Shift-JISだとASCIIで処理してる処理系でダメってよくあった話。
      まさかUTF-8でなくUTF-16とかUTF-7で保存してたんじゃ。
      文字符号化と文字集合をごっちゃにしてる奴ならやらかしても不思議じゃない。

      # UTF-7の存在はしってるけど実際にはみたことないなぁ。一部メーラーであったんだっけ?

  • by Anonymous Coward on 2020年03月06日 15時27分 (#3774373)

    VB6は内部UNICODE対応してるけどIFがCP932なんだよねぇ

    MSはまずUTF-8のCSVを関連付けで文字化けせずに開けるようにすべき。
    これのせいでなかなかShift-Jisが排除できない。

    • by Anonymous Coward

      BOMなしならShift_JISとみなす、は仕方ないと思うけどなぁ

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...