アカウント名:
パスワード:
Windows10だがローマ字入力中に子音が2文字され確定かきくけこKakikukeko キー入力kkあkkいkkうkkえkkお
メモ帳や他で出ないのでteamsの独自処理でしょうけどゴミ過ぎる。金を取れるレベルではない。
正しくない文字範囲が変換対象として自動的に選択され、予期しない変換候補が表示されるカーソルが予期しない位置に移動して間違った文字シーケンスが選択され、現象 1 が発生する可能性がある
この現象はWindows10のteamsでも起こります。テキスト入力や変更を行うとカーソルが変な所に移動するので文字の入力や編集ができない。
メモ帳で編集してコピペです。
動作的に内部処理が2バイトで文字が3ないし4バイトなので入力すると変な所に飛ぶ感じです。腐ったコードの使い回しでバグ感染しているのでしょう
マイクロソフトにはUnicodeを使いこなす技術がもはやないのか、そもそもUnicodeの使用が糞なのかしらんが、いっそのこと古のShift-JISに戻ったらどうだ? 絵文字いらんし。
日本語以外の話者? 知らんがな。
米国人は7bit ASCIIだけでいい、って言いそうだけど。
CP932を含む、Shift_JIS系符号化方式の利点として以下の2つがあります。①既存の半角カタカナ(1バイトカタカナ)を変換せずにそのまま使える②メモリに格納する際のバイト数が画面表示、印字の際の幅と一致するこれらの利点を理解できないひとが開発に携わると問題が解消されません。Shift_JIS系に戻すとよいでしょう。(個人的な予想では戻ると思ってます。)
NTのカーネルを日本のためだけにゼロから書き直すとか1000%ありえんわ。アホか
エスケープ文字含んでる時点で利点もクソもないだろ
Unicode系は制御文字含みすぎなんだよなぁ
ESCはあるけどそれは改行とかと同種のグリフに関係しない制御文字でプリンタブルじゃないだろ。プリンタブルな文字がすべて、バイト数と文字幅が一致するのがCP932。Unicodeは修飾系の文字もわんさかあるし、何より固定長フォントでも文字幅がフォント(言語)依存で変わるとかいう腐れ仕様も抱えてる。けど3バイト云々はUnicodeじゃなくてUTF-8が扱えてない不具合だね。これはCJKでなくても起こる問題。
それとももしかして、ISO-2022-JPみたいなのと混同してる?
この問題から見る限りでは、UnicodeというよりはUTF-8ですね。英語圏(英数字)の影響を最小化するために作られたモノなので、「7bit ASCIIだけでいい」をまさに体現したエンコードです。
現行Windowsの祖先であるWindows NTはUTF-16 ("Unicode" と称していた)なので、そこに戻るという手もあります。
とはいえ英語圏以外でもコードは7bit ASCIIで書くので、その他の文字コードの優先順位は低い。US-ASCIIと互換性のないUTF-16はバッチファイル書くのにすら使えなかったのでUTF-8が主流になった。
> Windows10のteamsElectronの問題と考えるのが妥当。Windows 11の問題の原因は別だろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
teamsもおかしい (スコア:0)
Windows10だが
ローマ字入力中に子音が2文字され確定
かきくけこ
Kakikukeko キー入力
kkあkkいkkうkkえkkお
メモ帳や他で出ないので
teamsの独自処理でしょうけど
ゴミ過ぎる。金を取れるレベルではない。
Re:teamsもおかしい (スコア:2, 興味深い)
正しくない文字範囲が変換対象として自動的に選択され、予期しない変換候補が表示される
カーソルが予期しない位置に移動して間違った文字シーケンスが選択され、現象 1 が発生する可能性がある
この現象はWindows10のteamsでも起こります。
テキスト入力や変更を行うとカーソルが
変な所に移動するので文字の入力や編集ができない。
メモ帳で編集してコピペです。
動作的に内部処理が2バイトで
文字が3ないし4バイトなので入力すると
変な所に飛ぶ感じです。
腐ったコードの使い回しでバグ感染しているのでしょう
Re: (スコア:0)
マイクロソフトにはUnicodeを使いこなす技術がもはやないのか、そもそもUnicodeの使用が糞なのかしらんが、いっそのこと古のShift-JISに戻ったらどうだ? 絵文字いらんし。
日本語以外の話者? 知らんがな。
米国人は7bit ASCIIだけでいい、って言いそうだけど。
Shift_JIS系符号化方式の利点 (スコア:0)
CP932を含む、Shift_JIS系符号化方式の利点として以下の2つがあります。
①既存の半角カタカナ(1バイトカタカナ)を変換せずにそのまま使える
②メモリに格納する際のバイト数が画面表示、印字の際の幅と一致する
これらの利点を理解できないひとが開発に携わると問題が解消されません。Shift_JIS系に戻すとよいでしょう。
(個人的な予想では戻ると思ってます。)
Re: (スコア:0)
NTのカーネルを日本のためだけにゼロから書き直すとか1000%ありえんわ。アホか
Re: (スコア:0)
エスケープ文字含んでる時点で利点もクソもないだろ
Re: (スコア:0)
Unicode系は制御文字含みすぎなんだよなぁ
Re: (スコア:0)
エスケープ文字含んでる時点で利点もクソもないだろ
ESCはあるけどそれは改行とかと同種のグリフに関係しない制御文字でプリンタブルじゃないだろ。
プリンタブルな文字がすべて、バイト数と文字幅が一致するのがCP932。
Unicodeは修飾系の文字もわんさかあるし、何より固定長フォントでも文字幅がフォント(言語)依存で変わるとかいう腐れ仕様も抱えてる。
けど3バイト云々はUnicodeじゃなくてUTF-8が扱えてない不具合だね。
これはCJKでなくても起こる問題。
それとももしかして、ISO-2022-JPみたいなのと混同してる?
Re: (スコア:0)
この問題から見る限りでは、UnicodeというよりはUTF-8ですね。
英語圏(英数字)の影響を最小化するために作られたモノなので、「7bit ASCIIだけでいい」をまさに体現したエンコードです。
現行Windowsの祖先であるWindows NTはUTF-16 ("Unicode" と称していた)なので、そこに戻るという手もあります。
Re: (スコア:0)
とはいえ英語圏以外でもコードは7bit ASCIIで書くので、その他の文字コードの優先順位は低い。
US-ASCIIと互換性のないUTF-16はバッチファイル書くのにすら使えなかったのでUTF-8が主流になった。
Re: (スコア:0)
> Windows10のteams
Electronの問題と考えるのが妥当。
Windows 11の問題の原因は別だろう。