例えば、同じ Apple の製品でも Mac は多言語入力が快適にできるのに、iPhone ではできない理由は、iPhone の場合は、Windows と同様に、いちいち言語ごとにキー配列を交換しなければならないからです。これは文字パレットよりははるかに快適ですが、「多言語」ユーザーにとってはいちいち言語を切り替えるのはとても面倒なだけではなく、同じ文字や記号の位置が言語によってクルクル変わるので混乱してしまいます。その点、Mac の場合は ABC Extended(拡張ラテン文字入力)というキー配列が用意されており、これをデフォルトに設定しておけばラテン文字を使う言語の特殊文字はほぼ全てこのキー配列だけで入力できてしまえるのです。いちいち言語を切り替えたり、言語を意識したりする必要がないのです。iPad Pro のみは外付けの Smart Keyboard を付けることで ABC Extended が使えるようになるので、iPhone よりはマシですが、それなら最初から MacBook Pro で入力した方が楽な訳です。
Windows は ABC Extended のようなキー配列は簡単にフリーウェアでも誰でも提供できそうなものなのですが、誰も提供していないようです。なぜか Microsoft も提供していない。(探してみたのですが、見つかりませんでした。もしかしたら、今ではもうどこかにあるのかもしれませんが。)二言語ユーザー程度ならば Windows でも困りませんが、言葉通り「多言語」ユーザーの場合は、Windows だと使えません。ポメラはさらにそれ以下のようです...。
ポメラで快適に多言語入力ができるのなら試してみようかなとも思ったこともあるのですが、今回ご紹介いただいたマニュアルをざっと拝見しても、どうも「単に仕様に上げるために付けただけの機能」という感じですね。設計者が多言語入力と言うものを理解していないのがわかります。と言うか、たぶん、設計者の発想は、Shift JIS だけでは入力し切れない旧字体や異体文字を入力できるようにするために Unicode にも対応したのでしょうね。外国語のことは全く考えていない。だから、そういう文字の入力なら文字パレットでも構わないという発想だったのでしょう。
キングジムのポメラもあるし (スコア:1)
過去のメーカーが今作ってないってだけで、文書作成専用機が滅んだわけではないよね。
Re:キングジムのポメラもあるし (スコア:3)
Re:キングジムのポメラもあるし (スコア:3)
CSVはいまだにISO-2022-JPで返すところが多いね。(Amazonでさえそう)
Excelの古いのがUnicode対応していないための対応なんだけれども。
Re:キングジムのポメラもあるし (スコア:2)
Excelって365の最新バージョンでもUnicode非対応じゃないですか?
#GoogleはUnicodeでCSV吐くしExcelはそれ読めないし、私はNumbersで読ませて解決しているけどWindowsユーザーの皆さんは同じ状況ではどうするのかと…
Re:キングジムのポメラもあるし (スコア:2)
Excelって365の最新バージョンでもUnicode非対応じゃないですか?
365になって状況が変わったのかは未確認ですが、BOM付だと関連付けで開いたときに正常に開けます。
https://doruby.jp/users/ueki/entries/BOM%E4%BB%98%E3%81%8DUTF-8%E3%81%... [doruby.jp]
「ファイルを開く」で開くのであれば、文字コードをしてしてやれば開けます。
が、そういう手間を省くためにシステム化してんだよ!って話があったりで要件によってそれじゃぁ意味無いってことでISO-2022-JPで提供するほうがユーザサポート的には安定そうではあります。
Excelで開かずにデータ連携させるのにそのCSV使いまわそうとすると、なんとも手間だったりしますが。。。
Re:キングジムのポメラもあるし (スコア:2)
ISO-2022-JPで提供するほうがユーザサポート的には安定そうではあります。
素人の素朴な質問です。自分は多言語ユーザーなので Excel 上でバンバン ő とか ű とか ö́ とか ǘ とか、ș とか ł とか Unicode 文字を使っているのですが、ISO-2022-JP の CSV ではどうやって対応するのでしょうか?
Re:キングジムのポメラもあるし (スコア:2)
ISO-2022-JPで提供するほうがユーザサポート的には安定そうではあります。
素人の素朴な質問です。自分は多言語ユーザーなので Excel 上でバンバン ő とか ű とか ö́ とか ǘ とか、ș とか ł とか Unicode 文字を使っているのですが、ISO-2022-JP の CSV ではどうやって対応するのでしょうか?
私はそういうのに関わったことないので分かりませんが、システム設計者によって結構対応方針違いそうなやつですね。。。
Re:キングジムのポメラもあるし (スコア:1)
>ポメラ
初代DM10(2008年)以降各モデルがシフトJIS機なるも、DM200はUTF-8対応機では?
最初の判断が後ろ向きだった、開発コストがUnicode対応にようやく着手できる
ところまで追いついた、みたいに見えますね。実情を知りませんけど。
>日本では相変わらず ISO-2022-JP サイトが大量に
こっちは、堂々と改修費用を予算取りする理論武装不足のせいとかそういう
理由かなあ?酷い言い方をすると iso-2020-jp 放置プレイ?
Re: (スコア:0)
DM200はUTF-8に対応しています(デフォルトでUTF-8、ShiftJISに切替可能)
https://www.kingjim.co.jp/resource-files/download/manual/pomera/pomera... [kingjim.co.jp]
(27ページ参照)
Re:キングジムのポメラもあるし (スコア:2)
なるほど。確かに仕様上は「Unicode 対応」のようですね! しかし、Unicode の入力方法が「文字バレット」からの選択では現実的には実用になりません。キーボードからの入力手段が提供されていないと使い物にならないのです。
多言語ユーザーの場合は様々な補助記号の付いた特殊文字を日常的にかつ頻繁に用います。なので入力方法がとても大事になってきます。
例えば、同じ Apple の製品でも Mac は多言語入力が快適にできるのに、iPhone ではできない理由は、iPhone の場合は、Windows と同様に、いちいち言語ごとにキー配列を交換しなければならないからです。これは文字パレットよりははるかに快適ですが、「多言語」ユーザーにとってはいちいち言語を切り替えるのはとても面倒なだけではなく、同じ文字や記号の位置が言語によってクルクル変わるので混乱してしまいます。その点、Mac の場合は ABC Extended(拡張ラテン文字入力)というキー配列が用意されており、これをデフォルトに設定しておけばラテン文字を使う言語の特殊文字はほぼ全てこのキー配列だけで入力できてしまえるのです。いちいち言語を切り替えたり、言語を意識したりする必要がないのです。iPad Pro のみは外付けの Smart Keyboard を付けることで ABC Extended が使えるようになるので、iPhone よりはマシですが、それなら最初から MacBook Pro で入力した方が楽な訳です。
Windows は ABC Extended のようなキー配列は簡単にフリーウェアでも誰でも提供できそうなものなのですが、誰も提供していないようです。なぜか Microsoft も提供していない。(探してみたのですが、見つかりませんでした。もしかしたら、今ではもうどこかにあるのかもしれませんが。)二言語ユーザー程度ならば Windows でも困りませんが、言葉通り「多言語」ユーザーの場合は、Windows だと使えません。ポメラはさらにそれ以下のようです...。
ポメラで快適に多言語入力ができるのなら試してみようかなとも思ったこともあるのですが、今回ご紹介いただいたマニュアルをざっと拝見しても、どうも「単に仕様に上げるために付けただけの機能」という感じですね。設計者が多言語入力と言うものを理解していないのがわかります。と言うか、たぶん、設計者の発想は、Shift JIS だけでは入力し切れない旧字体や異体文字を入力できるようにするために Unicode にも対応したのでしょうね。外国語のことは全く考えていない。だから、そういう文字の入力なら文字パレットでも構わないという発想だったのでしょう。
※ 「ラテン文字」は日常的には「アルファベット」と呼ばれているものですが、アルファベットはラテン語や英語等を表記するラテン文字以外にも、ロシア語などのキリル文字や、ギリシア語のギリシア文字、アルメニア文字やグルジア文字、コプト文字等も含むので混乱を避けるために「ラテン文字」という正式な名称を用いております。
Re: (スコア:0)
ポメラは今は対応しているはずだしキャリアメールも今はUnicode使えたかと。
デフォでUnicode使わないのは互換性を重視したら仕方ないし、SMSは規格の問題もある。
その手のデバイスでUnicode対応が遅くなったのは、文字コード変換用のマップを用意したり、
Unicode空間に対応したフォント形式に対応させた上でUnicode文字をサポートするフォントを準備したり(場合によってはビットマップで)、
対応に必要なコストが高めに付いたんだろうと思えば特に不思議でもない。
海外のサイト?
ASCIIで済んでる連中は単に文字コードの名前をUTF-8に
Re:キングジムのポメラもあるし (スコア:2)
キャリアメールも今はUnicode使えたかと。
メール自体 UTF-8 で作成されるようになったのですかね?
iPhone が登場した時には、iPhone から送信されるメールは当初は全て UTF-8 でした。UTF-8 ならば何語でも表示できるし、いちいち他の不完全な文字コードで送信する必要はないとの合理的な判断からだったと思います。
ところが日本のガラケーで iPhone のメールを受信すると、特に au の場合が一番悲惨で、1文字でも ISO-2022-JP で対応していない文字が含まれていると、メール全体が文字化けしてしまい、一切読めなくなってしまっておりました。ところがドコモの場合は、最初から Unicode でないと表示できない文字のみ「・」で置き換えられるという仕組みで表示していたので、メールの一部の文字は読めなくても全文は何となく読めたのでした。
その後、Apple も仕方なく (?) 日本語のメールの場合は ISO-2022-JP だけで送信できるメールは自動的に ISO-2022-JP で、ISO-2022-JP で表示できない文字が含まれている場合は UTF-8 で送信するように仕様変更されました。
暫くして au 等も「Unicode 対応!」を謳うようになりましたが、別に ISO-2022-JP で定義されていない文字も化けずに表示されるようになった訳ではなく、単にかつてのドコモと同じように ISO-2022-JP で定義されていない文字が「・」で置き換えられただけで、結局は Unicode の文章はきちんと表示されないままだと言うことがわかりました。
つまり、
「Unicode 対応!」=「ISO-2022-JP のままだけれど、Unicode 文字は『・』で置き換え、メール全文が文字化けしないようになりました」
というだけのように私は理解しておりましたが、現在では普通に文字化けせずにキャリアメールで „műbőr [ˈmyːbøːr]” とか „Straße [ˈʃtrɑːsə]“ とか „Nicolae Ceaușescu [nikoˈla.e t͡ʃe̯a.uˈʃesku]“ とか、“Hồ Chí Minh [ho˨˩ t͡ɕi˧˦ mïŋ˧˧]” とか «Михаил Сергеевич Горбачёв» とか «ἡ ἄναγνώρις τῆς ἄγνοιᾱς» (hē anagnṓris tẽs ágnoiās) とか、《태왕사신기》(太王四神記)とか、「毛泽东」とか、「深圳市」とか、”עמוס גיתאי„ (Amos Gitai) とか、„ქეთი მელუა“ (Keti Melua) [Katie Melua] とかいった文字が入力できたり、表示できるようになっているのでしょうか?(たぶん、ガラスマはきっと表示できるんでしょうね?)
Re: (スコア:0)
多くの日本人にとって、日本語が扱えればそれでいいんです。今は知りませんが、かつてはメールサーバーが7bitしかサポートしていなくて、8bitのUTF-8は使えない可能性がありましたし、メーラーも同様でした。国内利用者向けの携帯メールならなおさらですね。だから、国内向けにはUnicodeのサポートの必要はなかったんです。
私は、最初期の頃にOS Xを使っていましたが、標準のメーラーでメールを送るときはISO-2022-JPになるようにしていたように記憶しています。UTF-8で送ってしまう可能性があったからです。自分の持っている機械が最高だから、それに相手が
Re:キングジムのポメラもあるし (スコア:2)
多くの日本人にとって、日本語が扱えればそれでいいんです。
ええ、それはわかっています。ただ、いつまでも、例えば大学のシラバス入力サーバで参考文献がきちんと入力できないとかいう状況はやはりなんとかなって欲しいものです。
#ところで、引用符を使い分けているところに妙に感心してしまいました。ハンガリー語とドイツ語では同じように見えて、閉じる方は逆向きとか。
気付いていただけましたか♪
ついでにフランス語とイタリア語を追加すれば、
« Le Tokaji aszú – Vin des rois, roi des vins » と «E pur la terra si muove» とか♪
Re: (スコア:0)
ええと、Android端末が出回ったりキャリアメールをiPhoneで扱えるようになる前の時代からタイムスリップしてきたのか?
ガラケーとか既にほぼ絶滅した物とiPhoneだけ並べて話をされても意味がわからないと言うか、
さすがApple信者は正気を失っている・・・的な感想にしかならんわ。
昨今のキャリアメールはSMSで着信通知をプッシュしてIMAP辺りで拾うからIMAPとかに載せれりゃ何でもいいよ。
メールサーバーから先の互換性は今も昔もメールを送る相手によるとしか言えん。
iPhone()だろうがなんだろうが経路は大差無い。
Re:キングジムのポメラもあるし (スコア:2)
ASCIIで済んでる連中は単に文字コードの名前をUTF-8に差し替えとけばネイティブ共には何の支障もないし
日本語のサイトの場合でも Shift JIS で作成したサイトのソースの先頭に “charset=utf-8” と入れるだけじゃダメなんですかね? いや、ずっと以前、自分で作っていたウェブサイトで ウェブエディタが UTF-8 に対応したので、ソースファイルの先頭に “charset=utf-8” と打ち込んで、例えば「ő」と入力していた文字を „ő” に置き換えてスッキリさせてから公開したのですが、普通に何の問題もなく UTF-8 のサイトとして見ることができたもので、日本語のサイトを UTF-8 化するのはそんなに大変なことなのかなぁと...。(あ、そうか、エンコーディングを UTF-8 に変更した段階で GoLive のようなウェブエディタが必要な変換処理をやってくれていたのか?)
すみません、素人で。
Re:キングジムのポメラもあるし (スコア:2)
例えば「ő」と入力していた文字を „ő” に置き換えて
おっと、意味が通じなくなってしまいました。そうか、参照文字も変換して表示されちゃうのですね。元の記号を全角にして書いてみます。
例えば「ő」と入力していた文字を „ő” に置き換えて
Re: (スコア:0)
> 日本では相変わらず ISO-2022-JP サイトが大量に存在し続けている
まじで?
Shift_JISなら、まだ少し残ってる印象はあるが・・
Re: (スコア:0)
自己レス。
俺が普段見回るような、楽しいエンタメを提供しているサイトはどうせどれもutf-8ばかりだろうから
googleで「沿革」を検索して、10ページ目くらいのあまりよく知らない会社さんの
会社沿革ページを20社分くらい見回ったが、iso-2202-jpどころかShift_JISすらもなく
どれもこれもutf-8ばかりだぜ。。。
Re: (スコア:0)
会社のWebサイトをとりあえずでも作っとくかが増えてきた時代を考証しないとその調査では当てにならんような気もするが・・・
官公庁のサイトとかも今はUTF-8の方が多いかな?
Re: (スコア:0)
省庁のページをいくつか確認。
総務省 [soumu.go.jp]と財務省 [mof.go.jp]がShift_JISだった。
それ以外は大体(農林とか防衛とか官邸とかも含め)UTF-8だった。
Re: (スコア:0)
分かった。site:.ac.jp C言語 [google.co.jp]で検索したら、Shift_JISやEUC-JPの率が高かったぞ。
Re:キングジムのポメラもあるし (スコア:2)
案の定、シラバスに参考文献等を入力すると、次々にエラーが出まくり、コンピューターの専門ではない一般教授陣はパニクりました。大学ですから当然洋書率は高いのですが、é だとか ç だとか ö 等は全滅。しかし、彼らはそれがなぜダメなのかが理解できない...と言うか、そのせいで先に進めないということ自体思い至らない。さらに驚いたのは、この手の特殊文字が入力できないだけではなく、書誌では頻繁に出て来る「&」が入っているとアウト。著者名とかタイトルにはよく使われる文字です。まさかこれのためにエラーになってるなどとは誰も思いません。(ちなみに Shift JIS だと & はなぜダメなんですか?)ユーザーインターフェースがタコで、単にエラーが出るだけで、なぜダメなのかがわからない仕組みでした。
ちなみに、他大学のシラバスも非常勤で入力したことがありますが、utf-8 非対応のものが多いですね。
先ほど某政府機関からメールが届きましたが、Word のファイルが添付されていましたが、ファイル名の日本語部分が全て「?」に置き換わっておりました...。サイボウズを使っているらしく、エンコーディングは ISO-2022-JP でした。サイボウズからのメールは鬼門です。
Re: (スコア:0)
Shift JISは関係なさげ。
Re: (スコア:0)
その辺りもわからんマカーのいちゃもんを相手にしなきゃならんとか相手の人も大変だなぁとしか。
やっぱApple信者は害悪なんだな。
そう思われたくないApple信者の人が居たらこいつ引き取ってくれ。
Re: (スコア:0)
文字コード指定と実際の文字コード不一致というのがどこかにあったなぁ…
#当然文字バケ
Re: (スコア:0)
古いWebコンテンツを新しいサーバに持ってきた結果、古いHTMLのため文字コード指定がなかったり、Webサーバの指定してくる設定と違ったりして文字化けするケースもありました。
PCでは普通に読めても、スマホで化けたりします。
Re: (スコア:0)
そういや、まともに表示できる文字コードをブラウザのメニューから探すということをここ10年くらいやったことがないな
Re: (スコア:0)
シフトJISも、geocitiesの閉鎖で大幅に減りそうですね。
Re: (スコア:0)
日本マイクロソフトが、いつまでもCP932なんか標準にしているからじゃないの?