たまりば

パソコン・インターネット パソコン・インターネット三鷹市 三鷹市

ASCII-7セグメント対応
2014年12月30日 01:03

以前7セグ英字表記を作ったが、今回さらに7セグで全ASCII文字(ただしアルファベットの全半角の区別を除く)を考えてみた。
ASCIIと7セグの対応で最も難しいのは括弧類である。
括弧類は(),[],{},<>の4種類あり、さらに"C"を加えると似たような形の5種類を区別しなければならない。
以前から何度か7セグASCIIには挑戦したことがあったが、この5種類をひねり出すことがどうしてもできなかった。
これを今回、区別のために1つセグメントを追加することで一意に対応付けることができた。英字のときmとn、uとvの区別のために使った手法である。<>がセグメントを追加されている。
括弧類
他は、読めるかといえば微妙なものもあるが、一意に対応付けること自体はさほど難しくなかった。
完成したものがこちらである。
7セグASCII対応
「┤」「├」の形を{}に使ってしまったために「+」が完全に余り物になってしまったのと、どうしようもなくて諦めた「&」が読めない筆頭である。他は面影はあると思うので説明は省略する。
英字部分は基本的に前回のものを踏襲したが、Cは括弧との兼ね合いで小文字に、Wは#に取られて形を変更している。
英字部分変更点

余談
1セグメントのみの表示は7つ全て文字に対応している。何かと便利かもしれない。
単独セグメント

7セグメントに加えドットも使うならこういうのもありか。
ドット付きの場合
また、ドットを使うなら大文字フラグとして使ってASCIIの全文字を区別可能にするのもよいだろう。

