これが外見の問題なのか、それとも変容の問題なのかを判断する必要があります。また、これが文字レベルのセマンティクスまたは数字表現を含む質問であるかどうかを判断する必要があります。これが私の考えです：
Unicodeが数字のコードを分離していなかった場合、質問のセマンティクスはまったく異なります。次に、必要に応じてさまざまなグリフを表示するには、適切なフォントを使用するだけです。一方、フォントを変更せずに、以下のように単純に異なる文字を書き出すことはできなかったでしょう。（フォントは必ずしも32ビットUnicodeセットはもちろん、16ビットUnicodeセットの全範囲をカバーしているわけではないため、状況は完全ではありません。）
9, ٩ (Arabic), ۹ (Urdu), 玖 (Chinese, complex), ๙ (Thai), ௯ (Tamil) etc.
ここで、Unicodeセマンティクスを受け入れると仮定すると、つまり「9」、「٩」、および「۹」は別個の文字であると仮定すると、問題は外観（CSSの範囲内にあったもの）ではなく、変換-これについては後でいくつか考えますが、今のところ、これが当てはまると仮定しましょう。文字レベルのセマンティクスに焦点を当てる場合、状況はアルファベットや文字で起こることとそれほど異ならない。たとえば、ラテン語のアルファベットはEuboeaで使用されているギリシャ語のアルファベットとほぼ同じですが、ギリシャ語の「α」とラテン語の「a」は別個のものと見なされます。おそらくさらに劇的なことに、対応する大文字のバリエーションである「Α」（ギリシャ語）と「A」（ラテン語）は、両方のスクリプトをサポートする実質的にすべてのフォントで視覚的に同一です。
基本ルールを述べたので、それらを無視することによって、特に（文字レベルの）Unicodeセマンティクスを無視することによって、質問にどのように答えることができるかを見てみましょう。
（恐ろしく、厄介で、下位互換性がありません）解決策： 「0」から「9」を目的のグリフにマップするフォントを使用します。私はそのようなフォントを知りません。あなたは@font-faceとあなたが望むことをするために適切にハッキングされたいくつかのフォントを使わなければならないでしょう。
言うまでもなく、私はこのソリューションが特に好きではありません。ただし、サーバー側またはクライアント側のいずれかで「文字コードを変更せずに」質問が行うことを実行するのは、私が知っている唯一の単純なソリューションです。（技術的に言えば、以下で提案するCufonソリューションは文字コードも変更しませんが、テキストをキャンバスに描画することは非常に複雑であり、オープンソースコードを微調整する必要があります）。
注： 変換ソリューション、つまりDOMを変更し、「0」から「9」の範囲の文字を置き換えるソリューション。たとえば、アラビア語に相当するものは、数字がDOMの元の形式で表示されることを期待するコードを壊します。もちろん、この問題は、フォームと入力について議論するときに最悪です。
変革的アプローチを採用した回答の例は次のとおりです。
$("[lang='fa']").find("*").andSelf().contents().each(function() {
if (this.nodeType === 3)
{
this.nodeValue = this.nodeValue.replace(/\d/g, function(v) {
return String.fromCharCode(v.charCodeAt(0) + 0x0630);
});
}
});
注：VisioNの2番目のjsFiddleから取得したコード。これがあなたが好きなこの答えの唯一の部分であるならば、あなたが私のものではなく、VisioNの答えに賛成することを確認してください!!! :-)
これには2つの問題があります。
- これはDOMを混乱させ、その結果、「標準」形式の数字（数字の「0」から「9」を使用）が見つかると想定して機能していたコードを壊す可能性があります。ここで問題を参照してください：http：//jsfiddle.net/bKEbR/10/ たとえば、ユーザーが入力した整数の合計を含むフィールドがある場合、その値を取得しようとすると驚かれるかもしれません。 ..
- 要素の内部
input（および）で何が起こっているのかという問題には対処していません。textarea入力フィールドがたとえば「42」で初期化されている場合、その値が小売りされます。これは簡単に修正できますが、実際の入力の問題があります...文字が来たら変更したり、変更したときに値を変換したりすることもできます。このような変換を行う場合は、クライアント側とサーバー側の両方で、さまざまな種類の数字を処理できるように準備する必要があります。Javascript、jQuery、さらにはGlobalize（クライアント側）、ASP.NET、PHPなど（サーバー側）の箱から出てくるものは、非標準形式の数字を入力すると壊れます...
もう少し包括的な解決策（input / textarea要素、それらの初期値とユーザー入力の両方にも注意を払う）は次のようになります。
//before the DOM change, test1 holds a numeral parseInt can understand
alert("Before: test holds the value:" +parseInt($("#test1").text()));
function convertNumChar(c) {
return String.fromCharCode(c.charCodeAt(0) + 0x0630);
}
function convertNumStr(s) {
return s.replace(/\d/g, convertNumChar);
}
//the change in the DOM
$("[lang='fa']").find("*").andSelf().contents()
.each(function() {
if (this.nodeType === 3)
this.nodeValue = convertNumStr(this.nodeValue);
})
.filter("input:text,textarea")
.each(function() {
this.value = convertNumStr(this.value)
})
.change(function () {this.value = convertNumStr(this.value)});
//test1 now holds a numeral parseInt cannot understand
alert("After: test holds the value:" +parseInt($("#test1").text()))
jsFiddle全体はここで見つけることができます：http：//jsfiddle.net/bKEbR/13/
言うまでもなく、これは前述の問題を部分的にしか解決しません。クライアント側および/またはサーバー側のコードは、非標準の数字を認識し、それらを標準形式または実際の値に適切に変換する必要があります。
これは、数行のjavascriptで解決できる単純な問題ではありません。そして、これは、ある形式の数字から別の形式に移行するために適用する必要がある単純な文字から文字へのマッピングがあるため、このような可能な変換の最も単純なケースにすぎません。
もう1つは、外観ベースのアプローチです。
Cufonベースのソリューション（過剰な、下位互換性がない（キャンバスが必要）など）： Cufonのようなライブラリを比較的簡単に調整して、想定されていることを実行できます。Cufonはその機能を実行し、キャンバスオブジェクトにグリフを描画できます。ただし、要素に特定のプロパティがある場合、通常選択されているグリフの代わりに目的のグリフが使用されるように調整します。Cufonやその他の種類のライブラリは、DOMに要素を追加し、既存の要素の外観を変更する傾向がありますが、テキストには触れないため、変換アプローチの問題は適用されません。実際、（微調整された）Cufonは、DOM全体に関する限り、明らかに変革的なアプローチを提供しますが、その精神性に関する限り、外観ベースのソリューションであることに注意してください。私はそれをハイブリッドソリューションと呼んでいます。
代替ハイブリッドソリューション： アラビア語のコンテンツを使用して新しいDOM要素を作成し、古い要素を非表示にしますが、IDとコンテンツはそのままにします。アラビア語のコンテンツ要素を、対応する非表示の要素と同期します。
ボックスの外側を考えてみましょう（ボックスは現在のWeb標準です）。
特定の文字が一意であるという事実は、それらが無関係であることを意味するものではありません。また、必ずしも外観の違いであるとは限りません。たとえば、「a」と「A」は同じ文字です。ある文脈ではそれらは同じであると見なされ、他の文脈では異なると見なされます。Unicode（およびその前のASCIIとISO-Latin-1など）の違いは、それを克服するためにいくらかの努力が必要であることを意味します。CSSは、大文字と小文字をすばやく簡単に変更する方法を提供します。たとえばbody {text-transform:uppercase}、ページ本文のテキスト内のすべての文字を大文字に変換します。これは、変換ではなく外観変更の場合でもあることに注意してください。body要素のDOMは変更されず、レンダリング方法だけが変更されます。
注： CSSがそのようなものをサポートしていればnumerals-transform: 'ar'、それが表現されていたので、おそらくその質問に対する理想的な答えだったでしょう。
ただし、CSS委員会にこの機能を追加するように急ぐ前に、それが何を意味するのかを検討することをお勧めします。ここでは、小さな問題に取り組んでいますが、全体像に対処する必要があります。
出力：この数字変換機能は、「10」（2文字）を10（中国語、単純）、15（中国語、複雑）、X（ラテン）（すべて1文字）などとして表示できるようにしますか？ 'ar'の、適切な引数が与えられましたか？
入力：この数字変換機能は、「十」（中国語、単純）をアラビア語に相当するものに変更しますか、それとも単に「10」をターゲットにしますか？「MMXI」（2012年のラテン数字）が単語ではなく数字であることをどういうわけか巧みに検出し、それに応じて変換しますか？
数の表現の問題は、この質問を見ただけで想像できるほど単純ではありません。
だから、これはどこに私たちを残しますか？
- 単純なプレゼンテーションベースのソリューションはありません。将来登場する場合、下位互換性はありません。
- 今ここに変革の「解決策」があるかもしれませんが、これが私が行ったようにフォーム要素でも機能するようにされたとしても（http://jsfiddle.net/bKEbR/13/）、サーバー側と使用される非標準形式のクライアント側の認識。
- 複雑なハイブリッドソリューションが存在する可能性があります。それらは複雑ですが、場合によってはプレゼンテーションベースのアプローチのいくつかの利点を提供します。
CSSソリューションは素晴らしいでしょうが、実際には、他の数値システム（標準システムとの間の変換が簡単ではない）、小数点、符号などを含む全体像を見ると、問題は大きく複雑です。
結局のところ、現実的で下位互換性があると私が考えるソリューションは、Globalize（およびサーバー側の同等のもの）の拡張であり、ユーザー入力を処理するための追加のコードが含まれている可能性があります。これは文字レベルでは問題ではなく（全体像を考えれば問題ではないため）、千と小数点の違いが処理されたのと同じように処理する必要があるという考え方です。フォーマット/解析の問題として。