ユニコードではなく日本語固有のエンコーディングを使用するように導く問題は何ですか?


24

職場では、Shift-JISなどのエンコーディングの日本語のテキストファイルがたくさんあります。それは多くの原因が文字化け(判読できない文字)すべてのコンピュータユーザのための問題を。Unicodeは、すべての言語に単一の文字セットを定義することでこの種の問題を解決することを目的としており、インターネットでの使用にはUTF-8シリアル化が推奨されます。それでは、なぜ皆が日本語固有のエンコーディングからUTF-8に切り替えないのでしょうか?UTF-8のどのような問題や不利な点が人を引きつけていますか?

編集:W3CはUnicodeに関するいくつかの既知の問題をリストしていますが、これも理由でしょうか?


実際、ますます人気のあるサイトはUTF-8で、1つの例はニコニコ動画とはてな
Ken Li

8
誰もがISO-8851-1からUTF-8に切り替えないのはなぜですか?
ysdx

1
ここで渡すことで、SHIFT-JIS-> UTF-8変換はロスレスではないことが言及されています。これは、すでに使用されているSHIFT-JISを使い続ける主な理由です。しかし、表向きのファクトイドは驚くべきものであることがわかったので、ここでの答えの1つがより詳細になるか、少なくともクレームのソースを提供することを望んでいましたが、どれもありません。
カイルストランド


@LudwigSchulzeありがとう。まだ、多くの詳細が、少なくとも公式のソース...
カイルストランド

回答:


28

一言で言えば、レガシーです。

ユニコードが日本語をエンコードする唯一の方法であったため、Unicodeが利用可能/普及する前にShift-JISおよびその他のエンコーディングが使用されていました。企業は、Shift-JISのみをサポートするインフラストラクチャに投資しています。そのインフラストラクチャは、現在Unicodeをサポートしている場合でも、彼らはまだ至るまで、様々な理由からシフトJISで立ち往生していること-作品-SO-、ドントタッチ、それの上にエンコード-何を?migrating-all-existing-documents-is-too-costly移行します。

同じ理由でまだASCIIまたはlatin-1を使用している多くの西洋の企業がありますが、問題を引き起こしていないので誰も気づきません。


8
日本のソフトウェア業界...新しいソフトウェア/標準を利用するのは汚れより遅い。
マークホサン

2
@Mark Truerの言葉が話されました!(私は日本のIT部門で作業しています... -_- ;;)
11

5
確かに、欧米の企業は、レガシーソフトウェアが1バイト= 1文字というハードコードされた前提に満ちているという言い訳があります。
dan04

@MarkHosangあなたの声明が100%正しいことを確認します(私は東京の日系企業で働いています)
Hassan Tareq

9

これらは、主に日本で開発されているスクリプト言語RubyのUTF-8または別のUnicode表現をデフォルトの文字エンコーディングにしないことを私が覚えていた理由です。

  • 理由1:ハン統一。中国、韓国、日本に使用されている文字セット(ここで「アルファベット」が正しいかどうかはわかりません)は共通の歴史から発展したもので、詳細はわかりません。Unicodeコンソーシアムは、3つの言語すべてで外観が異なっていても、単一のUnicodeコードポイントのみを使用して、歴史的な同じ文字のすべてのバリアント(中国語、日本語、韓国語)をエンコードすることを決定しました。その理由は、テキストの表示に使用されるフォントによって外観を決定する必要があるということです。

どうやら、この推論は、ラテン語のアルファベットがギリシャ語のアルファベットから発展したので、ギリシャ語のアルファの単一のコードポイントを持っているだけで十分であると英語の読者に主張するのと同じくらい、日本のユーザーにとってばかげていると思われますα」およびラテン語「a」。使用するフォントによって外観を決定します。(「β」=「b」、「γ」=「g」などに同じ)

(スタックエクスチェンジの場合、ギリシャ文字をここに含めることはできないことに注意してください。)

  • 理由2:非効率的な文字変換。 文字をUnicodeから従来の日本語エンコーディングに変換し、逆変換するにはテーブルが必要です。つまり、Unicodeコードポイント値から従来のコードポイント値へ、またはその逆への単純な計算はありません。また、あるエンコーディングのすべてのコードポイントが他のエンコーディングで一意の表現を持っているわけではないため、変換時に情報がいくらか失われます。

私はもう覚えていないというより多くの理由が与えられたかもしれません。


2.0以降、RubyはデフォルトとしてUTF-8を採用したようです。しかし、漢語の統一はユニコードの世界では本当に重要なしわ(非常に物議を醸す問題)のようです。
カイルストランド

そして、ここにハン統一問題に関するウィキペディアの記事があります:en.wikipedia.org/wiki/Han_unificationそれは確かに有効な問題のようです、素晴らしい答えです!また、日付の損失は正当な理由でしょう。
spbnick

8

decezeの答えには非常に強い真実の要素がありますが、Shift-JISなどがまだ使用されているもう1つの理由があります。UTF -8は、一部の言語、ほとんどの場合CJKセットで恐ろしく非効率的です。Shift-JISはIIRCの2バイト幅のエンコードですが、UTF-8は通常、CJKなどのエンコードでは3バイト、場合によっては4バイトです。


7
それは事実ですが、Shift-JISと同じくらい効率的なUTF-16の代替が常にあります。また、さまざまなエンコーディングを処理する際の頭痛の種は、この時代と時代におけるサイズのわずかな増加よりもはるかに大きいと主張します。別の言い方をすれば、私はまだそれを使用している人から Shift-JISの効率の議論を聞いたことがありません。;-)
11

5
しかし、ナマケモノと慣性の言い訳として使用される効率の問題を聞いたことがあります。
ちょうど私の正しい意見

1
UTF-16は、基本的なASCII文字[たとえばHTMLにかなりの数がある]を2倍にします。私が理解しているように、これは実際にUTF-16を日本のWebページのUTF-8よりもさらに悪くすることになります。
Random832

2
@JUST私の正しい意見:「ソースの表示」または同等のものを試してください。すべての実際のテキストが日本語であると仮定すると、英語から派生し、ASCIIで表される多くのキーワードなどが存在する可能性があります。
デビッドソーンリー

4
これは私がそうする理由のように思えるので、後で見つけます。効率性は現状とはまったく関係ありません。私にとっては、ただのinertia性と遺産です。実際、日本人プログラマーによって作成されたコードのほとんどは他の日本人向けであるため、ユニコードのようなものを使用する必要さえ感じないという事実とも関係があると思います。
ジュリアンゲルトー

2

主な理由の中で文字列サイズ/メモリ使用量をカウントします。

UTF-8では、東アジア言語の文字には3バイト以上が必要になることがよくあります。UTF-16を使用する場合よりも平均で50%多くのメモリが必要になります。後者は既にネイティブエンコーディングよりも効率が悪いです。

他の主な理由は、decezeが指摘するように、レガシーです。


2

他の人が言ったように、レガシーとストレージのサイズですが、もう1つあります。カタカナ文字です。

Shift-JISでカタカナ文字を表すのに1バイトしかかからないため、カタカナを含む日本語テキストの文字あたりのバイト数は2バイト未満(50/50の場合は1.5)、Shift-JISはUTF-16(2バイト/ char)、およびUTF-8(3バイト/ char)よりもはるかに効率的です。

安価なストレージにより、これははるかに小さな問題になっているはずですが、明らかにそうではありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.