String.format (%s, %d) für Nummern

[uberl]

Ich habe gesehen, dass ein String.format("%d", 1) von der eingestellten Locale abhängt - ein String.format("%s", 1) nicht.

Sollte man daher %s für Nummern verwenden, wenn die Locale irgendwo geändert werden kann ?

Wie lässt sich dann eine Nummer formattieren, OHNE Einfluss der Locale ?

 

[Marcinek]

Aber das ist doch ein Vorteil oder?

Ich möchte, dass meine Zahlen in meiner Local formatiert werden.

 

[Tomate_Salat]

String.format(Locale.GERMANY,"%d",1);

%s verwendet man für Zeichenketten ;-)

[edit]

Ich möchte, dass meine Zahlen in meiner Local formatiert werden.

Nicht immer. Wenn man z.B. damit einen SQLQuery so zusammenbaut, möchte man in so manch einem Fall keine Deutsche formatterung, da es sonst kracht. [/edit]

 

[Timothy Truckle]

Wie lässt sich dann eine Nummer formattieren, OHNE Einfluss der Locale ?

Wer hätte gedacht, dass Java eine Klasse [JAPI]NumberFormat[/JAPI] mitbringt?

bye
TT

 

[uberl]

>>> Nicht immer. Wenn man z.B. damit einen SQLQuery so zusammenbaut, möchte man in so manch einem Fall keine Deutsche formatterung, da es sonst kracht.

Genau !

Aber es spricht nichts gegen String.format("%s", 1) ?

 

[Timothy Truckle]

>>> Nicht immer. Wenn man z.B. damit einen SQLQuery so zusammenbaut, möchte man in so manch einem Fall keine Deutsche formatterung, da es sonst kracht.

NAAAIIIINNNN!!!!
Wenn man eine SQL-Query zusammen baut möchte man Bind-Parameter verwenden, sonst haut einen der SQL-Injektor!

bye
TT

 

[Tomate_Salat]

Genau !

Wobei das nur ein Beispiel war. Wenn man kann, sollte man lieber Prepared Statements verwenden ;-)

Aber es spricht nichts gegen String.format("%s", 1)

Ja und nein. Es ist so sinnvoll wie folgendes:

String alter="1";

Ich würde schon darauf achten, dass der Typ passt. Wenn du dir das angewöhnst und in andere Sprachen übernimmst, kann es sein, dass es kracht (c++ ist da afair strenger).

NAAAIIIINNNN!!!!
Wenn man eine SQL-Query zusammen baut möchte man Bind-Parameter verwenden, sonst haut einen der SQL-Injektor!

Ich dachte mir schon, dass das kommt. Du weißt was ein Beispiel ist ;-)? Naja, dass es keine gute Idee ist, hab ich in diesem Post auch nochmal im ersten Satz geschrieben.

 

[uberl]

Ich möchte nur nicht immer die Locale mit angeben müssen, wenn ich einen String erzeugen will, welcher die Zahl "1" immer unabhängig von ihrer Locale darstellen soll. Daher muss ich doch String.format("%s", 1) verwenden ?

 

[nillehammer]

Aber es spricht nichts gegen String.format("%s", 1) ?

Nein, dagegen spricht überhaupt nichts. Aber es wird ja eine Darstellung geben, die Du Dir wünschst. Um bei dem Beispiel Query-String zu bleiben wäre das die englische Darstellung und da kann man ja die entspr. Locale so mitgeben.

 

[Timothy Truckle]

Ich dachte mir schon, dass das kommt. Du weißt was ein Beispiel ist ;-)?

Schon, aber bei SQL-Parameter per String-Konkatination kenne ich keine Freunde! :noe:

Naja, dass es keine gute Idee ist, hab ich in diesem Post auch nochmal im ersten Satz geschrieben.

zu spät... ueh:

bye
TT

 

[uberl]

Nein, dagegen spricht überhaupt nichts. Aber es wird ja eine Darstellung geben, die Du Dir wünschst. Um bei dem Beispiel Query-String zu bleiben wäre das die englische Darstellung und da kann man ja die entspr. Locale so mitgeben.

Ist das für so einen Fall die gängige Vorgansweise in Java ? (Komme von C)

 

[faetzminator]

Man verwendet ein [japi]PreparedStatement[/japi].

 

[uberl]

Man verwendet ein [japi]PreparedStatement[/japi].

Mal abgesehen von einem SQL-Query...

 

[Tomate_Salat]

Man verwendet ein PreparedStatement .

Sofern es von der DB unterstütz wird </klugscheismodus>

@TO: Geht es hier überhaupt um SQLs?

 

[faetzminator]

