文字コード総合スレ Part11
■ このスレッドは過去ログ倉庫に格納されています
https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC
>ベーシックマスターレベル3
>標準でひらがなの表示が可能。
>ひらがなモードでは8×16ドットによってキャラクターを表現する関係から
>インタレーススキャンを利用するため、ちらつきを防止するために
>専用ディスプレイは長残光仕様であった。
後継機のS1を持っていた
S1でも同様にひらがな表示は出来たが、持っていたディスプレイが
長残光仕様じゃなかったので、ちらつきがひどくてひらがなは使えなかった あーπだったか
πにしてもこの限られたなかに入ってるのはちょっとふしぎだ >>162
MSXにはバッククォート ` もあるんだな
S1にはなかった… みなさんありがとうございました。
恐らくMSXの日本語文字のことのようですね。
確かにJISの「半角カタカナ」（というと某氏に粘着されそうですが^^;）は良く聞くのですが
ひらかなやまして漢字が１バイトで表現されていた時代もあったとは知りませんでした。
勉強になりました。 >>172
どうせ過疎スレなんだから答えてやれよハゲ あの時代はVRAMに直接アクセスしてフォント書き換えるのが可能だったから漢字作るのも可能だったよね
まぁデフォルトて漢字用意してたのはMSXくらいしか知らないけど
普段使わないasciiコード255に「笑」を割り当てていたのを思い出してちょっと恥ずかしくなってみたり >>178
そりゃPCGだろ。書き換えるための仕組みとして用意してたんだよ。
VRAMに書けるからどんな文字も表示できるってことなら今だって同じだ。 >>179
月火水…とかはMSXのと文字コードは違うけど並び方は同じだし
ひらがなとかは文字コードも同じだな >>162 >>180
細かいこと端折ってしまったみたいで済まなんだ
VPOKE命令だからてっきりVRAM直なのかと思ってたよ >>179
セミグラフィックの文字，今じゃほとんどUnicodeに収録されてるなぁ（もちろんUnicodeがPC-6000を念頭に置いてる訳ではないけども）
と思って眺めてたら，Unicodeに無さそうな文字が。
1/8-7,8,9の総和記号を三分割した文字は多分未来永劫Unicodeには収録されないだろうから，
完全にPC-6000独自の文字として歴史に残るねw そこまで大袈裟に言う必要があるかどうかは不問にするとしてさ。 >>184
こんなのでフフッってなってしまった。
まだ4月始まったばっかりなのに疲れてるのかな… >>181
同じCGROM使ってたとか何か理由ありそう
P6の方は60の`を欠いてたけど >>183
あれ、確かUCS/Unicodeにも入ってなかったっけ？
……と思ったらUnicodeに入ってたのは三分割じゃなくて二分割だったか。うーん残念？
U+23B2 ⎲ SUMMATION TOP
U+23B3 ⎳ SUMMATION BOTTOM UCS/Unicodeっていう表現はどういう意味？ >>189
GNU/Linux みたいなもんだろ
知らんけど ISO-2022-JP/MIME
みたいなもんだと思ってた >>189
微妙な違いはあれど「ucsやunicodeなどと呼ばれてるもの」みたいな意味で使ってるんじゃないかなー。
x64/amd64みたいな？ Yahoo!ニュースが突如「？ ？ ？ ？ ？ 」しか書かれていない記事を公開、閲覧者の脳内が「？ ？ ？ ？ ？」になる【修正済み】 - Togetter
https://togetter.com/li/1220498
https://headlines.yahoo.co.jp/hl?a=20180422-00000028-yonh-kr
もう修正されちゃったけど、文字化けの記録として。 Windows 10 機能更新プログラム (2018 Spring Release) における元号のレジストリ更新について – Japan New Era Name Support Blog
https://blogs.technet.microsoft.com/jperablog/2018/04/20/rs4-registry/
「？？」ってさあ……もうちょっと、こう、何か無かったのか。 戦争の場が宇宙に移ったということだろう
水鉄砲というよりもSFにありそうなレーザーガンっぽいしw 過去の文献のニュアンスが変わってしまいそうだが大丈夫か…… 絵文字のデザインなんて前からコロコロ変わるゆるふわなものだってことじゃないの
U+1F3B1 BILLIARDS は例示ではキューと積まれたボールのデザインだったのに各メーカーは何が気に入らなかったのか知らんけど「8ボール」のデザインで実装
仕方ないので Unicode 12.0 では例示字形を変更し元々のキュー&ボールは U+1F93F BILLIARD GAMES として新たに追加(予定)とか
もう何でもありだなって思うわ。 元々auの絵文字が文字名はモヤイだけどグリフイメージがモアイだしなあ
そんでもってdocomo/Softbankへ送ると[モアイ]になるんだっけ？どっちだよｗ 新元号への対応に向けた検証とテスト ケースについて
https://blogs.technet.microsoft.com/jperablog/2018/05/01/test-case/
現時点で新元号は発表されておりませんが、新元号に対しても合字を用意すべく、
弊社では Unicode コンソーシアムや日本政府、業界団体とともに
Unicode 上の文字コードの確保や新しい字形の作成、フォントの更新について準備を進めております。
新しい合字のコード ポイント等については未確定の状況でございますが、
今一度、下記のような合字の表示、入力に問題がないかご確認ください。
また新元号の発表後に追加される合字を正しく表示するためにはフォントの更新 (合字のグリフの追加) が必要となりますため、
アプリケーションにてご使用のフォントについても確認が必要と想定されます。
- ㍻ (U+337B)
- ㍼ (U+337C)
- ㍽ (U+337D)
- ㍾ (U+337E)
また、合字を含めた検索や並べ替えについては、少々考慮が必要です。
弊社の Web 検索 "Bing" では、"㍻" を検索した際 ”㍻” と ”平成” の両方が検索されます。
一方、Word では "㍻" の検索の際には "㍻" のみが検索されます。
検索や並べ替えの動作についても正規化処理の状況によって異なる結果となることが予想されますため、
ご確認をいただくことをお勧めいたします。 年号に合字コード用意するのやめようぜ
普通に2文字使えばいいじゃん
どうしても組文字にしたければフォントじゃなくて
ワープロソフトとかDTPソフトにやらせてくれよ https://twitter.com/KawamataAkira/status/990740397490978816
そういえば、MSKKの社員だった時代(1990年頃)、自分のまわりにいた日本人の技術者は全員元号のサポートに反対だった。
元号を入れたがったのはアメリカ本社のアメリカ人技術者。
日本人はそんなものサポートしたって面倒が増えるだけだと分かっていたけど、
各国の伝統文化を尊重したというポーズを取って得点を稼ぎたいアメリカ人とは利害が違ったのだと思う。 フォントで合字するのは別にいいよ
わざわざ文字コードに入れるのがアホなんや >>214
その「元号のサポート」って機種依存文字エリアに合字の年号を入れることを指してる？
時刻の表示形式の「平成XX年XX月XX日」みたいなののことじゃ・・・
合字は伝統文化じゃないよね別に 合字に関しては、直前２文字の表示幅を半分にする制御文字を追加すればいい気がする。
絵文字で肌色指定する制御文字がすでにあるので、それと同じ。
システムにフォント表示幅を変える機能が必要ではあるけど。 >>219
＞絵文字で肌色指定する制御文字がすでにある
そんなものあるの？Unicodeの理念からどんどん遠ざかっている気がする >>220
肌の黒い中国人とか表示可能。
👲👲🏻👲🏼👲🏽👲🏾👲🏿 あー失礼。直前2文字ごとじゃなくて直前1文字ごとに設定すればいいだけか。 >>219
ゼロ幅接合子が漢字を対象に使われた場合は、その漢字同士で合字を作るようにすればいい 1文字単位で半角幅化できれば合字いらなくなるでしょ。 文字幅セレクタなんてもんができてしまったら
EAWもfullwidth領域もなんだったんだってことになるだろw 単純に幅半分にしたら縦と横の線の太さがチグハグになりそう
フォント屋が頑張って調整すればいいか >>228
白黒の2色じゃなくて中間色を使うアンチエリアスが必要。
フォント屋の仕事じゃなくてOSレベル(例：WindowsのClearType)の範疇。
印刷時の見栄えを一致させるには、当然、印刷機も中間色への対応が必要。 正体を単純に長体にすると視認性が落ちるからとCondensedやCompressedな書体を作ってるデザイナーが見たらガックリくるような話だな このネタいつまで引っ張っても元号に文字コード割り当てようという考えが如何に頭が悪いかということを思い知らされるだけだ これでその時点の元号を表示すればいいのか
<日本の元号を表すコード(共通)> <西暦年(100の位 : 6～20)を表す制御コード> <西暦年(0～99)を表す制御コード> <月(1～12)を表す制御コード> <日(1～31)を表す制御コード> 文字コードとプログラミングの区別ができない人は、このスレに書き込まないほうがいい。 >>235
順序はあるんだから
日本の元号を表すコード(共通)> <順序数コード>
で済むよね 全角文字を半角の幅で表示したい潜在需要は、中国や韓国にもあると思うます。 7pt文字から36pt文字までコードを割り当てれば十分だと思う。 >>239
<日本の元号を表すコード(共通)> <王朝を表す制御コード> <西暦年(100の位 : 6～20)を表す制御コード> <西暦年(0～99)を表す制御コード> <月(1～12)を表す制御コード> <日(1～31)を表す制御コード> 「制御コード」？ 普通の2進コードじゃイカンのか？ Unicodeの仕組みをよく知らないので
普通の2進コードを書けるならそれで そんなコード作ったところで検索もできないし、妄想の域にすらない
そもそも漢字で書ける元号に合字が必要かって話だし、まったく方向がおかしい ID隠してる奴なんてあぼーんしとけ
おかしなやつに構う奴も荒しだからな Unicodeの次の概念とかはまだないのかな。それとももうみんなUnicodeに満足してしまっているのかね。 universeの次がmultiverseなんだから次はmulticodeだろうね。
それかikuracode Progressive Unicode、略してPunicode glicoodeというやつが開発されてなんか賞取ってた気がする もう変な合成記号類は多数あるし、漢字合字開始、漢字合字終了の2文字だけ定義しとけばいいんじゃないかな。
そうすれば未来永劫大丈夫だ(フォントさえ準備すれば)。北の人とかでも使えるし、なんなら金印とかハンコとかも好きなだけ合成できる。 >>252
グリコが開発したプログラミング言語じゃないの？
文字コードと関係なくね？ >>252
> glicoodeというやつが開発されてなんか賞取ってた気がする
o が１つ多すぎる
正しくは glicode
ポッキーの並べ方でプログラミングするって奴ね
詳しくは次のページを参照
http://cp.glico.jp/glicode/ 「祇園」のフォントというかグリフって間違ってるよね？
Win10とAndroidは同じっぽいけどどっちも間違いの気がする >>239
20年以上前にとあるDBマネジメントシステムに関わっていたんだけど、和暦対応を導入しようかって話が出てときに南北朝の話で揉めたよｗ
あの時はどうやって解決したんだっけかな……西暦→和暦変換の関数にオプションを付けたんだっけかな？ (覚えてないやゴメン) >>257
明治5年以前は今使われている太陽暦とは違う暦、太陰太陽暦が使われていたんだけど
その変換はどうしてたんだろ スレ違い気味の自覚はあるのでほどほどにしときます……
>>258
和暦と西暦の相互変換が出来れば十分という要件だったので、それほど困らなかった気が。
西暦→和暦の変換は問題ないよね？
んで、和暦→西暦の変換では存在しない日付を指定したらエラーにしていたんじゃなかったかな。
(例:明治5年12月3日は存在しないため、西暦に変換しようとしてもエラー)
なお上記では西暦と表記してるけど、実際にはグレゴリオ暦とユリウス暦の違いを意識していた記憶がある。
ただし、どうやって解決していたのか思い出せない…… (使えなくてすみません)。 どうせスレチなら現代でも太陰暦に変換するツールが必要 例えば1月30日が存在するかどうかは年ごとに違っていたそうな
https://ja.wikipedia.org/wiki/%E9%96%8F%E6%9C%88
>太陰太陽暦では月の満ち欠けに基づく「30日」と「29日」の二つであり、
>「30日」を「大の月」、「29日」を「小の月」とする。
>しかもこの月の大小は、月の満ち欠けの仕方などによってその順番が年ごとに変わる。
>太陰太陽暦ではこの太陰暦の12ヶ月に、約3年に一度、1ヶ月を加え13ヶ月とし、
>季節とのずれをなるべく少なくする調整をする。この挿入された月を「閏月」という。
>しかしながら閏月をどの時期に入れるかについては、同じ時代でも地域によって食い違うことがあった。
>例えば日本では古来より西日本では伊勢暦、東日本では三島暦が主に用いられたが、
>時として閏月を挿入する時期が異なっていたので、日本国内で日付の異なる暦を使っていた事がある。 結局Alternative Unicodeはまだ存在しないのか……。
Unicodeの制定が1993年なことを考えると、そろそろ別の規格が立ち上がってもいい筈なんだけどな。
Unicodeの仕組みが余程完璧ならいざしらず。 Adobe、Apple、Facebook、Google、IBM、Microsoftといったコンピュータ業界の大会社がUnicode作ってるからなぁ
(実際あるのか知らないけど)他の方面からの立ち上がりに期待するしかないかと。 ローマ数字グリフはUnicodeではCJK互換用文字のように使用が推奨されないとどこかで読んだ記憶があるのですが、間違いでしょうか。
Wikipediaの当該項目を見てもそんなことは書いておらず、困惑してます。
もしも間違いなら積極的にローマ数字グリフを使っていきたいのですが……。 >>265
もしかして、これかな？
以下のページに「ただし、Unicodeの仕様では、これらは互換性用の文字であり、対応するラテン文字を用いる方が良いとされています。」という記載がある。
ローマ数字 - CyberLibrarian
http://www.asahi-net.or.jp/~ax2s-kmtn/ref/roman_num.html
Unicode Chart で Roman numerals (U+2160とか) を見てみると Compatibility decomposition mapping としてラテン文字が記載されている。
これを以って上記ページの筆者が「ラテン文字を用いる方が良い」と記載しているのなら、それは解釈が正しくないように思う。
あくまでも互換性があるよ、というだけの注記だと思うのだがどうだろうか。
ちなみに Compatibility decomposition mapping の説明は、こちら。
↓
Code Charts - Help and Links
https://unicode.org/charts/About.html#Key ■ このスレッドは過去ログ倉庫に格納されています
