Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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]
>>> 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) ?
>>> 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.
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.
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 ?
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.
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.
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]
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.
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.
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]
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?
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.
@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.
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?
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?
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