Einen String in einen int verwandeln? [c]Integer.parseInt(String)[/c]
Einen String in einen Integer verwandeln? [c]Integer.valueOf(String)[/c]
Edit: int in String? [c]String.valueOf(int)[/c]

 

[Timothy Truckle]

Sofern es von der DB unterstütz wird </klugscheismodus>

welche DB unterstützt den PreparedStatements nicht?
(nein, Access lasse ich nicht gelten...)

bye
TT

 

[uberl]

Sofern es von der DB unterstütz wird </klugscheismodus>

@TO: Geht es hier überhaupt um SQLs?

Nein es geht nicht um SQLs, sondern nur um das Erzeugen eines Strings mit einer Nummer, welche unabhängig der eingestellten Locale immer gleich dargestellt werden soll.

 

[nillehammer]

Ist das für so einen Fall die gängige Vorgansweise in Java ? (Komme von C)

Bei Umwandlung von Strings in andere Datentypen und umgekehrt würde ich bei technischen Parametern eher andere Methoden verwenden (z.B. siehe auch faetzminator's letzter Post). Vielfach bieten die Frameworks auch entsprechende transparente Konversionen an. PreparedStatement ist ein Beispiel solch einer transparenten Konversion. Du setzt programmatisch einen int und ein SQL-String wird an die DB gesendet. Ähnliches gibt es auch in Web-Frameworks für die Konversion von Request-Parametern.

Bleibt noch die Anzeige auf einer GUI oder in Logs. Da würde ich im Zweifel die Locale explizit setzen.

 

[Timothy Truckle]

Bleibt noch die Anzeige auf einer GUI oder in Logs. Da würde ich im Zweifel die Locale explizit setzen.

Log ja, GUI nein.

Ich bin ja der Meinung, dass das OS aus einem bestimmten Grund auf ein bestimmtes Locale eingestellt ist.

Aber vielleicht interpretiere ich da einfach zu viel hinein...

bye
TT

 

[uberl]

Einen String in einen int verwandeln? [c]Integer.parseInt(String)[/c]
Einen String in einen Integer verwandeln? [c]Integer.valueOf(String)[/c]
Edit: int in String? [c]String.valueOf(int)[/c]

Ich nehme an, dass dies Java dann implizit macht (bzw auch ein toString()), wenn ich String.format("%s", 1) aufrufe

 

[uberl]

Bei einem

String.format("%d", 1)

gibt es ja das Problem, dass wenn irgendwer die Locale global umsetzt, dann würde der String nicht mehr passen.

 

[Timothy Truckle]

gibt es ja das Problem, dass wenn irgendwer die Locale global umsetzt, dann würde der String nicht mehr passen.

Wozu passen?

bye
TT

 

[uberl]

Ich meine die Darstellung der '1' im String.

 

[nillehammer]

Log ja, GUI nein.

Ich bin ja der Meinung, dass das OS aus einem bestimmten Grund auf ein bestimmtes Locale eingestellt ist.

Aber vielleicht interpretiere ich da einfach zu viel hinein...

Ja, bei GUI eher nicht. Wollte es aber nicht gänzlich ausschließen. Habe deswegen auch "im Zweifel" geschrieben.

 

[Timothy Truckle]

Ich meine die Darstellung der '1' im String.

Ich stelle mich mal ganz dumm und sage:
Die Darstellung der 1 im String hängt doch gar nicht vom Locale sondern vom Font ab.

Das Locale kommt doch erst in's Spiel, wenn die Zahl größer 999 wird oder Nachkommastellen hat.

bye
TT

 

[uberl]

Ich stelle mich mal ganz dumm und sage:
Die Darstellung der 1 im String hängt doch gar nicht vom Locale sondern vom Font ab.

Das Locale kommt doch erst in's Spiel, wenn die Zahl größer 999 wird oder Nachkommastellen hat.

bye
TT

zb folgendes Beispiel :

String.format(new Locale("hi", "IN"), "%d", 1234)

 

[Timothy Truckle]

zb folgendes Beispiel :

String.format(new Locale("hi", "IN"), "%d", 1234)

Dann stelle ich meine Frage nochmal: Welche Anforderung verlangt, dass die Zahl unabhängig vom Locale formatiert wird? Gibt's da 'nen harten Business-Case oder sieht das nur besser aus?

bye
TT

 

[uberl]

zb. eine Reihe von IP-Adressen, welche dann in einer Schleife für Requests verwendet werden:
192.168.0.10 ... 192.168.0.20

for(int i=10; i<20; i++) {
   String ip = String.format("192.168.0.%s", i);
   //...
}

 

[faetzminator]

Ich nehme an, dass dies Java dann implizit macht (bzw auch ein toString()), wenn ich String.format("%s", 1) aufrufe

Kann sein. Trotzdem ist dies nicht der gängige Weg. Conversion hat einfach absolut nichts mit Locale-spezifischer Darstellung zu tun. Dementsprechend kann höchstwarscheinlich [c]Integer.valueOf()[/c] auch kein [c]1,2[/c] parsen - weiss ich aber nicht im Detail (weil wir aus der CH '.' statt ',' als Dezimaltrennzeichen verwenden, was in den Programmiersprachen auch dem normalen Trennzeichen entspricht).

Edit: Randanmerkung zu [c]String.format()[/c] -> noch nie benutzt in 7 Jahren Java.

 

[Tomate_Salat]

@TO: Wo hast du den da Probleme? Integers sind afaik unabhängig von den Spracheinstellungen. Einen Unterschied macht wohl eher folgendes:
[c]String.format("var alpha=%f;",10.5);[/c]
Das könnte z.b. aus einem Script kommen, dass du rennen lassen willst (um mal vom SQL wegzukommen). Da wäre es erforderlich, das Local.ENGLISH zu setzen.

 

[Timothy Truckle]

zb. eine Reihe von IP-Adressen, welche dann in einer Schleife für Requests verwendet werden:
192.168.0.10 ... 192.168.0.20

for(int i=10; i<20; i++) {
   String ip = String.format("192.168.0.%s", i);
   //...
}

Naja, da stellt sich dass Locale-Problem ja eigentlich nicht...
Aber wenn Du sowieso echte Netzwerkzugriffe vor hast könntest Du auch das nehmen:
http://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html#getByAddress(byte[])

bye
TT

 

[uberl]

Naja, da stellt sich dass Locale-Problem ja eigentlich nicht...
Aber wenn Du sowieso echte Netzwerkzugriffe vor hast könntest Du auch das nehmen:
http://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html#getByAddress(byte[])

bye
TT

aber im Falle von:

for(int i=10; i<20; i++) {
   String ip = String.format("192.168.0.%d", i);
   //...
}

gibt es das Problem.

 

[faetzminator]

Dann stelle ich meine Frage nochmal: Welche Anforderung verlangt, dass die Zahl unabhängig vom Locale formatiert wird? Gibt's da 'nen harten Business-Case oder sieht das nur besser aus?

aber im Falle von:

for(int i=10; i<20; i++) {
   String ip = String.format("192.168.0.%d", i);
   //...
}

gibt es das Problem.

Wir sprechen hier immer noch von einer Conversion von 4 byte (bzw. short / int) in eine IP. Hat immer noch nichts mit einer Locale zu tun.
Was ist nun dein tatsächliches Business Case?

 

[uberl]

Ich habe erfahren, dass ich mit String.format("192.168.0.%d", 1) aufpassen muss, welche Locale gesetzt ist, damit der erzeugte String auch wirklich die "1" darstellt (verwende ich zB Locale("hi", "IN") dann kommt mir die "1" in der anderen Sprache raus und ich kann den resultieren String dann nicht mehr verwenden)

Daher möchte ich gerne erfahren, ob es hier in JAVA eine Best-Practice gibt.

Ich kann ja auch noch einfach Concat nehmen: "192.168.0." + 1

 

[Timothy Truckle]

Daher möchte ich gerne erfahren, ob es hier in JAVA eine Best-Practice gibt.

Die Best Practice zum verwalten von Internetadressen ist die Klasse [JAPI]InetAddress[/JAPI] und deren Ableitungen.

Aber Du hast Dich ja entschieden, diesen Hinweis zu ignorieren...ueh:

bye
TT

 

[Tomate_Salat]

Tatsächlich:

String.format(new Locale("hi","IN"), "%d", 1)

damit hab ich auf der Console ein [c]?[/c]

Ich kann ja auch noch einfach Concat nehmen: "192.168.0." + 1

So würde ich es lösen. In Java habe ich afair nie ein String.format genutzt (wohingegen ich es in C++ intensiver nutze)

@Timothy Truckle: Ich bin mir nicht sicher, ob das Beispiel mit der IP tatsächlich der Anwendungsfall war ;-).

 

[Timothy Truckle]

@Timothy Truckle: Ich bin mir nicht sicher, ob das Beispiel mit der IP tatsächlich der Anwendungsfall war

Ich schon:

zb. eine Reihe von IP-Adressen, welche dann in einer Schleife für Requests verwendet werden:
192.168.0.10 ... 192.168.0.20

bye
TT

 

[Tomate_Salat]

könnte sein, muss aber nicht. Da steht ein zb ("zum Beispiel") davor. Aber darüber zu streiten macht wenig Sinn, die Antwort kennt nur der TO .