I use ICSharpCode.SharpZipLib.dll for zip my software file. in file path exist some character contain other language like persian and after zipping file, that turn to ? character an this makes some problem as Illegal characters in path.
C:\Program Files\my software\?.zip
Now how can I fix it?
Set the IsUnicodeText to true for each ZipEntry:
var newEntry = new ZipEntry(entryName)
{
DateTime = DateTime.Now,
Size = content.Length,
IsUnicodeText = true
};
Related
The Delphi DPROJ file contains an AppType XML tag-pair, for example:
<AppType>Application</AppType>
...where the value of AppType could be: 'Application', 'Library', 'Package', etc. etc.
Where is a comprehensive list of all possible AppType values?
Also, in some cases, the AppType XML tag-pair is missing or is empty in the DPROJ file. What are the conditions to make the AppType XML tag missing from the DPROJ file?
There are some constants declared in ToolsAPI.pas:
{ Default IDE application/project types }
sApplication = 'Application';
sLibrary = 'Library';
sConsole = 'Console';
sPackage = 'Package';
sStaticLibrary = 'StaticLibrary';
sOptionSet = 'OptionSet';
// sAndroidService = 'AndroidService';
This list may be extended in the future.
With the TextField Formatter add-on for Vaadin 8, I can do the following to allow only upper-case characters:
Options options = new Options();
options.setBlocks(dataLen);
if (format[1].equalsIgnoreCase("UPPER"))
options.setForceCase(ForceCase.UPPER);
new CustomStringBlockFormatter(options).extend(field);
However, after setting forced uppercase I can't enter space characters any longer. Does anyone how I can allow spaces as well as forced upper case characters?
The TextField Formatter add-on doesn't support arbitrary groupings.The setBlocks in method in Options determines the fixed space-separated groups, so you can specify e.g. options.setBlocks(3,3,2) to allow entering text in the format of XXX XXX XX. If you want to allow only capitals, but spaces allowed in the middle in any position, like so that both HELLO WORLD and HI WORLD are allowed, you can use a CSS trick to set the letters print in all uppercase. Add the following rule in your theme .scss file:
input.upper-textfield {
text-transform:uppercase;
}
and define your TextField without a formatter, like this:
TextField textField = new TextField("only upper");
textField.setStyleName("upper-textfield");
textField.setMaxLength(dataLen);
Now you just need to remember to change the text to uppercase in Java as well when you read it:
String value = textField.getValue();
if (value != null) {
value = value.toUpperCase();
}
How can I set ios application supported languages?
e.g I use NSDate to get current day. If the device language is other than my supported languages NSDateFormatter returns "day" in device's language but I want to get in English if I don't support that language.
I know there is a way to get day in specific language using NSLocal but I don't want to do that way because I need to convert other strings as well.
The Apple documentation covers this pretty clearly. I know all you need is the word "day", but the following will help you include any word for any language if you do as follows:
1) You need to place all of the words (Strings) in your application into a single .swift file. Each word should be returned in a function that converts this string into the localized string per the device's NSLocal set in the device settings:
struct Localization {
static let all: String = {
return getLocalized("All")
}()
static let allMedia: String = {
return getLocalized("All Media")
}()
static let back: String = {
return getLocalized("Back")
}()
// ...and do this for each string
}
2) This file should also contain a static function that will convert the string:
static func getLocalized(_ string: String) -> String {
return NSLocalizedString(string, comment: "")
}
Here, the NSLocalizedString( method will do all of the heavy lifting for you. If will look into the .XLIFF file (we will get to that) in your project and grab the correct string per the device NSLocale. This method also includes a "comment" to tell the language translator what to do with the "string" parameter you passed along with it.
3) Reviewing all of the strings that you placed in your .swift file, you need to include each of those into an .XLIFF file. This is the file that a language expert will need to go over and include the proper translated word per string in the .XLIFF. As I stated before, this is the file that once included inside your project, the NSLocalizedString( method will search this file and grab the correct translated string for you.
And that's it!
So, I'm localizing an app from japanese to english.
In japanese, there is no distinction between (say) "Mr." and "Ms."(/"Mrs."), so I need to do something like this:
/* Salutation format for user (male) */
"%#様" = "Mr. %#";
/* Salutation format for user (female) */
"%#様" = "Ms. %#";
As you can see, the Japanese localization uses the same string in both cases. I was under the impression that, when the strings file contains more than one entry with the same 'source' (i.e., left side) string, the 'comment' was used to determine which one was employed. It turns out I was wrong, and the comment parameter is just an aid for human translators, totally ignored by NSLocalizedString().
So if I run the app, both of the code paths below produce the same string, regardless of the user's gender:
NSString* userName;
BOOL userIsMale;
/* userName and userIsMale are set... */
NSString* format;
if(userIsMale){
// MALE
format = NSLocalizedString(#"%#様",
#"Salutation format for user (male)");
}
else{
// FEMALE
format = NSLocalizedString(#"%#様",
#"Salutation format for user (female)");
}
NSString* salutation = [NSString stringWithFormat:format, userName];
So, how should I deal with a case like this?
Well, actually “left side” of the NSLocalizedString is a key. So you could do something like:
NSLocalizedString(#"SalutForUserMale", #"Salutation format for user (male)");
NSLocalizedString(#"SalutForUserFemale", #"Salutation format for user (female)");
Then in your base *.strings file (Japanese I presume) you would have:
"SalutForUserMale" = "%#様";
"SalutForUserFemale" = "%#様";
And in your English *.strings file you would have:
"SalutForUserMale" = "Mr. %#";
"SalutForUserFemale" = "Ms. %#";
The Localizable.strings files are nothing more than key value lists. You are using the Japanese phrases as keys which is unusual but I guess it works. I assume this is because the original app was developed in Japanese(?). I usually use English phrases keys, but whatever.
The point is that if you want two different phrases in even just one translation you have to have two different keys in all your translations. If there is something in your base language that is not distinguished but in the translations it is, then you can just "split" an existing key in two new ones. Just change it slightly or add a number, see below:
/* english .strings file */
"hello_world_key" = "Hello World";
"Yes1" = "Yes"; // same in english but different values in german
"Yes2" = "Yes";
/* german .strings file */
"hello_world_key" = "Hallo Welt";
"Yes1" = "Ja";
"Yes2" = "Jawohl";
I have path Manipulation problem. The following code is placed in Page_load method of ASPx page.
String rName = Request.QueryString["reportName"];
string path = "C:\\hari" + rName;
if (File.Exists(path))
{
File.Delete(path);
}
But Fortify scan report for the above sample code shows ‘Path Manipulation’ issue as high
Need help to modify above code so that it can pass fortify scan
Jackson is right, this is a direct File Path Manipulation vulnerability that can be fixed through indirect selection.
From your known directory, list all the files. Use the value coming from your own directory list, not the user-supplied value.
String rName = Request.QueryString["reportName"];
String knownPath = "C:\\hari";
DirectoryInfo di = new DirectoryInfo(knownPath);
FileInfo[] files = di.GetFiles(rName);
if (files.length > 0)
{
files[0].Delete();
}
I think the problem is that someone could spoof a request with reportName = "..\\Windows\\Something important" which is clearly a security flaw. You need to change your code so that it doesn't read a partial filename from the request query string.