あと何かに使いたい人のためにビット表示。左からABCDEFGセグメント。
【 !"#$%&'()*+,-./】
0000000
0101000
0100010
0111111
1011010
0010010
0011110
0000010
1000011
1100001
1100011
0010001
0011000
0000001
0000100
0100101
【0123456789】
1111110
0110000
1101101
1111001
0110011
1011011
1011111
1110000
1111111
1111011
【:;<=>?】
1000001
1000101
1001101
1001000
1011001
1101001
【@】
1111101
【AbcdEFGHiJKLmnoPQrStuvWXYZ】
1110111
0011111
0001101
0111101
1001111
1000111
1011110
0010111
0010000
0111100
1010111
0001110
1010101
0010101
0011101
1100111
1101011
0000101
0011011
0001111
0011100
1011100
0101010
1001001
0111011
1101100
【[\]^_】
1001110
0010011
1111000
1100010
0001000
【`】
0100000
【{|}~】
0110001
0000110
0000111
1000000
  

  • Yahoo翻訳が残念だ ~ついでに機械翻訳考~
    2014年12月23日 03:49

    先日(2年ちょっと前)、Webで見つけたドイツ語の文章を読みたくなったので「翻訳」とググって上位に出たYahoo翻訳を使ってみた。

    これが残念な出来であった。
    何が残念かというと、ドイツ語→英語のような翻訳が出来ず、日本語→X語とX語→日本語でしか翻訳できない。
    多数の翻訳エンジンを作るのはコストがかかるからしかたないと思う人もいるかもしれない。
    だが違う。そもそも中・韓・英以外のX語↔日本語の翻訳エンジンなど存在しない(と思う。もしあったら教えてください。見分け方は後述)。X語→日本語翻訳をしているつもりでも中でやっているのはX語→英語→日本語の2段階翻訳である。
    であれば、多少なりとも英語が読めるなら1段しか翻訳を通していない状態で読めば得られる情報は多い。英訳した上でそれでも分からない部分だけを和訳すれば誤訳も減る。
    システムにかかるコストも、単に処理の途中で止めるだけであるから、1つの翻訳エンジンを作るコストを考えれば無視できるレベルである。それで得られる情報を考えればすべからく搭載すべき機能だ。
    それを分かっているからだろう、エキサイト翻訳ではX語翻訳のページにはX語↔日本語とX語↔英語のボタンがある。Infoseekマルチ翻訳やGoogle翻訳ではX語↔Y語の翻訳まであるが、それをしないのは日本人にはあまり必要ないという判断だろう。

    さて、X語↔日本語の翻訳が間に英語を介しているというのは、まあなんとなく見れば想像がつくことではあるのだが、明確な証拠を見つけるのに苦心していた。
    以前考えたのが、「光陰矢のごとし」と「時間蝿たちは矢を好みます」が「Time flies like an arrow」になることを利用してどうにかならないかということだが、「光陰矢のごとし」から「蝿」が出てきたら明らかにおかしいということしか思いつかず、いまいち方法論として確立できなかった。
    今回色々考えてやっと確立したのでここに記しておく。

    ・英語において同綴異義語で、日本語でもX語でも同綴異義語でない1組の単語を用意する。
    ・その2つをそれぞれ翻訳機に通し、結果を見る
    ・同一の結果になれば、間に英語を介している証拠である。

    なお実際には単語だけで翻訳すると変化形になったり主語述語が付いたりすることがあるので、文章にした方が確実である。

    これに使う同綴異義語の選定は意外と難しい。
    まず、X語で同綴であってはならない。これを誤ると結果が信用できなくなってしまうため重要だ。元々同じ意味が分化したようなものだと欧米語ではみな同綴だったりする。きちんと英X辞典で調べておく必要がある。
    次に、品詞が異なる語は使いづらい。例えば「fly」は「蝿」と「飛ぶ」だが、この単語だけが異なるように文章を組み立てるのは難しい。
    さらに、他言語から訳したときに確実にその語に訳される保証が無くてはいけない。例えば英語で「cattle」を出したくて「牛」を入れてもYahoo翻訳では「cow」になってしまう。このような語は使えない。
     
    その辺を考えつつ、思いついた同綴異義語がこのあたり。
    bat : (野球の)バット / 蝙蝠
    scale : 秤・標準 / 鱗・鱗粉
    bow : 弓 / お辞儀
    light : 光 / 軽い (品詞が違うが、両方"I am light"の形で使える)

    試してみよう。
    「私はバットでボールを打ちます」と「私は蝙蝠でボールを打ちます」をYahoo翻訳でドイツ語へ翻訳してみる。
    結果、両方とも「Ich traf den Ball mit einer Fledermaus.」となり、間に英語を介している確証が得られた。
    なおFledermausは蝙蝠である。

    もう1つ試してみよう。
    「鱗」と「秤」を翻訳すると、「鱗」は「Maßstab」に、「秤」は「Die Waage」になってしまった。不思議だ。直接訳しているのだろうか?
    そこで英語に訳してみると、「鱗」は「scale」に、「秤」は「scales」になっていた。
    単語を翻訳するとこのようなことが起こる。なので文章にしてみる。
    「私は2つの秤を持っています。」と「私は2つの鱗を持っています。」で試すと、両方「Ich habe die zwei Waage.」となり、やはり間に英語を介していることが確認できた。


    これをやっていて思ったのだが、自動翻訳機は文脈を判断してくれない。平気で蝙蝠でボールを打ったりお辞儀で矢を射たりしてしまう。
    文脈を判断するというのはそんなに難しいことなのだろうか。
    であれば逆に文脈判断は諦め、多段翻訳の時に多義語の部分だけでも原語を見て選ぶような仕組みはできないものだろうか。
    もしくは、翻訳中に情報が失われないよう、中間的な言語情報を持てないものか。
    中間言語といっても新しい言語を1から作るのは現実的ではないので、既に中間言語の地位にある英語を元にいじるのがいいだろう。
    例えば、「bat1」と「bat2」を内部的に用意しておき、「蝙蝠」の訳は「bat1」、「バット」の訳は「bat2」とする。これを英語として出力するときには両方「bat」になるが、続けてドイツ語に翻訳したときは「Fledermaus」と「Schläger」に訳し分けるようにする。
    逆に意味の広い単語が入力された場合、例えば「牛」なら「cow/ox/cattle」となったりする。これは出力段になってどれか一番メジャーなものに寄せるのもありだが、そのまま「(cow/ox/cattle)」のような状態で出力する方法も考えられる。
    実は韓国語→日本語の翻訳では同綴異義語のあまりの多さに「○○(△△)」のような訳がしょっちゅう出る。これを欧米語↔日本語でもやってもよいだろう。


    ところで、今回の件は折角なので問い合わせフォームから意見を送っておいた。
    Yahoo翻訳において、「X語⇔英語」の翻訳が出来ない仕様は不便ですので、改善を願います。(X=中韓日以外)
    中韓以外⇔日本語の翻訳は間に英語を挟んだ2段階であり中間で止めることにかかるコストは少ないと思います。
    来た返事がこれだ。
    Yahoo!翻訳カスタマーサービス●●です。
    いつもYahoo!翻訳をご利用いただき、ありがとうございます。

    お問い合わせの「他国語から他国後への翻訳」について回答いたします。 ←※「他国後」は原文ママ

    ご連絡いただいたように現在Yahoo!翻訳では、他国語から他国語への
    翻訳は行えない仕様となっております。

    ◇Yahoo!翻訳で翻訳できる言語
    http://help.yahoo.co.jp/help/jp/honyaku/honyaku-02.html

    このたびお客様よりご連絡いただきました内容は、より便利にご利用いただける
    サービスをご提供できますよう、担当部署に報告のうえ、今後のYahoo!翻訳の
    検討課題にさせていただきます。

    今後も、皆様に親しんでいただけるサービスを目指してまいりますので、
    引き続きご愛顧くださいますようお願い申し上げます。
    むー、なんだか回答のポイントがずれているというか、人の言葉を読む気が感じられないというか…。
    「~仕様は不便ですので、改善を願います。」に対して「ご連絡いただいたように~仕様となっております。」というのは会話になっていない。仕様は分かった上でその仕様を改善してくれと言っているのだが。
    言ったから変わるものじゃないとは思うが、「検討します」とか「ご要望に添いかねます」とかの返事が欲しかったんだけどなあ。
    あと求めているのは他国語から他国語ではなく他国語↔英語だけなんだが誤解されてる気がする。2行目を読めば英語がポイントなのは分かるように書いたつもりなのだが。
    ついでに、貼られたヘルプページのURLについて。Yahooのヘルプページは各ページ最下部に問い合わせフォームへのリンクがある。で、自分が問い合わせに飛んだ元がまさにこのURLのページだったのだが。リンク元の情報くらいとっておけばいいのに。

    追記:
    なんとGoogle翻訳がついに直接翻訳できる(場合もある)ようになった。→新しいGoogle翻訳は日本語からドイツ語に翻訳が出来る(場合がある)
      

  • バックスラッシュと円記号の話
    2014年12月20日 02:05

    0x5Cはバックスラッシュですが円記号で表示されます。
    まあ常識ですね。

    その先の話をこまごまと。

    ・韓国では₩
    0x5Cは日本で¥になるのと同様、韓国では₩になる。
    日本語版WindowsにもBatang, Dotum, Gulim, Gungsuh, Malgun Gothicといった韓国語フォントが入っているので試せる。
    なお中国ではどうやらバックスラッシュのままのようだ。

    ・Tahoma
    Tahomaは非Unicodeの頃からWindowsのUIに使われていたフォントなので、たぶん何らかの互換性のための配慮だと思うのだが、不思議な力で特定の状況でだけ0x5Cが¥表示になる。(ならない場面も多く詳細不明)
    これはコントロールパネルの「言語」ではなく、「地域」から設定できるUnicode対応でないプログラムの言語(システムロケール)によるようで、これが日本または韓国に設定されている場合、Tahomaの0x5CはTahomaにFontLinkされた最初のフォントで表示される(場合がある)。
    なので、MS UIGothicのビットマップが気に入らなければメイリオにするとか、Gulimにして₩を見て楽しむとかができる。

    ・Word
    MSOffice Wordには「バックスラッシュを円記号に変換する」設定がある。
    この機能は正確には、特定のフォントで0x5Cを打ち込んだとき、見た目だけを当該フォントの0xA5「¥」で表示するものである。
    表示だけの変更なので、0xA5のグリフで表示された文字をコピーすると0x5Cとしてコピーできる。
    この機能の働くフォントの条件はよく分からないが、MSPゴシック・Gulim・SimSunで効かないところを見ると「漢字圏以外」といったところか。

    ・MacのSafari
    「font-familyにMS系日本語フォントが先行して指定されている」か「HTMLドキュメントの文字コードがレガシーな日本語系文字コードである」場合に0x5Cを0xA5で表示するらしい。
    参考: Mac/iOS Safariでバックスラッシュを円記号として表示する方法 - teppeis blog

    ・余談
    なぜかWindowsのパスや正規表現のエスケープ文字としての0x5Cが0xA5で書かれているブログ記事がたまにあって不思議なのだが、何か特定のブログシステムが勝手に変換しているのではないかとにらんでいる。